[Team] Coding Styles

Question

[Assuming you write code on a team]

Does your team actually agree on a coding style standard? Independent of what language you are using, I'm curious to know A) do you agree and B) are the styles something you created as a group or did you decide to use a "third party's" style guide?

Our team uses C# primarily, and we've taken to using Microsoft's StyleCop. Not because it's necessarily THE way to do it, but because it's something we [generally] agree with and it's easy to enforce.

I'm also interested to know of style-compliance tools in other languages.

Answer 1

We agree on a coding style standard coz I'm in charge and I say we agree. :)

The third party I use is always the language authors' preferred style. i.e. we do C like K&R, C++ like Stroustrup, Python like Guido, etc. If anybody gives me any grief, I say something like "Take it up with Dennis Ritchie and have him get back to me when you've got it hashed out."

Answer 2

The teams I've worked with have tended to follow the prevailing standards and guidelines as prescribed by the language or framework designers. On a .NET team for example, when a new member joins the team he/she will be told to go and read the Guidelines here http://msdn.microsoft.com/en-us/library/ms229042.aspx. This gets everyone singing off of the same hymnsheet.

Answer 3

For C, there's always GNU indent.

Answer 4

Teams should use style guidelines, though what style is settled on isn't really important. The dev lead should be the ultimate arbiter on code style and the team should adhere to it.

Developers should be forgiving though if code is delivered to source control and it does not meet the guidelines. I don't mean public API names etcetera that are visible to API consumers, I mean stuff like whitespace and brace styles. Spending time on these non-issues is not only a waste of time, it can introduce bugs.

For example, say you check out a file to make a fix and see that it does not conform to the style guide. You replace tabs with spaces and/or use the automated formating tools. You check that file back in. Now, anyone else working on the file has a merge conflict and the whole file seems to have changed. There is a risk that they might overwrite your change, or waste a lot of time fixing the code again, or whatever. Multiply this across multiple files and you start having serious problems.

Here's a source control axiom: once a file is in source control, you can only format new code.

Answer 5

My team has a code style guide, along with naming standards (for both source code and database object) that we all follow. When working with more than just 1 or 2 other developers, it's practically a necessity.

Answer 6

@Kevin, @Mark, @McDowell - What, if any, tooling exists to support enforcing these styles?

Answer 7

I found the C# Coding Style Guide to be a good resource for C# Programmers.

Answer 8

Yes, the team I lead has a standard coding style. Our philosophy: When looking at code in the system, you shouldn't be able to tell who wrote it.

I know that's impossible to achieve, but that's the ideal we strive for.

Why is it important? Because having that level of consistency makes it easier to read and understand another person's code.

As for enforcement, certain IDEs do provide style guides/templates that you can customize. It's up to you how far you want to take that, but at a bare minimum you should standardize the tab spacing.

Answer 9

Style Guidelines are a must whenever you get more than 2 brains or more working on the same code (this can be two people at the same time or the same person 6 months apart). It's not enough to work in the same language.

If, talk like Yoda, I start, then the English speaking among us are likely to have to engage more more of their brain understanding what I'm trying to say than understanding what I'm actually saying (especially those not familiar with Star Wars).

Having said that I'm not sure that it really matters what those guidelines are as long as everyone adheres to them. An important thing to consider in relation to that statement is that if everyone's style is remotely close to that chosen there will be less resistance to change.

@McDowell mentioned that Once a file is in source control, you can only format new code. I'd add to that Nothing is allowed into source control until it conforms to the style guidelines.

Answer 10

I beg to differ with @McDowell's rule. I'm working on a code base that is awfully indented. Everybody uses a different editor with different default indentations and different tab widths, and as a result each line in the same block can have a different indentation to the point where the code is illegible. I've gone out of my way to format some files and I've been thanked by other people on the team, so I'm not sure it's all bad.

The question is, do any tools exist that allow you to enforce a coding style (what interest me, specifically, are Linux tools)? I know that I can put a formatting instructions for VIM and Emacs inside the file as a header or footer. Does the same exist for Nedit (which is very popular in my group), for instance?

Answer 11

It makes total sense to enforce coding standards within a team because otherwise you get code that is different and when you need to fix a bug from developer x, you won't have to spend time working out his coding style (in terms of formatting). So the answer to the question of whether you should have coding standards is either "yes" or "you mean you don't already?!"

The question of which coding standard to use is the same kind of question as which OS is best in that it's a war where everyone has an opinion and they usually differ! Do braces start on a new line or on the same line as the expression? Is there a space after brackets? And so on. I know what I like but other developers will have their own style so the difficulty is getting them to switch. The important thing is consistency so once you choose something, stick with it.

I actually wrote an article about this in 2004 for SitePoint.com which goes into more detail about why you should have standards.

If you're looking for something to enforce standards, I was playing with a PHP PEAR package just last weekend which does this - PHP_CodeSniffer - of course this is PHP only.

Answer 12

For C# (or any .NET language) the Framework Design Guidelines, combined with FxCop and StyleCop are probably the best way to go. The guidelines in the FDG can be applied to just about any code, not just framework APIs and is a great printed reference. FxCop and StyleCop are great ways to validate and enforce the standard.

Incidentally, a lot of the guidelines in the FDG can be applied to other languages as well.