However, there are many different tools and IDEs that will format to whatever standard the programmer prefers.

Good luck with that. My experience, there are a tiny number of tools (zero!) that can properly reformat code from format X to format Y. There are just too many things that get in the way. Tabs vs spaces, multi-line statements, etc. Just look at GNU’s implementation of the C++ standard library files. What you can do is make your IDE do is to always use spaces instead of tabs and just don’t bother reformatting foreign code. Now your code looks the way you like it, and the foreign code looks the way the original author wrote it.

A specific indentation style is the last thing a coding standard should specify. That’s verging on starting a programming religious war. IMO, a coding standard should specify a reasonable suite of acceptable indentation styles, but leave the specifics to the authors of a package. Indentation style is, or should be, a tiny part of a coding standard. Rule number zero of coding standards: Don’t sweat the small things. Indentation style is a small thing.

Bigger things:

• How do I name things?
• Are certain parts of the language off limits?
• Does the code need to compile clean, and with what compiler settings?
• Does the code have to pass certain metrics?
• What kind of testing is needed?
• What kind of documentation is needed, both in the code (comments) and elsewhere?
• Most important, how do I get a waiver to the standard?

Addendum
Perhaps even more important is what not to put in a coding standards. Topics such as how to write requirements do not belong in the coding standards. Details on testing do not belong, either. A project should not use the coding standards as a stand-in for the project management plan, the test management plan, the verification and validation plan, etc. The goal of the coding standards is to improve code safety, quality, understandability, maintainability, and other “ilities”. There are lots of ways to ensure that this won’t happen. Just a few: Making the standards a book as complex as some country’s tax laws, inciting programming religious wars, having bad naming conventions.

Coding standards can have unintended consequences. Example: Some fool of a project engineer is going to interpret the “no magic numbers rule” to mean that if (index == 0) {...} and for (ii = 0; ii < 3; ++ii) {...} must be changed to if (ZERO == index) {} and for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...} Don’t laugh. I’ve seen it happen. Nowadays when I write a coding standard it’s a “no magic numbers guideline” rather than a rule to counteract this kind of foolishness.

The coding standard is not the number one defense against bad programming style / dangerous coding practices. The code review is. Despite many years of automation, there is still nothing better than a having somewhat subjective set of human eyes look at and pass judgement on a chunk of code.

Coding standards are not just about the favored parameters for indent — they also include naming conventions, commenting conventions, and a large number of possible recommendations for idioms, language feature use, etc.

More to the point, you still need to document all this somewhere. And finally, not everyone will want to use an IDE that reformats code that way…

If you use a consistent style within a team, your code becomes easier to read. When your code becomes easier to read then your team will be more productive. They will be more productive because they don’t have to mentally parse the code, and can focus on the logic rather than the syntax when reviewing and maintaining the code.

If each person lets the IDE reformat the code to their choosing you have one of two problems: either you must make sure you always convert it back to the original format when saving, or suffer from the fact your diff’s will show a lot of noise, making it harder to see what has changed in the logic of the code.

Short Answer: Yes, it does reflect the quality.

What is it and why we need it?

Coding standards are very important piece of high quality software. They do increase productivity in the development process, make code easier to maintain, and keep code from being tied to one person or team. Consistency in coding standard also differentiate prematurely created code from well crafted art.

OK, every developer knows that coding conventions are good. But where should standards come from?

It is mostly dictated by the vendor who owns the product. Every developer can choose from many industry coding standards. Some companies Microsoft, Oracle and Sun Microsystems offer guidelines.

Are there any arguments for the development of a coding standard (we don’t have one, but I was looking into creating one)?

Yes, there are industry standards that are recommended to be used. However, each coding standard is specific for the development platform. Thus, coding standards are mostly language specific. For example, Java has a different standard than .NET. For example C# .NET is using that standards in the this reference.

Common standards

The common standards do not have dependencies on any programming language. In addition to the vendor offered standards, aka the mentioned industry coding standards, there are different programming notations like Hungarian Notation or CamelCase. I think Microsoft .NET coding standards were initially based on CamelCase notations.

Team coding standards and guidelines

In think, every development team should agree on coding standards as soon as project is started. The coding guidelines is usually created by Team Lead or chief Architect of the company. It is usually an open document to be followed and improved upon a need. For example, in our company we have Wiki pages where this document is uploaded and available for the company developers.

I’m going to take the controversial opinion and say no you don’t need a coding standard. Either the rules are, as you say, IDE enforcable guidelines, general best practices that everyone at every company should follow, or they are case-by-case per-team judgement calls that should be made by more than one person on a capable team via pair programming or code reviews.

Things like How should we name this variable? What language features should we use? Should we avoid? What testing is best? These are best left unanswered until we encounter the narrowly defined problem that we are working on right now.

Crystallized from these minute decisions, informal standards/patterns within teams may arise, based on the intersection with the current problem domain and the technologies in use. Codifying these means we think that things like the naming standard, appropriate language subset, etc used on these projects, based on hundreds of micro decisions, and informally adopted by these teams should guide every project moving forward.

In principal it sounds like a great thing, but in reality it just becomes a magnet for politics. What tools can we force everyone to use? What do I want to force other people to avoid? If everyone agreed on these questions, we wouldn’t need a standard. We’d just do it. In my experience standards come out of a desire for one subset of the developers to exercise control over another subset. Typically this type of politics and the technological policing that follows it only stifles innovation rather then providing guidance.

If you want real guidance, instead of reading a standard with a bunch of unhelpful rules, go find capable members of your team and ask them what they think. What have they been burned by? How do they suggest you write code? You’ll get a variety of useful answers with a lot of valuable experience to back it up. You’ll see a lot of intersection based on common experience. Instead of the monoculture enforced by the standard, you’ll also see a lot of diversity which can only help you see lots of valid ways to solve problems.

And when somebody tells you not to do something cause of a rule in the “standard” but has no experience or reasonable backup to their claim, ignore them. Here the standard hasn’t served anyone or made anyone a better developer.

Now that commercial aircraft are fly-by-wire you would hope the programs flying the plane based on the pilots input works. When the programmers write such code you hope they follow a strict set of rules to avoid commonly avoidable programming errors. One way to do this is with a coding standard.

See: Proposed Federal Aviation Administration C and C++ Coding Standards

Need I say more.

Note: I could not find the actual standard from the FAA online, but I have seen it.

For me its a matter of discipline and being disciplined always helps, its a reflection of the quality of the work you produce.

Having said that, I would make the coding standard keeping in view the IDE and/or tools in use. Further, the IDE should be configured identically (e.g. each developer’s IDE should either be using all tabs or all white-spaces for indentation and everyone’s IDE should have the same tab length) for each developer so everyone can follow the standard easily…

Also, check-in scripts could be developed and used which may help in adhering to the coding standards to certain extent, e.g. they can fix the indentation before actually committing the checked in file into the version control system.

Coding standards could NOT be any more important! I’m an avid CakePHP user and I like to review the changesets from version-to-version and the developers are not following standards there.

In fact, I was so upset by the differences in style that I had to write A Short Rant About Coding Conventions. It costs a lot of time and money bringing new developers into an existing team already – just imagine bringing a new developer on with no standards…learning the code would be next too impossible.