Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Clean Code

Clean Code

Why you should do clean code and ways to achieve it - an overview based on the great book by Robert C. Martin and my own personal experiences

Daniel Kummer

April 15, 2013
Tweet

More Decks by Daniel Kummer

Other Decks in Programming

Transcript

  1. CLEAN CODE BECAUSE IT REALLY MATTERS PRESENTED BY DANIEL KUMMER

    NAMICS AG WWW.NAMICS.COM SENIOR SOFTWARE ENGINEER
  2. CLEAN CODE WHY DOES IT EVEN MATTER? HOW CAN IT

    BE DONE? BESIDE THE CODE… SUMMARY
  3. CODE SMELLS IT STINKS! DETECT BAD CODE … when it’s

    not obvious there are dozens google it for a more complete list warning signs / indicators
  4. A SMELLY SELECTION DEAD CODE COMMENTS DUPLICATE CODE LONG METHOD

    LONG PARAMETER LIST CONDITIONAL COMPLEXITY SPECULATIVE GENERALITY SHOTGUN SURGERY
  5. HOW TO DO IT! “Any fool can write code that

    a computer can understand. Good programmers write code that humans can understand.” ~Martin Fowler
  6. CLEAN WHAT’ CLEAN CODE? SIMPLE READABLE EXTENDABLE EFFICIENT understand what

    it does able to solve upcoming problems if you do it, do it right someone cared for it it has a story to tell
  7. WRITE DIRTY CODE FIRST, THEN CLEAN IT 1 you can’t

    write clean code on the first go! successive refinement is key your first attempt won’t be your best
  8. LEAVE IT CLEANER THAN YOU FOUND IT 2 incrementialism –

    make tiny changes Even if it’s just reformatting, you cared! the “boyscout” rule
  9. REVEAL INTENTION – CLARITY IS KING no questions asked about

    the purpose LONG NAMES AREN’T BAD pick names corresponding to the scope ONE WORD PER CONCEPT keep the lexicon consitent NAMING
  10. FUNCTIONS DRY - DON’T REPEAT YOURSELF duplication is a root

    of evil! KISS - KEEP IT SIMPLE AND STUPID equals understandable DO ONE THING ONLY – AND DO IT WELL keep the level of abstraction to a minimum ZERO ARGUMENTS – THE IDEAL pursue it, as best as you can (think about testing)
  11. FUNCTIONS CONT. FLAGS ARE BAD! prefer polimorphism SIDE EFFECTS ARE

    LIES! the function should do one thing EXTRACT ERROR HANDLING improve readability, don’t obscure logic RETURN ONLY ONCE – OR FAIL FAST keep the exit clear
  12. COMMENTS NEVER EXPLAIN WHAT CODE DOES explain WHY //drunk, fix

    later DON’T COMMENT OUT CODE we have VCS for this! NO CHANGE HISTORY HEADER see above (it wouldn’t be maintained anyway) NO REDUNDANT OR MANDATED COMMENTS example: why document an accessor?
  13. FORMATTING DO IT LIKE THE NEWSPAPERS { TOP-DOWN PRINCIPLE MAIN

    FUNCTIONS ON TOP followed by called functions } VERTICAL DENSITY what belongs together should be together HORIZONTAL ALIGNMENT don’t align just for the looks
  14. OBJECTS & CLASSES SRP – SINGLE RESPONSIBILITY PRINCIPLE same as

    functions - do one thing SMALL keep away from the “god”-classes ORGANIZE FOR CHANGE – USE INTERFACES it’s most likely going to happen LoD - LAW OF DEMETER (LOOSE COUPLING) a given object should assume as little as possible about the structure or properties of anything else
  15. ERROR HANDLING USE UNCHECKED EXCEPTIONS you decide when to handle

    them EXTRACT HANDLING BLOCKS (TRY/CATCH) don’t disturb the code flow DON’T RETURN NULL, DON’T PASS NULL avoid NPEs LoD - LAW OF DEMETER (LOOSE COUPLING) a given object should assume as little as possible about the structure or properties of anything else
  16. FAST tests should run quick – or you won’t run

    them INDEPENDENT no test should depend on another test REPEATABLE in any environment, your laptop, the CI server… SELF-VALIDATING pass or fail - no manual action required TIMELY don’t write your tests too late, it only gets harder F.I.R.S.T
  17. VERSION MANAGEMENT TOOLING ISSUE MANAGEMENT SCM / VCS CONTINUOUS INTEGRATION

    CODE METRICS track your discussions and descisions early problem recognition analyze your code with heuristics define your cycles keep a clean history educate your team