Clean Functions

The first rule of functions is that they should be small. The second rule of parts is that they should be smaller than that.

Functions should not be large enough to hold nested structures.[¹]

The ideal number of arguments for a function is zero (niladic). Three arguments (triadic) should be avoided where possible. Next comes one (monadic), followed by two (dyadic). More than three (polyadic) require exceptional justification and shouldn’t be used. Even obvious dyadic functions like assert_equals(expected, actual) is problematic. How many times have you put the actual where the expected should be? The two arguments have no natural ordering. The expected, exact order is a convention that requires practice to learn.

To ensure our functions are doing “one thing,” we need to ensure that the statements within our function are all at the same level of abstraction. If your function must change the state of something, have it change the shape of its owning object.

Functions should either do something or answer something, but not both. Either your process should change the state of an object or return some information about that object. Doing both often leads to confusion.

—

[¹]: Robert Martin(2008): (Clean Code: A Handbook of Agile Software Craftsmanship)