Bitter hygiene - Bitter Java - page 277

leadership team is likely to have at least one member with an old style
guide that can be adapted for use.
Buy one and modify it. Out of the box, no style guide is going to work
for a team of strong programmers with distinct personalities. I recom-
mend the approach of taking a guide and trimming it, rather than
adding to it or combining multiple guides. The idea is to build a short,
concise guide that works. Did I mention short ?

9.7.2 A sample style guide from Contextual, Inc.

This section contains the style guide used by Contextual, Inc., a startup based
in Austin, Texas (http: // www.contextual.com). I worked with the same people
at allmystuff; they interview aggressively and tend to do a good job of screen-
ing for good understanding and hygiene. Therefore, their style guide reflects
an advanced community. They use XP principles, including a shared code base,
so their style guide reflects source code structure and spacing for consistency.
They use Emacs extensively within their base development environment; there-
fore, advanced regular expression searches, which look for certain patterns as
well as fixed text, are important to them. As such, punctuation rules dictating
the use of white space and braces are prevalent in their style guide.
They decided to publish a short style guide that captured the basic essence
in two short web pages. The guide resides on their intranet, so the whole team
can get to it quickly.
My thanks to Brian Dainton at Contextual for providing this style guide.
Reviewing Contextual's style guide
With slight modifications, this is the style guide used by Contextual, Inc., a startup
based in Austin, Texas. The guide is short by design. All programmers can access the
guide. Violations of the style guide are usually handled one-on-one, but frequent
offenses or common community violations are broadcast. (Used with permission of
Contextual, Inc., 2001.)

Enclose statements such as if , while , and for within open and closed
curly braces even if the body is a single line.

Typically, import statements should import java.util.* rather than
java.util.Vector to make maintainability simpler.

Name all objects as if they were in the same package as all the JDK and
other application objects.

Make variables names descriptive and never abbreviate them.