Are You Ready For Clean Code?
•Descargar como PPTX, PDF•
1 recomendación•936 vistas
What, when, how, and for whom is clean code? It's just ordinary weekly devTalk material at Vox Teneo Indonesia.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
Destacado
Destacado (20)
Similar a Are You Ready For Clean Code?
Similar a Are You Ready For Clean Code? (20)
Último
Último (20)
Are You Ready For Clean Code?
- 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
- 5. Good Code Matter because it doesn't end there!
- 6. • 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?
- 7. Boy Scout Rule Leave the campground cleaner than you found it.
- 9. Meaningful Names Functions Comments Formatting Objects and Data Structures Error Handling Unit Tests
- 10. 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;
- 11. 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())
- 12. 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)
- 13. Formating • The Purpose of Formatting? • Vertical Matter, Horizontal Alignment • Breaking Identation • Team Rules
- 14. Object and Data Structures* • The Law Of Demeter (Train Wrecks) * lol + m/ =
- 15. Error Handling • Prefer Returning an Exceptions • Don’t Return null
- 16. 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.
- 17. In Practice it’s all about RTM
- 20. From STUPID to SOLID
- 21. STUPI D
- 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. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
- 28. Singleton Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication
- 29. S OL I D
- 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
- 33. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
- 34. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
- 35. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
- 36. Single Responsibility Principle Open/Close Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
- 38. For Coding Standard ? …and any Questions?
Notas del editor
- 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