Clean Code

Rules from current article were written by Robert C. Martin, you can find all Clean code rules in his book: Clean Code: A Handbook of Agile Software Craftsmanship

G1: Multiple Languages in One Source File

Today’s modern programming environments make it possible to put many different languagesinto a single source file. For example, a Java source file might contain snippets of XML,HTML, YAML, JavaDoc, English, JavaScript, and so on. For another example, in addition toHTML a JSP file might contain Java, a tag library syntax, English comments, Javadocs,XML, JavaScript, and so forth. This is confusing at best and carelessly sloppy at worst.The ideal is for a source file to contain one, and only one, language. Realistically, wewill probably have to use more than one. But we should take pains to minimize both thenumber and extent of extra languages in our source files.

G2: Obvious Behavior Is Unimplemented

Following “The Principle of Least Surprise,” 2 any function or class should implement thebehaviors that another programmer could reasonably expect. For example,Day day = DayDate.StringToDay(String dayName);We would expect the string “Monday” to be translated to Day.MONDAY . We would also expectthe common abbreviations to be translated, and we would expect the function to ignorecase.When an obvious behavior is not implemented, readers and users of the code can nolonger depend on their intuition about function names. They lose their trust in the originalauthor and must fall back on reading the details of the code.

G3: Incorrect Behavior at the Boundaries

It seems obvious to say that code should behave correctly. The problem is that we seldomrealize just how complicated correct behavior is. Developers often write functions thatthey think will work, and then trust their intuition rather than going to the effort to provethat their code works in all the corner and boundary cases.There is no replacement for due diligence. Every boundary condition, every cornercase, every quirk and exception represents something that can confound an elegant andintuitive algorithm. Don’t rely on your intuition. Look for every boundary condition andwrite a test for it.

G4: Overridden Safeties

Chernobyl melted down because the plant manager overrode each of the safety mecha-nisms one by one. The safeties were making it inconvenient to run an experiment. Theresult was that the experiment did not get run, and the world saw it’s first major civiliannuclear catastrophe.It is risky to override safeties. Exerting manual control over serialVersionUID may benecessary, but it is always risky. Turning off certain compiler warnings (or all warnings!)may help you get the build to succeed, but at the risk of endless debugging sessions. Turn-ing off failing tests and telling yourse.

G5: Duplication

This is one of the most important rules in this book, and you should take it very seriously.Virtually every author who writes about software design mentions this rule. Dave Thomasand Andy Hunt called it the DRY 3 principle (Don’t Repeat Yourself). Kent Beck made itone of the core principles of Extreme Programming and called it: “Once, and only once.”Ron Jeffries ranks this rule second, just below getting all the tests to pass.Every time you see duplication in the code, it represents a missed opportunity forabstraction. That duplication could probably become a subroutine or perhaps anotherclass outright. By folding the duplication into such an abstraction, you increase the vocab-ulary of the language of your design. Other programmers can use the abstract facilities you create. Coding becomes faster and less error prone because you have raised theabstraction level. The most obvious form of duplication is when you have clumps of identical code thatlook like some programmers went wild with the mouse, pasting the same code over andover again. These should be replaced with simple methods.A more subtle form is the switch / case or if / else chain that appears again and again invarious modules, always testing for the same set of conditions. These should be replacedwith polymorphism.Still more subtle are the modules that have similar algorithms, but that don’t sharesimilar lines of code. This is still duplication and should be addressed by using the T EMPLATE METHOD , or STRATEGY pattern.Indeed, most of the design patterns that have appeared in the last fifteen years are sim-ply well-known ways to eliminate duplication. So too the Codd Normal Forms are a strat-egy for eliminating duplication in database schemae. OO itself is a strategy for organizingmodules and eliminating duplication. Not surprisingly, so is structured programming.I think the point has been made. Find and eliminate duplication wherever you can.

Leave a Reply

Your email address will not be published. Required fields are marked *