views:

173

answers:

7

Hi,

Which naming convention is more preferable in C++? The `underscore' method or the camelCase method? I have coded in Java for a while and I am used to the camelCase naming conventions. Which one is more prevalent?

Also, while defining a class, is there any preferred ordering of private/public/protected variables/methods?
Are friends usually put in the end?
What about typedefs, do they come at the top of the class definition?

Thanks, Ajay G.

+3  A: 

This is all very subjective, but generally for C++ I do:

camelCase for functions and variables.

CamelCase for classes.

public:
protected:
private:

In classes.

Edit: Forgot these 2:

Yes, friend at the end, typedef either at the beginning if they are used in the class, or after if they use the class (for obvious reasons).

Adam W
I'd say the same. I tend not to use friends much though - in c++ that is ;)
Steven
@Steven - I hope you don't use your friends in real life. 8v)
Fred Larson
Well I just avoid friends in general :)
Adam W
+2  A: 

underscores are often more prevalent on unix or cross platform code.

windows code tends to be camel cased

generally public, protected, private is what i would expect - but maybe that is more from my C# time.

dice
A: 

I use underscores for local variables; ALL_UPPERCASE for macros and constants; camelCase for nothing and CamelCase for everything else.

I always use structs and never classes, and thus start with public: (without specifying it) and then put private: at the end.

This is all very subjective and there is no right or wrong answer.

Andreas Bonini
+5  A: 

I prefer to take the boost route, and match the standard library. That means lower_case_names. I like that my code reads consistent with respect to the STL.

GMan
I used to do that as well, but one project I worked on said that following that sometimes makes it hard to instantly pick out which code you wrote and which is from std:: if you do using namespace std;That made sense to me, but upvote for you sir as I like this style as well.
Adam W
@Adam: so why would it be desirable to differentiate optically between STL code and own code? That never made sense to me, yet people use it in all kinds of environments (not only C++). That’s what *namespaces* are there for – and they do incredibly good work.
Konrad Rudolph
@Konrad: Yes I understand that, but sometimes you don't want to use std:: or myown:: in front of everything, so you use using namespace ...Then as you go along, you see `something.push_back(item)` then `something.sort()` is this std::list::sort(), or myown::objectwithalist::sort()?Again, I was forced to follow this at one time, and it has slowly replaced my own standard methods.
Adam W
Why not just type `std::`? It solves the problem, and increases readability.
GMan
@GMan: Because I can't write other peoples code, and coding standards take precedence over my personal preference.
Adam W
A: 

Which naming convention is more preferable in C++? The `underscore' method or the camelCase method? I have coded in Java for a while and I am used to the camelCase naming conventions. Which one is more prevalent?

I'd say 'just stick with what you know on this if you are starting to write your own libraries', they are both used regularly.

Also, while defining a class, is there any preferred ordering of private/public/protected variables/methods?

This varies by programmer/team. I order by category. I use a category for 'internal/private methods', and that category is generally second to last (the last being prohibited implementation).

Are friends usually put in the end?

I use them rarely; I insert them above the dependency (method), otherwise, after the constructor/destructor category.

What about typedefs, do they come at the top of the class definition?

That is where I put them.

If you want to get into details, there are publicly available coding conventions. Since you already have a Java background, you'll easily be able to cut through the 'taste' in them.

Justin
+3  A: 

I usually respect the traditions of the platform/environment i'm programming in, except on multiplatform C/C++ projects where I'm neutral. When programming C + raw Win32 I tend to use the hungarian-notation for variables (type or semantic-prefixes). When programming MFC m_ member variables, etc. The only thing that I cannot get easy in my eyes is the Unix/POSIX open_device_driver convention versus OpenDeviceDriver camelcase style.

Hernán
+1. When in Rome, etc etc...
Marcus Lindblom
+1. ... do as the Roumanians do
Joe
+1  A: 

The most important thing here is that you stay consistent. If you are incorporating other people's code into your project, stick with whatever method they were using. If you are planning on contributing this code to, say, an open-source software project in the future, try to abide by their coding conventions. If you are writing all of your own code from scratch, I would say stick with the conventions that you are accustomed to using. This will especially help when you come back to your code later and try to understand what you wrote.

Regarding structure/class access specifications, you will typically see public members listed first, followed by protected then private (in order of increasing access control). This is done mainly for readability reasons. When other people are using your code it will be these public members that they will be interfacing with, so placing them at the top of the declaration makes them easier to find. Ordering members in this fashion keeps the most likely to be used information closest to the top. I don't see friend used all too often, so I can't recall any patterns as to its usage. typedef usually appears at the top so that when looking through the rest of the class, the reader already has an understanding of your custom types (also for readability reasons, typedefs are typically grouped together and not interspersed with member declarations).

There are a number of existing coding conventions out there in common use, and the one thing they have in common is a standard. Whatever system you go with, even if you define it yourself, it helps if you have a document (or a page of example code) outlining the coding convention. Consistency improves readability, especially when you are revisiting older code at some time in the future.

Here are a couple coding conventions to perhaps give you some ideas:

bta