Clean Code: Chapter 3 Function

1. Clean Code
Chapter 3: Function
Kent Huang

2. Outline
• Case Study: HtmlUnit.java
• Small
• Switch
• Argument
• Error handle
• Structured Programming
• Conclusion

3. Case Studying
Sample Code
Listing 3-1
Sample Code
Listing 3-2

4. What’s different??
• What is it makes a function like Listing3-2 easy
to read and understand?
• How can we make a function communicate it
intent?
• What attribute can we give our functions
allow a casual reader to intuit the kind of
program they live inside?

5. Small
• Rules of functions:
– Should be small
– Should be smaller than that
• < 150 character per line
• < 20 lines
public static String renderPageWithSetupsAndTeardowns(
PageData pageData, boolean isSuite) throws Exception {
if (isTestPage(pageData))
includeSetupAndTeardownPages(pageData, isSuite);
return pageData.getHtml();
}

6. Do One Thing
• Functions should do one thing. They should do
it well. They should to it only.
• Listing 3-3 do three things
1. Determining whether the page is a test page.
2. If so, including setups and teardowns.
3. Rendering the page in HTML.

7. Is It?
• If a function does only those steps that are
one level below the stated name of the
function, then the function is doing one thing
• If you can extract another function from it
with a name that is not merely a restatement
of its implementation

8. One Level of Abstraction per Function
• In Listing3-1
– High level: getHtml(),PathParser.render(pagePath)
– Low level: .append(“n”)
• Broken windows
– Once details are mixed with essential concepts,
more and more details tend to accrete within the
function

9. Reading Code from Top to Bottom
• The Stepdown Rule:
– We can read the program, descending one level of
abstraction at a time as we read down the list of
functions

10. Switch Statements
public Money calculatePay(Employee e) throws InvalidEmployeeType {
switch (e.type) {
case COMMISSIONED:
return calculateCommissionedPay(e);
case HOURLY:
return calculateHourlyPay(e);
case SALARIED:
return calculateSalariedPay(e);
default:
throw new InvalidEmployeeType(e.type);
}
}
1. It’s large, and when new employee type are added, it will grow.
2. Does more than one thing.
3. Violates the Single Responsibility Principle
4. Violates the Open Closed Principle
5. There are an unlimited number of other functions will have same
structure.

11. public abstract class Employee {
public abstract boolean isPayday();
public abstract Money calculatePay();
public abstract void deliverPay(Money pay);
}
-----------------
public interface EmployeeFactory {
public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType;
}
-----------------
public class EmployeeFactoryImpl implements EmployeeFactory {
public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType {
switch (r.type) {
case COMMISSIONED:
return new CommissionedEmployee(r);
case HOURLY:
return new HourlyEmployee(r);
case SALARIED:
return new SalariedEmploye(r);
default:
throw new InvalidEmployeeType(r.type);
}
}
}

12. Use Descriptive Names
• Don’t be afraid to make a name long
• A long descriptive name is better than a long
descriptive comment
• Use the same phrases, nouns, and verbs in the
function names
– Ex: includeSetupAndTeardownPages, includeSetupPages,
includeSuiteSetupPage, includeSetupPage

13. Function Arguments
• The ideal number of arguments for a function
is zero (niladic).
0 > 1 > 2 > 3 >> 4
• Arguments are even harder from a testing
point of view.

14. Common Monadic Forms
• If a function is going to transform its input
argument, the transformation should appear
the return value
• StringBuffer transform(StringBuffer in)
• Void transform(StringBuffer out) 

15. Flag Arguments
• Flag arguments are ugly
rander(true) 
renderForSuite() 
renderForSingleTest() 

16. Dyadic Functions
• Function with two arguments is harder to
understand than one
– writeField(name) v.s writeField(outputStream, name)
• Some times, two arguments are appropriate.
– Point p = new Point(0,0);
• Still have problem
– assertEquals(expected, actual)

17. Triads
• Don’t use!!!
– assertEquals(message, expected, actual) 
• Argument Objects
– Circle makeCircle(double x, double y, double radius);
– Circle makeCircle(Point center, double radius);

18. Verbs and Keywords
• Choosing good names for a function can go a
long way toward explaining the intent of the
function and the order and intent of the
arguments.
– Write(name)
– WriteField(name)
– AssertEquals(expected, actual)
– AsertExpectedQqualsActual(expected,actual)

19. 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;
}
}

20. Output Arguments
• appendFooter(s);???
– public void appendFooter(StringBuffer report)
• report.appendFooter();

21. Command Query Separation
• if (set("username", "unclebob"))...
– public boolean set(String attribute, String value);
if (attributeExists("username")) {
setAttribute("username", "unclebob"); ...
}

22. Prefer Exceptions to Returning Error
Codes
if (deletePage(page) == E_OK) {
if (registry.deleteReference(page.name) == E_OK) {
if (configKeys.deleteKey(page.name.makeKey()) == E_OK){
logger.log("page deleted");
} else {
logger.log("configKey not deleted");
}
} else {
logger.log("deleteReference from registry failed"); }
} else {
logger.log("delete failed"); return E_ERROR;
}
try {
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
}
catch (Exception e) {
logger.log(e.getMessage());
}

23. • Don’t Repeat Yourself
– Duplication may be the root of all evil in software
• Structured Programming
– Edsger Dijkstra’s rules
• One entry, one exist
• Never, ever, ant goto
– When function is small
• Multiple return, break, continue are ok
• Goto only makes sense in large functions

24. Conclusion
• Every system is built from a domain-specific
language
– Functions are the verbs of that language
– Classes are the nouns
• Master programmer do:
– Functions are short, well named and nicely
organized
– Never forget, your real goal is to tell the story of
the system

25. The End