ProgrammerHumor
howCanYouKnowTheTypesIfYouDontUsePrefixes
Discussion
Back in my old job, we had the following conventions: Pointer or not, public or private, type, scope, name.
Example: p_pub_int_global_counter
Extended hungarian notation
We have gone past notation - this is the whole Hungarian black army!
Jesus-holy-christ-in-mother-have-you-heard-of-IDEs moment...
ms_deezNuts;
Or you could get a decent IDE lets you easily see the variable being defined.
I hear this argument a lot, but here's the problem with it: when you're looking at code, you're not always necessarily in your IDE. What if you're doing a code review on github? What if you have to use windbg for whatever reason? Admittedly these cases don't apply to everyone but I think depending on the IDE to make code readable is likely to bite you in the ass at some point.
Double click on an variable or function in github, and it can quick glance you to the definition/header, right there in the browser. I was pleasantly surprised when I found that out.
Originally the "type" was a semantic one like "safe" vs "unsafe" so if you see a call like:
beware(sInput: uShitComingDirectlyFromTheUser)
If the "s" prefix is for safe data you know you can use wherever and "u" is for unsafe one, you can easily see some shit happened there. It can be a good thing for languages using only basic types (int, char* etc.).
But most languages encode this information by using types nowadays. So you'd declare a SafeString and UnsafeString types and your compiler / IDE would be able to tell you if you fucked up. You could even overload the assignment operator on SafeString to clean UnsafeString if you're lazy (or use a specific constructor to keep the change obvious).
Idk, like IDE tells you
More like C devs
From C++ standpoint.
It's extremely important to know if your variable is a member variable or a local varable. You do not want to return by reference on a local variable. You do not want to capture your local variable by reference if your lambda function is going to be used out of scope.
Always keeps track the life time of your variable will save you from a lot of segmentation fault headaches down the road. So adding m in front of member variable is a good reminder not just for you but also to make code reviewer's job a lot easier.
Without prefixes, you can't have the legendarily useless type names like LPARAM and WPARAM.
Hungarian notation is so undervalued. yes, modern tools will give you type, but will it give you context information? for instance is this string URL encoded? or base24 encoded, or raw and unchecked? or is it suppose to represent the number in specific format?
yes, yes, i know. in "correct OOP" approach, i suppose to create a class, and make methods to retrive and set, and make this context information part of methods, but then i have a question: why all new popular languages and frameworks, essentially trow OOP under the bus?
I agree on your specific examples. I would argue that this is different from encoding basic types in the name of every single variable though.
I, for example, would always suffix variable names for context (encoding, checked / unchecked, etc...). But why do I need to suffer a 'arru8' before the name of an array when any modern IDE is capable of showing me what type it is, when it was declared, etc... That's more obfuscating than helping. No extra info there...
Edit: typo...
ideas evolve. before modern IDE, and memoty safe languages having type in variable name was essential. then it become redundant, but approch itself is not bad not good. screaming "Hungarian notation is bad" because one day it was used to outline variable types, is like stating that "c++" is bad, becouse it was used to write console applications.
Indeed, ideas evolve. And practices should evolve as well, when applicable.
I believe Hungarian notation made a lot of sense with older tools, or with loosely typed languages. And I could even agree (to some extent) that they can still make sense for some modern tooling. For example, the GitHub online editor does not provide a lot of insight when doing PR reviews. And I have not yet found a valid counter argument to this when people point it out.
But I've seen teams of experienced (and not) devs refusing to learn new techniques or tools, and refusing to question in any way their practices because of the golden rule of "it works well like this, and we've always done that". Don't get me wrong. It's not a huge problem. I just get frustrated and start looking for a new job, where people are more welcoming to criticism and improvements. (BTW not all change is good, and some conservatism is important)
tools and practices, shuld be used on purpose, not because of habbit. in best case scenario - discussed by project team in the beginning, with keeping in mind tooling, challenges and environment. refusing to learn some new is never an excuse, it contradict the very essence of being engeneer. not only in IT.
Any code base with a sufficient lifespan due to its usefulness will eventually have some members change types.
Changing the type in a header is easy. Changing every use of a variable is really hard (time consuming) to do properly.
Make a strong type and names won't protect you from misusage.
The only prefixes I see used regularly in c++ are m for member, s for static, g for global and sometimes p for pointer. And it has its reasons. For example m is also good for avoiding some name collisions.
prefixes for individual types are not used in modern code in c++ that often.
My linter keeps yelling at me about using PascalCase on member variables. Can't imagine going back to Hungarian notation...
I guess it depends of the company and team culture. I've seen 'extreme' use of Hungarian notation in a few of the teams I joined already...
i still didnt find a single Hungarian notation out in the wild ( this is my 18th year)
I never understood the m prefix. You should just use
this->Well as I explained it is also good for preventing name collisions in the class / structure. And many people think it is good to differentiate that something is a private member.