Archive Notes

Week 7. Clean Code

1 min read

Clean Code

As technical debt grows and the cost of change grows, the responsiveness to change decreases which in turn may increase technical debt further.

A team may try to avoid technical debt by developing as cleanly as possible.

A simple method to write clean code is:

  1. Write something that works
  2. Refactor your code
Link to original

Naming Things

Naming Things (Clean Code)

  • Use intention revealing names, it is obvious what the variable is used for
  • Avoid disinformation, for example Account[] accountList; (not a list) It’s better to use Account[] accountArray; or better Account[] accounts;
  • Use British English everywhere
  • Make meaningful distinctions between variables
  • Do not include “noise” words such as “variable”, “the”, “data”.
  • Use searchable names
  • Avoid “magic values”; hard-coded constant values
Link to original

Comments

Comments (Clean Code)

  • When possible, explain yourself in code not comments (meaningful names)
  • Useful for documentation generation
  • Required for legal comments
  • May be useful to explain intent (i.e. when using regex)
  • Warnings are useful
  • To-do comments should not be used as an excuse for bad code

Bad comments include:

  • Noise: no meaningful information
  • Redundant information
  • Commented out code
  • Too much or wrong type of information
Link to original

Clean Functions

Functions (Clean Code)

Functions should do one thing, do it well, do it only

  • One level of abstraction per function
  • Functions must not have side effects
  • Functions should have as few arguments as possible
  • Avoid flag arguments, i.e. “boolean isModerator” Instead define two operations if possible.
  • DRY Code
  • Stepdown Rule
  • Command Query Separation Principle
Link to original

Graph View