Clean Code by Robert C. Martin

Notes from Uncle Bob's clean code principles.

Published January 15, 2025 ET

You can learn and practice with Leetcode: https://leetcode.com/

Part 1

  • Good code is measured by "WTF"s/minute. The fewer, the better.

  • How many processors in an iPhone?

    • bluetooth, wifi, screen, GPS, main, each have their own processor
    • one iPhone's processing power exceeds the entire processing power available in 1980
  • Says I should read a book called "Implementation Patterns" by Kent Beck

    • says it's based on a "fragile premise", which is that "good code matters"
  • We write messy code because we have to move fast. But as time goes on we can't move fast because the code is messy.

    • You should spend as much time cleaning the code as the time it took you to write it.
    • "the only way to go fast is to go well"
  • Nobody writes clean code on the first time around. You should spend as much time cleaning it as you originally spent writing it.

Quotes from Industry Leaders

Bjarne Stroustrup (inventor of C++):

  • Good code is elegant and efficient
  • "clean code does one thing well"

Grady Booch (chief scientist at Rational):

  • "clean code reads like well-written prose"
  • "clean code always looks like it was written by someone who cares"

Ward Cunningham (invented the wiki, 19 lines of perl, still available at c2.com):

  • "you know you're working on clean code when each routine you read turns out to be pretty much what you expected"

Key Principles

  • C# and Java are the "same language"

  • It is "rude" to have code that operates at different levels of abstraction in the same function. The fundamental rule is "every line of a function should be at the same level of abstraction, and that level should be one below the name"

  • If a variable only exists to give a certain conditionality a clear name then it is known as an explanatory variable

    • example: const isPlanetSmallerThanEarth = planetDiameter < 7917;
    • using variables like this are part of the method you use to make code read like "well-written prose"
  • First rule of functions: they should be small. How small should a function be? How many lines?

    • it used to be that it should fit on your screen (24 lines by 72 columns)
      • 72 lines because the punch card had 80 columns and the last 8 columns were sequence numbers
    • the modern rule is "a function should do one thing"
      • a function "does one thing" if you cannot meaningfully extract another function from it
  • The best IDE is IntelliJ (for Java)

    • Has a menu item "extract method"
  • Switch statements are bad

    • better off using sub-classes, i.e. a "shape" class instead of conditional logic that selectively applies different logic
    • Open-Close Principle: a module should be open for extension but closed for modification. You should be able to extend the behavior of a module without modifying that module

Other Names to Study

Martin Fowler, Niklaus Wirth, Edsger W Dijkstra, Tony Hoare