• Save
Clean Code summary
Upcoming SlideShare
Loading in...5
×
 

Clean Code summary

on

  • 8,775 views

Presentation I held before my colleagues about the book Clean Code (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)....

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.

Statistics

Views

Total Views
8,775
Views on SlideShare
7,825
Embed Views
950

Actions

Likes
4
Downloads
0
Comments
2

9 Embeds 950

http://www.techgig.com 822
http://confluence.barcapint.com 74
http://myitcareercoach.com 27
http://www.slideshare.net 13
http://plydevwamp 6
https://twitter.com 3
http://www.techgig.timesjobs.com 2
http://www.docseek.net 2
http://115.112.206.222 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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

Clean Code summary Clean Code summary Presentation Transcript

  • By: Jan de Vries E-mail: [email_address]
    • Title: Clean Code A Handbook of Agile Software Craftmanship
    • Author: Robert C. Martin
    • Pages: 349
    • Chapters: 17
    • Target Audience: Developers
    • Slides: 29
    • 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!
    • Smart developer
      • Difficult code
      • Has great developing skills
      • r = lowercase url
    • Professional developer
      • Readable code
      • Maintanable code
      • ‘ Clarity is king’
      • lowercaseUrlOfCurrentPage = lowercase url
    • Seiri – Organize/Sort
    • Seiton – Systemize/Tidiness
    • Seiso – Cleaning
    • Seiketsu – Standardization
    • Shutsuke - Discipline
    • Go fast?
    • Angry boss?
    • Tired of project?
    • Get working now, clean up later?
    • Everybody does it!
    • Redesign of system
    • Everybody wants in
    • Everything the old system does + better
    • Takes a long time
    • Team members leave
    • Requirements change and not meet design
    • Schedules too tight
    • Stupid managers
    • Intolerant customers
    • Useless sales
    • It’s us, the developers!
    • 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
  •  
    • Take your time
    • Not theList
    • Searchable names
      • Constants
    • Hungarian Notation
      • IDE
    • Member prefixes
    • Interfaces
    • Mental mapping
      • i, j, k, l
    • Pronouncable
    • 1 word per concept
      • Get, retrieve, fetch
      • Controller, manager, driver
    • Use domain names
      • Read by programmers
    • Small
      • < 150 characters per line
      • < 20 lines
    • Blocks, indenting
    • 1 thing!
    • Arguments
    • Side effects
    • Prefer exceptions
    • Extract try-catch
    • Error handling is 1 thing
    • Don’t repeat
    • Not all at once
    • Don’t
    • Self-explaining
    • If you can’t do any better
    • Clarification
    • Warning
    • TODO
    • Redundant
    • Misleading
    • Noise
    • Copy-pasting
    • Use a function or variable
    • Closing brace comments
    • Commented out code
    • Version control!
    • Variable declarations
      • Where they are used
    • Instance variables
      • Top of class
    • Dependancy
      • Top-down
    • Not 1-line functions
    • Team rules
      • 10 minutes
      • IDE formatter
    • 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
    • Narrow down exceptions
    • Provide context
    • Don’t return null; Don’t pass null
      • Prevents null-checking
    • Exploring & learing
      • Experiment & learn
      • Reading manual
    • Using non-existing code
      • Interface
      • Write your own
    • 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
    • Keeping tests clean
      • Maybe more important as actual code
    • No fear of refactoring
    • One assert per test
    • Single concept per test
    • F.I.R.S.T.
      • Fast
      • Independent
      • Repeatable
      • Self-validating
      • Timely
    • Should be small
    • Single Responsibility Principle
      • SQL  Select, Update
    • Easy to change code
    • Start small
    • Add features later
    • Keep synchronized blocks small
    • Don’t share objects
    • Suspicious failures
      • Are bugs, not cosmic glitches
    • 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!
  •