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.

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