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...
Meanwhile, the intern:
auto temp =
WTF!
ms_deezNuts;
More like C devs
C++ dev working in embedded here.. you would not believe how those C gremlin refuses to use namespace and use prefix for every stupid thing.
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).
Without prefixes, you can't have the legendarily useless type names like LPARAM and WPARAM.
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.
Github has syntax highlighting and reference links for some languages though (at least it has for C#)
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.
Similarly, using an underscore prefix (which I do a lot for private members) communicates to the reader that the field is private without them having to go to reference. I say do whatever makes the code easier to read and understand, because in 2 weeks, that code might as well have been written by a stranger.
Idk, like IDE tells you
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.
In modern languages you'd want to encode that info directly in type system and have it checked by compiler whenever possible - hungarian notation works well to convey important context that type system is unable to express, or makes it more obscure.
Sure, if you're working in C, having variables names "msTime" (time in milliseconds), "cbSize" or "cSize" (respectively size expressed in bytes and amount of elements) is fine, but most higher level languages have better way of expressing that information, often with build-time or runtime checks available.
For your strings example, it's where I'd use strict aliasing/empty subclass - allows implicit upcast (url-encoded string is still a string for all possible uses), but requires explicit casting that's immediately visible to programmer when making assumptions or checks about contents. Paired with good use of generics/templates it isn't even bad to work with.
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.
I never understood the m prefix. You should just use
this->My guess is that people who write
this->are also C programmers and are used to the object state being explicit.Having started with C++ I got used to the object state being implicit so I never think to write
this->, and so inevitably I started using an m prefix to differentiate between local and member variables.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.
Way too wordy.
If you're in a member function, all your non-member variables should be within line of sight, so disambiguation is nearly unnecessary. Leading m or trailing _ is enough.
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)
Win32 API and related use it quite extensively to denote semantics, given that neither C nor C++ (until very recently) had a way to typecheck against different semantics of same underlying type.
I work with Linux mainly, i think I met some on x11 libs, but can't remember anything else atm