Writing Clean Code (Recommendations by Robert Martin)
Download as PPTX, PDF0 likes817 views
The document discusses clean code best practices as outlined by Robert C. Martin. It covers topics such as meaningful naming conventions, writing small functions, using comments appropriately, formatting code consistently, separating data and objects, handling errors through exceptions, defining clear boundaries, and writing unit tests. The goal is to write code that is readable, maintainable, and flexible through applying these best practices.
Ad
More Related Content
What's hot (20)
Viewers also liked (17)
Ad
Similar to Writing Clean Code (Recommendations by Robert Martin) (20)
Ad
Recently uploaded (20)
Writing Clean Code (Recommendations by Robert Martin)
- 1. Clean Code Best Practices …….by Robert C. Martin
- 2. Background • Studied • Clean Code: A Handbook of Agile Software Craftsmanship • Presentation provide the summary of clean code best practices given by Robert C martin
- 3. Meaningful Names • Naming Rules • Avoid mental mapping when naming methods, classes or variables • Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser etc • Methods should have verb or verb phrase names like postPayment, deletePage, or save . • Accessors, mutators and predicates should be named for their value and prefixed with get, set, and is according to the javabean standard. • Don’t Add Gratuitous Context • If your application Name is GSD then do not prefix GSD to class names like GSDMailing , GSDAccountProcessing .
- 4. Meaningful Names • Use Pronounceable Names • The length of a name should correspond to the size of its scope • Variables i , j could be used as loop variables • Avoid Disinformation • Use Intention-Revealing Names • The name of a variable, function, or class should answer Why it exists ? What it does ? and how it is used ? • int d; vs int elapsedTimeInDays or int daysSinceCreation • Variables named as hp, aix and sco should be avoided
- 5. Functions • Should Be small • Handle One Abstraction per function • Function should do One Thing ,they should do it well , they should do it only • Prefer exceptions than Returning error codes • Remove code duplication • Function should not produce side effects
- 6. Comments • Should be used when required like • Legal terms and conditions • Provides information about the intent • Clarification • Warning of consequences • TODO comments • Java Docs in public API
- 7. Comments • Following comments would be considered as Bad comments if they are • Redundant • Misleading • Java docs in non public code • Journal • Noise • Closing brace • Dead code
- 8. Formatting • Team should decide the formatting/indentation strategy and everyone in the team should follow this strategy • Strategy could be about • Vertical formatting . Recommended No. of Lines per Java source File • Vertical Openness between concepts • Variable declaration – Local variables and instance variables • Dependant functions should be just below the caller • Horizontal formatting – line should be less than 120 chars • Indentation - should not break indentation for small if or loop statements
- 9. Objects and Data Structures • Data/Object Anti-Symmetry • Objects hide their data behind abstractions and expose functions that operate on that data • Data structure expose their data and have no meaningful functions. • Sometimes you really do want simple data structures with procedures operating on them. Data Structures like Value Objects, Beans , DTO’s recommends having setters and getters • Data structures Should not contain business rule methods
- 10. Objects and Data Structures • The Law of Demeter • module should not know about the innards of the objects it manipulates. • The Law of Demeter says that a 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 • final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath(); // This is violation of law of Demeter • Demeter Law does not apply to Data structures because by nature Data Structure expose their internals
- 11. Error Handling • Use Exceptions Rather Than Error Codes • Create informative error messages and pass them along with your exceptions • Don’t Pass Null value to function and don’t return null • If your API expected to return Null then this condition needs to be handled in our code • We can write robust clean code if we see error handling as a separate concern
- 12. Boundaries • Exploring and Learning Boundaries • Learning tests could be very helpful for this • boundary should be supported by a set of outbound tests • manage third-party boundaries by having very few places in the code that refer to them
- 13. Unit Tests • Unit tests keeps our code flexible, maintainable and reusable. Confidence of change increases when there are more number of tests. • The BUILD-OPERATE-CHECK pattern should be used for Unit tests • The Three Laws of TDD 1. You may not write production code until you have written a failing unit test 2. You may not write more of a unit test than is sufficient to fail, and not compiling is failing. 3. You may not write more production code than is sufficient to pass the currently failing test • Single Concept per Test Vs One Assert per Tests • Tests Should be Fast ,Independent ,Repeatable ,Self-validating and Timely – F.I.R.S.T
- 14. Classes • Classes should Be small • Single Responsibility Principal – There should be only one reason to change the class • Open Close Principal – Class should be Open for extension and close for modification • Classes should have High Cohesion and Loose Coupling
- 15. References • Clean Code book by Robert C Martin