Show Menu
Cheatography
  1. Home >
  2. Programming >

Summary of 'Clean Code' By Robert C. Martin Cheat Sheet by

Hints that the code you're reading is a mess

Rigi­dity
No change is trivial, every change in the code add more twists and tangles.
Comp­lex­ity
As above, no change is trivial and requires a lot of research.
Frag­ility
Changes breaking other parts of the code.
Immo­bil­ity
You cannot reuse part of the existing code

General Rules

Follow the Boy Scout Rule : Leave the code cleaner than when you found it
Follow Standard Conven­tio­ns, both langage related and team related
Keep it simple stupid
Don't repeat yourself
Be cons­ist­ent
Do not override safeties

Design Rules

Functions should descend only one level of abstra­cti­on, and statements in a function should be at the same level of abstra­ction
Use depe­ndency inject­ion
Keep your boun­daries clean
Enca­psulate condit­ion­als, try to avoid negative condit­ionals
Make logical depend­encies physical
Use poly­mor­phism instead of if / else or switch / case
Avoid hidden temporal couplings
Keep config­urable data (ie: constants) at high levels, they should be easy to change
Use Enums over constants

Source Code Structure

Use vertical format­ting to separate your code and different concepts, you should read your code from top to bottom without "­jum­pin­g" over functions
Variables should be declared as close to their usage as possible
Instance variab­les should be declared at the top of the class
Put statics methods on top of the package
Similar and depend­ent functions should be close vertic­ally
Balance between vertical openness and vertical density. Same rules apply for horizontal density
Do not align your code horizo­ntally
Use cons­istent indent­ation
 

Naming Rules

Use desc­rip­tive and inte­nti­on-­rev­eal­ing variable names
Make mean­ingful distin­cti­ons
Use pronou­nceable and sear­chable names
Avoid disinf­orm­ation and encoded names
Avoid member prefixes or types inform­ation (Hungarian Notation)
Avoid mental mapping
Replace Magic Numbers with Cons­tants

Functions

Func­tions should do one thing and they should do it well
Functions should be relatively small
Functions should have desc­rip­tives names
Functions should have as few argume­nts as possible (no more than 3 if possible)
Functions should have no side effects
Use expl­anatory variab­les to explain your intent / algorithm
Don't use flag arguments
Avoid output arguments, they're misleading

Objects VS Data Structures

Data structures exposes data and have no behavior.
So, procedural code makes it easy to add new function without changing the existing data struct­ures.
Objects expose behavior and hide data.
Object Oriented code makes it easy to add new classes without changing existing functions
Avoid hybrids (half object and half data structure)
 
The Law of Demeter : A class should not know about the innards of the objects it manipu­lates. Objects should not expose theirs internals.
Same as functions : they should do one thing and they should be small
Avoid and split Train Wrecks : objec­tA.g­et­B().ge­tC(­).g­etD();
Keep the number of instance variables low, if your class have too many instance variable, then it is probably doing more than one thing

Error handling

Error handling is one thing, don't mix error handling and code
Use Exce­pti­ons instead of returning error codes
Write the try-ca­tch­-fi­nally statement first, it will help you structure your code
Don't return null, don't pass null either
Throw exceptions with context
 

Tests

F.I.R.S.T : Fast, Indepe­ndent, Repeat­able, Self-V­ali­dating, Timely
One assert per test
Keep your tests as clean as your production code, they should be easily readable
Use a coverage tool
Tests should be easy to run

TDD

3 Laws of Test Driven Develo­pme­nt, this should ensure that you write your tests and your code simu­lta­neo­usly
You may not write production code until you have written a failing unit test
You may not write more of a unit test than is sufficient to fail, and not compiling count as failing
You may not write production code that is sufficient to pass the currently failing test

Comments

When to write a comment ?
Explain yourself in code, not in comment. If it's not possible, take your time to write a GOOD comment.
What makes up a Good comment ?
Use comments to info­rm, expl­ain, clar­ify, or warn the reader
Commen­t-out code ?
DELETE IT
 
Avoid using more than one langage in a single source file (Html comments, Javadoc for nonplublic code)
Avoid inappr­opriate Inform­ations (change history, license, ...)
Avoid misleading or noise comments
Don't be redundant ( i++; // increment i)
Closing brace comments (} // end of function)

Credits

From "­Clean Code" by Robert C. Martin
Inspired by this summary
 
By Coste Maxime
 

Metadata

  • Languages:
  • Published: 13th February, 2019
  • Last Updated: 14th February, 2019
  • Rated: 5 stars based on 3 ratings

Favourited By

codevista rubashov4 albinotonnina ChristianMEC clintonowen

Comments

Thanks for putting this together—very useful reference!
I did notice one typo: the first item under 'General Rules' should be the "Boy Scout Rule".

CosteMaxime CosteMaxime, 10:39 14 Feb 19

Thanks for your comment !
It's fixed now.

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Regular Expressions Cheat Sheet
          PHP Cheat Sheet
          Python Cheat Sheet