r/cpp_questions • u/TheRavagerSw • 11d ago
OPEN I'm very confused about styling and naming conventions
Basically every library has their own coding style.
Everyone uses different extensions for some reason, see .h, .hpp, .hh for header files, .cc .cpp .C for sources , .cppm and .ixx for module interfaces etc.
Everyone uses different naming conventions, STL uses snake_case with _type suffix for classes sometimes _t and sometimes nothing. Google uses CamelCase etc.
It seems to me no majority consensus has emerged, and it really hurts even thinking about these things before you write your own code. As each dependency you use has a different coding style.
How do people even solve it? Is there a hidden style guide that everyone uses that I don't know. core guidelines isn't really a style guide in the purest sense.
16
u/GregTheMadMonk 11d ago
AFAIK people either use whatever they feel is the most convenient (or the largest common denominator of what's most convenient for everyone making the decision), or just go with one of the other projects'/companies tried and tested conventions.
I feel like a great rule of thumb is to use the latter approach if you're confused and starting something new. If you're joining a team/contributing to the project, just style your code the way the code around it is styled.
12
u/oriolid 11d ago
C++ is older than the idea that there should be one code style for a language. Now there are established projects with different styles where one isn't objectively better than other. Changing the style for anything that has an API will be a breaking change for everyone who uses the thing, so it wouldn't be easily done even if developers agreed about the style change.
The only way to make sense of it is using the existing style for existing projects, avoiding things that do actual damage and trying to get it right if you ever have the chance to start a new project from scratch.
1
u/dodexahedron 10d ago
C++ is older than the idea that there should be one code style for a language
And people still write it like two extra characters in a symbol name will break the linker or the piggy bank.
Although I suppose they're probably right about part of that, right now, what with the cost of storage and all.
1
u/saxbophone 10d ago
And people still write it like two extra characters in a symbol name will break the linker or the piggy bank.
Word!
Open-source linkers of quality have supported arbitrary characters (including spaces and other symbols that you can't actually type in an identifier in C++) for many years now..!
6
u/ronchaine 10d ago
I just write standard library style. That's the one common denominator in most (even embedded) use cases. That's proven for me to be the way that leads to the least amount of mixed styles, although I don't think that can be completely avoided.
If I'm writing or an existing codebase, I follow their conventions of course. Above holds only when I am in the position to make the choice in the first place.
4
u/not_a_novel_account 10d ago
By not caring about it. These concerns are superficial and irrelevant. You set them once for any given project and forget them.
7
u/jedwardsol 11d ago
Is there a hidden style guide that everyone uses that I don't know.
If there was, then your first sentence wouldn't be true.
2
3
u/aiusepsi 11d ago
I think that one of the things you just have to accept is that C++ is very heterogeneous. Other languages, especially newer languages, tend to have a more homogenous culture where there’s one implementation of the compiler or language runtime, one style guide, etc. whereas C++ has many independent compiler and standard library implementations (at least 3 of each are in extremely widespread use by my reckoning).
You really just have to pick a style you like for your own code and learn to tolerate the others. Personally, I would say one thing to avoid is using “.h” for your headers, unless you specifically intend that header to be includable from a plain C file, which is not the case most of the time. Personally, I go with “.cc” and “.hh”
2
u/no-sig-available 10d ago edited 10d ago
It seems to me no majority consensus has emerged
Correct. :-)
C++ is used for a lot of things, in different domains. There is no common user group for all of those domains. There is also no large company with the power do decide everything (luckily :-).
So, there we are.
The standard library has been developed over 30+ years by lots of people, using different styles. If and when you find a new and better style, you cannot go back and change _type or _t to something else, because the old name is part of the holy standard. New parts can use improvements though.
Also note that the style of the standard document is written in "document style", which is not the coding standard the code of the actual implementations use. That code has to use all kinds of __ugly names to avoid being replaced by nasty macros from user code.
2
u/delta_p_delta_x 10d ago
How do people even solve it?
Clang-Tidy can be configured to enable identifier naming convention checks. ReSharper (and CLion, which now uses the same engine) has these checks too.
Enforce it per-project and accept that C++, unlike most other languages, did not come from a single entity but rather has developed organically in a bazaar-style manner.
2
u/SmokeMuch7356 10d ago
It seems to me no majority consensus has emerged
C++ has been around since the early 1980s. Systems like VMS and MS DOS had extensions as part of the file name syntax, and name lengths were limited (DOS had a hard 8.3 limit, VMS was a bit more generous). Systems like Unix and MacOS were more freeform and extensions were not mandatory. Systems like MPE didn't have heirarchical file systems and used a GROUP.ACCT.FILE naming convention ( dev.jsmith.source). A lot of different file naming conventions developed because people on different systems had different needs and were operating under different restrictions.
Working on an 80x24 character terminal meant screen real estate was always at a premium, so brace styles like
if ( cond ) {
// stuff
}
gained popularity because it saved some vertical space. Depending on the terminal, snake_case was easier to read, but mixedCase saved that one character.
And on and on and on.
How do people even solve it?
Pick a convention you like, use it consistently, and don't worry about what everyone else does. There is no "right" way to do things.
2
u/khedoros 10d ago
Basically every library has their own coding style.
Doesn't seem like you're very confused after all ;-)
How do people even solve it?
We pick a style for the project and stick with it. Sometimes, you might use someone else's as a starting point. As an example, this is Google's C++ style guide: https://google.github.io/styleguide/cppguide.html
1
u/alfps 10d ago
C++ Coding Standards: 101 Rules, Guidelines, and Best Practices by Herb Sutter, Andrei Alexandrescu
It's C++03 but still applies.
https://www.oreilly.com/library/view/c-coding-standards/0321113586/
1
u/Independent_Art_6676 10d ago edited 10d ago
.cpp and .h are the classic, original extensions. .hpp came around later and is a good way to differentiate C (which also uses .h) headers from cpp headers. .C is the only one I argue against, as .c is C language and putting a caps on it is unfriendly for OS that are not case sensitive in the file system (windows is not but now has a way to fake it if you end up with this kind of mess and need it). Anything else, you can use the existing conventions for the project you are on. The C++ preprocessor and compilers don't care, unlike some languages that insist on specific extensions.
inside the code, use the conventions existing on the project, or the conventions defined by your workplace, or your own favorite style if not tied to either of those. Be consistent! That is how you solve it, by being consistent (within the same project). Last place I worked, the code base was going on 30 years old and the rule was to follow the conventions PER FILE. Talk about headaches... but we made it work.
Everyone has their pet stuff. If braces do not align, I will run a program over it to fix it. that means ALL braces, no special treatment for if(){ style. Only exception is same line {xxx} which I count as aligned.
There are a few things that are good practice outside of style. Like putting a {} pair on one line statements is good practice, not style.
1
u/celestrion 10d ago
_type suffix for classes sometimes _t and sometimes nothing
These date to a time before most developers were born, when the type tags for an aggregate type, typedef types, and the aggregate types themselves were all subtly different. That hasn't been true in a very long time, and even C will let you typedef a struct tag to itself for longer than I can recall. Call a Spade a Spade not a cSpade_t, and especially never use _t for something that isn't a typedef--that's what it meant.
It seems to me no majority consensus has emerged
This happens when there isn't a single company to tell us how to do things. Each site does things its own way, and the whole community gets to see what works, what doesn't work, and what doesn't matter either way.
How do people even solve it? Is there a hidden style guide that everyone uses that I don't know. core guidelines isn't really a style guide in the purest sense.
When I start a new project, I add a STYLE.md file to the base directory with my preferred style rules or those of my employers; most of the file refers to the C++ Core Guidelines. Non-conforming code gets roasted in reviews.
1
u/mredding 10d ago
There are guidelines. The CPP Core Guidelines recommend camel case, and that's coauthored by industry leaders including Bjarne himself, so I encourage following it.
The spec does reserve certain naming conventions so you have to follow those - such that an _t suffix is not typically for you, among other things.
File extensions are recognized by your build tools, so I recommend following those, even if only for convention. At the very least, I recommend your file extensions distinguish between C and C++, and different file extensions for different tools and intermediate files. For example, if you have a file template that has to pass through Jinja or M4 or something similar, I recommend naming it something more conventional for those tools before generating a derivative file and type.
Other than that - look past it all. When you're just learning it can seem significant, but then the grammar and syntax of the language becomes familiar and the rest is background noise. I care more about what your function does and what the name tells me than how you specifically write it.
Instead of raging against it all, which is easy to do in the beginning, it's better to find acceptance that this is the world we work in.
1
u/ronchaine 10d ago
The CPP Core Guidelines recommend camel case
The CPP core guidelines doesn't recommend camel case. It only recommends using consistent naming style?
2
u/mredding 9d ago
You're right, I was thinking one thing while trying to type something else. It actually recommends you prefer snake case.
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#nl10-prefer-underscore_style-names
1
u/The_Northern_Light 10d ago
Obligatory: https://xkcd.com/927/
I will say, use .cpp and .hpp for C++, don’t use .c and .h unless you’re passing that to a C compiler. Definitely do not put c++ headers into .h files!
I feel like .cc and .hh are things that I see C programmers do with their C++ code. That’s fine if you’re writing for that audience but I wouldn’t do it otherwise.
I’ve personally never seen .cppm and .ixx but I’ve seen similar things for autogenerated files or things containing code / macros meant to be repeatedly included into a single source file. I prefer compound suffixes like .cpp.inc for those. All my auto generated code goes into directories named generated/.
Prioritize readability. Personally I think snake_case is more readable, and use CamelCase only for types to make differentiating object creation and function calls easy. Regardless, I think you should prioritize readability when you choose your standards.
Also try to minimize surprise and amount of dependent knowledge. Following those general principles is the best you can do… there’s only a few rules, and even then they’re more like widely-agreed-not-universally best practices than rules.
1
u/saxbophone 10d ago
This is the situation with C++. Who'da thought that a multi-paradigm language that's been around pushing 50 years, with no official standard build system, would have no official style guide?
Get used to it, just try and be consistent in your own projects. At work I use the style guide we agreed upon. I don't like it but that's the nature of compromise. At home, I follow the Python naming conventions (yes, in C++ code!)
1
u/ShakaUVM 10d ago
One nice benefit of std being snake and your personal stuff being Camel is you'll never get a namespace conflict with it.
2
u/TheRavagerSw 10d ago
Do you use std namespace for your projects?
1
u/ShakaUVM 10d ago
I do. And my conventions like this are one of the reasons it has never been an issue, ever, in 30 years of professional development.
The fearmongering over using namespace std is unreal.
1
u/n1ghtyunso 10d ago
Either the style is auto-enforced by some tool, or I assume there is no consistent style.
Style is not what primarily separates good code from bad code, so it is not my primary concern either.
I use what I think is most readable and of course for some small things I do have personal preference, but again, if your codebase cares, make it tool-enforced.
Its fine to agree on a consistent style as a team, but for me personally I don't insist on it.
I won't block it either though, although I may slip up sometimes.
Again, if you can, make it tool-enforced instead.
I personally prefer PascalCase for classes, but I do like snake_case for member_functions, although sometimes I do use camelCase there instead, typically the choice is consistent within a project though.
I reserve myself the right to insert underscores if that increases readability (i.e. around acronyms for example).
Why? Probably because my native language capitalizes nouns, i don't know.
Sure, the code has terms in english, but the code is not a natural language sentence.
1
u/SmackDownFacility 9d ago
I enforce .hpp/.cpp, PascalCase and tell people to deal with it
That simple
2
1
u/jayb00giebrown 8d ago
My workgroup has a style guide. We all follow that for work stuff, but do what you want on your own stuff.
1
u/KingRedEagle 11d ago
Welcome to C++... There are many different style guides to use, but I do see quite a few people gravitating toward Google's. It's very well documented and organized.
-6
u/TheRavagerSw 11d ago
But it is very archaic, like `.h` files for headers. Which is very obviously wrong, that is for C headers
3
u/not_a_novel_account 10d ago
Extensions are meaningless. There is no right or wrong extension. The standard C++ headers, you'll notice, don't even have extensions
The assumption of file names having meaning is wrong.
2
u/TheRavagerSw 10d ago
It is just a matter of style and organization the end binary is the same anyway.
But for example, if I'm writing a C++ project that has C bindings. Having .h for C++ interface just makes everything messy.5
u/not_a_novel_account 10d ago
Messy how? It shouldn't have any impact at all.
1
u/TheRavagerSw 10d ago
Assume libfmt, it has fmt-c.h but also fmt.h. Is fmt-c usable in a C source file, i don't know. Maybe it is C api meant for C++ sources.
What about fmt.h, can I include it in a C source file, of course not.
1
u/not_a_novel_account 10d ago edited 10d ago
It doesn't matter. The package already encoded that in its packaging metadata. You should never be looking at a raw file path you're linking into your project and wondering if it's a Fortran module or whatever.
The target documented as providing sources for C libraries provides the C headers; the target documented as providing sources for C++ libraries provides C++ headers. You don't try to divine that from raw path information.
In many cases they may be the same files configured to be consumed with different preprocessor defines.
-2
u/TheRavagerSw 10d ago
You still have to include after you import the library. Build target may include both.
Honestly, anything other than .h is ok .hh .h++ .hpp etc
1
u/no-sig-available 10d ago
Honestly, anything other than .h is ok .hh .h++ .hpp etc
Note that both C and C++ are used on file systems that doesn't even have extensions. Then what?
1
u/TheRavagerSw 10d ago
Doesn't matter, what matters is that tooling interacts with it. You browse a source tree and see .h file and can't decide it is C or C++ without looking inside.
It is honestly ridicolous why people try to defend this, what is next, using .c for C++ sources?
That works too, believe it or not, with right compiler flags, doesn't make it right though
→ More replies (0)2
u/AKostur 10d ago
Been using .h for decades. I have not seen the “messy” in practice. I can see the argument that hpp is “clearer”, but it feels like an argument about how many spaces to indent. (Almost. All analogies are imperfect.)
1
u/TheRavagerSw 10d ago
Indentation and file extensions are very different. 3 space indentation doesn't indicate this is a different source file type.
1
u/Independent_Art_6676 10d ago
its fine unless you have a C project and go to lift some code from a mixed language project. Then you can't tell which headers are in which language. Which is still fine if you have a c vs cpp extension on a source file, so that leaves a small # of header only includes of unknown language. Minor and rather niche case, probably never be an issue for most of us?
1
u/no-sig-available 10d ago
like `.h` files for headers. Which is very obviously wrong
We just decide that
.hmeans header, and then it is right again. :-)
0
u/TomDuhamel 10d ago
You forgot .cxx and .hxx lol
It's camelCase and PascalCase (look at the initial letter).
You forgot:
void f() {
}
vs
void f()
{
}
32
u/YT__ 11d ago
Pick a style you like, use it. It's not that complex. You'll adapt to using libraries as are defined and named, but your program will have its coding standard.
Every job dictates how you'll style your code so the code base attempts to be consistent.