Clean Code

G32: 
Don’t Be Arbitrary
Have a reason for the way you structure your code, and make sure that reason is communi-
cated by the structure of the code. If a structure appears arbitrary, others will feel empowered
to change it. If a structure appears consistently throughout the system, others will use it
and preserve the convention. For example, I was recently merging changes to FitNesse and
discovered that one of our committers had done this:
public class AliasLinkWidget extends ParentWidget
{
public static class VariableExpandingWidgetRoot {
...
...
}

---

304
Chapter 17: Smells and Heuristics
The problem with this was that 
VariableExpandingWidgetRoot
had no need to be
inside the scope of 
AliasLinkWidget
. Moreover, other unrelated classes made use of
AliasLinkWidget.VariableExpandingWidgetRoot
. These classes had no need to know
about
AliasLinkWidget
.
Perhaps the programmer had plopped the 
VariableExpandingWidgetRoot
into
AliasWidget
as a matter of convenience, or perhaps he thought it really needed to be
scoped inside 
AliasWidget
. Whatever the reason, the result wound up being arbitrary. Pub-
lic classes that are not utilities of some other class should not be scoped inside another
class. The convention is to make them public at the top level of their package.
G33: 
Encapsulate Boundary Conditions
Boundary conditions are hard to keep track of. Put the processing for them in one place.
Don’t let them leak all over the code. We don’t want swarms of 
+1
s and 
-1
s scattered hither
and yon. Consider this simple example from FIT:
if(level + 1 < tags.length)
{
parts = new Parse(body, tags, level + 1, offset + endTag);
body = null;
}
Notice that 
level+1
appears twice. This is a boundary condition that should be encapsu-
lated within a variable named something like 
nextLevel
.
int nextLevel = level + 1;
if(nextLevel < tags.length)
{