Common notation

Assuming C++, then prefixing your class names with an underscore is big bad mojo. Identifiers with leading underscores are reserved in the global scope and with leading underscores followed by capital letters are reserved in any scope, so you can get many weird problems with your class names if you use that practice.

I write my variables with the first word lowercase and the first letter of the following words in uppercase, for example:

sampleVarName

For functions and custom data types, I capitalize the first word as well:

CustomClassName

Thats what I do, whats most important is consistancy, whatever you do, do it the same way throughout a project.

there are many notations that are "common" ...

they are almost completely specific to which language / domain you are programming in.

The Java world has a fairly standard notation, direct from the Sun example.

The .NET (especially in C#) world has a common style / notation, with only a few areas left open for the programmer to decide on their own ... you can go to the msdn.microsoft.com website and look for programming and style guidelines for .net (google is easier).

In C++ there are probably 3-4 main competing styles depending on domain (Old windows MFC programmers, UNIX / LINUX programmers, part-time Java programmers, .NET programmers, and people like me (who come up with their own mix-match style to meet their own guidlines for consistency).

These last 2-4 years have seen a lareg convergence of styles in C derived languages (C++, C#, Java) ... so that I would say the most commonly agreed upon thing is that people usually use:

PascalCase for things like class names. And the people who do this also use PascalCase for namespaces too. Functions are usually done in either camelCase or PascalCase by these people (they don't all agree on which to use), and variable names are almost always done in camelCase, sometimes with things like m_ added to the front of member variables, or a trailing _ appended.

As mentioned already, DO NOT start any non-members with an underscore, it just makes life easier (some people do start member variables with an underscore ... which is ok).

Then there are the people who follow the C++ standard example, and use lower_case_with_underscores for just about everything ...

Quote:

Original post by Xai As mentioned already, DO NOT start any non-members with an underscore, it just makes life easier (some people do start member variables with an underscore ... which is ok).

Underscore followed by a capital letter is not ok, even for member variables.

How I roll:

classes and functions:
ThisIsAClass

member variables:
thisIsAMemberVariable

defines:
THISISDEFINED

brackets:
(on my own I do this because I like it more)
function{
}
(however at work and in larger groups I conform to this standard)
function
{
}

comments:

Section heading comments
/*********************************\
| major comments appear like this |
\*********************************/

function description blocks
//Just simple
//one-line
//comments

I refrain from multi-line comments wherever they are not necissary because they can screw up attempts to comment out code blocks which gets annoying in some cases.


Tabs: I use 3 spaces in my own projects, but at work and in groups I use a standard 4 space tab character.
_____________________


Anyhow, nothing revolutionary, basically keep things smooth and consistant and whatever style it is probably won't offend me.

Thanks guys :D
Ahh, and I would never have guessed that underscores could be that evil. I'll start writing classes in all caps from now on. Functions LikeThis look nice and variables likeThis too, so I'll try getting into using them.
Oh, and I have always used functions like this
function {
}

function
{
}
looks rather ugly to me.

Rating++ to all :D, if anyone else has something to contribute, please do.

Quote:

Original post by ZadrraS I'll start writing classes in all caps from now on.

I wouldn't, if I were you. One of the most common conventions among C and C++ programmers is to use all caps for constants and macros.

I'm just a beginner programmer but I tend to prefix all my classes, functions and variables for easy identifying with either C, F or V

e.g.

CThisIsMyClass

FThisIsMyFunction

I tend to write variables like this

Vthisismyvariable

I don't know if this is good or bad but it is helping me learn, not sure what others would think though.

FWIW, here's my style:

<li>don't use "C" in front of the class' name, because it makes the names ugly. <li>use as few comments as possible, name as well as possible.<li>bool dont_fear_long_variable_names = true;<li>variables are in lowercase, separated with an underscore _ if they are local<li>member variables have 'its' before them: itsstyle<li>static variables have 'static_' in before their names<li>global variables SHOULD BE FEW and clearly be flagged. <li>all DATA should be WELL DOCUMENTED as well as CLEARLY named (can't stress this enough)<li>value-like types are named all_lowerscore.<li>'complex' types which have special construction/destruction semantics, are NamedLikeSo.<li>private/protected member functions begin lowercase and the first letters of following words are uppercase<li>public/global functions are NamedLikeThis<li>global and static constants are ALL_UPPERCASE<li>intend carefully, and use braces {} for all loops and if-conditions

Quote:

Original post by Roboguy Quote: Original post by ZadrraS I'll start writing classes in all caps from now on. I wouldn't, if I were you. One of the most common conventions among C and C++ programmers is to use all caps for constants and macros.

Ahh.. But I do wish to make my classes stand out as much as possible, I write the instances of the classes all in lower caps, and I need to see a clear diffrence between a class and its instance. Till now "_player player" or "PLAYER player" looked good enough, but if I can't use those, what then?

Quote:

Original post by Mordt I'm just a beginner programmer but I tend to prefix all my classes, functions and variables for easy identifying with either C, F or V e.g. CThisIsMyClass FThisIsMyFunction I tend to write variables like this Vthisismyvariable I don't know if this is good or bad but it is helping me learn, not sure what others would think though.

Heh. I certainly don't want to use those. IMHO things like these makes the code VERY ugly.. (just an opinion :) )

I'm not sure if this is a common thing, but naming an instance the same name as the class is probably not the greatest idea in the world. Just might lead to confusion/typos. I'm guilty of doing this myself, but I've oftentimes regreted it, especially when its just one or two leters that are different(like no longer capitalized). An exception to this might be if you have a singleton.

Anyone else agree with this since I'm *far* from being even good at writing code.

I agree with the others that you should not name your classes in all caps. That is really the one convention that is extremely consistent, so its even worse when its been broken.

And that's exactly why I want the same words to be as diffrent as possible.
I remmember using "Player player" before, and it led to a lot of confusion. "_player player" fixed this for me...

Normally struct names are all caps and class names have the first letter of each word capitalised.

As for your Player player thing, why not try this:

Player thePlayer;

Quote:

Heh. I certainly don't want to use those. IMHO things like these makes the code VERY ugly.. (just an opinion :) )

Your right ZadrraS and I must get out of the habit :> It is helping me though and some standard for of notation would be helpful if there was such a thing :)

Quote:

Original post by Mordt I'm just a beginner programmer but I tend to prefix all my classes, functions and variables for easy identifying with either C, F or V e.g. CThisIsMyClass FThisIsMyFunction I tend to write variables like this Vthisismyvariable I don't know if this is good or bad but it is helping me learn, not sure what others would think though.

i dont think this is required, which things are functions and classes are fairly obvious from how they are used and so are variables.

some people like to declare member variables different, but not me, i know my member variables from the lack of declaring them inside a member function...

Naming structs all capital comes from C where things like
typedef struct MyStruct { ... } MYSTRUCT;
were done, as far as I know, to avoid the need of writing
struct MyStruct
and instead writing
MYSTRUCT
However, since C++ that isn't needed any longer, and I personally see no requirement of distinguishing between classes and structs in this sense.

My favorite writing is like this:

where the comments are formatted as are due to doxygen.

A thing I know that could be complained is the leading underscore of protected/private member fields.

Quote:

Original post by SiCrane Quote: Original post by Xai As mentioned already, DO NOT start any non-members with an underscore, it just makes life easier (some people do start member variables with an underscore ... which is ok). Underscore followed by a capital letter is not ok, even for member variables.

Oh, come on. Stop nitpicking on this issue already.
I realize that it may be good to know that they're technically reserved, in fact I like trivia and obscure language details as much as the next guy, but do we really have to comment on it every single time someone shows a code snippet containing a leading underscore in one of the identifiers? I mean if someone uses "foo" then no one complains but apparently "_foo" is some kind of sin, now which one do you think is more likely to cause problems?

I personally use them all over the place to mark internal things (i.e. private or local), mostly because I find trailing underscores quite ugly. In fact the consistent use of underscores to separate all of those short local names combined with the use of module prefixes and namespace has significantly reduced the number of collisions I've had to deal with during the last few years.

And guess what, they've *never* collided with any reserved identifiers for me. Ever (well, I can't be absolutely certain but it hasn't happened in recent history).
On the other hand I've frequently crashed into the WinAPI (I swear they must have defined half the English language in that rat's nest of headers) and various other libraries. And in any event a global search and replace to fix the name is rarely more than a two minute affair, especially with private names since they're by their very nature easy to fix.



[Edited by - doynax on January 7, 2006 8:48:55 AM]

Quote:

Original post by doynax Quote: Original post by SiCrane Quote: Original post by Xai As mentioned already, DO NOT start any non-members with an underscore, it just makes life easier (some people do start member variables with an underscore ... which is ok). Underscore followed by a capital letter is not ok, even for member variables. Oh, come on. Stop nitpicking on this issue already. I realize that it may be good to know that they're technically reserved, in fact I like trivia and obscure language details as much as the next guy, but do we really have to comment on it every single time someone shows a code snippet containing a trailing underscore in one of the identifiers? I mean if someone uses "foo" then no one complains but apparently "_foo" is some kind of sin, now which one do you think is more likely to cause problems?

Leading underscore, not trailing underscore. And the nitpick was about leading underscore followed by a capital ex: _Foo, not _foo, and it wasn't someone showing an identifier, it was someone trying to explain what identifier patterns to avoid. And guess what, I have run into problems with that one. One of the Metrowerks preprocessor versions took the identifier _Line and stripped it out of source code. So yes, it is worth commenting on. Just because you've gotten away with doing a bad practice doesn't mean that it isn't a bad practice.

Quote:

Original post by SiCrane Leading underscore, not trailing underscore.

Whoops, I meant leading of course.

Quote:

Original post by SiCrane And the nitpick was about leading underscore followed by a capital ex: _Foo, not _foo, and it wasn't someone showing an identifier, it was someone trying to explain what identifier patterns to avoid.

I was trying to reply to the last post in the discussion (from which your first post had been stripped out), it wasn't even particularily aimed at you personally. And I was trying to deal with the use of leading underscores in general, regardless of what they're followed by or where you use them.

Quote:

Original post by SiCrane And guess what, I have run into problems with that one. One of the Metrowerks preprocessor versions took the identifier _Line and stripped it out of source code. So yes, it is worth commenting on. Just because you've gotten away with doing a bad practice doesn't mean that it isn't a bad practice.

I don't doubt that it does infact happen, the point was that it's exceedingly rare and not at all the big issue it's made out to be.
Personally I'm more than willing to deal with a few collisions (especially since I haven't actually had any as of yet) in order to keep my current short and "pretty" coding style, and I doubt that I'm alone.

So, yes, I agree that it's bad practice but you have to realize that it's just as bad to use short identifiers or overly generic names. Thus I belive that it's worth dealing with when it comes up rather than banning their use entirely.