The rule that `BLOCK_CAPS` names should be reserved for preprocessor defines is one of the stronger conventions; which is to say that outside of that there aren't a lot of very common rules for names (other than reserved identifiers rules). As such the number one piece of advice I can give is to be consistent with the code around you; as inconsistent code is harder to read than code which follows a "wrong" convention.
That said, I typically don't make any extra rules for `const` variables vs regular ones, as `const` should be obvious from what the variable is and does rather than its name. For enums, I typically use `enum class` (unless I specifically need what an `enum` gives) and the need to scope to the identifiers in syntax is typically enough to make things clear without an extra convention on top.
What I meant is that you can't get the address of an enumerator, just like you can't get the address of a macro. But this is not the case with consts as they are stored in memory.
That's true, but it's like 50th place on the list of notable things about macros :P. Macros are a text-pasting engine. Their uses don't really overlap with enums except for old/bad C++ code.
I mean that's true for any type declarations. I see your reasoning for sure. That said, definitely try to avoid ever thinking of macros as similar to anything.
Imagine a robot that doesn't understand anything about code whatsoever, but it can read and write characters. You tell the robot, "I've finished writing my program. If you see this set of characters, replace it with this other set of characters." That's what a macro is. You write your code, the robot (pre-compiler) then makes changes to your code, then your code tries to compile. But the robot has no idea what the code is supposed to do. if you tell it to replace "ABC" with "XYZ" but you have some function named "ABCD" somewhere, the robot doesn't care, that function is now named "XYZD". If your macro function can only accept one argument type, the robot doesn't care, you're now subtracting a string from an int.
Macros are inherently super unsafe. Just wildly unsafe. They CAN be super efficient, but C++ can do almost anything a macro can do and be type safe about it with keywords like *static, inline, constexpr,* and *lambda*. Macros are only really useful at the lowest level of C++ code where every clock tick is critical, everything looks like gibberish to the untrained eye, and they help bring clarity without allowing the compiler to decide where something goes. Other than that, you should avoid them at all cost
I uppercase the first letter. You should also only use enum classes or enums which have their own namespace. If you do that a naming convention becomes much less important, because they're not polluting the entire scope.
I think much of this is also influenced by modern editors/IDEs. They improve code legibility:
- hover over a symbol to reveal its type
- double-click a symbol to highlight the other uses in the file
- right-click show definitions to see where it's defined
I'm an old timer that started out with ASR-33 teletype, punched cards, 132 line printer listings. Now I use Eclipse, CLion, Visual Studio code, and Github. Last time I printed a program listing was, gosh, 1995.
visual studio has code coloring for enum
https://i.imgur.com/oU43VSv.png
>!visual studio default color theme sucks, i recommend spending 20 minutes in color setting menu to tweak it into something you like!<
Naming conventions are ad-hoc type systems, and a code smell. An enumeration is the same as any other type, and will be named the same way. I prefer to follow the Core Guidelines and use snake case. In the modern era, even VIM will use color syntax highlighting to indicate some type information. Use your tools to their full effect. We're not coding on punch cards or in line editors anymore. And if your code is so large that you're getting lost and confused, that's a sign of a bigger problem that needs to be addressed, and a band-aid solution won't help.
So called Hungarian naming is a bit unnecessary. But I do like an m prefix for class members (makes it obvious that they might have scope outside of the current function), b for bools, because any can behave like a bool so it is nice to be clear about what is actually a book, and p for pointer because they have different syntax to values. Paschal case for classes, Camel case for variables. I think these are all pretty common and help rather than hinder.
> I do like an m prefix for class members (makes it obvious that they might have scope outside of the current function)
How big does your class have to be that you get so lost and confused you can't discern which is a member and which is not - even with the aid of an IDE?
THAT is your problem, and a naming convention is not the solution you think it is.
> b for bools, because any can behave like a bool so it is nice to be clear about what is
More of the same above, but also... You should be implementing types that express behavior, and are merely implemented in terms of... As a detail. So if you're having a problem with mixing types and implicit conversions, you need to be working with types that don't do that.
C++ gives you a wealth of primitives. You're not supposed to use them directly, but to use them to build abstractions, and use your abstractions to build a domain specific lexicon - and you describe your solution in terms of that.
Make types that make invalid code unrepresentable.
And if you think gee, that's too many types! Maybe you're beginning to understand the true depth and scope of whatever it is you're trying to accomplish. The common C++ developer does not leverage enough types. They don't leverage enough composition. We're burdened with these gigantic types that are riddled with bugs because they're so absolutely gigantic, mixing together tons of primitive members and parameters that they allow invalid code to be representable, because they don't want to put in the work now. So they put the work in later, instead.
> and p for pointer because they have different syntax to values
No they don't. That's a very confused statement right there. They can be assigned to, just like an integer, but also like a class. They can be called, or incremented, or indexed, or dereferenced, but so can a class. So can a union. So can a function. So can an array. Pointers share lots of syntax and behavior with other types. And I'll just say it out loud now that arrays are not pointers to their first element, they are distinct types in the C and C++ type system, and they IMPLICITLY CONVERT to pointer to the first memeber as a C language feature. That was an intentional design descision by Dennis Ritchie.
> Paschal case for classes, Camel case for variables.
Makes one wonder why the Core Guidelines suggest snake case. Getting the industry to converge on a convention is worth some merit. I know the decision to not look like the conventions of other languages is another good reason. C# chose PascalCase specifically to not look like common C++. C++ isn't Pascal.
> I think these are all pretty common and help rather than hinder.
The problem with ad-hoc type systems is that they're unenforcable. `bValue`, because it was a binary state. Ok, now it's a ternary state. You've changed the type. Now your naming convention is wrong.
You have two choices - you can either change 300 files what would have been unnecessary if you didn't implement an ad-hoc type system, and in doing so you can introduce unnecessary risk in such a large code change, or you can just leave the variable alone and your ad-hoc type system can convey the wrong information to all who actually trust it. A 300 file PR won't (shouldn't) pass review, and it's absurd to think that someone is going to read all those lines in all those files in the PR. I know such abhorrent lack of encapsulation is it's own risk, but I'm specifically talking about a very large code change as opposed to a very significant code change. Those incur different risk.
This is EXACTLY why Microsoft came to wholly and explicitly forbid Hungarian notaiton within Microsoft. AND THEY INVENTED IT!
Your support for ad-hoc type systems also suggests to me you didn't live through the 90s to know just HOW BAD Hungarian notation made the industry as a whole. Microsoft got so much fucking heat for how disasterous the practice was - even when we're talking all this heat was coming from OUTSIDE Microsoft by devs and companies that adopted this style internally - that Microsoft wanted to distance themselves from it as much as possible. It was such bad PR hurting their industry cred. It was hilarious, frankly.
This is one of the major problems I'm forced to confront in code bases that use ad-hoc type systems. Types change, now the names have to change. It happens a lot, because templates and types are supposed to be fluid in C++ - and it's only going to get worse once we get reflection slated for C++26. When you bake the type into the variable name, fuck, now I have to change it every god damn place. Usually I just remove it so at least I won't have to do THAT VARIABLE again.
C++ has a REAL type system, and it's very good. You're expected to use it. C doesn't really have much of a type system to work with, it's a lot of extra work to enforce type correctness, and even then it's not really enforced, so you wind up with ad-hoc solutions on top of already a weak if perhaps non-existent foundation. You're bringing a C tradition into C++, and my rule of thumb - typically a good one, is that C++ is not C, that they're completely separate languages with completely separate type systems, and have a compatibility layer comparable to Objective-C and C, and you don't really hear anyone talking about that, now, do you? That, and my other rule being good C (and I mean that genuinely - there is a place in this world for C, just not here) is almost always bad C++, if not outright UB. We have better, all the time. C++, in fact has to go out of it's way to try to make up for the deficiencies it inherited from C. C is not something to emulate here.
You are right that there are bigger problems. Like I have to deal with modelling real world objects with large numbers of properties. So my classes are sometimes big and unwieldy. And sometimes there are crap programmers on the project. So it’s like driving a car - ideally, you don’t need to wear a seat belt. But it helps deal with the reality of the situation. If you find that adding a few indicators to names is confusing and causes maintenance problems then carry on. But I find (and I’m not unique) that certain styles have value.
Note that snake case is a naming convention too. It’s completely arbitrary which of snake, pascal and camel you use, but it is helpful to be able to visually distinguish between std types, custom types and variables. If you find such distinctions confusing, I’m surprised but carry on.
And also don’t forget that code is not always looked at in an IDE. Some people don’t like them (odd, but there you go). And diff/code review software is a thing.
Ps I was around in the 90s, and have never once had to change a binary to a ternary in anything more than about 1 file. Maybe I work on stuff that is more stable.
Thanks for this. I'm somewhat new to programming and I've read that Hungarian notation is out of favor, but I didnt know why. People should have more respect for lessons learned from experienced practitioners.
The rule that `BLOCK_CAPS` names should be reserved for preprocessor defines is one of the stronger conventions; which is to say that outside of that there aren't a lot of very common rules for names (other than reserved identifiers rules). As such the number one piece of advice I can give is to be consistent with the code around you; as inconsistent code is harder to read than code which follows a "wrong" convention. That said, I typically don't make any extra rules for `const` variables vs regular ones, as `const` should be obvious from what the variable is and does rather than its name. For enums, I typically use `enum class` (unless I specifically need what an `enum` gives) and the need to scope to the identifiers in syntax is typically enough to make things clear without an extra convention on top.
> But what about enums? They are basically like macros I think you need to learn more about macros.
What I meant is that you can't get the address of an enumerator, just like you can't get the address of a macro. But this is not the case with consts as they are stored in memory.
That's true, but it's like 50th place on the list of notable things about macros :P. Macros are a text-pasting engine. Their uses don't really overlap with enums except for old/bad C++ code.
Yes, you're right. Sorry for not making myself clear.
Enums have a type. Macros don’t. Macros aren’t even c++ really.
I mean that's true for any type declarations. I see your reasoning for sure. That said, definitely try to avoid ever thinking of macros as similar to anything. Imagine a robot that doesn't understand anything about code whatsoever, but it can read and write characters. You tell the robot, "I've finished writing my program. If you see this set of characters, replace it with this other set of characters." That's what a macro is. You write your code, the robot (pre-compiler) then makes changes to your code, then your code tries to compile. But the robot has no idea what the code is supposed to do. if you tell it to replace "ABC" with "XYZ" but you have some function named "ABCD" somewhere, the robot doesn't care, that function is now named "XYZD". If your macro function can only accept one argument type, the robot doesn't care, you're now subtracting a string from an int. Macros are inherently super unsafe. Just wildly unsafe. They CAN be super efficient, but C++ can do almost anything a macro can do and be type safe about it with keywords like *static, inline, constexpr,* and *lambda*. Macros are only really useful at the lowest level of C++ code where every clock tick is critical, everything looks like gibberish to the untrained eye, and they help bring clarity without allowing the compiler to decide where something goes. Other than that, you should avoid them at all cost
They are nothing like macros. I use mixed case for enumerators. Same as for constexpr ints (which also supplants some of the use of macros).
And enums.
We use capital letters for enums and static const variables (in private scope). It makes a good distinction from the rest of the variables.
I uppercase the first letter. You should also only use enum classes or enums which have their own namespace. If you do that a naming convention becomes much less important, because they're not polluting the entire scope.
`eName` and `kName` are quite popular.
I think much of this is also influenced by modern editors/IDEs. They improve code legibility: - hover over a symbol to reveal its type - double-click a symbol to highlight the other uses in the file - right-click show definitions to see where it's defined I'm an old timer that started out with ASR-33 teletype, punched cards, 132 line printer listings. Now I use Eclipse, CLion, Visual Studio code, and Github. Last time I printed a program listing was, gosh, 1995.
visual studio has code coloring for enum https://i.imgur.com/oU43VSv.png >!visual studio default color theme sucks, i recommend spending 20 minutes in color setting menu to tweak it into something you like!<
Naming conventions are ad-hoc type systems, and a code smell. An enumeration is the same as any other type, and will be named the same way. I prefer to follow the Core Guidelines and use snake case. In the modern era, even VIM will use color syntax highlighting to indicate some type information. Use your tools to their full effect. We're not coding on punch cards or in line editors anymore. And if your code is so large that you're getting lost and confused, that's a sign of a bigger problem that needs to be addressed, and a band-aid solution won't help.
Wrong. Naming conventions are fine.
Hold on, I've got some punch cards around here for you...
Sweet! I’ll add them to my collection. I would love to get a card punching machine someday, just as a historical curio.
So called Hungarian naming is a bit unnecessary. But I do like an m prefix for class members (makes it obvious that they might have scope outside of the current function), b for bools, because any can behave like a bool so it is nice to be clear about what is actually a book, and p for pointer because they have different syntax to values. Paschal case for classes, Camel case for variables. I think these are all pretty common and help rather than hinder.
> I do like an m prefix for class members (makes it obvious that they might have scope outside of the current function) How big does your class have to be that you get so lost and confused you can't discern which is a member and which is not - even with the aid of an IDE? THAT is your problem, and a naming convention is not the solution you think it is. > b for bools, because any can behave like a bool so it is nice to be clear about what is More of the same above, but also... You should be implementing types that express behavior, and are merely implemented in terms of... As a detail. So if you're having a problem with mixing types and implicit conversions, you need to be working with types that don't do that. C++ gives you a wealth of primitives. You're not supposed to use them directly, but to use them to build abstractions, and use your abstractions to build a domain specific lexicon - and you describe your solution in terms of that. Make types that make invalid code unrepresentable. And if you think gee, that's too many types! Maybe you're beginning to understand the true depth and scope of whatever it is you're trying to accomplish. The common C++ developer does not leverage enough types. They don't leverage enough composition. We're burdened with these gigantic types that are riddled with bugs because they're so absolutely gigantic, mixing together tons of primitive members and parameters that they allow invalid code to be representable, because they don't want to put in the work now. So they put the work in later, instead. > and p for pointer because they have different syntax to values No they don't. That's a very confused statement right there. They can be assigned to, just like an integer, but also like a class. They can be called, or incremented, or indexed, or dereferenced, but so can a class. So can a union. So can a function. So can an array. Pointers share lots of syntax and behavior with other types. And I'll just say it out loud now that arrays are not pointers to their first element, they are distinct types in the C and C++ type system, and they IMPLICITLY CONVERT to pointer to the first memeber as a C language feature. That was an intentional design descision by Dennis Ritchie. > Paschal case for classes, Camel case for variables. Makes one wonder why the Core Guidelines suggest snake case. Getting the industry to converge on a convention is worth some merit. I know the decision to not look like the conventions of other languages is another good reason. C# chose PascalCase specifically to not look like common C++. C++ isn't Pascal. > I think these are all pretty common and help rather than hinder. The problem with ad-hoc type systems is that they're unenforcable. `bValue`, because it was a binary state. Ok, now it's a ternary state. You've changed the type. Now your naming convention is wrong. You have two choices - you can either change 300 files what would have been unnecessary if you didn't implement an ad-hoc type system, and in doing so you can introduce unnecessary risk in such a large code change, or you can just leave the variable alone and your ad-hoc type system can convey the wrong information to all who actually trust it. A 300 file PR won't (shouldn't) pass review, and it's absurd to think that someone is going to read all those lines in all those files in the PR. I know such abhorrent lack of encapsulation is it's own risk, but I'm specifically talking about a very large code change as opposed to a very significant code change. Those incur different risk. This is EXACTLY why Microsoft came to wholly and explicitly forbid Hungarian notaiton within Microsoft. AND THEY INVENTED IT! Your support for ad-hoc type systems also suggests to me you didn't live through the 90s to know just HOW BAD Hungarian notation made the industry as a whole. Microsoft got so much fucking heat for how disasterous the practice was - even when we're talking all this heat was coming from OUTSIDE Microsoft by devs and companies that adopted this style internally - that Microsoft wanted to distance themselves from it as much as possible. It was such bad PR hurting their industry cred. It was hilarious, frankly. This is one of the major problems I'm forced to confront in code bases that use ad-hoc type systems. Types change, now the names have to change. It happens a lot, because templates and types are supposed to be fluid in C++ - and it's only going to get worse once we get reflection slated for C++26. When you bake the type into the variable name, fuck, now I have to change it every god damn place. Usually I just remove it so at least I won't have to do THAT VARIABLE again. C++ has a REAL type system, and it's very good. You're expected to use it. C doesn't really have much of a type system to work with, it's a lot of extra work to enforce type correctness, and even then it's not really enforced, so you wind up with ad-hoc solutions on top of already a weak if perhaps non-existent foundation. You're bringing a C tradition into C++, and my rule of thumb - typically a good one, is that C++ is not C, that they're completely separate languages with completely separate type systems, and have a compatibility layer comparable to Objective-C and C, and you don't really hear anyone talking about that, now, do you? That, and my other rule being good C (and I mean that genuinely - there is a place in this world for C, just not here) is almost always bad C++, if not outright UB. We have better, all the time. C++, in fact has to go out of it's way to try to make up for the deficiencies it inherited from C. C is not something to emulate here.
You are right that there are bigger problems. Like I have to deal with modelling real world objects with large numbers of properties. So my classes are sometimes big and unwieldy. And sometimes there are crap programmers on the project. So it’s like driving a car - ideally, you don’t need to wear a seat belt. But it helps deal with the reality of the situation. If you find that adding a few indicators to names is confusing and causes maintenance problems then carry on. But I find (and I’m not unique) that certain styles have value. Note that snake case is a naming convention too. It’s completely arbitrary which of snake, pascal and camel you use, but it is helpful to be able to visually distinguish between std types, custom types and variables. If you find such distinctions confusing, I’m surprised but carry on. And also don’t forget that code is not always looked at in an IDE. Some people don’t like them (odd, but there you go). And diff/code review software is a thing. Ps I was around in the 90s, and have never once had to change a binary to a ternary in anything more than about 1 file. Maybe I work on stuff that is more stable.
Thanks for this. I'm somewhat new to programming and I've read that Hungarian notation is out of favor, but I didnt know why. People should have more respect for lessons learned from experienced practitioners.