The document discusses principles of 'clean code' that emphasize meaningful naming, function simplicity, and proper commenting practices. It outlines key practices such as using intention-revealing names, avoiding disinformation, ensuring functions adhere to single responsibilities, and the importance of unit testing. Overall, it advocates for writing clear, understandable, and maintainable code.

1. Clean Code
Pranjut Gogoi
Senior Software Consultant
Knoldus Software LLP

3. What is clean code ?

4. Agenda
● Meaningful Names
● Functions
● Comments
● Classes

5. Meaningful Names
●
Intention Revealing Names
int d; // elapsed time in days
int elapsedTimeInDays;
public List<int[]> getThem() {
– List<int[]> list1 = new ArrayList<int[]>();
– for (int[] x : theList)
– if (x[0] == 4)
– list1.add(x);
– return list1;
– }

6. Questions
● 1. What kinds of things are in theList ?
● 2. What is the significance of the zeroth
subscript of an item in theList ?
● 3. What is the significance of the value 4 ?
● 4. How would I use the list being returned?

7. Answers
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}

8. Avoid Disinformation
XYZControllerForEfficientHandlingOfStrings
XYZControllerForEfficientStorageOfStrings
“Avoid disinformation” = “similar name with
different spelling”

9. Make Meaningful
Distinctions
● (a1, a2, .. aN)
public static void copyChars(char a1[], char a2[]) {
for (int i = 0; i < a1.length; i++) {
a2[i] = a1[i];
}
}

10. Use Pronounceable Names
class DtaRcrd102 {
private Date genymdhms;
private Date modymdhms;
private final String pszqint = "102";
/** */
};
class Customer {
private Date generationTimestamp;
private Date modificationTimestamp;;
private final String recordId = "102";
/* ... */
};

11. Use Searchable Names
for (int j=0; j<34; j++) {
s += (t[j]*4)/5;
}
int realDaysPerIdealDay = 4;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
for (int j=0; j < NUMBER_OF_TASKS; j++) {
int realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
int realTaskWeeks = (realdays / WORK_DAYS_PER_WEEK);
sum += realTaskWeeks;

12. Avoid Mental Mapping
● Avoid i, j, k
● Be a professional programmer than a smart
programmer

13. Class names & Method Names
● Class Name should be a Noun
● Method name should be a verb
● Don't be cute with names

14. Pick One Word per Concept But
don't pun
● For Fetching use only fetch, not retrieve and
get
● Don't pun means don't use add for inserting a
record into the database and adding two
numbers as well.

15. Domain Names and meaningful
context
● Use domain problem and solution names
● Don't use technical names
● Prefix or suffix for context

16. Functions
● Small
● Do one thing
● Use Descriptive Names
● Function Arguments
● Have No Side Effects
● Command Query Separation
● Don’t Repeat Yourself
● Structured Programming

17. Function Arguments
● Niladic is best, Monadic is better, Dyadic is good,
Triad is bad and Polyadic is worst
● Common Monadic Forms : when input gets
changed in the function
● Flag Arguments are ugly.
● Dyadic Functions
● Triad
● Argument Objects

18. Have No Side Effects
public class UserValidator {
private Cryptographer cryptographer;
public boolean checkPassword(String userName, String password) {
User user = UserGateway.findByName(userName);
if (user != User.NULL) {
String codedPhrase = user.getPhraseEncodedByPassword();
String phrase = cryptographer.decrypt(codedPhrase, password);
if ("Valid Password".equals(phrase)) {
Session.initialize();
return true;
}
}
return false;
}
}

19. Comments
“Don’t comment bad code—rewrite it.”

20. Comment practices
● Comments Do Not Make Up for Bad Code
● Explain Yourself in Code
if ((employee.flags & HOURLY_FLAG) &&
(employee.age > 65))
Or this?
if (employee.isEligibleForFullBenefits())
● Good Comments
● Bad Comments

21. Good Comments
● Legal Comments – for copyright and authorship
● Informative Comments
// format matched kk:mm:ss EEE, MMM dd, yyyy
– Pattern timeMatcher = Pattern.compile(
– "d*:d*:d* w*, w* d*, d*");
● Explanation of Intent
● Warning of Consequences
● TODO Comments
● Javadocs in Public APIs

22. Bad comments
● Mumbling
●
Redundant Comments
●
Misleading Comments
● Mandated Comments
● Journal Comments
●
Noise Comments
●
Position Markers
●
Closing Brace Comments
● Commented-Out Code
●
Too Much Information

23. Classes
● Variables at the beginning
● Keep class small
● Keep name for determining the responsibility
● Name should be able to described in 25 words.
● Single Responsibility Principle
● Cohesive
● Interfaces and abstract classes

24. Unit Test
●
1st
law: You may not write production code until
you have written a failing unit test.
●
2nd
law: You may not write more of a unit test than
is sufficient to fail, and not compiling is failing.
●
3rd
law: You may not write more production code
than is sufficient to pass the currently failing test.
● Unit tests are not second class citizen
● Its even more important than the architecture.

25. What makes a clean test?
● Ans: Three things. Readability, readability, and
readability
● Readibility = clarity, simplicity, density of
expression
● FIRST = Fast Independent Repeatable Self-
Validating Timely

26. Thank you !!!