Untitled.Bat

G19: Use Explanatory Variables - Break up calculations into intermediate values that are held in variables with meaningful names, rather than inlining them. More explanatory variables are generally better than fewer

G20: Function Names Should Say What They Do - Function names should clearly express what the operation will do. If you have to look at the documentation to find out what it does then you should work to find a better name. (eg: date.add(5) - does this add 5 days, 5 minutes? Does is it modify the existing date or does it return a new one?)

G21: Understand The Algorithm - Programming is often an exploration. You think you know the right algorithm to solve a problem but you poke and prod until you get it to work. Once it works though, you *must* spend the time to understand exactly *why* it works. Refactor the function so that it becomes obvious why the implementation works.

G22: Make Logical Dependencies Physical - If one module depends on another, then the dependent module should not make assumptions (aka logical dependencies) about the module it depends upon. Rather, it should explicitly ask the module for all information it depends upon.

G23: Prefer Polymorphism to If/Else or Switch/Case - There may be not more than one switch statmeent for a given type of selection. The cases in that switch statement must create a polymorphic object that takes the place of other such switch statements in the rest of the system.

G24: Follow Standard Conventions - Every team should follow a coding standard based on common industry norms. There should not be a need to document this these conventions because the code provides the examples.

G25: Replace Magic Numbers With Named Constants - It is bad to have raw numbers in your code. You should hide them behind well-named constants. THis allows the code to be more expressible and the intent clearer. This also applies to magic strings.

G26: Be Precise - When you make a decision in your code, make sure you make it precisely. Know why you have made it and how you will deal with exceptions. If you decide to call a function that might return a null, make sure you check for null. Ambiguity and imprecision in code is either a result of disagreements or laziness.

G27: Structure Over Convention - Enforce design decision with structure over convention. Naming conventions are good, but they are inferior to structures that force compliance. For example, switch/cases with nicely named enumerations are inferior to base classes with abstract methods. Noone is forced to implement the switch/case statement the same way each time, but the base classes do enforce that concrete classes have all abstract methods implemented.

Clean Code: Chapter 17