Naming conventions: the only aspect of code formatting more contentious than where to put your braces (for the record, braces go on a new line). We all have our favorites, and anybody who doesn’t comply is an idiot. Not a regular idiot either like the person who says cut and paste when they mean copy and paste, but a major idiot like that guy in the office who can’t figure out how to Google error messages (we all know one).

So here’s the big question: how do you know your naming conventions are right?

I grew up with C++ using a book that predated the ISO 98 standard, so I was still typing #include <iostream.h>. Like most books from that period, it uses all capitals for constants. Code like this was common:

#include <iostream.h>
const int MAX_COUNT = 73;

And life was good and consistent. I knew if something was a constant value just by its name, and giving programmers information is a good thing. Well, some constants. Not constants in a function, because that’d be stupid. Those looked like normal variables.

int main()
{
    const int array_size = 73;
    int data[array_size];
    // ...
    return 0;
}

But this inconsistency was okay because #reasons. Not any reasons I could describe mind you, but they existed somewhere, to someone. Probably. Maybe if we looked hard enough.

So obviously the inconsistency is an easy issue to solve: since we know consts should be named in all caps, just make const variables local to a function all caps too. Unless you have a convention that local variables use snake-case conventions, and then you have to decide which rule wins.

Instead though, let’s ask why we care if a variable is const. If I’m only reading the variable it doesn’t matter if it’s const or non-const, so I don’t care; if I’m trying to write to the variable, then I’ll get a compilation error, so I still don’t really care. There’s not going to be a subtle bug that takes weeks to track down and solve because a variable was supposed to be read-only and somebody wrote to it because it had a different naming convention.

The best I can figure is that the convention originated from the days C, when const wasn’t a thing and developers used macros for constants.

#define MAX_COUNT 42
#define SOME_CONST 40 + 2

Macros are dangerous and evil, so that’s a place where it makes sense to name them in an obvious way – all capitals makes them stand out and experienced developers automatically become more cautious. Using all capitals for const variables though, when C++ and C (since C89) has the effect of weakening those warning flags. If your language supports const or the moral equivalent, then you have a really easy solution to this problem:

const variables should follow the same naming patterns as non-const variables.

And if you’re working in a language like Python that doesn’t support constant variables? Well now we’re back to a scenario where naming conventions around const variables make sense.

THE_ANSWER_TO_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42
# much later
THE_ANSWER_TO_LIFE_THE_UNIVERSE_AND_EVERYTHING = 24

The above code is obviously wrong since we see a const being modified. It’d also be wrong if we saw something beginning with an underscore being used in a different module, since the Python convention is that an underscore represents private stuff. The distinction is that Python lacks the same level of type-safety in these cases that C and C++ provide, so naming conventions is the best you can do.

If you’re still not convinced, how do you feel about Hungarian notation? Most developers (correctly) say it’s useless in real code since you don’t need to name your variables iFoo and iBar just to know they’re ints. Even proper Hungarian notation is better served by writing actual types.

SafeString foo = make_safe(some_unsafe_string);
someFunctionThatTakesASafeString(foo); // okay
someFunctionThatTakesASafeString(some_unsafe_string); // compilation error

Hopefully you’re nodding along, because I’m curious how developers can defend all capitals for const variables but also bash Hungarian notation.