[cdarklight]

I want to program in a way that others can read easily. I decided to look into naming conventions to use. What is most Commonly used?
Is the link below seemed pretty specific. Is it accurate to common programming?
http://geosoft.no/de...t/cppstyle.html
http://www.possibili...ngStandard.html

What programming styles/naming conventions are widely used?

This post has been edited by cdarklight: 29 November 2009 - 06:10 PM

[JackOfAllTrades]

Moved to C++ Programmers forum.

[ccubed]

I think the ones from the first link are good to follow. Honestly though, there's not a whole lot of uniformity. It's one of the reasons it's so hard to go through someone else's code.

[Bench]

This kind of thread is a great way to start a holy war - Programming styles are often down to the invidivual, or down to company/department/team guidelines set by your employer/project leader.
Someone who doesn't like "your" coding style will likely tell you that theirs is better and that your coding style makes code harder to read (What they probably mean is that they find your code harder to read than their own code, or they are simply arrogant in their belief that their style is 'best' - both seem to be pretty common).

There aren't really any set-in-stone rules when it comes to asking which style is better, or even more common. The most important thing is to remain consistent - especially when editing someone else's code. You might not like someone's style, and it may even make you cringe to copy that style, but a block of code written in a style which you don't like or find a little harder to read is always easier to read than code where style is mixed with yours and theirs, and maybe someone else's on top of that too.

Personally I think both of those guidelines links are reasonable (and 'guideline' is a good word to use when it comes to style) - though its also perfectly acceptable to deviate from those guidelines in any place you see fit - particularly where it comes down to those matters which usually end up in so-called "holy wars"

From what I've seen the most common source of holy wars (i.e. the ones which generate heat rather than light) can include

• When/where/how should I use capitals in names?
  
• When/where/how should I use underscores in names?
  
• Should I put my curly bracket at the end of the line or on a new one?
  
• Should I use type prefix abbreviations? (a.k.a. "Hungarian" notation)
  
• How many spaces should I use to indent a line?
  
• ..etc.

Good examples of where even some of the programming gurus may disagree can be seen if you compare, for example, the style used in the STL versus the style used in some 3rd party libraries.

Notice that the STL uses all lowercase (I can't think of anywhere that uppercase letters are used for anything except some of the behind-the-secenes template parameters), and nearly always uses names separated by underscores; e.g. std::reverse_copy_if() and std::basic_string; however I see few other C++ libraries which adopt the same naming conventions (Boost is one of the few which does - probably because much of the STL originated from some of the boost authors)

Looking at style between languages, the difference in opinion is even more apparent; alot of C programmers seem to be keen on abbreviations and short names to keep code size down, whereas alot of Java programmers seem to prefer camelCaseNames.

This post has been edited by Bench: 30 November 2009 - 04:10 AM

[NickDMax]

I myself try to keep just a couple of things in mind in C/C++:

I use ALL_CAPS for processor constants and macros
I use StartingCapitals for types (classes, structs, unions etc) and for C++ constants or Global variables.
I use camelCase for variable names and function names.


I do sometimes use a pseudo "Hungarian" notation -- I will often prefix things like iForInteger, or pForPrivate, sForString. but I don't tend to combine them like sptrStringPointer or piForPrivateInteger.

in general I like the idea of Hungarian notation -- but I find that just naming variables with a meaningful name works better. The problem with prefix schemes is that there are too many types/situations and such schemes tend to be come overly cumbersome and IMO harder to read. So I will use a prefix if it helps make the purpose of a variable clearer.


The variables: i, j, k -- are generally reserved in my programming for loops

The variables: n, m -- are generally reserved for enumeration/indexs of arrays/collections.

The variables: x, y, z -- are generally reserved in my programming for coordinates or coordinate-like variables.

The variable: retVal is often the return value of a function -- its type is determined by the current function. I generally use this variable where others would use multiple return statements (I like to follow the convention that every function has only 1 exit point (if possible)).

IN general for C/C++ I think the first guide you gave is very good. I definetly don't follow ALL of these conventions, but I think it gives good guidance.

[Ancient Dragon]

I've changed programming styles over the years, as probably most programmers do too. In addition to what Nick mentioned above, I like to see { and } brackes on their own lines, and each code statement that ends with semicolon on its own line.

int foo()
{
	int one;
	int two;
	cout << one << " " << two;
	cout << "Hello World\n";
}

Also I almost never use c++ endl statement unless I want to flush the output stream.

In c++ I now prefer to use fstream and iostream classes, but I used to use C's FILE for streaming even in c++ programs, although C streams are more consise and often easier to use.

[ccubed]

I think these response only go to show just how unorganized we are when it comes to structure. There is no true universal structure, which is sad, because I'm sure it would help.

[NickDMax]

You know, it really is not that big a deal. Being handed a large printout or emailed a huge PDF with the "style guidelines" is always a downer because too much time gets wasted worrying about code consistency that could be spent working on code correctness, reliability, and security.

Going into a code review and having someone nit-pick about your naming conventions.

I think that programmers who put so much importance on naming conventions tend to miss the big picture.

While there are a few conventions I do hate to see ignored (like MACROS_IN_UPPER_CASE) I generally don't think that it is more important than ensuring the memory management is handled consistently.

And there is a universal structure -- enforced by the compiler.

[ccubed]

NickDMax, on 4 Dec, 2009 - 07:15 AM, said:

You know, it really is not that big a deal. Being handed a large printout or emailed a huge PDF with the "style guidelines" is always a downer because too much time gets wasted worrying about code consistency that could be spent working on code correctness, reliability, and security.

Going into a code review and having someone nit-pick about your naming conventions.

I think that programmers who put so much importance on naming conventions tend to miss the big picture.

While there are a few conventions I do hate to see ignored (like MACROS_IN_UPPER_CASE) I generally don't think that it is more important than ensuring the memory management is handled consistently.

And there is a universal structure -- enforced by the compiler.

I can write a 20 line program in one line. It's things like that i'm nitpicking. Some people just put a bunch of code on one line, or have no spaces so you can't read anything, or, and this is my absolute favorite for worst stylistic code ever,

if( condition ){ something; }

or

if( condition )
{ something; }

If only it was so simple as everyone at least having an understanding of space between lines. but there's not and as far as the compiler is concerned, space is useless.

[KYA]

I do not care for Hungarian notation.
I prefer this:

int main(){
}

//rather then

int main()
{
}

but I'm at the point that if you write coherent code, it's irrelevant.

Quote

I use ALL_CAPS for processor constants and macros
I use StartingCapitals for types (classes, structs, unions etc) and for C++ constants or Global variables.
I use camelCase for variable names and function names.

The variables: i, j, k -- are generally reserved in my programming for loops

The variables: n, m -- are generally reserved for enumeration/indexs of arrays/collections.

The variables: x, y, z -- are generally reserved in my programming for coordinates or coordinate-like variables.

I follow a similar if not the exact same ideology for all of the quoted above.

I'm a huge fan of self documenting code. My goal is to have a few as comments as possible simply because the code explains itself through naming and structure. Comments are for the why, not the how.

This post has been edited by KYA: 04 December 2009 - 11:00 AM

[NickDMax]

I do things like this all the time:

if (condition) { something }

Ao long as "something" is short and the code is readily readable in 1 line. Nothing wrong with it. The compiler likes it, I can read it, you SHOULD be able to read and parse it... whats the big deal.

I never write a conditional block without brackets if (condition) something; but I don't go around hounding other to do it (though I might "mention" that it is safer)

That is why I HATE coding style talks -- they are pointless religious wars that have no right or wrong answer because they are based upon opinion, preference, and habit.

If my opinions, preferences, and habits make it hard for you to read my code -- tough cookies! My code is not obfuscated, I didn't intentionally make my code less readable just to piss you off -- I don't do anything unprofessional like name all my variables "o" "oo" "ooo" "oooo" etc.

Learn to read code. The style of indention might be a little hard for you to read... most IDE's can reformat it for you with 1 key combo.

I like the fact that different programmers have their different personalities. As a team lead I like being able to look at a section of code and say "AH, ccubed must have programmed this class, I recognize his style".

Programming is a creative art -- don't stifle others with your preferences.

[KYA]

I'm a huge fan of

if( condition ) { something; }

class Cat{
private:
	int itsAge;
public:
	int getAge()   {return itsAge;};
};

[Ancient Dragon]

Yes I agree with that too, especially the inline code that KYA just posted ^.

At my last job we had periodic peer code reviews because our boss wanted coding standards to be enforced. IMO we spent way too much time nitpicking each each others coding styles which could have been better used by solving actual problems. It's nice to have a coding style standard as a goal, but should not waste a lot of time requiring unnecessary coding changes just to satisfy that standard.

[ccubed]

I don't mind that in moderation, but I've seen code where that is done way too often and they don't even put SPACE between the { }. At least do that and help me read it. I have bad enough eye sight as it is.

[NickDMax]

Beginners tend to have very messy code - they have not learned the benefits of readability yet and most of those who stick with programming will eventually pickup a basic consistent style (which will probably continue to drift here and there).

Some programmers are very "smart" and arrogant and proud of their abilities to understand and parse complex code -- these programmers will continue to write very dense and unreadable code until... well who knows. There is very little you can do here, if you meet one of these guys (I have only seen this in male programmers) they will either be brilliant or borderline retarded. i.e. Really really smart or just putting on a show to cover for incompetence.

And all I can say is if they are really smart, strive to understand what they are doing, you will probably learn a lot, if they are just covering incompetence, get rid of them as soon as you can because their code will be costly in your code base.

Every programmer has a "style" and they tend to be pretty consistent with it so you can generally learn to parse anyones code if you work with them for a while.