The following is chapter 3 from Clean Code Summary book available from Amazon. It was written and designed for experienced software engineers and managers looking to save time and learn key concepts from the critically acclaimed software engineering book, Clean Code: A Handbook of Agile Software Craftsmanship.
Functions Chapter 3
A function is a type of procedure or routine in computer programs. What makes good functions?
Lines should not be 150 characters long.
Functions should not be 100 lines long.
Functions should hardly ever be 20 lines long.
Blocks and Indenting
Blocks within statements should be one line long.
The indent level of a function should not be greater than one or two.
Do One Thing
The following advice has appeared in one form or another for over 30 years:
Functions should do only one thing and do it well.
One Level of Abstraction per Function
To make sure our functions are doing “one thing,” we need to make sure that the statements within our function are all at the same level of abstraction.
To determine abstraction level, use the “Step Down” rule. This rule is reading the program as though it were a set of TO paragraphs, each of which is describing the current level of abstraction and referencing subsequent TO paragraphs at the next level down.
Making the code read like a top-down set of TO paragraphs is a useful technique for keeping the abstraction level consistent.
Switch statements may be tolerated using the following guidelines:
appear only once
used to create polymorphic objects
hidden behind an inheritance relationship so that the rest of the system can’t see them
Use Descriptive Names
Choosing good names rely on small functions that do one thing. And with this kind of function in place, consider the following:
Don’t be afraid of using long names
Don’t be afraid of spending time to choose a descriptive name
Be consistent in naming
How many arguments should functions allow? The ideal number of arguments is zero (niladic), followed by one (monadic), followed closely by two (dyadic). Avoid three arguments where possible and do not use more than three (polyadic).
Other argument considerations:
Do not use flag arguments such as booleans because it implies the function doing more than one thing
Two arguments make the function more complicated to understand and three arguments even more so
Wrap multiple arguments into a class of their own
Have No Side Effects
Ensure functions have no side effects and especially side effects that include temporal coupling. Temporal coupling creates dependencies between code and timing.
Command Query Separation
Functions should either perform an action or answer a question, but not both.
Prefer Exceptions to Returning Error Codes
And when using exceptions, it’s often preferable to extract try/catch block include into functions.
Don’t Repeat Yourself
Avoid duplication. (For summary version of this principle, check out The Pragmatic Programmer Summary on Amazon)
How do you write functions as previously described? Writing functions within these guidelines doesn’t happen right away. It requires iterating over versions.
Featured Image credit https://flic.kr/p/9V82S5