How do you enforce coding standards in your team?

Question

We are a .NET shop, mostly coding using C# in VS. We created coding standards for our organization, and now we need to enforce them. We can use tools like FxCop & StyleCop.

What we want:

1. On each developer's PC, have settings that will give them a warning or error when they compile their code.
2. When they check in the code into version control, don't let them check in if they don't follow company's coding standards.

How can we achieve this? How does your team enforce coding standards?

I'm looking to learn how you do that, so we can improve our procedures.

Related:

What should coding guidelines do, and are there any good examples of guidelines?

---

Update:

Our setup:

IDE: VS 2008

Virsion control: Currenlty it's StarTeam but in a near feature it's going to be SVN.

In our build process we use CruiseControl.Net with NAnt scripts.

Answer 1

If you are using Team Foundation Server (TFS) for your version control, you can set up a continuous integration build type, and have the build automatically run static code analysis tools, such as FxCop, NDepend, Simian.

You can also set up rules, that prevent check-ins without comments, prevent check-in if unit tests not passing etc.

EDIT: in response to your comment about SVN, check out CruiseControl.NET and Nant. Also CIFactory is a low friction way of quickly setting up a CI build system.

Answer 2

You can setup the standards on each dev's IDE, and have it as a precheckin check as well. But more importantantly, you need

• Buy in from management
• Consensus among your team members about the standard
• Understanding and appreciation among your team members about why this is important.

The last one is tough to achieve, especially in teams where the members come from diverse backgrounds, or there are a lot of junior members, or there are the hack-and-run kinds. But the first two can be followed - and hopefully the third will come by itself over time.

My answer is assuming you were asking about how to do this in general, and not for a specific technology/IDE/build system/source control system.

Answer 3

We've done this previously by turning on "Warnings as Errors" as a compiler flag. Then we also enforce running FxCop (and StyleCop) as part of the build.

Continuous Integration fails quite quickly if developers don't adhere to standards.

This can all be achieved through Visual Studio Team System and Team Foundation Server.

Answer 4

How can you turn coding standard violations into warning / errors?

This is dependent upon what tools you're using for coding standards. For instance it's possible to make FxCop violations build errors in Visual Studio. Just ensure that code analysis is enabled for running on all of your build configurations. This will effectively turn coding standard violations into build errors.

I'm not familiar with StyleCop but I'm sure there is a similar way to turn it into a build error.

How to prevent checkins of standards violating code?

This is impossible to answer without understanding your source code control solution. With certain providers such as TFS, you can set check in policies. A check-in policy is a check run on the client before code is submitted. If the check fails then the code is not allowed to be checked in. It's certainly possible to define a policy which checks for successfull builds and hence enforces your coding standards.

But again, this is highly dependent upon what your source code solution is. Can you elaborate?

Answer 5

Systematic code reviews + a good dose of goodwill (and a standard that's been agreed upon by the developers)

Answer 6

We use FxCop and StyleCop

Answer 7

This isn't a technical problem, it's a people problem. It's also widely dealt with in the Open Source / Free Software community. A good answer from there is to require OKs from other team members for a commit. That serves to enforce standards and also as a sanity check and/or peer review.

It really comes down to how serious you are about enforcing standards. If you had a developer who was constantly writing horrible, buggy code then what would you do? Are you willing to treat your standards in anything like the same serious manner? If not, why not? Developers tend to give you what they think is important, but they usually tell by what you do, not what you say.

Answer 8

Not only do you need mgmt buy-in, but you need programmer buy-in. If you developers don't think this is a good idea then you lose. Well the code will meet the letter of the standards, but, it will break every intent of the standards. Don't bet your developers can't do this? Try them. 'But aSdFfFfG is a variable name which meets the naming requirements. And so is AsDFFfFg. What's wrong with them?'

This is the carrot way.

The stick way could involve having someone approve the code once it is checked in. This can be shared around, ie, 60% of your time coding, 20% reviewing, etc.

When that fails you can always use the cattle prod that you keep next to your desk. Of course, maybe that developer is more trouble then he/she is worth it then.

Answer 9

Coding standards can be just a management shortcut to avoid actually managing a team. It's a lot easier (and less confrontational) to just "turn on" the automated tool on a developer's output than it is to actually evauluate them, and their work, and make decisions, and then act on them. It also deflects the confrontational issues from yourself as a manager, to the "rules". I guess in a way it's unavoidable, as making judgments about people and acting on those judgments maturely and productively is a rare talent, not a common one. But to me it's a clear sign of a poorly managed team when I see a manager who does not evaulate the quality of his/her team, or the code they produce, but instead relies on absolute rules or automated tools.

That's not to say that anything goes... Developers and the code they produce must be managed. But way better is to evaluate them and their code individually, on the real end game quality aspects that matter. Which ones matter depends on the situation. The aspects that can be important include maintainability, readability, extensibility, as well as performance, or "slickness". If it's a framework for use by other developers down the road, a whole other set of considerations should apply. Useability, cogent and clear method naming and namespace organization, internal Xml documentation (for intellisense). Take the time to personally (use the better "star" members of your team to help, but you as the manager should make the final judgment, and deliver the message). Evaluate each member of your team and their work, on these real aspects, the ones that matter. Give them honest feedback on your judment and the opportunity to correct and improve the quality of their work. And take the appropriate actions when they cannot.

And don't fall into the trap that it's ALWAYS more readable when it conforms to the absolute standard established in some document. "Standards" established to improve readability 10 years ago, when IDEs were all monocolor, don;t apply the same today when code editors are intelligentlyu color-coded. Naming conventions designed before intellisense existed don;t quite accoplish whjat they were designed for when using modern IDEs.

If you do establish standards, try to ensure that they are minimuims, not absolutes... To those who regularly and habitually produce exceptional code, it's annoying to have to "dumb down" or reduce the quality of your code, simply to meet a "standard".... So, you have to either be willing to make exceptions, (how does the rest of the team react to that?) or write your "standards" definitions (and your automated tools that eveluate the code) so that code that violates them in the "better" direction is not flagged as a violation. Not so easy... What actually happens in practice is that the manager "ignores" the "violations" by the stars on the team, and everyone else either gets resents it, or gradually, no one folows the rules at all. (Why should I do it that way -- He doesn't have to")

Answer 10

G'day,

I've written C++ coding standards for major companies. One lesson I've learnt regarding adoption of coding standards is to spell out the advantages of adhering to the coding standards to those using the standards. In fact, my last set of C++ coding standards provided the reasoning behind each of the rules that were provided.

They weren't "carved in stone" either, so if someone had a good reason to change something the suggestion was listened to.

Steve McConnell's excellent book "Code Complete" (sanitised Amazon link) has several excellent sections that cover reasoning behind using coding standards.

Off the top of my head, I can think of several:

1. enforcing naming standards frees people's heads to work on the more interesting aspects of the code. For example, the author can work on the algorithms to be used rather than spending ages working out what to call this class, or variable.
2. contrary to some people's beliefs, it does improve maintainability of code and allows someone to pick up some new code that's been written to the same standard and understand it much faster than if they have to work out the author's naming conventions, architectural style, code layout techniques, etc. If you say that the IDE enforces this, then you are simply copping out by pushing the coding standard into that enforced by the IDE being used.
3. enforcing semantics for constructs minimises problems with the designs. For example, having a guideline that "public inheritance shall only be used to implement an 'isa' relationship" means that the script kiddies who want to use inheritance because "it's a really cool way to bring in functionality under the covers" can't do that.

HTH

cheers,

Answer 11

Coding standards exist to improve the maintainability of the code your team produces, which can be a huge cost burden in the long term.

If developers aren't adhering to your coding standards, you need to first answer the following questions:

1. Do the coding standards make sense? (i.e. are they self-consistent & simple to remember?)

2. Do the coding standards actually improve the readibility and maintainability of the code?

3. Are the coding standards easy to use? (i.e. ensure your IDE supports them natively)

If the answer to any question is not a definite "yes" then you've got to rethink your code standards - because if you can't explain their benefit why should the developers adhere to them?

For the above reason a good coding standard should be able to be documented on just one page, perhaps with a small amount of sample code.