My Reading Notes from Clean Code by Robert C. Martin

Image from:

Chapter 1: Clean Code

  • It runs all the tests.
  • It contains no duplication.
  • It expresses all the design ideas that are in the system.
  • It minimizes the number of entities such as classes, methods, functions, etc.

Chapter 2: Meaningful Names

  • Why it exists?
  • What does it do?
  • How it is used?

Chapter 3: Functions

Chapter 4: Comments

  • When you find yourself in a position where you need to write a comment, think it through and see if isn’t some way to turn the tables and express yourself better in code.
  • Legal comments for corporate coding standards
  • Informative comments when the code can’t be expressed via functions
  • Warning of consequences
  • TODO comments are sometimes reasonable as long as they are not an excuse to leave bad code in the system

Chapter 5: Formatting

  • The name should be simple but explanatory and should be efficient to tell us whether we are in the right module.
  • Detail should increase as we move downward

Chapter 6: Objects and Data Structures

Chapter 7: Error Handling

Chapter 8: Boundaries

Chapter 9: Unit Tests

  • First Law: You may not write production code until you’ve written a failing unit test.
  • Second Law: You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
  • Third Law: You may not write more production code than is sufficient
  • Fast. Tests should run quickly.
  • Independent. Tests should not depend on each other.
  • Repeatable. Tests should be repeatable in any environment.
  • Self-Validating. The tests should have a boolean output. They either pass or fail.
  • Timely. The tests need to be written in a timely fashion. They should be written just before the production code that makes them pass.

Chapter 10: Classes

Chapter 11: Systems

Chapter 12: Emergence

  • Runs all the tests
  • Contains no duplication
  • Expresses the intent of the programmer
  • Minimizes the number of classes and methods

Chapter 13: Concurrency

  • Single Responsibility Principle (SRP) states that a given method/class/component should have a single reason to change. Keep your concurrency-related code separate from other code.
  • Corollary: Limit the Scope of Data. Take data encapsulation to heart. Severely limit the access of any data that may be shared.
  • Corollary: Use Copies of Data. If there is an easy way to avoid sharing objects, the resulting code will be far less likely to cause problems.
  • Corollary: Threads should be as independent as possible. Attempt to partition data into independent subsets than can be operated on by independent threads, possibly in different processors.

Chapter 14: Successive Refinement

Chapter 15: JUnit Internals




Linktree: | LinkedIn: | Github: | Site:

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How I personalized my Hashnode blog and you can too! 🌟

Basic CI/CD on Google Cloud Platform using Cloud Build

*Loops In Java*

Incipia Mobile App Survey — January 2017 (App Tools)

Setting up Media Wiki

Simple way to create kubernetes cluster locally using kind.


ARTH — Task 1.5

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Dan Blevins

Dan Blevins

Linktree: | LinkedIn: | Github: | Site:

More from Medium

Python Programming — Conditional Statement

Addition of two Roman numerals

Commonly used Github commands

Linux Commands For Beginners