views:

350

answers:

11

What's the convention for naming functions in C++?

I come from the java environment so I usually name something like:

myFunction(...){
}

I've seen mixed code in C++,

myFunction(....)
MyFunction(....)
Myfunction(....)

what's the correct way?

Also, is it the same for a class function and for a function that's not a class function?

+10  A: 

There isn't a 'correct way'. They're all syntactically correct, though there are some conventions. You could follow the google style guide, although there are others out there.

From said guide:

Regular functions have mixed case; accessors and mutators match the name of the variable: MyExcitingFunction(), MyExcitingMethod(), my_exciting_member_variable(), set_my_exciting_member_variable().

int3
+3  A: 

Do as you wish, as long as your are consistent among your dev. group. every few years the conventions changes..... (remmeber nIntVAr)...

Dani
+3  A: 

If you look at the standard libraries the pattern generally is my_function, but every person does seem to have their own way :-/

TofuBeer
+3  A: 

There isn't so much a 'correct' way for the language. It's more personal preference or what the standard is for your team. I usually use the myFunction() when I'm doing my own code. Also, a style you didn't mention that you will often see in C++ is my_function() - no caps, underscores instead of spaces.

Really it is just dictated by the code your working in. Or, if it's your own project, your own personal preference then.

Daniel Bingham
+5  A: 

Most code I've seen is camelCase functions (lower case initial letter), and ProperCase class names, and (most usually), lower_case variables.

But, to be honest, this is all just guidance. The single most important thing is to be consistent across your code base. Pick what seems natural / works for you, and stick to it. If you're joining a project in progress, follow their standards.

Donnie
+1  A: 

I think its a matter of preference, although i prefer myFunction(...)

Neeraj
+2  A: 

It all depends on your definition of correct. There are many ways in which you can evaluate your coding style. Readability is an important one (for me). That is why I would use the my_function way of writing function names and variable names.

Peter Stuifzand
+1  A: 

Unlike Java, C++ doesn't have a "standard style". Pretty much very company I've ever worked at has its own C++ coding style, and most open source projects have their own styles too. A few coding conventions you might want to look at:

It's interesting to note that C++ coding standards often specify which parts of the language not to use. For example, the Google C++ Style Guide says "We do not use C++ exceptions". Almost everywhere I've worked has prohibited certain parts of C++. (One place I worked basically said, "program in C, but new and delete are okay"!)

Laurence Gonsalves
"program in C, but new and delete are okay" - that's opening a big can of worms, just to type `Foo *foo = new Foo;` instead of `Foo *foo = malloc(sizeof(Foo)); assert(foo);` ;-)
Steve Jessop
Well yeah, that was the point. At that company we pretty much always used new and delete instead of malloc and free. Other that that it was practically just C though: no constructors, methods, templates or exceptions allowed. They were building embedded software and were afraid that they might need to port to a platform that didn't have a C++ compiler (this was almost 15 years ago).
Laurence Gonsalves
Sounds mad as a hatstand to me. If they're worried they might need a platform without C++, they could write C, and get the benefit that by compiling it with `-std=c89 -pedantic` they can actually be validating it as C89, which will work in a C compiler, instead of C++, which might not. If they wanted so desperately to type "new" and "delete", use a couple of macros (admittedly you'd need extra parentheses: `delete(new(TYPE));` instead of `delete new TYPE;`.
Steve Jessop
I never said it was a good convention. I only mentioned it as an example of how extreme the "forbidden parts of C++" type of coding convention can get.
Laurence Gonsalves
+3  A: 

The most common ones I see in production code are (in this order):

myFunctionName     // lower camel case

MyFunctionName     // upper camel case

my_function_name   // K & R ?

I find the naming convention a programmer uses in C++ code usually has something to do with their programming background.

E.g. ex-java programmers tend to use lower camel case for functions

Steven
+2  A: 

As others said, there is no such thing in C++. Having said that, I tend to use the style in which the standard library is written - K & R.

Also, see the FAQ entry by Bjarne Stroustrup.

Nemanja Trifunovic
A: 

Personally, I prefer thisStyle to ThisStyle for functions. This is really for personal taste, probably Java-influenced, but I quite like functions and classes to look different.

If I had to argue for it, though, I'd say that the distinction is slightly more than just aesthetic. It saves a tiny bit of thought when you come across function-style construction of a temporary. Against that, you can argue that it doesn't actually matter whether Foo(1,2,3) is a function call or not - if it is a constructor, then it acts exactly like a function returning a Foo by value anyway.

The convention also avoids the function-with-same-name-as-a-class-is-not-an-error fiasco that C++ inherits because C has a separate tag namespace:

#include <iostream>

struct Bar {
    int a;
    Bar() : a(0) {}
    Bar(int a) : a(a) {}
};

struct Foo {
    Bar b;
};

int Bar() {
    return 23;
}

int main() {
    Foo f;
    f.b = Bar();
    // outputs 23
    std::cout << f.b.a << "\n";
    // This line doesn't compile. The function has hidden the class.
    // Bar b;
}

Bar is, after all, both a noun and a verb, so could reasonably be defined as a class in one place and a function in another. Obviously there are better ways to avoid the clash, such as proper use of namespaces. So as I say, really it's just because I prefer the look of functions with lower-case initials rather than because it's actually necessary to distinguish them from from classes.

Steve Jessop