Clean Code
•
24 gefällt mir•4,500 views
Clean Code talk held at the HSR "Hochschule für Technik Rapperswil" and the FHNW "Fachhochschule Nordwestschweiz" based on the great book by Robert C. Martin and enriched with personal experiences
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Clean Code
Ähnlich wie Clean Code (20)
Mehr von Daniel Kummer
Mehr von Daniel Kummer (12)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Clean Code
- 1. CLEAN CODE IT REALLY MATTERS BROUGHT TO YOU BY SENIOR SOFTWARE ENGINEER DANIEL KUMMER NAMICS AG ZÜRICH WWW.NAMICS.COM
- 2. CLEAN CODE AGENDA ? WHY DOES IT EVEN MATTER? ! HOW CAN IT BE DONE? * BESIDE THE CODE…
- 3. DEFINITION OF CLEAN CODE WORKS EFFICIENT READABLE EXTENDABLE CORRECTLY IT TELLS YOU A STORY SIMPLE TO UNDERSTAND IT DOES IT RIGHT EASY TO MODIFY CLEAN SOMEONE CARED
- 4. ? WHY CARE ”The only valid code metric is WTFs per minute” ~ A comic strip
- 5. SOFTWARE ENTROPY THE BROKEN WINDOW DON’T LIVE WITH BROKEN WINDOWS!
- 6. IT’S ALL ABOUT $$$ THE COST OF BAD CODE TIME PRODUCTIVITY NERVES PROJECTS Mo$va$on No one wants to take it
- 7. DETECTING BAD CODE DEAD CODE UNUSED = UNNEEDED COMMENTS WHY NOT WHAT A FEW SMELLS DUPLICATES DON’T REPEAT YOURSELF CONDITIONAL LONG METHOD / SPECULATIVE COMPLEXITY PARAMETER LIST GENERALITY HARD TO TEST SHORTER = EASIER SOLVE TODAYS PROBLEM, NOT TOMORROWS A more complete list can be found at http://www.codinghorror.com/blog/2006/05/code-smells.html
- 8. ! HOW TO DO IT “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” ~Martin Fowler
- 10. 1 WRITE DIRTY CODE FIRST, THEN CLEAN IT YOU CAN’T WRITE CLEAN CODE ON THE FIRST GO! YOUR FIRST ATTEMPT WON’T BE YOUR BEST SUCCESSIVE REFINEMENT IS KEY START WITH PSEUDOCODE
- 11. 2 LEAVE IT CLEANER THAN YOU FOUND IT THE “BOYSCOUT” RULE INCREMENTIALISM – MAKE TINY CHANGES EVEN IF IT’S JUST REFORMATTING – YOU CARED YOU ARE TAKING RESPONSIBILITY
- 12. THREE WORDS CARE FOR CODE
- 13. CLEAN TIPPS HOW TO GO ABOUT IT
- 14. NAMING CONVENTIONS 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 / NOT AMBIGUOUS keep the lexicon consistent USE ENGLISH – DON’T USE YOUR LANGUAGE just don’t!
- 15. CODING DRY - DON’T REPEAT YOURSELF duplication is a root of evil! DON’T OPTIMIZE PREMATURELY unless it’s really, really necessary DON’T SAVE ON CHARACTERS one liners are not faster, just unreadable DON’T TRY TO OUTSMART THE COMPILER really smart people are working on it…
- 16. FUNCTIONS KISS - KEEP IT SIMPLE AND STUPID equals understandable DO ONE THING ONLY – AND DO IT WELL keep the level of abstraction to a minimum MINIMIZE ARGUMENTS – LESS IS MORE pursue it, as best as you can (think about testing)
- 17. FUNCTIONS FLAGS ARE BAD prefer polymorphism SIDE EFFECTS ARE SCARY the function should do one thing EXTRACT ERROR HANDLING improve readability, don’t obscure logic RETURN ONCE ONLY – OR FAIL FAST keep the exit clear
- 18. COMMENTING //drunk, fix later NEVER EXPLAIN WHAT CODE DOES explain WHY you did it this way DON’T COMMENT OUT CODE we have VCS for this! COMMENT STRANGE OR UNNATURAL CODE do it even if it’s not your own – explain why NO REDUNDANT OR MANDATED COMMENTS example: don’t document getters / setters
- 19. 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 NO HORIZONTAL ALIGNMENT DON’T ALIGN JUST FOR THE LOOKS
- 20. OBJECTS AND CLASSES SRP – SINGLE RESPONSIBILITY PRINCIPLE one responsibility per object 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
- 21. ERROR HANDLING USE UNCHECKED EXCEPTIONS AND DOCUMENT THEM IN THE JAVADOC 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 NULL checks and NPEs CONCENTRATE ON WHAT YOU CAN HANDLE not what to throw
- 22. TEST YOUR CREATION SO YOU MAY SLEEP CALM AT NIGHT
- 23. THE F.I.R.S.T PRINCIPLE 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
- 24. TESTING PYRAMID
- 25. BESIDE CODE THE SATELLITES OF A SOFTWARE PROJECT
- 26. USE TOOLS COMBINE YOUR MAGIC HELPERS CONTINUOUS INTEGRATION EARLY PROBLEM RECOGNITION RELEASE MANAGEMENT SCM / VSC ISSUE MANAGEMENT CODE METRICS DEFINE YOUR RELEASE CYCLES TRACK DISCUSSIONS AND DESCISSIONS KEEP A CLEAR HISTORY HEURISTIC CODE ANALYSIS
- 27. HUMAN FACTORS DON’T BE SHY… OTHERS HAVE THE SAME PROBLEMS YOU HAVE – EVEN PROS! REVIEW LEARN DISCUSS SHARE IMPROVE AND LEARN GUIDELINES / PROBLEMS / SOLUTIONS DELIBERATE PRACTICE THOUGHTS / TOOLS / IDEAS
- 29. READING MATERIAL SOFTWARE CRAFTSMANSHIP CODE OF CONDUCT CLEAN YOUR CODE WITH COMMON SOLUTIONS