By Nicholas Zakas CHAPTER 2If the first case wasn’t supposed to fall through, then it should end
with a statement such as break. In either case, the original code doesn’t
match the style guide and that means you need to double-check the intend-
ed functionality. In doing so, you might very well find a bug.
As another example, members of one of my teams decided that they did
not like using three values for padding or margin in CSS, such as:
.box {
padding: 5px 10px 6px;
}
The consensus was that three values didn’t clearly indicate the intent
of the author. Is it obvious that the fourth value was left off on purpose? Is
it an accident? While you may not think of this as a likely error condition,
my team did, and so we made a rule that you could have one, two or four
values for padding and margin but not three. That way, if we ever saw just
three values, we would know that it was a mistake of leaving off the fourth.
When you have a style guide, code that otherwise seems innocuous
immediately raises a flag because the style isn’t followed. This is one of
the most overlooked aspects of style guides: by defining what correct code
looks like, you are more easily able to identify incorrect code and therefore
avoid potential bugs before they happen.
Coding style takes care of what code looks like, which is an important
first step. The next step is to take care of how the code is organized, and
that’s where a good architecture comes into play.
Architecture
There is an interesting tension between developers and architects in most
software engineering organizations. Developers see architects as theo-
reticians who like to draw diagrams and make proclamations about how
software should be built, without taking into account that the world isn’t
perfect. Architects are frequently looked at as those who are incapable of