Your SlideShare is downloading. ×
Are You Ready For Clean Code?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Are You Ready For Clean Code?

305
views

Published on

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

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


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
305
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 1. Clean Code Whisnu | Vox Teneo Indonesia
    • 2. Reason? • We Are Programmer • We Want to be a Better Programmer
    • 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. Good Code Matter because it doesn't end there!
    • 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. Boy Scout Rule Leave the campground cleaner than you found it.
    • 7. CLEAN CODE = WTF’s Minutes
    • 8. Meaningful Names Functions Comments Formatting Objects and Data Structures Error Handling Unit Tests
    • 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. 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. 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. Formating • The Purpose of Formatting? • Vertical Matter, Horizontal Alignment • Breaking Identation • Team Rules
    • 13. Object and Data Structures* • The Law Of Demeter (Train Wrecks) * lol + m/ = 
    • 14. Error Handling • Prefer Returning an Exceptions • Don’t Return null
    • 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. In Practice it’s all about RTM
    • 17. READABILITY TESTABILITY MAINTAINABILITY
    • 18. From STUPID to SOLID
    • 19. STUPI D
    • 20. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    • 21. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    • 22. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    • 23. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    • 24. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    • 25. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    • 26. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
    • 27. S OL I D
    • 28. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    • 29. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    • 30. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    • 31. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    • 32. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    • 33. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
    • 34. For Coding Standard ? …and any Questions?