Clean Code Summary – Sample Chapter

clean code

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 the 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

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

Function Arguments

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 of 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 a 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. 



For more on Clean Code Summary


Featured Image credit

Leave a Reply

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