Recommended C++ and Java Coding Standards?

Gerard J. Pinzone queries: "My company is looking to implement C/C++ and Java coding standards. However, I can't seem to find a definitive list. I'm more familiar with Java and have suggested that we use 'Elements of Java Style' and Sun's documentation. BTW, beware of 'Netscape's Software Coding Standards Guide for Java.' It's woefully out-of-date! Any suggestions?"

Try this

[pong]

Coding Conventions [macadamian.com]

for java may I recommend..

[zonk the purposeful]

Use the pretty printer [sourceforge.net]

It reformats your code (i use it via ANT)

Just play with the settings and see what you like, it'll reformat the code to what you want.

I just set it up here, and it works a treat.
Saves all those source code arguments about where the squigaly brackets go.

Things to think about

[cjhuitt]

I helped develop our coding standard at work, although it is still somewhat a work in progress. Bear in mind that this is all for C/C++, but a lot of it may carry over into Java.

I don't think you need to be reminded of the reasons for having a coding style standard, but in case anyone questions it, it undoubtly increases readability of people's code, and reduces the time needed to understand other people's code. We have also found that we are slightly better organized in how we produce code when we follow these guidelines.

Some suggested things to think about:

• Naming Conventions? Be sure to have all functions named the same way, regarding capitals, underscores, and that sort of thing. The same with variables, macros, and whatever else you can think of.
  
  For example, you might say all begining capitals for functions, such as "void OnOKButtonClicked()", first lower case then all starting caps for variables, such as "fltNewGradePercentage", and all caps for macros, such as "STANDARDSIZE".
• Where do braces go? Some people prefer ending the line with an open brace, then indenting the next line. Others like having the open/close braces on lines by themselves, indented with the rest. Still others like the latter, but without indenting them. Find one that everyone currently there can agree on, and enforce it, so that everyone can get used to seeing the braces one way, which improves debugging and code reviews, among other things, when you don't have to be getting used to ignoring a different brace style than what you are used to.
• How are variable names constructed? Some people have different prefixes/suffixes to signify things about the variables, such as the fact that they are global, or class members, and also what type of variable they are - ints, chars, pointers, etc.
  
  For example, at work, we use three-to-six letter prefixes to designate the type of the variable - intFiles is an int, chrpCurrent is a character pointer, etc.
• Indentation Standards? Some people don't believe this should be important, but it depends on how similar your development environments are. If you all use the same IDE, then this is unimportant. If, however, you develop on Unix/Linux with a wide range of editors (vim, emacs, kwrite, etc), then indentation needs to be standardized to have the display readable on each of these. Also, do you allow tabs or not?
• Comments? Yes, do use them. But, where are they required? The easiest place to require them is in the header for classes, for the public member functions. They should at least explain what the function does, what the arguments are that it takes, and what it returns. (I personally think that all functions, not just the public ones, need these. But perhaps that's just due to the fact that I can't interpret "int GetPtHitOn3dMseClk(int x, int y, int z)" very easily.)
• Spaces? Spaces need to be determined - as in, where are they absolutely required. At work, we use spaces, at a minimum, between math operators and after commas in a parameter list. Other places may also be useful.

I'm sure that there are other things to think about, which will be suggested, but these are places to start when considering a standard.

Linux

[sohp]

For the love of Dijkstra please don't use Hungarian style. There's a lovely common style in linux/Documentation/CodingStyle [linuxhq.com] Which references (and bashes) the GNU Coding Standards [gnu.org]. Either one of those could be a good starting point, once you resolve the fights you'll get into over style.

The proposed Boost C++ Coding Guidelines

[Rolf W. Rasmussen]

For C++, the best coding guidelines I've ever read is the proposed Boost C++ Coding Guidelines [sourceforge.net]. (The link points to an old version in the boost CVS tree. To get an updated version you'd need to join the Boost Yahoo group [yahoo.com] and get it from the "Files" section of the group.

What I like about the guidelines is the well thought out rationales presented and its adherance to current C++ standards. After reading them, I wanted to follow the guidelines because I agreed with the rationale, rather than simply because the document said so.

Avoiding anal retentiveness...

[ChaoticCoyote]

Too many coding standards get into issues that are, quite frankly, ludicrous. If the programmers I hire can't handle slight differences in C++ brace placement, I need to find better programmers! Sheesh, I've never had problems following code because someone places the open bracket on the same line as the if, while I put mine on a subsequent line.

Having written for publication, I've had quite some experience with the anal retentive crowd. For example, I was excoriated for having an algorithm with 1-character variable names -- the code was, however, an implementation of a specific mathematical formula, and my code precisely matched variables in the original notation. To change the names to longer "descriptive" ones would have broken the continuity between definition (in a math text) and implementation (C++). The short names were actually more descriptive and accurate!

And then we have the "goto" wars -- I actually use a single goto in one of my books, bringing down the ire of mypoic ninnies (usually pre-degree college students) who only know that "gogot is bad" without a clue as to why they've been taught that. A rare, judicious goto can make code faster and more readable! But try telling that to fools who only parrot dogma... if a programmer can't understand the rare usefulness of a goto, they probably can't think far enough "outside the box" to be useful in the real world.

This isn't to say that I'm against coding standards -- I'm all in favor of them! But a coding standard should by flexible in nature and open-minded where practical; the goal is readable code and ease of typing. Programmers have habits, a rhythm when they type, and so long as their code follows broad guidelines of style. I'll take a dozen good comments and a solid design document over the placement of curly brackets any day!