Code standards in agile teams with modern IDEs?

Question

We're an agile project of about 20 developers organized in 2-3 teams, doing no pair programming, a little bit team rotation and a lot of peer reviews. Most of us are addicted to the "green status bar" of IDE code analysis (most of use idea, some eclipse and netbeans, resharper is idea functionality in the .net world).

We are considering dropping the formal code standard altogether. Being agile, we try to ditch all things that give us nothing, and quite frankly it just sits there looking like a relic from the past.

The argument is that code quality enforced by the regular code standard simply is the wrong metric; placement of braces has little or nothing to do with quality. IDE code analysis, findbugs and peer reviews creates the quality we want

Arguably we have some "hallway" code standards that you don't want to break if you expect to eat lunch with the others (nobody uses hard tabs, we have some limits!)

Are code standards a relic from the waterfall past ?

P.s. I'm not tagging this language-agnostic because I believe there is a substantial difference to what tools can do in java/c# compared with other languages.

Edit: I would not consider choice of external libraries to be part of the code standard. For most core libraries this is most certainly a centralized decision.

Answer 1

Static analysis and peer review can be used as enforcements, but you still need some standards that the team agrees on.

Also, there are low-level mechanics like naming conventions and more higher level standards like use of certain libraries, protocols, and concurrency agreements. I cannot image 20 developers coming up their own names for class names and method names that are consistent on their own.

If for some magical reason, all disputes are resolved peacefully within code reviews for your team, then maybe you don't need any written laws; however, having a written law shifts the argument from being "A is better/worse than B" to "A is right/wrong according to the convention," which saves time.

Answer 2

No, a coding standard is essential. It is all about readability, and therefore reviewability of the code. The human brain is very good at pattern recognition, and e.g.placement of braces is crucial for its ability to quickly recognize the kind of code you're looking at.

In addition, a coding standard is needed for new project members. Especially when you are not doing enough pairing. It allows new project members to get up to speed faster.

Answer 3

When you don't have a coding standard, every member of the team is using his own standards. Consequentially, your code will be messy. Messy code takes more time to read. It's like reading a bad handwriting - it just takes more time to read.

Answer 4

If you all do things the same way, you are adhering to a standard; so you might as well codify it - although it might consist only of a small handful of things (like using spaces not tabs). If you have it written down somewhere, new team members can be pointed at it and will know what the expectations are (as opposed to being avoided in the hallway and not invited to lunch).

Just my two bits. But I think standards bring a value to the table.

Answer 5

I believe a standard is essential, however how formal it needs to be defined depends on how well your team communicates. If your team is working effectively and reviewed code is clean and readable then you can probably relax the formality but completely removing it will make it more difficult for new members.

The main objective of a coding standard should be to set expectations to the developers in a team (especially new members), some of this can be done with static analysis tools. If these are used right from the beginning as a habit then this can be effective, otherwise providing a document can be a great starting point for new developers. You don't want the standard\guidelines to be a surprise during their first code review.

Part of this purpose is to encourage clean, readable code by guiding developers in the style they use (see http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882).

Over time, as you have already witnessed, the standard becomes an internalised responsibility of each developer and relies less on external ceremony (formal documentation of the standard).

You may want to consider reducing the emphasis of the formal coding standard on hard format issues e.g. brace placement, format for variable names etc, which can be demonstrated easily by static analysis and more on style guidelines e.g. naming, size of methods\classes, clarity of purpose etc.

Answer 6

Having a coding standard ensures consistency. It makes it easier for new team members to familiarize themselves with the code base.

But I don't believe in creating some monolithic coding standard document that must be referred to. I prefer to configure CheckStyle and PMD for my team's coding standard. I integrate checks for both tools into my Maven build script and use the Eclipse plug-ins to highlight violations during editing.

Answer 7

Are code standards a relic from the waterfall past ?

I don't think so. Code standards are an important mechanism for ensuring uniformity in the readability of the code. This would be especially important when a new/less experienced programmer joins the team in the middle of the project.

The argument is that code quality enforced by the regular code standard simply is the wrong metric

Agreed. This a valid point. But adhering to a common agreed upon standard provides "intangible" benefits in terms of quicker reviews and common understanding of control blocks. On one of our projects we had a "flexible" standard for braces which lead to different/ambigious interpretation leading people to skip them totally if they could. This created a potential for bugs when people assuming otherwise changed the same piece of code.

Answer 8

Personally I'mm less against there not being a formal coding standard now than I use to be at least in certain circumstances:

• C#/Java - there are pretty much well-known standard conventions anyway

• Small number of developers (less than 10 say)

• Few "junior" developers

• You use Static analysis tools to limit complex/long methods, large classes,loss of encapsulation etc

I no longer feel the formal standardization of things such as the placement of braces, spacing and indentation matter that much.

If you are a reasonably large organization with lots of junior developers or have a large sharable code base then a formal coding standard would probably be a lot more important need.

I don't really see that a formal coding standard or not is related to the method used

Answer 9

Coding standards are good, they are there for uniformity and readability, and for best practices to avoid bugs. Review is good too, for similar reasons. if the developers have internalised it, that is good. But what about if someone else comes on board? What if the developers want to use something similar on a following project?

But I believe that most people are doing it wrong, or at least not up to date with what's possible these days.

1) Buy before you build. There's no need for you to write a hefty code standards document. Others have done it before you, many times over. A company-wide style is better than an individual style, but an industry-wide style is better still. The people that you hire, the contractors and clients may know it too. Look for an industry standard and adopt it. You "in-house style" could just be a reading list followed by a short list of exceptions, modifications and additions.

2) Automate. Use the tools that will flag up style violations, and other potential problems such as cut-and-paste code. In the .net world, FxCop and StyleCop can enforce standards to a high degree.

3) Know which are hard rules, and which are more what you'd call "guidelines than actual rules". Know which ones you are better off doing every time, and which ones you are better of doing as default, unless there's a reason not to. There's a wealth of guidance in books and so on, but not all of it is always right.

4) Derive rules from code reviews. if something comes up more than once in a code review. It's worth putting it on a checklist for future reviews. You can separate "code standard" from "code review common issue checklist" if you like.

Answer 10

From a purely stylistic point of view, code standards help in the sense that every developer is used to read that style of naming, indentation, brace placement, etc. It takes some of the cognitive load of reading someone else's code away, and lets the code reviewer focus on what the code actually does.

That said, one interesting standard your team could take advantage from is a glossary. How are things named (in the team/project)? Did you ever re-write some piece of code because you grepped for "connection" but not for "link"? Having a project glossary might save some additional time and effort, by making sure people use consistent names.