You assume there is exactly one 'correct' way. There is not even a recommendation which coding convention to use. The standard library follows one clear consistent style (snake_case). I like it and I have adopted it for my own personal projects.
Several other libraries use CamelCase or slight adaptations of it (for example GDAL). I used it in the past and still do at work. I have no strong feelings for or against it.
Some people like adding a prefix, like C for classes. I personally do not like that. It makes slightly more sense for Qt (where they prefix Q) but I would still prefer a proper namespace.
Both CamelCase (with some variations) and snake_case are rather common styles in C++ but neither can claim to be the style. Trying to say you must use one specific style (the way you did) will (and, looking at the thread quite obviously did) not go down well.
Do you usually prefix your classes with the letter 'C' or something else?
Yes, but i write on Delphi, and in Delphi normal code must follow official code styling convence, else code unreadeable
This thread is tagged "C++" and people have talked about that.
Even in the context of Delphi saying "must follow" is unwise though. It might be bad style to ignore a language's common conventions but there is still no "must" and it is still readable.
There exist some few exceptions to this, for example QML requires you to respect camelCase in property names because it generates event handlers based on their names.
Even in the context of Delphi saying "must follow" is unwise though. It might be bad style to ignore a language's common conventions but there is still no "must" and it is still readable.
There exist some few exceptions to this, for example QML requires you to respect camelCase in property names because it generates event handlers based on their names.
There are no strict standards for success.
Actually there is. Be consistent, at least in your own codebase. If I know something is called a foo bar I should be able to deduce its name without having to check on which day it was written. FooBar, CFooBar, TFooBar, foo_bar, ... are all somehow acceptable provided they follow a clear pattern.
I still wished C or T prefixes would remain in the dustbin of history though.
That doesn't happen.
The point I'm making is that readability (for the next guy) is far more important than a bunch of strict coding styles that are largely subjective and change over time.
I'm talking from years of experience developing large enterprise level systems that evolve. Code bases developed by multiple developers often contain mixed styles. That's the reality regardless of how idealistic you are. As programmers we deal with what IS and not with what should be. The fact is most successful business systems contain mixed conventions and poorly written code anyway . So unless you are the sole developer for the entire life of an application, there's no sense in being strict in regards to programming style. For success, focus on the architecture of your product, which is the true measure of success, and don't be guilty of using meaningless notations.
Now, I'm not trying to write a book here or publish a thesis to become famous, I'm just telling you the way it really is. With that said, I'm frequently reminded of all those jokers in my class that couldn't code very well. I found out the hard way that they are busy writing endless lines of bad code for us all. :) So in the grand scheme of things, stylistic conventions are the least of our concerns as programmers.
Actually, m_ for members and g_ for globals helps quite a bit while reading a lot of unknown code.
The problem is that this kind of convention is brittle. It encodes information about scope into the variable name, but if you refactor to change scope the encoding is wrong and the variable must be renamed. Forget or neglect to rename the variable and now you've got misleading information.
A far more robust convention is to require the use of this-> for members and to require full namespace naming for globals. The compiler can then help you by catching incorrect usage. In an ideal world C++ would have had these requirements from the outset.
this, a thousand times this (pun absolutely intended). I sometimes wish c++ had gone the same route as python or rust with an explicit self/this parameter. which could also enable things like templates based on the reference qualifiers of the object.
shortly after the wheel we invented find/replace and yet things still get missed.
This is a subjective opinion presented as an objective fact.Yes, if you want good code style, you must make classes as CMyClass and interfaces as IMyClassInterface
...and it's not even a popular opinion.Lowercase with underscores is actually the most 'official' style that C++ has, as it's used by the standard library (and many other projects).Naming classes from lowercase is bad practice, and using "_" in defining is bad style(for readeable). You must start every letter from uppercase and not use "_".
The people who choose it would say the opposite opinion: that CamelCase is bad style and makes code less readable..
I work with one programmer who hates underscores. So we all try to add a few extra once and a while just to hear him scream "I hate f**king underscores!'.
btw, you gotta love coders who, before they even begin to make modifications, waste half the day or more changing the coding style.
One guy I worked with changed all the database commands to upper case. I was like really?
As for camelCase or PascalStyle, my pinky has been brutalized on this shift key because you!
i'm interested why microsoft in MFC uses C prefix, if it not correct for CPP?
MFC is a not a good example to follow when writing C++.
Aside from the actual design of the library, the coding conventions used are mostly considered bad style these days.
My keyboard doesn't have a '' key. So I an't prefix my lasses. :(It's pretty hard to ode in /++ or #.
Not funny... spilt water over my keyboard and now it won't accept the c key. By the way I am using C as class prefix so i guess no more coding for today... :( (Posted from my smartphone obviously)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
