Clean Code summary
30 likes19,370 views
The document is a summary of 'Clean Code: A Handbook of Agile Software Craftsmanship' by Robert C. Martin, emphasizing best practices for writing maintainable and readable code. It covers principles such as the Boy Scout Rule, the importance of clarity, and the necessity of refactoring, along with practical tips for developers. Additionally, it discusses the significance of unit testing and the responsibility developers have in keeping code quality high.
![By: Jan de Vries E-mail: [email_address]](https://image.slidesharecdn.com/20100405cleancode-100409015003-phpapp01/85/Clean-Code-summary-1-320.jpg)
Clean Code summary
- 1. By: Jan de Vries E-mail: [email_address]
- 2. Title: Clean Code A Handbook of Agile Software Craftmanship Author: Robert C. Martin Pages: 349 Chapters: 17 Target Audience: Developers Slides: 29
- 3. Awareness Tips on how to produce better code Readability The ‘boy scout rule’ Starting out with tips and examples Later on real world examples It’s not the bible!
- 4. Smart developer Difficult code Has great developing skills r = lowercase url Professional developer Readable code Maintanable code ‘ Clarity is king’ lowercaseUrlOfCurrentPage = lowercase url
- 5. Seiri – Organize/Sort Seiton – Systemize/Tidiness Seiso – Cleaning Seiketsu – Standardization Shutsuke - Discipline
- 6. Go fast? Angry boss? Tired of project? Get working now, clean up later? Everybody does it!
- 7. Redesign of system Everybody wants in Everything the old system does + better Takes a long time Team members leave
- 8. Requirements change and not meet design Schedules too tight Stupid managers Intolerant customers Useless sales
- 9. It’s us, the developers!
- 10. They ask us for information If they don’t, make yourself noticed Users ask us if requirements fit the system Project managers ask us to help with schedule
- 12. Take your time Not theList Searchable names Constants Hungarian Notation IDE Member prefixes Interfaces
- 13. Mental mapping i, j, k, l Pronouncable 1 word per concept Get, retrieve, fetch Controller, manager, driver Use domain names Read by programmers
- 14. Small < 150 characters per line < 20 lines Blocks, indenting 1 thing! Arguments Side effects Prefer exceptions
- 15. Extract try-catch Error handling is 1 thing Don’t repeat Not all at once
- 16. Don’t Self-explaining If you can’t do any better Clarification Warning TODO
- 17. Redundant Misleading Noise Copy-pasting Use a function or variable Closing brace comments Commented out code Version control!
- 18. Variable declarations Where they are used Instance variables Top of class Dependancy Top-down Not 1-line functions Team rules 10 minutes IDE formatter
- 19. Law of Demeter Method f of a class C should only call the methods of these: C An object created by f An object passed as an argument to f An object held in an instance variable of C Objects Data structures
- 20. Narrow down exceptions Provide context Don’t return null; Don’t pass null Prevents null-checking
- 21. Exploring & learing Experiment & learn Reading manual Using non-existing code Interface Write your own
- 22. Three laws of TDD 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 is failing You may not write more production code than is sufficient to pass the currently failing test
- 23. Keeping tests clean Maybe more important as actual code No fear of refactoring One assert per test Single concept per test
- 24. F.I.R.S.T. Fast Independent Repeatable Self-validating Timely
- 25. Should be small Single Responsibility Principle SQL Select, Update Easy to change code
- 26. Start small Add features later
- 27. Keep synchronized blocks small Don’t share objects Suspicious failures Are bugs, not cosmic glitches
- 28. Start with bad code and clean it Keeping things small Keeping code readably Self-explaining Standards Unit testing Interfaces, abstract classes, OO You are responsible!
Editor's Notes
- #3: Niet alle slides, komt wel op internet/share Auteur zo’n 40 jaar ervaring
- #4: Bewustmaking van het probleem Tips geven hoe te verbeteren Leesbare code maken Het is niet de bijbel noch staat het in steen geschreven. Eigen interpretatie is goed, maar sla de adviezen niet zomaar in de wind. 40 jaar ervaring is niet niks ‘ boy scout rule’ Laat je kampeerplaats schoner achter dan je hem bent tegen gekomen. Openen van een klasse, verbeter deze!
- #5: Smart -> Moeilijke code, iedereen echt zo van ‘Wow dat het kan’, show-offs om te laten zien dat ze zo goed zijn en snappen waar de moeilijke code voor dient. ‘ r’ is voor de lowercase url Professional -> deze code goed leesbaar, goed te onderhouden
- #6: Organiseer je code, sorteer alle functies en klassen Breng een systeem aan om dit te doen en maak het netter, bijvoorbeeld regions, public boven, getters setters bij elkaar, etc. Maak de code schoon, kleine aanpassingen zijn comments weg halen, betere variabele namen. Grote zijn om de code te herschrijven met interfaces, abstracte klassen, etc. Spreek een standaard af en gebruik deze in het hele team Discipline is nodig om alles te kunnen volgen.
- #7: Komt door snel je code afleveren Deadlines Vervelend project, snel afmaken Maak het later wel beter Iedereen doet het
- #8: Wordt 1 grote zooi Niemand wil er meer aan werken Schoon maken is een immens karwei Nieuw systeem zal komen waar iedereen aan wil werken Moet hetzelfde kunnen als het oude systeem Duurt lang Originele bezetting is weg, nieuwe members, uiteindelijk ontstaat er weer een draak, mits geen goede discipline
- #9: De eisen/wensen kloppen niet met je systeem, moet veel worden omgeschreven Te strakke planning Stomme managers die er niets van snappen Klanten die niet weten wat ze willen of niet accepteren dat ze iets moeten doen Sales heeft iets raars verkocht
- #10: Het komt eigenlijk door ons zelf
- #13: Geen List of zo, want later wordt het misschien een Array en dat is iets heel anders “ de waarde” is lastig zoeken, lastiger als DE_WAARDE Hongaarse notatie is ouderwets, IDE moet het wel af kunnen Member variabelen geen prefixes, moet de IDE aan kunnen Dit heb ik nog niet kunnen bewerkstelligen Interfaces zonder I. Die zegt namelijk niets.
- #14: Uitspreekbaar, zodat je het over de code kunt hebben Ontwikkelaars lezen en maken de code, je kunt dus best namen en dergelijke uit het vakgebied gebruiken
- #15: Organiseren van je code 0 argumenten is beter als 1. 1 is beter als 2, 3 is een draak van een functie Return altijd iets, anders kun je niet testen Functie maar 1 doel Exceptions zijn beter dan error codes
- #16: Try-catch in een zo’n klein mogelijke scope Eigen error handling klasse Niet alles in 1x proberen goed te doen, dat is ondoenlijk
- #17: Gebruik geen commentaar, als dat nodig is, kun je de tijd beter besteden om een goede functie/naam te bedenken Alleen maar als je niet beter code kunt schrijven Code is self-explaning Warnings geven dat iets lang duurt, kan TODO’s of zo mag ook
- #18: Commentaar kan oud worden en niet vernieuwd Misleidend Niemand leest het Bij een } commentaar is onnodig, omdat functies al klein zijn Commented out code Versiebeheer
- #19: Variabelen declareren waar ze nodig zijn Member variabelen boven in Niet alles op 1 regel proppen Snelle afspraken waar iedereen zich aan houdt en die uitbreiden waar nodig
- #20: Objecten en data structures zijn niet hetzelfde. Gebruik ze dan ook anders
- #21: Zo klein mogelijke exceptions, dus niet catch(Exception ex) Stacktraces mee geven, maar ook aangeven wat er fout is gegaan met welke waarde, etc. Niet null door geven, dat scheelt ook weer code
- #22: Als je iets moet implementeren kun je beter proberen het te maken en testen schrijven ipv tientallen pagina’s documentatie doorlezen. Zo maak je dus ook al een begin met je testen Interfaces gebruiken voor nog niet bestaande code en zelf implementeren
- #24: Test code is bijna belangrijker als normale code Als het niet leesbaar/bruikbaar is, is het vertrouwen ook weg
- #25: Fastt, otherwise no one will test Independant, no dependency from each other Repeatable on any environment Self-validating, either true or false, no log file Timely, just before the actual code is written
- #26: Select & update in their own classes, they do somehting similar, but different nonetheless
- #27: Snelweg concept van Yves