c++ code conventions

Question

0.00/5 (No votes)

See more:

I have started to learn c++ language and when i opened ysm code (for example), there was conventions like "szName" or "ptrName", "iName", etc. I know what is that "sz" - null terminated string, "ptr" - pointer, "i" - integer. In another code were functions with parameters and every parametr was on separate line - i know that it is cpp convention but i don´t know, where to learn from. I want to learn c++ coding conventions but i cant found some resources to learn from. Do you recommend me some book or resource?

why c++ using so much alias for data types like wchar_T or uint8, ... ?

in large source codes are used a lot of macros, why?

Sorry for my english and this newbie qustions, but i know only C# and there are no pitfalls.

Posted 27-Jan-13 14:24pm

black_devil

Updated 27-Jan-13 14:25pm

v2

Add a Solution

Comments

Philippe Mori 27-Jan-13 22:48pm

Some code might have been written maybe 20 years ago with convention that was genreally used at that time...

While hungarian notation might have been usefull for large C code at a time where there was no IntelliSense, now it is considered a bad practice as it hurt refactoring and it does not play well with STL (templates) nor C++/CLI and .NET for example.

Typically, if you write C++ code, you should more or less have a convention that is similar to standard librairies.

3 solutions

Solution 3

There are a lot of opinions about coding conventions. If you ask 10 people what it is about, you will get 11 opinions.

The style you cite with a 1/2/3 letter lowercase prefix is called "Hungarian notation" (ask Google) and was most popular with Microsoft code in the early years. It has fallen out of favor for the most part, especially when prefixes can't easily be found for class or struct instances.

A book I like on coding conventions is C++ Coding Standards[^], by Herb Sutter and Andrei Alexandrescu (who are opposed to Hungarian notation).

Regardless, I still use some of the features of Hungarian, such as "m_" prefix for member variables and several other artifacts. I find it makes the code easier to develop and maintain.

Posted 27-Jan-13 17:23pm

H.Brydon

Solution 4

Don't confuse Hungarian notation with C++ code conventions. I'm not aware of any official C++ code conventions. It's a free world, and everybody should pick what they consider most appropriate.

Why wchar_t or uint8_t? The _t suffix that simply denotes "type" was a convention introduced in C89. I don't know why they did it? Is it really necessary? No, but there we have it and that's it. You can ask yourself why "int" and not "integer" like in Pascal. That's how the C++ types are called and that's it.

Macros are a powerful feature in C/C++. They can be used with same benefits in both small and large projects. One important reason, I guess, for using macros is reducing code, and perhaps increasing readability. Actually the code that you write, because the pre-processor expands them before compiling, and therefore the actual code gets bigger.

Posted 27-Jan-13 22:32pm

Marius Bancila

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Andreas Gieriet · Accepted Answer · 2013-01-27T14:46:00

Solution 1

There is not such thing like "the one and only code convention".
Your team/company may/may not decide on some code convention.
If no explicit convention is given, anyone does whatever he thinks is the right way (or does not care at all...).

Naming conventions, layouting, etc. is very much debatable. Settle on one convention and follow it (no matter which).
Using macros is usually a left-over of C coding. C++ assumes you get away with little macros.
Regarding "alias" - you probably mean typedefs: that's very convenient when working with templates. You usually have many typedefs when working with templates, and very little if not working with templates.
If you have C code, then you might have many typedefs again: C++ implicitly typedefs a class/struct with its class/struct name where as C does not do that - you have to do that explicitly if you want to access a struct without prefixing it all the time with the keyword struct.

From what you write, I assume you are mainly reading C code and not C++ code, correct?

Cheers
Andi

Posted 27-Jan-13 14:46pm

Andreas Gieriet

Comments

Sergey Alexandrovich Kryukov 27-Jan-13 22:08pm

Very nice answer, my 5.

The question "why" is really an ill-posed one, but I personally think that the root of the problem is extremely bad features of this language. I seriously think that wide acceptance if this language is the biggest harm software industry ever had; and none of those very effective compilers and successful application can prove the opposite.
—SA

Andreas Gieriet 28-Jan-13 3:30am

Thanks for your 5!
I have no such reservation towards C++ as you express above. Freedom means responsibility: C++ enables you to develop as effective as in other languages regarding maintainability, robustness, etc. as long as you care about it ;-) For the sake of the discussion, it would be interesting to see which aspects of C++ you dislike so much.
Cheers
Andi

Sergey Alexandrovich Kryukov 28-Jan-13 10:23am

I'm afraid this is not a place and time for the whole discussion.
There are languages offering exact same access to low level but less error-prone, so "balance" arguments are not so impressive. C++ was very archaic from the moment of creation, an attempt to revive C. Look at "include". This is just the consequence of collective decision making, which always picks the worse of acceptable...
—SA

Andreas Gieriet 28-Jan-13 13:08pm

Sure, this is not the place to do so, I agree.
There is some disputes on the web why which language is crap, etc. BTW: This was already going on while I was student those days in the eighties. I see it from a pragmatic point of view: all languages have their edges, some a bit more than others, but you need to know what you do in all of them. For me, the general language concepts is far more important and knowing which of these concepts are available in what form per language at hand.
Cheers
Andi