Clean Code summary
ā¢
30 likesā¢19,315 views
Presentation I held before my colleagues about the book Clean Code (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882). It contains the highlights of several chapters and hint/guidelines a developer should know.
![By: Jan de Vries E-mail: [email_address]](https://image.slidesharecdn.com/20100405cleancode-100409015003-phpapp01/85/Clean-Code-summary-1-320.jpg)
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Clean Code summary
Similar to Clean Code summary (20)
More from Jan de Vries
More from Jan de Vries (17)
Recently uploaded
Recently uploaded (20)
Clean Code summary
Editor's Notes
- Niet alle slides, komt wel op internet/share Auteur ļ zoān 40 jaar ervaring
- 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!
- 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
- 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.
- Komt door snel je code afleveren Deadlines Vervelend project, snel afmaken Maak het later wel beter Iedereen doet het
- 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
- 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
- Het komt eigenlijk door ons zelf
- 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.
- 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
- 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
- Try-catch in een zoān klein mogelijke scope Eigen error handling klasse Niet alles in 1x proberen goed te doen, dat is ondoenlijk
- 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
- 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
- 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
- Objecten en data structures zijn niet hetzelfde. Gebruik ze dan ook anders
- 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
- 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
- Test code is bijna belangrijker als normale code Als het niet leesbaar/bruikbaar is, is het vertrouwen ook weg
- 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
- Select & update in their own classes, they do somehting similar, but different nonetheless
- Snelweg concept van Yves