Coding-style: How to improve coding-styles and standards at a company

Question

What are the best ways to improve the standards of coding-styles at a company? Let's use C# as an example here.

I guess there are many differences between developers that need to be taken into consideration. The concrete ones could be education, experience and past programming-languages.

How does one justify that something is right over something else?

One person may say "I move my body to the place where I earn my money with my 4-wheeled vehicle". So why is it more "right" to say "I drive to work in my car"?

Some people might like code more explicit with more lines of code. Some might like more tight code.

// Explicit
string text = defaultValue;
if (string.IsNullOrEmpty(text)) {
   text = fallbackValue;
}
// Tighter
string text = defaultValue ?? fallbackValue;

Or the old protective programming-style, where you check for error-cases in the beginning and not wrap the whole method body inside a positive if-clause:

public string ChangeText(string text)
{
    if (!string.IsNullOrEmpty(text))
    {
        // Do a lot of stuff 
    }
    else {
        throw new Exception();
    }
}
// vs.
public string ChangeText(string text)
{
    if (string.IsNullOrEmpty(text)) {
        throw new Exception();
    }
    // Do a lot of stuff
}

Is the old "I'm having troubles reading this code" valid here? It's the same situation that was when Generics was introduced to C#, people had an initial trouble reading it.

Where is the line drawn between unreadable code and code that some developers are not used to?

Which part of Phil Haacks "7 Stages of new language keyword grief" has valid points here?

Are there any easy ways to set coding-standards and uphold them in a company?

UPDATE: Take in consideration things like variable-naming, that can't really be defined in a document. Or can it?

Answer 1

I think consistency is important here. There's not a lot of point in getting into a semantic debate over which way is better than the other unless the current methodology is particularly bad.

What is important is that the team writes their code consistently so that if someone resigns or gets hit by a bus then his/her colleagues know what is going on with the code when they are forced to work with it.

Answer 2

The easiest way to set coding-standards at a company:

Create a Standards Document and enforce it.

...people love to complain about code quality, but few will sit down and take the time to create a standards document. It's worth the effort and as long as you can enforce it (code reviews, etc.) then you're bound to notice an improvement in your code.

Answer 3

You always can use free tools like StyleCop from Microsoft.

You can disable or modify rules you don't like

Answer 4

Most companies use Coding-Style-Guidelines/Conventions. These are documents telling that you should always do braces around the if body even for one command, that you should indent with tabs/spaces, and so on.

There are a lot of tools for (automatically) check and enforce the coding-style. (An example for the java-world is checkstyle, which can be integrated into eclipse and also in a continuous integration solution like 'hudson'.)

Answer 5

First, you will always have to enforce the coding styles - there will never be a consent.
That's, why I would try to automate the check for consistency. Depending on your language you can use StyleCop (for .Net) or something like indent under linux.

Every developer can work with his own code style in his environment (the reformat can be very easy, depending on your environment), but all checked-in code has to be of the company's style.

Which style do you choose? Well, often there are already popular styles - depending on the language. For your example (C#) I would choose the Microsoft style. At last: only the project manager (senior programmer) has the right to adjust it.

Answer 6

How does one justify that something is right over something else?

Easy: just don't. Pick a coding style, communicate it, and enforce it.

Answer 7

There are two main sides of coding style:

1. "Where do I put the opening brace?" type issues - These are usually unimportant, i.e. there are no real reasons to prefer one style over the other.
2. Actual coding rules, like do we use return's in the middle of a function.

The way I see it, for #1 type issues, there is no point in any debate. Just set a standard in a standards document, and enforce it (more on this later).

As for the second issue, I'm honestly not sure whether it should be regulater. I personally love sprinkling functions with return values to check for error conditions, and I know some people who cringe at the practice. But at the end of the day, we can usually read each other's code just fine. These kinds of issues are much more about how you prefer expressing yourself, what is easier for you to write, and I wouldn't want a company making rules that get to this level.

As for how to enforce things, standards documents are good, but in my experience, are just never read or followed closely, and are soon forgotten. The best way is to have some kind of automated tool which tells you that you're violating the standard.

For example, even as a completely new Java programmer, I knew when to uppercase/lowercase my identifiers, simply because Eclipse let me (quietly, unobtrusively) know what the standard is.