[thelist] Coding standards....

Lee kowalkowski lee.kowalkowski at googlemail.com
Thu Dec 7 11:30:41 CST 2006

On 07/12/06, Chris Ditty <cditty at gmail.com> wrote:
> The company that I work for currently does not have any coding
> standards.  No comments, no stylesheet usage, no nothing.  I have
> spoken with my supervisor about this and she has commented that she
> would like to try and get some standards in place.
> Can a few of you share your coding standards?  Below is what I
> currently have, but I am drawing a blank on what else needs to be
> said.

Typical standards documents tend to group rules into standards and
guidelines.  Standards are absolute requirements and must be followed.

Guidelines describe practice that is encouraged.  There may be valid
reasons to ignore a guideline in particular circumstances, but it's
important to understand and carefully weigh the implications before
choosing a different course.  "It's just a guideline" is not a good
enough reason; all exceptions to guidelines must be justified.

Regardless of whether a rule is a standard or a guideline, it's a good
idea to write them in a manner that implies that they're mandatory.
This facilitates the promotion/demotion of rules, and reinforces the
notion that the guidelines aren't there to be ignored.

Rather than dictate my coding standards, I'll list a few decisions
that you ought to make for yourself and incorporate into your

Which DOCTYPE should be used?  Which character set?

What naming convention?  CamelCase?  What about acronyms?  toXML() or
toXml()?  XMLDocument or xmlDocument?

Tabs or spaces for indentation?  If spaces, how many?  Where should
new-lines go in statement blocks?

Do you use the LABEL element in forms?  Is it explicit or implicit labelling?

What are your conventions for form-field tabbing?

Named HTML entities or numbered?

Do you always put width & height attributes on inline images?  Do you
use inline images for style?  Do you use inline images for space at

Do you allow more than one H1 element in your pages?  Can you use a H3
heading if there's no subsequent H2?

Do you have an access key policy?

Are you allowing style attributes or style elements?

Do you support clients without JavaScript?  Do you think the eval
function or with construct should be used?

You may also like to incorporate any past gotcha's you have
encountered into your standards, like not naming form fields "submit",
and not using underscores in class names.

Good luck.


More information about the thelist mailing list