github twitter email rss
Clean Code - Robert C. Martin
0001 Jun 1
4 minutes read

Clean Code - Robert C. Martin

Bad code is

  • Rigid
  • Fragile
  • Inseperable
  • Opaque

What is good code ?


  • reveal intent.
  • avoid desinformation.
  • prononceable names.
    avoid «getYYYY()»
  • avoid encoding.
    avoid prefixes and notations, like «m_name»
  • Use parts of Speech
    – class and variable names should be naun
    – boolean variables should be written like predicate
    for example: «isEmpty», «isTerminated»
    – methods - verbs
    for example: «PostMessage», «get»
    – if method return boolean it should be written as predicate
    for example: «isDBNull»
    – properties - nauns
    if boolend - predicates
    – enums - states or object descriptors

The Scope Length Rule

Relationship between scope length and name length
  • Variables
    Longer the scope - longer name of the variable
    variables in very short scope should have very short names

  • Functions and Classes
    Longer the scope - shorter name
    private classes and variables - can have long explanatory names
    public derive classes can be longer and longer because they add adjectives


  • Keep functions small
  • Well named functions acts like sign on your way.
  • Large function is where classes go to hide.
  • Function should do one thing
  • Extract till you drop

Function structure


we should treat every argumnet as liability
Three arguments max

  • booleans
    – if you pass boolean to functions you say that it doing two things, you should better write separate functions.
  • no output arguments please.
  • null.
    – always bad as passing boolean, introduce same double behavior
    – Don’t use null as pseudo boolean
    – replace function that takes possible null argument with two functions, first takes not null, second don’t take null
    – checking for null is defensive programming, better rely on unit tests
    – best defence is good offence, and good offence is good suite of tests

The Stepdown Rule

Important stuff on top, details on bottom (from abstract to detailed)

    private variables
    public methods
        private methods
            private methods
  • OO vs. switch statement
    OO gives ability to manage dependencies
    A -> B
    module A call function in module B
    Flow of Control(runtime) dependency A->B
    Source Code Dependency A->B

    dependency inversion
    A -> I <|- B
    A call function in interface I, B derives from interface I
    Flow of Control(runtime) dependency A->B
    Source Code Dependency A->I I<-B

    FAN-OUT problem
    App -> switch -> other methods
    App -> base class <|- Derivatives

    how create instances ?
    #dependency injection
    Core application functionality | low leved details
    App partition <- Main partition(almost plugin)


functional 1957

  • side effects
  • function must be called in order = «temporal coupling»
  • passing a block technique

  • command query separation
    functions that change state should not return values, but can throw Exceptions
    functions that return values should not change state

  • tell don’t ask
    we should tell objects what to do, not ask what state of this objects

  • train racks is bad
    too much knowledge in single line

  • the law of demeter
    you may call methods of objects that are:
    – passed as arguments
    – created locally
    – instance variables
    – globals
    yoy may not call methods on objects that are:
    – returned from previous call

structured 1967

  • sequence
    entrance -> ( block -> block ) -> exit
  • selection
    entrance -> ( predicate -> block | block ) -> exit
    entrance -> ( predicate -> block ) -> exit

oo 1962-66

error handling

  • fail first
  • throw exception that scoped to the class it throws
  • use unchecked exception
  • null is not error
  • try keyword
    must be first after any variable declaration
    must contain only one function call
  • catch, finally should always be last in function

  • function do one thing: something, or error handling

Coding Standard


  • every time you write comment you fail
  • DRY principle, even in comments
  • get rid of misleading comments
  • delete commented out code


horizontal space

lines should be ~ 40 and always be < 120 characters

Class vs. Data Structure

  • classes
    protect from new types
    exposes to new methods
  • data structures
    protect from new methods
    exposes to new types

The expression problem

—-crossing boundries—>

concrete    |       abstract
main        |       App
view        |       model
database    |       domain objects

---------------------------------> source code dependency
<--------------------------------- flow of control
database    <-| DB Interface | ->   domain objects

the impedance mismatch

domain objects AND database tables NOT SAME THING


  • you must trust your test as your parashute
  • tdd is personal practice
  • 100% code coverage


Three laws of TDD

  • write no pruduction code except to pass a failing test
  • write only enough of a test to demonstrate a failure
  • write only enough production code to pass the test

misplaced responsibility code smell


  • don’t depend on delivery mechanism
  • focus on use case
  • separate cost of use cases from cost of UI and other system components

use case

  • primary course of use case
  • exception course


  • business objects(entities)
    application independent business rules
    encapsulates business objects

  • boundries
    isolates use case from delivery mechanism
    isolates from user interface

  • Interactors(controllers)
    application specific business rules
    encapsulates use cases
    responsible for arcestrating database access


Back to posts

comments powered by Disqus