Back in the day systems hungarian was the done thing and just about everyone named variables like nStudents (signed-integer), szName (zero-terminated string) and msaxProfiles (static member variable that’s an array of structs…yes, people would often stack prefixes)
That all went out of fashion as 99% of the time it was just extra typing and didn’t really help with much (and it could even mislead if someone had changed a type without bothering to update the name).
But personally I still find hungarian aids clarity in some cases, so I still do:
p for ptr
k for constant
m / ms member variable or static member variable
I for interface
And, when doing forms in C#, I prefix my control names with 3-letter abbreviations (e.g. btnDoAnalysis, txtUserName). I’ve found this handy because often several controls are associated with the same functionality, so having the control type in the name reduces ambiguity.
I never used it. Reading Hungarian notation makes my brain hurt. For that matter, I avoid C/C++ shorthand types like UINT.
As a Born Again Object Oriented programmer, a widget is a Widget. The attribute types are things like unsigned integer, double, and char *, unless I use another class like String. Coding like this is thoroughly unambiguous, IMAO.
Here is an excellent essay on how Hungarian-style coding conventions can be used to improve software reliability. Making Wrong Code Look Wrong by Joel Spolsky. His thesis is that by a judicious choice of variable naming conventions (not exactly the Hungarian notation as most of us have come to know it via Microsoft), you can tell at a glance if you are doing some kinds of bad things with your variables.
Towards the end of the essay is a section on Hungarian notation, as used by Microsoft, and how they got it seriously fucked up. The original conventions, as intended by Simonyi, got lost in the bureaucracy and mutated into the abomination that we know now.
I don’t have time to get too far into this now, but the goal is to find the ideal amount of verbosity in variable names. Not too short to be distinct and readable, and not too long that it makes lines too long and allows the names to be misread.
As for Hungarian, I don’t use it unless there are multiple variables containing the same data in different types. So if I was keeping the INT and FLOAT versions of the same number in different variables, I’d add an I or an F, or something like that to be distinct. Modern compilers alleviate the need to that very much anyway.
Yes, very interesting link. That one little misunderstanding had huge implications. As I said, for years I worked in teams where (systems) hungarian was virtually a religion and it was quite a task to keep up with all the permutations of stacked prefixes.
How does this variable stack up, from a current project that I’m working on?
class WowIWonderWhatShiteCodeMustBeInTheCompilerToMakeThisWorkaroundWork
I program in C# and everything gets a prefix. Forms get btnThing, lblThing, txtThing, etc. In the code not as much as we used to with classic ASP (because everything has to be declared and the Intellisense is so good) but usually integers get an i, dates get a dte and anything other than strings are prefixed.
What really sucks is when you have an outside programmer come in and he doesn’t take a minute to figure out (or ask about) your group’s prefix standards and does stuff slightly different than you’re used to, and you have to either fix his shit, conform to his shit, or have a project with two different sets of prefixes. :-/
I never use it in personal projects, but the work project I’m on now uses some. We mostly don’t use whole stacks of prefixes, but constants and variables get prefixed with “c” and “v” respectively, and a fair number of other things. Of course, that’s probably because all the tools we’re using were written in Hungary, and the Eclipse plugin they wrote complains about naming conventions if you don’t follow their (undocumented) scheme.
I also do this (some IDEs even give you predefined names starting with btn, txt, etc when you create a control), but variables should be self-evident if they are named properly (a variable like UserName obviously is a string type).
I’ve never even heard of the term. But I guess I do use it most of the time. Things like counters I use more generic names. I don’t know if there’s a standardized Hungarian naming convention but I use my own prefixes. I like the system because after trying to figure out my boss’ confusing intermittently-commented spaghetti code*, I realize that knowing what the variables are rather than scrolling up and trying to find the declaration saves hours.
The main thing I don’t like, addressed in the OP, is if you do change the variable type, e.g. signed to unsigned, single to double, etc. and have to either change or ignore the prefix.
*Sample variables: ilut, nrev, cor1, value, sterr. None of those have the variable name in the first letter.
J, K are always my work counters. I also use them to subscript arrays.
Card-File and Info-Rec are hold overs from our old Batch days. Operations would use a punch card for simple program input like a date range we wanted to use and whether we wanted Summary or Detail reports. 2011010120110630S would be used to summarize the first two quarters of 2011. We continued using a real punch card until 1989.
I still use Card-File and Info-Rec in my programs even if my input is coming from a User typing at the computer. Its understood in our shop that Card-File is data input at run time.
I do something similar sometimes. Sometimes you have a “lblFirstName” (label for the “First Name” field), “txtFirstName” (the textbox for the first name field), and “hdnFirstName”, which is a hidden field related to some programmatic need related to the First Name functionality that you need. You could always just factor the whole thing into a “NameInput” component with sub-objects called “label”, “name”, and “hiddenField”, and then declare a “FirstNameInput” and a “LastNameInput”, but sometimes you just need two names and it isn’t worth it.
I’m tempted to say that’s justified use of an overlong variable name. But WTF might have served just as well.