1. The document discusses principles and best practices for writing clean code as outlined in Chapter 3 of Clean Code by Robert Cecil Martin. It covers topics such as writing small and focused functions, using descriptive names, avoiding flag arguments, and separating commands and queries. 2. Key principles discussed include writing small functions that do one thing well, using block indentation to improve readability, and applying SOLID principles like the single responsibility, open/closed, and dependency inversion principles. 3. The document provides examples of applying these principles, such as extracting logic from functions, replacing switch statements with polymorphism, and avoiding output arguments in functions.

1. Clean Code
Chapter 3.
Author: Felix Chen

2. Categories
1. Small!
2. Block And Indenting

5. Small!
1. the first rule should be small
2. the second rule should be that they should be smaller than that.

6. Block And Indenting
1. This implies that the blocks within if statements, else statements, while
statements, and so on should be one line long. Probably that line should be a
function call. If you do so, you can obtain two benefits:
a. Enclosing function small
b. Add documentary values
c. Block can have a nicely descriptive name

7. 1. Functions should do one thing, They should do it well. They should do it only.
a. One level of abstraction per function
b. Tell whether a particular expression is an essential concept
2. One level of abstraction per function:
a. Higher: getHtml();
b. Middle: String pagePathName = PathParser.render(pagePath)
c. Lower: .append(“n”)
3. The Stepdown Rule: includeSetupsAndTeardownsIfTestPage()
a. To include the setups and teardowns, we include setups, then we include the test page
content, and then we include
i. To include the setups, we search the suite setup if this is a suite, then we include the
regular setup
1. To include the suite setup, we search the parent hierarchy for the SuiteSetUp ...
a. To search the parent
Do One Thing

8. SOLID
1. Single Responsibility Principle, SRP
2. Open/Closed Principle, OCP
3. Liskov Substitution Principle, LSP
4. Interface Segregation Principle, ISP
5. Dependency Inversion Principle, DIP

9. Single Responsibility Protocol, SRP
1. Each responsibility is an axis of change. That change will be manifest through a change in responsibility amongst the
classes.
2. More than one responsibility, then there will be more than one reason for it to change.
3. Rectangle has two methods, 1) Draws the rectangle, 2) Computes the area of the rectangle.
4. GeometricRectangle and ComputationalGeometryApplication classes are rendered cannot affect the
ComputationalGeometryApplication.

10. Open/Closed Principle, OCP
A class is closed, since it may be compiled, stored in a library, baselined, and used by client classes. But it is also open,
since any new class may use it as parent, adding new features. When a descendant class is defined, there is no need to
change the original or to disturb its clients.
1. OCP belongs to an abstract coupling.
2. Run Time Type Identification (RTTI)

11. Liskov Substitution Principle, LSP
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it:
1. Liskov Substitution Principle becomes an extension to OCP.
2. Violations of LSP are also meant to violations of OCP.
3. LSP depends on abstract coupling. Heavily depends on preconditions and postconditions.
a. Preconditions: A contract that must be satisfied before a method can be invoked.
b. Postconditions: It must be true upon method completion.
c. Here is an example:
i. public class InvalidAmountException extends Exception {...}, this class inherits from java base
Exception class. And can be thrown if the amount we try to deposit is less than zero. Create a new
class, public abstract deposit (int amt) throws InvalidAmountException {...}. A developer can not use
the following way to write a class, public void deposit (int amt) throws Exception {...} which is not
allowed.
4. The (o instanceof A_class) should not happen in a class file.

12. Liskov Substitution Principle, LSP
1. Supertype-Subtype relations between types (classes) defining a taxonomic hierarchy, where
a. For a subsumption relation: a subtype, subclass has a type-of (is-a) relationship with its supertype, superclass
2. Whole/Entity/Container-part/Constituent/Member
a. For an aggregation relation (Iterator):
i. a whole has a has-a relationship with its part
b. For a composition relation:
i. a constituent has a part-of relationship with its entity.
c. For a containment:
i. a member has a member-of relationship with its container
3. Type-Token relations between classes and instances, where
a. an object has an instance-of relationship with its class
4. Composition is dynamic binding (run time binding), whereas inheritance is static binding (compile time binding)
5. UML diagram:

13. Liskov Substitution Principle, LSP
1. PersistentSet::Add:
template <class T>
void PersistentSet::Add (const T& t)
{
// using const will postpone the error to the runtime
// ,throw bad_cast
PersistentObject &p =
dynamic_cast<PersistentObject &>(t);
itsThirdPartyPersistentSet.add(p);
}
2. The logic flaw is
a. Either the decision to pass a PersistentSet into the failed function
b. or it is the decision to add an object to the PersistentSet that is not derived from PersistentObject.

14. Liskov Substitution Principle, LSP
4. template <class T>
void PersistentSet::Add(const T& t)
{
// this will generate a compiler error if t is not derived from PersistentObject.
itsThirdPartyPersistentSet.Add(t);
}

15. Interface Segregation Principle, ISP
No client should be forced to depend on methods it does not use. ISP splits interface into smaller and more specific ones.
1. Can employ the object form of the Adapter pattern to the TimedDoor problem..
2. Drives from TimerClient and delegates to the TimedDoor.
3. TimedDoor wants to register a timeout request with the Timer. It creates a DoorTimerAdapter and registers it with the
Timer.
4. Adapter calls TimedDoor by TimeOut which is inherited from TimerClient.

16. Interface Segregation Principle, ISP
5. Separation through Multiple Inheritance, (author prefers to use this way rather than adapter design pattern, except
that DoorTimerAdapter is necessary)
a. TimedDoor inherits from both Door and TimerClient.
b. class TimedDoor: public Door, public TimerClient
{
public :
virtual void TimeOut (int timeOutId);
};

17. Dependency Inversion Principle, DIP
1. High level modules should not depend upon low level modules. Both should depend upon abstractions.
2. Abstractions should not depend upon details. Details should depend upon abstractions.
3. Let us talk a look at the two diagrams shown in this slide:
a. Figure 3: Simple Layers will cause a problem because dependency is transitive.
b. Figure 4: Lower level layers are represented by an abstract class. The actual layers are derived from these
abstract classes. Not only is the transitive dependency of Policy Layer upon Utility Layer broken, but even the
direct dependency of Policy Layer upon Mechanism Layer is broken.

18. Switch Statement
Can make sure (polymorphism):
1. switch statement is buried in a low-level class
2. It is never repeated.

19. Abstract Design Pattern v.s. Switch Statement
public abstract class Employee {
public abstract boolean isPayday();
public abstract Money calculatePay();
public abstract void deliveryPay(Money pay)
}
-----------------------
public interface EmployeeFactory {
public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType;
}
----------------------
public class EmployeeFactoryImpl implements EmployFactory {
public Employee makeEmpoyee(EmployeeRecord r) throws InvalidEmployeeType {
switch (r.type) {
...
}
}
}

20. Use Descriptive Names
Modern IDEs like Eclipse or Intellij make it trivial to change names.
1. Don’t be afraid to make a name long
2. Don’t be afraid to spend time choosing a name.
3. Be consistent in your names

21. Function Arguments
1. Zero argument (niladic), One argument (monadic), Two arguments (dyadic),
Three arguments (triadic) should be avoided!
2. More than three requires very special justification.

22. Monadic
1. boolean fileExists(“MyFile”), transforms a file name String into an InputString
return value.
2. void passwordAttemptFailedNtimes(int attempts), single argument function is
an event, but no output argument.
3.

23. Flag Arguments
1. Flag arguments are ugly.
2. loudly proclaim that this function does more than one thing.
3. If you encounter this situation, you can extract the statements, like so, it
replaces render(boolean isSuite) into the followings:
a. renderForSuite()
b. renderForSingleTest()

24. Dyadic Functions
1. A function with two arguments is harder to understand than a monadic
function.
a. changes writeField(outputStream, name) to outputStream.writeField(name) by adding
writeField(name) into outputStream class.
2. Point p = new Point(0,0), two arguments are appropriate.
3. assertEquals(expected, actual) are problematic. Why?

25. Triadic Function
1. Functions that take three arguments are significantly harder to understand
than dyads.
2. assertEquals(message, expected, actual).
3.

26. Output Arguments
1. appendFooter(StringBuffer report), you would not like to use report as an
output argument.
2. Arguments are most naturally interpreted as inputs to a function.
3. Output arguments should be avoided.
4. Use this to act as an output argument.

27. Command Query Separation
1. Functions should either do something or answer something, but not both.
2. Use two methods to replace one method. As follows,
a. attributeExists(“username”)
b. setAttribute(“username”,”unclebob”)
c. Here is an example:
if (attributeExists(“username”)) {
setAttribute(“username”, “unclebob”);}

28. Extract Try/Catch Blocks
Original After:

29. References
1. Clean Code, Book by Robert Cecil Martin
2. Java Design: Objects, UML, and Process