Clean Code

G23: 
Prefer Polymorphism to If/Else or Switch/Case
This might seem a strange suggestion given the topic of Chapter 6. After all, in that chapter I
make the point that switch statements are probably appropriate in the parts of the system
where adding new functions is more likely than adding new types.
First, most people use switch statements because it’s the obvious brute force solution,
not because it’s the right solution for the situation. So this heuristic is here to remind us to
consider polymorphism before using a switch. 
Second, the cases where functions are more volatile than types are relatively rare. So
every
switch statement should be suspect. 
I use the following “O
NE
S
WITCH
” rule: 
There may be no more than one switch state-
ment for a given type of selection. The cases in that switch statement must create polymor-
phic objects that take the place of other such switch statements in the rest of the system.
G24: 
Follow Standard Conventions
Every team should follow a coding standard based on common industry norms. This cod-
ing standard should specify things like where to declare instance variables; how to name
classes, methods, and variables; where to put braces; and so on. The team should not need
a document to describe these conventions because their code provides the examples.
item.tenths = e.getTenthsWorked() % 10;
page.add(item);
}
public class LineItem {
public String name;
public int hours;
public int tenths;
}
}
Listing 17-1 (continued)
HourlyReporter.java

---

300
Chapter 17: Smells and Heuristics
Everyone on the team should follow these conventions. This means that each team
member must be mature enough to realize that it doesn’t matter a whit where you put your
braces so long as you all agree on where to put them. 
If you would like to know what conventions I follow, you’ll see them in the refactored
code in Listing B-7 on page 394, through Listing B-14.