Sign in to follow this  
Ainokea

Naming conventions

Recommended Posts

Quote:
Original post by Boder
Well I think there should be some way to distinguish classes from user-defined structs and enums. [crying]


Why does it matter if classes can be distinguished from structs and enums? In other words, what is gained from it?

Share this post


Link to post
Share on other sites
Truth be told I do more programming in C than C++. But I'm gradually doing more C++.

Articles and books I have read sometimes recommend the C prefix on classes. I guess it just makes the code seem more organized and readable to me, and doesn't really seem to obfuscate anything (unlike g_lplpBlah). I also think of classes as being an entirely different flavor of objects, when compared to data structures. I know classes only really exist before compilation, but classes have functions, and inheritence, and public and private parts [embarrass].

I guess if I weren't to use the C prefix, I would make structs using this naming convention...

variableName
rather than...
ClassName

in order to group structs with variables rather than classes.

One more thing, please don't capitalize variable names. Save full caps for defines and enums ... I think this is a pretty widely accepted standard but I've seen some radical leet coder outliars that don't seem to follow any rules [lol].

Share this post


Link to post
Share on other sites
I like this:

variable
ClassNames
FunctionNames

it's not that hard to tell Classes and functions apart in my honest opinion, especialy since most IDEs give it away nowadays. And it's not like they ever come in contact with eachother...


Hungarian is evil.....

(I use c/cpp)

Share this post


Link to post
Share on other sites
structs are NOT variables, they ARE classes, period .. in C and C++ structs have the meaning of the logical construct of "classes" in the smalltalk sense.

A struct name, and enum name, and a class name are all: Type Names. Units of knoweldge used to tell the compiler what shape data instances should be in.

Global functions, member functions, static functions, virtual functions are all: Method / Function Names. Units of knowledge used to allow a programmer to execute the same operation from mutliple places easily.

Globals, Locals, Parameters, Member Variables, Contants, are all: Value Container Names (Variable Names). Units of knowledge representing a logical meaning, based on the bits stored within them.

Honestly, a naming convention need not distinguish between any of the above in most cases:


int main(void)
{
int exit_code = 0;

framework.initialize();

current_game = game.create_game();

bool program_complete = false;
while(!program_complete)
{
framework.process_commands();
}

if(current_game != null)
delete current_game;

framework.shutdown();

return exit_code;
}



while the above is just a made up sample ... I hope it shows how any and all distinction between types, functions, methods, data, etc .. is not absolutely necessary to create fairly readable code. It is primarily habit and experience that shapes the conventions we prefer for code styles. There are "bad" conventions ... conventions that hide usefull information, increase "noise" information, focus on the elements that are not what the program needs to focus on, waste time, are too complicated to get comfortable with, are too ambiguous to assist in "getting the job done", etc ... but there are no "right" conventions. capitol or lower case, underscore or MixedCase, which elements should be distinguished. All of these vary from person to person, langauge to language.

That said however, A convention for C++ almost definately does not need to distinguish between the different types of methods and classes, as the compiler will catch mistakes within that realm ...

people often distinguish between the scope of variables to help prevent them from accidentally using variable in other scopes that they do not intend ... for instance if you type:

logger->Log(x);

you cannot tell or guarantee that that logger uses the local version, the instance version, a static version, or global version ... without scanning thorugh the file(s) looking for values with the exact same name ... and simple typos can still easily byte you ...

so the g_SystemLogger, or gSystemLogger conventions are meant as a way to tell a programmer - WHERE to start looking for the proper definition of the item you INTEND to be manipulating ... something the compiler cannot deduce on its own.

Doesn't mean I always like even this convention. But I use something a little like it, some of the time. Mostly I use: ClassName, FunctionName, variableName ... just cause that seems to be the most common standard, and I work at a job with other people. My rule is, if my standard is better than theirs in some quantifiable definate way, then I use my own preference - or at least make the case for it and hope we can adopt it as a team. Otherwise, all else being equal, we just vote for 1, and everyone lives with the result.

Share this post


Link to post
Share on other sites
Good post, Xai.

localVariable
PublicMemberVar
_privateMemberVar
ClassName
Function

Lack of a 'real' naming convention for C++ kinda sucks. It is similar to the fact that some 'smaller' languages have whole communities devoted to them in one spot but there are so many C++ users that there isn't a whole lot of unity.

Share this post


Link to post
Share on other sites
someVariable
SomeFunction
SomeClass
SOME_DEFINED_VALUE

Really, if you can't tell the difference between a class and a function without help, you have problems no naming convention can fix. The two are quite different and impossible to confuse IMO. I like the convention I use for variables, because using underscores to seperate words gets long and looks very fragmented when you're reading it IMO. Not capitalising the first word is important, because you don't want to have to worry about capital letters for small simple names, like 'i' if you use that common name. I also like the convention I use for #defined values, like macros and constants, because it stands out so much and is unmistakeable. You rarely encounter many of these in one place, so it doesn't end up looking ugly.

Share this post


Link to post
Share on other sites
i personally i hate hungarian notation (yes i do understand it) & now microsoft agrees with that aswell because they recommend you avoid it.

i find upper-casing the first letter of an operation just plain weird operation names are verbs, verbs don't start with capital letters.

Share this post


Link to post
Share on other sites
(Hi, all ...)

Ftn: Your style looks like the one used in STL. Doesn't this style suffer from name ambiguity problems (in practice)?

For example, hipothetically:

struct something {
};
struct creator_of_something {
something* create_something() {
// problem (I don't won't to adapt the instance name to something else - I wan't it to be "something".)
something* something = new something;
return something;
}
};


I'm just curious how those who use this kind of coding style handle these problems in practice - or how often these problems do show up. I'm also wondering what's the rationale behind the STL naming style - why it was chosen?

Share this post


Link to post
Share on other sites
The .NET naming convention is easy to remember, if nothing else: Everything public uses PascalCase. Private attributes, parameters, and locals use camelCase.

The Java convention is a bit more... conventional: types use PascalCase, methods use camelCase, constants are IN_ALL_CAPS.

Share this post


Link to post
Share on other sites
I use pythonic_names in my Python (but not the leading _'s for private vars; when I get to the point that other people see my Python code, I will rethink things) and generally follow Java conventions when writing anything more C-like. Except that I'll also use pythonic_method_names in Java for the dirty hacks that I'm not proud of, something like "this smells like it wants its own class, but everything got seriously uglified in an optimization attempt." (*space* optimization, mind; I'm developing for J2ME. It takes a *lot* of manual switches to outweigh the class overhead, I'm rather disappointed actually :( )

IMHO humility is an important quality for a programmer (but so is pride :) ), and you should recognize the poorer-aesthetic bits of your work, and at least acknowledge them if you can't afford to fix them.

Share this post


Link to post
Share on other sites
harsh

Well so far it seems like no one has recommended including any sort of type information with variable names, apart from sometimes using g_ to destinguish global scope.

What if I design a class for my game and I only intend to have one instance (global) in my program. The class is very specific and only designed for one purpose. This way I don't have to resort to the_Class or myClass or g_Class when naming it.

resulting in..
CApplication Application;
Application.Run();

instead of..
Application myApplication;
myApplication.Run();

I also sometimes like to distinguish strings with a little s in front.

Share this post


Link to post
Share on other sites
Convention 1: How your supposed to do it (i think)
ClassNames
variableNames
constant_Names
FunctionNames

Convention 2: How I do it
ClAsSNAmEs
vaRiAbLeNaMeS
cOnStAnT_NaMeS
FUnCtIoNNAmEs

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this