Click here to Skip to main content
13,502,360 members
Rate this:
Please Sign up or sign in to vote.
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
Updated 27-Jan-13 14:25pm
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.
Rate this: bad
Please Sign up or sign in to vote.

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?

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.
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.
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...
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.
Rate this: bad
Please Sign up or sign in to vote.

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.
Rate this: bad
Please Sign up or sign in to vote.

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.

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

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy |
Web01 | 2.8.180417.1 | Last Updated 28 Jan 2013
Copyright © CodeProject, 1999-2018
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100