Do you have coding standards? If so, how is it being enforced?

Question

I've worked on a couple of projects where we have spent a great deal of time discussing and writing elaborate coding standards covering everything from syntax layout to actual best practices. However, I have also found that these are rarely followed to the full extend. Many developers seem to hesitate to reject a code review based on coding standard violations alone. I.e. violations are committed to the repository on a regular basis.

My questions are: Do you have coding standards? What does it cover? Is it being followed by everyone? And what do you do (if anything) to make sure everybody is following the standard?

I'm aware, that there is a similar question here, but my concern is not so much how you could do it, but how you are actually going about it and what are the perceived benefits?

Answer 1

We take use of the Eclipse's save actions and formatters. We do have a suggested standard, but nobody is actually enforcing it, so there are some variations on what is actually formatted, and how.

This is something of a nuisance (for me), as various whitespace variations are committed as updates to the SVN repository...

Answer 2

I've worked in places with barely-followed coding practices, and others where they're close to being enforced - or at least easily checked.

A few suggestions:

• The most important thing is to get buy-in to the idea that consistency trumps your personal preferred style. There should be discussion of the coding standard both before and after it's instituted, but no-one should be allowed to just opt out of it.
• Code reviews should be mandatory, with the checkin comment including the username of the reviewer. If you're using a suitably powerful SCM, consider not allowing checkins which don't have a valid reviewer name.
• There should be a document which everyone knows about laying out the coding standards. With enough detail, you shouldn't get too much in the way of arguments.
• Where possible, automate checking of the conventions (via Lint, CheckStyle, FXCop etc) so it's easy for both the committer and the reviewer to get a quick check of things like ordering import/using directives, whitespace etc.

The benefits are:

• Primarily consistency - if you make it so that anyone can feel "at home" in any part of the codebase at any time, it gives you more flexibility.
• Spreading best practice - if you ban public fields, mutable structs etc then no-one can accidentally plant a time bomb in your code. (At least, not a time bomb that's covered by the standard. There's no coding standard for perfect code, of course :)

EDIT: I should point out that coding standards are probably most important when working in large companies. I believe they help even in small companies, but there's probably less need of process around the standard at that point. It helps when all the developers know each other personally and are all co-located.

Answer 3

I have never seen a project fail because of lack of coding standards (or adherence to them), or even have any effect on productivity. If you are spending any time on enforcing them then you are wasting money. There are so many important things to worry about instead (like code quality).

Create a set of suggested standards for those who prefer to have something to follow, but leave it at that.

Answer 4

I think the best way to look at coding standards is in terms of what you hope to achieve by applying, and the damage that they can cause if mis-applied. For example, I see the following as quite good;

• Document and provide unit tests that illustrate all typical scenarios for usage of a given interface to a given routine or module.
• Where possible use the following container classes libraries, etc...
• Use asserts to validate incoming parameters and results returned (C & C++)
• Minimise scope of all variables
• Access object members through methods
• Use new and delete over malloc and free
• Use the prescribed naming conventions

I don't think that enforcing style beyond this is a great idea, as different programmers are efficient using differing styles. Forcing programmers to change style can be counter productive and lead to lost time and reduced quality. Standards should be kept short and easy to understand.

Answer 5

Do you have coding standards?

Yes, differs from project to project.

What does it cover?

Code(class, variable, method, constant), SQL naming and formatting convention

Is it being followed by everyone?

Yes, every new entrant in project could be asked to create a demo project following organization coding convention then it gets reviewed. This exercise makes developer feel at ease before starting real job.

And what do you do (if anything) to make sure everybody is following the standard?

Use StyleCop and FxCop to ensure they are religiously followed. It would show up as warning/error if code fails to comply with organization coding convention.

Visual Studio Team system has nice code anlysis and check-In policies which would prevent developers checking in code that does not comply

Hope, it helps

Thanks, Maulik Modi

Answer 6

StyleCop does a good job of enforcing coding layout practices and you can write custom rules for it if something isn't covered in the base rules that is important to you.

Answer 7

Oh yes, I'm the coding standard police :) I just wrote a simple script to periodically check and fix the code (my coding standard is simple enough to implement that.) I hope people will get the message after seeing all these "coding convention cleanups" messages :)

Answer 8

We have a kind of 'loose' standard. Maybe because of our inability to have agreement upon some of those 'how many spaces to put there and there', 'where to put my open brace, after the statement or on the next line'.

However, as we have main developers for each of the dedicated modules or components, and some additional developers that may work in those modules, we have the following main rule:

"Uphold the style used by the main developer"

So if he wants to do 3 space-indentation, do it yourself also.

It's not ideal as it might require retune your editor settings, but it keeps the peace :-)

Answer 9

Do you have coding standards? What does it cover?

Yes, it has naming conventions, mandatory braces after if, while ... , no warning allowed, recommendations for 32/64 bits alignment, no magic number, header guards, variables initialization and formatting rules that favor consistency for legacy code.

Is it being followed by everyone? And what do you do (if anything) to make sure everybody is following the standard?

Mostly, getting the team agreement and a somewhat lightweight coding standard (less than 20 rules) helped us here.

How it is being enforced ?

Softly, we do not have coding standard cop.

• Application of the standard is checked at review time
• We have template files that provide the standard boilerplate

Answer 10

I think coding standards are very important. There is nothing more frustrating than trying to find the differences between two revisions of a file only to find that the whole file has been changed by someone who reformatted it all. And I know someone is going to say that that sort of practice should be stamped out, but most IDEs have a 'reformat file' feature (Ctrl-K Ctrl-D in Visual Studio, for example), which makes keeping your code layed out nicely much easier.

I've seen projects fail through lack of coding standards - the curly-brace wars at my last company were contributary to a breakdown in the team.

I've found the best coding standards are not the standards made up by someone in the team. I implemented the standards created by iDesign (click here) in our team, which gets you away from any kind of resentment you might get if you try to implement your own 'standard'.

A quick mention of Code Style Enforcer (click here) which is pretty good for highlighting non-compliance in Visual Studio.

Answer 11

JTest by ParaSoft is decent for Java.

Answer 12

Our coding standards are listed in our Programmer's Manual so everyone can easily refer to them. They are effective simply because we have buy in from all team members, because people are not afraid to raise standards and style issues during code reviews, and because they allow a certain level of flexibility. If one programmer creates a new file, and she prefers to place the bracket on the same line as an if statement, that sets the standard for that file. Anyone modifying that file in the future must use the same style to keep things consistent.

I'll admit, when I first read the coding standards, I didn't agree with some of them. For instance, we use a certain style for function declarations that looks like this:

    static       // Scope
    void         // Type declaration 
func(

char   al,                //IN: Description of al
intl6u hash_table_size,   //IN/OUT: Description of hash_table_size
int8u  s)                 //OUT: Description of s
{
<local declarations>

        <statements>
}

I had never seen that before, so it seemed strange and foreign to me at first. My gut reaction was, "Well, that's dumb." Now that I've been here a while, I have adjusted to the style and appreciate how I can quickly comprehend the function declaration because everyone does it this way.

Answer 13

I have a combination of personal and company coding standards that are still evolving to some extent. They cover code structure, testing, and various documents describing various bits of functionality.

As it evolves, it is being adopted and interpreted by the rest of my team. Part of what will happen ultimately is that if there is concensus on some parts then those will hold up while other parts may just remain code that isn't necessarily going to be up to snuff.

I think there may be some respect or professional admiration that act as a way of getting people to follow the coding standards where some parts of it become clear after it is applied, e.g. refactoring a function to be more readable or adding tests to some form, with various "light bulb moments" to borrow a phrase from Oprah.

Another part of the benefit is to see how well do others work, what kinds of tips and techniques do they have and how can one improve over time to be a better developer.