Does your team have its own coding guidelines?

Question

Does your team develop its own coding guidelines? How long is the document? How often do you read/need it? How often do you make mistakes by not abiding to the guidelines?

Who has permission to edit it?

Answer 1

Yes we do only a small group actually make edits and distributes new versions, but we are very much open to discussion and dialog.

We try to take this seriously as many customers have also ask us for our guidelines and do share them.

Answer 2

Most of the development teams I've worked with have had coding guidelines.

Most of the guideline documents I've seen average 5 to 15 pages.

I find that once I've studied the guide I don't need to refer to it very often at all.

I've found that the guidelines rarely need to be edited and when they do, the team usually does it together.

Most mistakes are found during code reviews and don't happen very often unless the guideline is something really weird.

We had a guideline that stated that there must be a space between each parenthesis and the next character, like ( chars ), which I found pretty onerous - I broke that a lot. I think VS 2005 won't even let you do that or at least it defaults to removing those spaces.

This link goes directly to Juval Lowy's excellent c# coding guidelines. It's a great place to start.

Answer 3

Yes we did. One person edited it and did an excellent job on it. You would typically read it when first joining the group and had nothing better to do. No one edited it later since no one was interested or had the time. Many of the guidelines were motivated by readability and the ability to easily step through individual lines of code in softice, or to eliminate errors related to debugging code. The coding standards were treated company secret. About 10 pages.

Answer 4

We (a C++ team) use the Google C++ Style Guide with a couple of modifications. The important thing is to be consistent and the Google style is a great place to start IMHO.

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Answer 5

If you're doing .Net development, I would recommend this. It bascially sums up Microsoft's recommended conventions (with a few changes) and can almost be put into a single page.

My goal with our coding standards was to keep them short and keep them consistent with the framework. From past experience, I can safely say that long, unconventional standards don't work. If a developer has to read 50 pages to learn them they just don't get followed.

Answer 6

In languages where they're available -- eg, C with indent -- instead of detailed coding guidelines, or in addition to them, publish a standard reformatting command. Code can then be normalized in a simple operation.

Beyond that, just be cautious of fancy style guidelines; you can waste a lot of time on religious disputes over

}
else
{

versus

} else {

Answer 7

We sat down and hashed them out in about half an hour, and they fit on a sheet of notepad paper. Mostly naming conventions for classes, methods, properties, global variables, function variables, etc. I needed to refer to them a few times the first day and haven't since. My junior colleague has needed to be reminded of them several additional times. :)

Answer 8

Generally, it is better to stick to industry standards than reinvent the wheel.
Depending on platform we use, there are

• Google C++ Style Guide

• Framework Design Guidelines (contains C# coding style guidelines)