Are You Ready For Clean Code?

579 views
452 views

Published on

What, when, how, and for whom is clean code? It's just ordinary weekly devTalk material at Vox Teneo Indonesia.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
579
On SlideShare
0
From Embeds
0
Number of Embeds
112
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Revealing names
    Avoid Disinformation (ex: paymentStat)
    Meaningful Distinct (same name on one place, make other bad)
    Pronouncable
    Searchable
    Class Must noun, But Method must Verb
    Don’t be cute
    Pick one word per concept
    Don’t Joke
    Konsisten
    Mental Mapping = a, b == I,j,k
  • Single Responsibilty Principle
    Open/Close Principle

    Niliadic, monadic, dyadic, triadic, polyadic (requires very special justification)

    DRY -> duplication may be the root of all evil in software

    Structured
  • Clarification assertTrue(a.compareTo(b)==-1) ; // a < b

    Journal comment
    Noise comment
    Construct
    The day of month : private int dayOfMonth
    Scary comment
    private string name; // the name
    Private byte age; // the age


    To much information!!
  • There is a well-known heuristic called the Law of Demeter2 that says a module should not
    know about the innards of the objects it manipulates. As we saw in the last section, objects
    hide their data and expose operations. This means that an object should not expose its
    internal structure through accessors because to do so is to expose, rather than to hide, its
    internal structure.

    Dog.getBody().getTail().wag();
    Dog.expressHappiness();
  • E_ERROR
    E_OK

    Return empty Collection.emptyList()
  • Test Driven Development
  • Readable code is understandable code
    Naming
    Class names
    Context specific
    Method names
    Say exactly what they do
    The don’ts
    Don’t confuse
    Don’t hide
    Don’t joke
    Don’t be informal
    Tell a story!
    ----------------------------------------------------------------
    Making it testable, is making it clean
    Isolation
    Decoupling
    Separation of concerns
    TDD
    Design
    Clean is the side effect of testable
    -----------------------------------------------------------------
    Easy to extend
    A change requires one change, not ten
    Easy to understand
    Unbrittle
    Test coverage
    Spreads optimism
    Importance level: Readable > maintainable
  • Are You Ready For Clean Code?

    1. 1. Clean Code Whisnu | Vox Teneo Indonesia
    2. 2. Reason? • We Are Programmer • We Want to be a Better Programmer
    3. 3. A = 1 B = A Print BA = 1 C = A B = C Print B - Same Task - Same Effort - Same Test Result - No BUG’s
    4. 4. Good Code Matter because it doesn't end there!
    5. 5. • You Will Have To Go Back • Someone Else Will Have To Go Back • They Don’t Teach That in School • Good Code Matter • Definition • Degrees of Bad • The Netscape Fallacy • Why Write Good Code • But Doesn't Good Code Cost More Up Front?
    6. 6. Boy Scout Rule Leave the campground cleaner than you found it.
    7. 7. CLEAN CODE = WTF’s Minutes
    8. 8. Meaningful Names Functions Comments Formatting Objects and Data Structures Error Handling Unit Tests
    9. 9. Meaningful Names int d; // elapsed time in days string htmlOutput; // form configuration html DataGrid dataGrid1; DataGrid dataGrid2; Label label1; Object myObj; int elapsedTimeInDays; string formConfiguration; DataGrid dgCustomers; DataGrid dgProducts; Label lblFirstName; Object objCustomer;
    10. 10. Functions • Small and Should be smaller than that • Do One Thing • One Level of Abstraction • getHtml(); • String pagePathName = PathParser.render(path); • .append(“n”); • Switch Statement (break it for SRP/OCP reason) • Ideal number of arguments is ZERO • Object Argument (hidden dependency, inject dependency, SRP) • Have No Side Effect (setAndCheckIfExists())
    11. 11. Comment • Don’t Comment Bad Code! • Explain on Code • Legal comment, TODO comment, JavaDoc, PHPDocumenter • Clarification • Warning of Consequences • No Mumbling • Redudant Comment • Position Marker • Closing Brace comment • Attributes and ByLine • Comment Out Code (your note code)
    12. 12. Formating • The Purpose of Formatting? • Vertical Matter, Horizontal Alignment • Breaking Identation • Team Rules
    13. 13. Object and Data Structures* • The Law Of Demeter (Train Wrecks) * lol + m/ = 
    14. 14. Error Handling • Prefer Returning an Exceptions • Don’t Return null
    15. 15. Unit Tests The Three Laws of TDD: • First Law You may not write production code until you have written a failing unit test. • Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing. • Third Law You may not write more production code than is sufficient to pass the currently failing test.
    16. 16. In Practice it’s all about RTM
    17. 17. READABILITY TESTABILITY MAINTAINABILITY
    18. 18. From STUPID to SOLID
    19. 19. STUPI D
    20. 20. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    21. 21. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    22. 22. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    23. 23. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    24. 24. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    25. 25. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    26. 26. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    27. 27. S OL I D
    28. 28. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    29. 29. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    30. 30. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    31. 31. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    32. 32. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    33. 33. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    34. 34. For Coding Standard ? …and any Questions?

    ×