14

I know that it's been proven that a coding standard helps enormously. However, there are many different tools and IDEs that will format to whatever standard the programmer prefers. So long as the code's neat/commented (and not a spaghetti mess), I don't see the need for a coding standard.

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

4
  • If you do decide to implement a coding standard, consider enforcing it during continuous integration. Sep 22, 2012 at 3:58
  • 10
    Should everyone on the team be required to use the same IDE? Sep 22, 2012 at 4:06
  • 11
    No amount of code reformatting is going to replace a guideline like Do not overload operators except in rare, special circumstances.. If your coding standards are mostly about the way your code is formatted, you need better standards.
    – Caleb
    Sep 23, 2012 at 2:56
  • Not all people use an IDE either, I use Acme for instance. Sep 24, 2012 at 1:52

8 Answers 8

33

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.

7
  • +1 for a great list - making it my favorite answer. Especially off-limits code, compiler warnings, testing, and documentation. But I still think tabs vs. spaces and indentation are important. Someone else mentioned the nightmare this makes when diffing changes in source control. Sep 22, 2012 at 3:17
  • An easy way to deal with tabs vs. spaces is to disallow tabs in the coding standard. An easy way to enforce this is to have a checkin hook that either rejects the checkin or that converts tabs used as whitespace to spaces. Automatically verifying some of the coding standards such as during a nightly build or at checkin (preferable due to the near-instant feedback) is a very nice-to-have feature. What if the checkin is allowed (or forced), and conversion makes a mess? There's an easy answer to that, too: Code review. An ugly POS shouldn't pass muster; it shouldn't even be reviewed. Sep 22, 2012 at 10:04
  • Note that the "no tabs" rule (something I avoided in my list because opinions do vary) doesn't mean you can't use tabs when you are typing your code. A decent editor can convert the tabs the programmer types in to whitespace. If your editor can't do that, maybe think of switching to a better editor. Sep 22, 2012 at 10:22
  • No arguments there. Just saying that indentation/formatting belongs in the list. Tabs may be appropriate for HTML or files which are downloaded or parsed at run-time. Sep 23, 2012 at 12:08
  • @GlenPeterson - Indentation/formatting is in my list, or just before my list: "IMO, a coding standard should specify a reasonable suite of acceptable indentation styles, but leave the specifics to the authors of a package." And yes, there are exceptions to the "no tabs" rule. Makefiles, for instance. Sep 23, 2012 at 14:25
60

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...

11
  • 1
    Good answer, it expanded my knowledge with a good explanation covering the things I hadn't thought of. +1 Sep 21, 2012 at 23:11
  • They can also cover things like how to handle cross-platform compatibility, which is extremely important if a new developer isn't experienced in writing cross-platform code. Sep 22, 2012 at 0:03
  • 3
    If you think this answer is a good one and answers your question, just mark it as such.
    – marktani
    Sep 22, 2012 at 0:34
  • 3
    Not to mention that mass reformatting can cause headaches when you throw another good standard in there: source control. Sep 22, 2012 at 1:16
  • 1
    @MatthewScharley generally you push the changed code through the formatter and then commit (after maybe one last test run to ensure the formatter didn't break anything) so only formatted code get on the repo Sep 22, 2012 at 1:53
13

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.

2
  • 4
    Diffs! I hadn't thought of that. Sep 21, 2012 at 23:20
  • 1
    Yeah, definitely don't let everyone reformat the code the way they like it every time they work on it. That's just pandemonium. Even a bad standard is better than that. Given the choice, I'd try to do what's most popular in the language so that new developers could get up to speed quickly. Use the web to find what's the standard standard for your language. Sep 22, 2012 at 3:14
5

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.

enter image description here

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.

3
  • I think the question is asking why those things are important. You describe what a coding standard covers, but the question is asking why it's needed. Sep 22, 2012 at 0:07
  • i did not finish my answer yet
    – Yusubov
    Sep 22, 2012 at 0:10
  • That While Not should totally be a Do Until.
    – Ry-
    Sep 22, 2012 at 3:08
3

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.

5
  • Fine by me - one less thing to waste time on, especially if all devs have a Resharper license and fxcop / stylecop is running on the build server.
    – StuartLC
    Sep 22, 2012 at 4:07
  • 1
    Standards should be, and usually are, the culmination and consolidations of peoples experiences. The very "capable people" you refer to. If they are wrong, develop them, but to dismiss out of hand is a recipe for anarchy.
    – Andrew
    Sep 22, 2012 at 5:21
  • @Andrew Those experiences might not apply and may just bind you to a lot of ideas that have nothing to do with the current problem you are solving
    – Doug T.
    Sep 22, 2012 at 13:03
  • 2
    +1 for stifling innovation, controlling subsets, general best practices, and politics. Educate, don't regulate! Sep 22, 2012 at 18:22
  • "No written coding standard, rely on convention and ask for guidance" works fairly well in small teams (less than, I don't know, 50? 100?). When you have thousands of people, migrating back and forth between projects within a code-base, it really helps having a written set of guidelines for the code.
    – Vatine
    Oct 10, 2012 at 10:31
1

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.

1
  • That is a prototypical bad coding standard. It's too long, it raises religious issues, and most importantly, it runs contrary to modern C++ programming. For example, it precludes POD (plain old data), and its rules on exceptions range from bad to archaic. Bad: Trying to catch std::bad_alloc turns out to be a very bad idea. Archaic: The Java idea of specifying all exceptions that might be thrown and catching all exceptions thrown by called functions just doesn't work in C++. Much better is to write exception-safe code based on the concepts of David Abrahams's concepts of exception guarantees. May 16, 2014 at 14:20
1

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.