C++ coding standard for small group using modern IDEs

views:

160

answers:

+1 Q:

C++ coding standard for small group using modern IDEs

+7 A:

Coding standards remain an issue because everyone secretly thinks they can solve all the world's programming problems with a very clever coding standard. And then forcing programmers to follow them. (Pretty much like programming programmers.)

Unfortunately, few coding standards address the issues that matter in a complex project like:

how to cleanly and effectively partition and model a problem
how program partitions should best interact with others
how an explanation of logic ("comment") should be written to explain the code

Instead, most coding standards address trivia like:

indentation and brace style
whether comments should be present or not
mechanical rules about constructing identifiers
placing arbitrary limits on characters in a line, number of parameters, etc., etc.

As for the primary question, I don't know of any good detailed standards other than design and implement code which other engineers would be proud of.

wallyk 2010-08-09 03:52:30

I agree with this. I work on code which has changed coding standards 4-5 times through it's life, so basically each file uses one or more different styles. It doesn't hurt readability at all. If it were up to me, I'd be more open to letting developers use whatever they want for their files, but keep it consistent. The only standard I would have in this regard is tab width.

dauphic 2010-08-09 04:15:54

+1 A:

As far as coding standard go, in most cases, it's less important what the specific coding standards are, so long as they're firmly in place. Tabs vs. space? Who cares. Pick one and go with it. Curly braces on the same line as the conditional or the next line? Who cares. Pick one and stay consistent.

I personally like the Linux kernel coding standards.

http://www.kernel.org/doc/Documentation/CodingStyle

It is for C, and not C++, but it may be a good place to start on the standards for your project. Unfortunately, I doubt it offers suggestions on a "do not write" list.

haydenmuhl 2010-08-09 03:53:45

I highly recommend the Google style guide, which I haven't stopped using since interning there two years ago. The link above enumerates the rules in detail, along with each rule's justification in terms of pros and cons.

It is indeed highly readable and very detailed, but the important rules (the ones that come up all the time) are few and easy to remember. They have really streamlined my C++ coding by giving consistency to my naming and function argument-passing conventions.

I know you're using an IDE, but emacs users can use their "google.el" file for automatic formatting. There's also a powerful "cpplint" script that runs through a source file, printing out style violations in the same warning format as used by gcc. This lets you quickly fix style violations before checking in a file. If your IDE can parse gcc warnings and jump from warning to warning in a source file, then fixing such violations becomes a snap. Emacs and Eclipse CDT do this, as do other editors/IDEs.

SuperElectric 2010-08-09 04:25:53

Strongly disagree with the Google Style guide. Google's guidelines are mandated by Google to help integrate with their extremely large existing (mostly C) codebase. For example, there's no reason to not use exceptions in new code, nor should one avoid boost libraries that can make your job easier.

Billy ONeal 2010-08-09 04:37:01

Oh, but the header guards and formatting things are fine.

Billy ONeal 2010-08-09 04:42:33

Yeah, the no-exceptions-rule is independent of the rest of the style rules, and one can take it or leave it, to taste. Same goes with boost; it's only banned because exceptions are. If you are ok with exceptions, you can use boost.The style guide does indeed help integrate with C code by having output arguments passed by pointer, but that's not it's raison d'etre. Its goal is to tame the feature sprawl that is c++, which can lead to inconsistent naming and argument passing conventions even within single-coder projects. The header guards and formatting things are just surface details.

SuperElectric 2010-08-09 06:33:14

@Billy ONeal: In every new project I work on I refrain from the usage of Boost. I know that it's not a common agreement on stackoverflow, but boost creates huge link times, often hard-to-read code and personally I think that a lot of their things (such as shared-pointers) tend to lead to bad designs and most of the time costly overhead. I generally write time-critical real-time software so my usage case is quite specific.

Simon 2010-08-09 08:39:45

@Simon: 1. I'm unsure what could cause huge link times. There are some boost libraries (*cough* spirit) which are insane w.r.t. their compile/link times, but things like `boost::bind` make code more readable, not less. Re: Shared pointers -- you've pointed at one of the few things the style guide *allows*. I'm missing your argument here.

Billy ONeal 2010-08-09 13:50:03

@Billy ONeal: Google style guide allows boost call traits, compressed pairs, pointer container, array, BGL, property map and their iterator defining. Not boost::shared_pointer. They do, however, allow smart-pointers (such as scoped_ptr). I don't see any personal use for boost::bind. There probably are specific parts of boost which doesn't create longer link-times, I agree. The link-time was regarding boost as a whole.

Simon 2010-08-09 14:31:34

@Simon: They allow std::tr1::shared_ptr, which amounts to the same thing.

Billy ONeal 2010-08-09 14:43:24

@Billy ONeal: "You should only use std::tr1::shared_ptr under very specific conditions, such as when objects need to be held by STL containers". They don't have any specific rule against STL, although they do not allow variable-length arrays (such as std::vector).

Simon 2010-08-10 06:07:20

@Simon: Your point? It's allowed. You should only use it where necessary, but that's not an unreasonable requirement.

Billy ONeal 2010-08-10 12:06:15

@Billy Oneal: Yep, "where necessary" is never in the software development I've seen. Judging by their call of no variable-length arrays, there's not very much left of STL-containers. My "point" is that I think that google's guidelines are excellent. At least to time-critical real-time software, as that's the only thing that I have any extensive knowledge of.

Simon 2010-08-10 19:37:51

@Simon: Err.. they don't allow C99 VLAs. There's no restriction on `std::vector`. I don't see what you mean by that. And I strongly disagree with you. Google's guidelines are good for C++ code that has to meld with a large existing C codebase. That's what it's designed for; even the guide itself tells you that. Those of us who don't need to maintain large existing C codebases need not constrain ourselves in the way Google has constrained itself.

Billy ONeal 2010-08-10 19:57:12

@Billy ONeal: Ah, you are indeed correct regarding the C99 VLA's, I wasn't aware of that. I still don't see any reason why to use boost.

Simon 2010-08-11 05:18:01

+1 A:

Read C++ Coding Standards. It is not what most people would call a coding standards document, but you probably want to read it. One of the first guides is do not swell the small stuff (do not put too much emphasis on details: focus on rules that affect the semantic not the syntax, as in prefer RAII over raw pointers instead of add braces everywhere, in it's own line and indenting 3 spaces)

David Rodríguez - dribeas 2010-08-09 07:34:14

ansaurus

tags:

views:

answers:

C++ coding standard for small group using modern IDEs

related questions