c++ coding conventions

The most important thing concerning coding conventions is that if the project uses the same in all the places, it is much easier to read and develope.

You should try all conventions to get familiar with them, because every company or project you will work in will use some different one. If you can only use one, you will be hated by everybody working with you.

If nobody cares (and since stuff isn't enforced, I'd guess so) then I'd use what you think is good. The idea being that the next person looks at the code, sees string strName and string PirateName and make the subtle leap to see which is better.

Though also perhaps broaching the subject within the team or with management.

These days I use the conventions given in a language's standard library. If part of a team I propose that as the convention to use on a new project.
For modern languages like Java and C# people tend to do that anyway.
For other languages, like C++, people tend to struggle with finding a comfy convention, so sticking with the standard library's makes this decision easier.

In the specific case of C++ the only minor difficulty remains in deciding whether to name something like_this or likethis since the SC++L seems to use some sort of black art to decide when to use either one.

Quote:

Original post by popsoftheyear I know that coding conventions are more personal preference than anything

Yep, the personal preference of your boss ;)

I work to the standards required of me because a cheque hits the bank every month and they pay for conformal coding. As long as the standard isn't too bizarre I don't see a problem in adapting (though of course I do have my preferences just as does the boss.)

I second what PKLoki said.

If you do happen to have full freedom in deciding coding conventions for your project, think of the management and economical impact it will have. In issue X, will choosing option Y result in more efficiency and quality for the software? Will it ease communication in the team and clarify things to reduce conflicts between developers and improve general cooperation climate in the group? Or, is option Z better at achieving this? Or, is it better to not standardize issue X at all?

Finally, note that if you make a good plan for change management of the coding conventions, it won't be as crucial to make the conventions right from start.

If this kind of economical reasoning and attempts at predicting the future (by use of a mix of experience, strategical reasoning and educated guesses) doesn't interest you, I'd recommend you use some existing publicly available coding conventions. For syntactic style, the STL/boost convention, or something more like the Java style guide but adapted to C++. Those are AFAIK the most common ones for new projects in C++. For semantics, structure and correctness, have a look at the "Effective C++" books by Scott Meyers and "C++ Coding standards" by Alexandrescu & Sutter.