By Nicholas Zakas CHAPTER 2Some developers rebel when presented with style guides, believing that
they can’t properly do their job if someone is telling them how to write
their code.
I liken the situation to a group of musicians trying to form a band. Each
one comes in believing that their way of doing things is best (their method
or process). The band will struggle so long as everyone is trying to do their
own thing. It’s impossible to create good music unless everyone in the band
agrees on the tempo, the style, and who should take the lead during a song.
Anyone who has ever heard a high school band perform knows this to be
true. Unless everyone is on the same page, you aren’t going to accomplish
much. That’s why I strongly recommend style guides for software develop-
ment teams. Getting everyone on the same page is difficult, and the style
guide is a great place to start. By having everyone write code that looks the
same you can avoid a lot of problems down the road.
CoMMuniCaTion iS KeY
Programs are meant to be read by humans
and only incidentally for computers to execute.— Harold Abelson and Gerald Jay Sussman,
Structure and Interpretation of Computer Programs, 1984The most important thing when working in a team is communication.
People need to be able to work together effectively and the only way to
do that is by communicating. As developers, we communicate primarily
through code. We communicate with other parts of the software through
code and we communicate with other developers through code.
While the software your code communicates with doesn’t care how the
code looks, the other developers on your team certainly do. The way code
looks adds to our understanding of it. How many times have you opened
up a piece of code that somebody else wrote and, before doing anything