A blog about teaching Programming to non-CompSci students by Tim Love (Cambridge University Engineering Department). I do not speak on behalf of the university, the department, or even the IT group I belong to.

Thursday, 20 April 2017

"The Clean Coder" by Robert C. Martin (Pearson Education, 2011)

The full title is "The Clean Coder: a code of conduct for professional programmers". "In the pages of this book I will try to define what it means to be a professional programmer. I will describe the attitudes, disciplines, and actions that I consider to be essentially professional" (p.2)

The book contains many opinions, some repeated. I'll organise the quotes into sections.


  • "It is not your employer's responsibility to train you, or to send you to conferences, or to buy you books" (p.16)
  • "Good managers crave someone who has the guts to say no. It's the only way you can really get anything done" (p.26)
  • "Here are some examples of words and phrases to look for that are telltale signs of noncommitment: ... "We need to get this done" ... "I hope we can meet again some day" ... "Let's finish this thing" (p.48)
  • "when professionals say yes, they use the language of commitment so that there is no doubt about what they've promised" (p.56)
  • "Professional development organisations allocate projects to existing gelled teams, they don't form teams around projects" (p.170)

Working practises

  • "The only way to prove that your software is easy to change is to make easy changes to do. And when you find that the changes aren't as easy as you thought, you refine the design so that the next change is easier" (p.15)
  • "Why do most developers fear to make continuous changes to their code? They are afraid they'll break it! Why are they afraid they'll break it? Because they don't have tests!" (p.15)
  • "When you have a suite of tests that you trust, then you lose all fear of making changes. When you see bad code, you simply clean it up on the spot ... the code base steadily improves instead of the normal rotting that our industry has become used to" (p.81)
  • "Here is a minimal list of the things that every software professional should be conversant with:
    • Design patterns. You ought to be able to describe all 24 patterns in the GOF book and have a working knowledge of many of the patterns in the POSA books.
    • Design principles. You should know the SOLID principles and have a good understanding of the component principles
    • Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design
    • Disciplines. You should practice TTD, Object-Oriented design, Structured Programming, Continuous Integration, and Pair Programming
    • Artifacts: You should know how to use: UML, DFDs, Structured Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables
    " (p.18)
  • "If you are tired or distracted, do not code" (p.59)
  • "Nowadays when I feel myself slipping into the Zone, I walk away for a few minutes. I clear my head" (p.62)
  • "Choose disciplines that you feel comfortable following in a crisis. Then follow them all the time. Following these disciplines is the best way to avoid getting into a crisis" (p.153)
  • "programmers do not tend to be collaborators. And yet collaboration is critical to effective programming. Therefore, since for many of us collaboration is not an instinct, we require disciplines that drive us to collaborate" (p.75)
  • "The three laws of TDD [Test Driven Development]
    1. You are not allowed to write any production code until you have first written a failing unit test
    2. You are not allowed to write more of a unit test than is sufficient to fail - and not compiling is failing
    3. You are not allowed to write more production code that is sufficient to pass the currently failing unit test
    " (p.80)
  • "[Model Driven Architecture] assumes that the problem is the code. But code is not the problem. It has never been the problem. The problem is detail" (p.201)


  • "QA Should Find Nothing" (p.12)
  • "For some reason software developers don't think of debugging time as coding time" (p.69)
  • "Writing these tests is simply the work of specifying the system. Specifying at this level of detail is the only way we, as programmers, can know what 'done' is" (p.105)
  • "Make sure that all your unit tests and acceptance tests are run several times per day in a continuous integration system" (p.110)
  • "It should be QA's role to work with business to create the automated acceptance tests that become the true specification and requirements document for the system" (p.114)
  • "
    • Unit tests - written by the programmers, for programmers ... before the production code is written
    • Component tests - The components of the system encapsulate the business rules, so the tests for those components are the acceptance tests for those business rules ... written by QA and Business with help from development
    • Integration tests - They do not test business rules ... they ... make sure that the components are properly connected and can clearly communicate with each other ... typically written by the system architects ... typically not executed as part of the Continuous Integration suite, because they often have longer runtimes
    • System tests - They are the ultimate integration tests. ... We would expect to see throughput and performance tests in this suite
    • Manual exploratory tests - These tests are not automated, nor are they scripted
    " (p.116)


  • "FITNESSE is 64,000 lines of code, of which 28,000 are contained in just over 2,200 individual unit tests. These tests cover at least 90% of the production code and take about 90 seconds to run" (p.80)

No comments:

Post a Comment