Untitled.Bat |
Developer, dad & dangerously dopey.....Also awesome at alliteration and assonance . Visit my main website @ http://www.xerxesb.com if you're tech-inclined |
G28: Encapsulate Conditionals - Boolean logic is hard to understand without having to see it in the context of an IF..THEN. Extract the boolean logic into a function which clearly expresses the intention of the conditional from the clause which executes it.
G29: Avoid Negative Conditionals - Negatives are harder to understand than positives. Conditional operations should be expressed as positives where possible.
G30: Functions Should Do One Thing - It is often tempting and easy to create functions that have multiple sections that perform a series of operations. Functions should do one thing and should be split up accordingly.
G31: Hidden Temporal Couplings - Temporal couplings are often necessary, but they should not be hidden. For instance, if one method relies on the execution of another one before it in order to maintain state, there is a temporal coupling between the two (ie: the sequence of calls). The hidden sequence coupling could be broken if a caller doesn’t make the calls in the right order. You can expose temporal couplings like this by making subsequent calls stateless and take in any data they need to work on instead of relying on common state. This makes it clear that there is a coupling between the two methods
G32: Don’t Be Arbitary - If code layout and organisation conventions are followed and maintained throughout the codebase, then there is less chance that people will come along and make arbitary changes against the conventions. If there are arbitary random differences, it empowers people to break conventions.
G33: Encapsulate Boundary Conditions - Boundary conditions are hard to keep track of. Put the processing in them for one place. EG: if the value “Level + 1” is mentioned in a number of places, then encapsulate it in a variable.
G34: Functions Should Desccend Only One Level Of Abstraction - The statements within a finctions should all be written at the same level of abstraction, which should be one level below the operation described by the name of the function. Though it seems simple, humans are just far too good at seamlessly mixing levels of abstraction.
G35: Keep Configurable Data At High Levels - Constants such as defaults or configuration values that are known and expected at a high level of abstraction, should not be buried in a low-level function. They should be exposed to the low-level function by way of a parameter that is passed into it.
G36: Avoid Transitive Navigation - Modules should only know about their immediate collaborators and do not know the navigation map of the whole system. The Law Of Demeter is what prevents getA().getB().getC().Something();. Breaking is is how architectures become rigid - they know too much about other modules and breaking that dependency is difficult.
Clean Code: Chapter 17
Clean Code: Chapter 17