• (cs) in reply to Remy Porter
    Remy Porter:
    warlaan:
    There was a time when IDEs were not able to use colors to mark keywords and when it was not possible to display tooltips when you hovered over a variable name with the mouse.

    Here's the thing: I never use the IDE to check the type of a variable. I generally just look at the code, because the variable declaration is someplace convenient, like a few lines above where I'm using it. Or the variable is named something that semantically implies its type. "DueDate" is how we say it in English. "dteDue" or "dteDueDate" is not.

    Didn't read until the end so maybe somebody already replied.

    Hungarian notation is NOT about writing "dteDueDate" to indicate that your date really is a date, or writing intOffsetX to indicate that this is really an int.

    Hungarian is about encoding useful information into a variable name. For example you could have distances expressed in centimeters and in inches.

    "cmTotalDistance = cmFirstPart + inchSecondPart" is immediately understood to be wrong. Your compiler won't help you there.

  • TopTension (unregistered)

    To each their own. But to some it seems to be a religion. This is worse than Mac vs. Windows vs. Linux:-) Did we have any comments about other aspects of todays WTF at all?

    I've worked on code with and without hungarian notation. I like the scope prefixes, beeing able to see at a glance if it's a member, a global or a static variable. I guess I could live without the type prefixes and I never do the really long multiple composite prefixes.

    If I'm in someone elses code without hungarian, then I won't use it, no biggie.

  • Anon (unregistered) in reply to Whatever

    On Hungarian notation:

    Having 100 variables that all start with int makes intellisense a sad panda.

  • Anon (unregistered) in reply to bjolling
    bjolling:
    Remy Porter:
    warlaan:
    There was a time when IDEs were not able to use colors to mark keywords and when it was not possible to display tooltips when you hovered over a variable name with the mouse.

    Here's the thing: I never use the IDE to check the type of a variable. I generally just look at the code, because the variable declaration is someplace convenient, like a few lines above where I'm using it. Or the variable is named something that semantically implies its type. "DueDate" is how we say it in English. "dteDue" or "dteDueDate" is not.

    Didn't read until the end so maybe somebody already replied.

    Hungarian notation is NOT about writing "dteDueDate" to indicate that your date really is a date, or writing intOffsetX to indicate that this is really an int.

    Hungarian is about encoding useful information into a variable name. For example you could have distances expressed in centimeters and in inches.

    "cmTotalDistance = cmFirstPart + inchSecondPart" is immediately understood to be wrong. Your compiler won't help you there.

    What you describe is possibly helpful, but it ain't Hungarian notation. You are redefining the term.

  • neminem (unregistered) in reply to bjolling
    bjolling:
    Hungarian notation is NOT about writing "dteDueDate" to indicate that your date really is a date, or writing intOffsetX to indicate that this is really an int.

    Hungarian is about encoding useful information into a variable name. For example you could have distances expressed in centimeters and in inches.

    It wasn't supposed to be: hence the comment about the difference between system hungarian and apps hungarian. Hungarian notation was supposed to be for denoting critical pieces of information in a standardized way that wouldn't be known by your IDE, because they were semantic pieces of information, not syntactic. It got misinterpreted by Microsofties way back when, and the incorrect interpretation spread like a disease, and now everyone "knows" that hungarian notation means "be stupid". But encoding (for things that it would be useful for: not for every variable) information like "this int came from a memory pointer", or "this string has had an html-encoding function run on it" or "this Point object is a point relative to its parent groupbox" into the name of the variable, makes perfect sense. (See also: Joel On Software being right about things.)

    I'd argue most good programmers do that already: they just might do it in a slightly more readable way, because nobody cares about lengths of variables so much anymore, now that we have autocomplete and more-than-80-characters-wide screens.

    (On the other hand, I think his dislike of exception-handlers is dumb.)

  • Barf 4Eva (unregistered)

    TRWTF is that everyone who commented on this article only cared about the "issue" of hungarian notation. :(

    Seriously, over it man...

  • Brad (unregistered)

    "Suspends UI redraw rather than use asynchronous UI and callbacks"? This is stone age pre-.net Visual Basic, no? Could such a thing even be done using that toolset?

  • Will A (unregistered)

    Taking code that used Hungarian Notation dates itself to the past and then applying todays logic to it for not using asynchronous is TRWTF

  • (cs)

    Using comments as version control is something that is industry wide practice in US of A. I have seen this many times in my own code as well as coed I inherited from others.

  • (cs) in reply to Nagesh
    Nagesh:
    Using comments as version control is something that is industry wide practice in US of A. I have seen this many times in my own code as well as coed I inherited from others.

    And it's often done by clueless retards who don't understand the point of version control. My last job had a dude (old VB guy) who would litter the code with this crap; change logs, comments stating what bug was fixed, and the occasional "No clue why this is here but removing it breaks things :(" comment.

    When I asked him why he didn't put those in SVN, he gave some BS answer about it being easier to see the comment/note in code instead of having to hunt through the logs.

  • anonim (unregistered) in reply to Remy Porter

    Most programmers misundestand Hungarian Notation. It was never meant to indicate the type of the variable, but its unit. For example: dxLength1 is the distance in the x-direction, and dyLength2 is the distance in the y-direction. If you then add dxLength1 and dyLength2, it is immediately apparent that the two numbers don't add up. Hungarian Notation is a life-saver when you need to calculate engineering-units.

  • Shinobu (unregistered)

    Spanish flu Dutch comfort German measles Chinese ace Russian roulette Hungarian notation

  • best airline (unregistered)

    I could go for a ride on a g string airline

  • (cs) in reply to Remy Porter
    Remy Porter:
    I'm tempted to flex on my "hungarian is evil" for the special case of pointers, only because pointers require a very different syntax.

    Tempted, but I won't. And the main reason that I won't, is that if the purpose and meaning of the variable isn't clear from its context, then your context is broken.

    What rot. Tell me whether a var named "view" is a pointer or an object or a reference?

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Nagesh:
    Using comments as version control is something that is industry wide practice in US of A. I have seen this many times in my own code as well as coed I inherited from others.

    And it's often done by clueless retards who don't understand the point of version control. My last job had a dude (old VB guy) who would litter the code with this crap; change logs, comments stating what bug was fixed, and the occasional "No clue why this is here but removing it breaks things :(" comment.

    When I asked him why he didn't put those in SVN, he gave some BS answer about it being easier to see the comment/note in code instead of having to hunt through the logs.

    The odd note "this was added for F/24:5" is fine and good - hunting through 100s of versions is a pain. But it should be limited to major changes you want to know about.

  • MiniMax (unregistered)

    Ahh - magic text strings!

    I have been hit by that too. I took over a system created by non-English speakers that for some reason had decided it was a good idea to log messages in English.

    Unfortunately, they did not use spell-checkers when creating the messages, and they had a total disregard for minor details such as starting sentences with uppercase, use a space after comma, and finish the message with a full stop.

    I started fixing that when I came across such ugliness and soon the system started to leak left and right. It turned out that other parts of the system relied on those log messages for displaying statuses and for triggering events. And of course that part of the code did not recognize the reformatted log messages.

    So now the code has been sprinkled with warnings like

    // OBS: Magic finish message. Used by MasterRouter to start processing the file.

    and // OBS: Magic size message. Used by ReportPreparation when when collecting event information.

  • (cs) in reply to SeySayux
    SeySayux:
    faoileag:
    SeySayux:
    Third, for those who say "but it helps me remember the type!". If you need to scroll more than 50 lines up or down to see the type of your variable, you're doing something wrong.
    Ever heard of the notion "member variables"? These nifty things are usually declared in the .h files in C++ projects, so you not only have to scroll 50 lines to see their type declaration, you have to open another file prior to it as well.

    I don't know what editor or OS you use, but mine have these nifty features called "split windows", "multiple windows", "toggle header/source" and "go to declaration". Quite handy!

    How big is your monitor?

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Nagesh:
    Using comments as version control is something that is industry wide practice in US of A. I have seen this many times in my own code as well as coed I inherited from others.

    And it's often done by clueless retards who don't understand the point of version control. My last job had a dude (old VB guy) who would litter the code with this crap; change logs, comments stating what bug was fixed, and the occasional "No clue why this is here but removing it breaks things :(" comment.

    When I asked him why he didn't put those in SVN, he gave some BS answer about it being easier to see the comment/note in code instead of having to hunt through the logs.

    Partly I agree with the old guy. Speed of checking comments in code is much higher than sifting through subversion comments and trying to find out what is happening.

    Also another bad practice, which I like is comment out old code and keep it there. We have java servlets that contain pages and pages of commented code. then we know what took place on 1-Apr-2006 that caused the code to change.

    Some comments are also colourful with email messages in them.

    /* Mail from John **Jun,30, 2008 We want to bypass this condition where it checks for specific branches. Don't care about report loading time. Make it happen.

    */

  • (cs)

    Not that I want to try to justify any of that mess but when I see the word "airline" I think "screen-scraping 3rd-party apps" and in that case, it might well be that the word "Complete" is a trigger word for something else.

    It's still a steaming pile when you could use some kind of event notification/generic pub-sub/MQ/whatever if you need interop.

  • (cs) in reply to BrainrotFromVB.Net
    BrainrotFromVB.Net:
    TopTension:
    So Hungarian Notation is a WTF these days?
    Yes!

    I'm ahead of the game: I use my own personal reverse-Hungarian notation. Any object that I don't really want to keep around ends in either "foo" or "bar." So there!

  • (cs) in reply to bluesman
    bluesman:
    I prefer camelToe notation.

    I bet I'm getting Whooshed here, but that's "CamelCase." "Cameltoe" is a rather different, NSFW topic.

  • PG4 (unregistered)

    Damn kids that don't know how to code down to the bare hardware

    Do some VMS macro programming... you will love it that DEC named things they way they did.

    3 letter facility name, $ datatype _ name

    for example

    CIA$L_FAILLOGINCOUNT

    CIA - Central intrusion App

    L a longword

  • (cs) in reply to Nagesh
    Nagesh:
    ... as well as coed I inherited from others.
    You inherited a coed? I'd keep quiet about that if I were you.
    Nagesh:
    Some comments are also colourful with email messages in them.

    /* Mail from John **Jun,30, 2008 We want to bypass this condition where it checks for specific branches. Don't care about report loading time. Make it happen.

    */

    Next time someone tells me to do something stupid, I am SO going to do this !

  • jay (unregistered)

    I'm not a big fan of Hungarian Notation, but many of the criticisms are unconvincing to me. Funny that I can agree with you but totally disagree with many of your reasons.

    "If you need to scroll more than 50 lines up or down to see the type of your variable, you're doing something wrong."

    Really? When you're reading code, you continually scroll up searching for the declaration of a variable, and then scroll back down to where you were, see the next variable, scroll up searching for a declaration, etc? That seems like an awfully awkward process. Even if you find it within 50 lines or so, that's a lot of scrolling up and down.

    RE tooltips in the IDE: Okay, that's way less of a pain than scrolling up and down. But (a) It assumes that you have an IDE with such a feature and you always use it when reading code, and never, e.g. read code in vi or from a print-out; and (b) It's still distracting to have to be mousing all over the place when trying to read code.

    As I say, I rarely use Hungarian Notation, but I can see the argument for it: It means the type information is all right there: you just read it, you don't have to look for it.

    There is one circumstance where I do use HN or HN-like notation: When the same logical value is stored in different formats or different structures.

    Example 1:

    String strQtyOnHand = request.getQueryString("onhand");
int intQtyOnHand = Integer.parseInt(strQtyOnHand);

    In such cases, HN makes very clear what we are doing and which is which.

    Example 2:

    dim strCustomerName as String = tbCustomerName.text

    Again, the control is closely associated with the text value that we will read from or write to the control. It makes good sense to give them names which only differ in a prefix or suffix that identifies which is the string (or int or whatever) and which is the control.

    RE the type may be a lie and thus gives only a false sense of security:

    Sure. But you can say that about any variable name. If I see a variable called "customerName", it's possible that it really contains the zip code and the original programmer is lying to me. Indeed, while that example is extreme, I've read plenty of programs where variable names are misleading. The solution to that is to not lie when naming variables, not to deliberately remove information from variables names to avoid the possibility that the information might be wrong.

    I had a job once where IT management announced a new standard that in the future all program names must be sequence numbers. (With a prefix identifying what environment they ran in -- like Web vs GUI -- and what language they were written in.) So we had program names like NBC1057 and IOF3298. Of course the programmers objected that this made it very difficult to keep track of which program was which. Management's response was that a program name could never tell you exactly what the program did and might be misleading. So ... because a name can't be guaranteed to be complete and accurate, we should make it totally meaningless?

    RE the type should be obvious from the name: Well, it often is, but not necessarily. And that, I think, is the point. If I see, for example, "hireDate", I'd probably assume that's a date. But is it an internal date object, or is it a string? In Java it might be a Date or it might be a Calendar. Sure, if I see "customerName", then barring the possibility that the variable name is a complete lie, I think I can safely assume that it is not an integer or a date. It is probably a string. But it might be a text box. Or for that matter, it might be an enum that is used to identify customer name versus address versus company name. There are lots of possibilities.

    Personally, I do not normally use HN. But I do use it, or something like it, when I run into cases where I have the same "logical thing" in two different formats, or when the name could be misleading.

  • (cs) in reply to Steve The Cynic
    Steve the Cynic:
    We impose a reasonable rule that a variable contains a maximum of one sort of text,

    You mean you won't let me use strAddressEmployee as a temporary work area for an XML of federal tax id? WTF?

    Reuse, man!

  • GeneralKnowledge (unregistered) in reply to Brian Bobley
    Integers of type char* and so on though ...

    ... are still integers since they reference a memory location. They do so by specifying the start of the referenced data structure as offset from the start of a process' address space.

    So, yes, char* is an integer. It refers to some (hopefully null-terminated) characters, but in itself it is an integer.

  • Slapout (unregistered)

    TRWTF is not a single featured comment

  • GeneralKnowledge (unregistered) in reply to Brian Bobley
    Brian Bobley:
    faoileag:
    Pointers point to memory locations, in other words: are integers.

    Integers of type char* and so on though ...

    ... are still integers since they reference a memory location. They do so by specifying the start of the referenced data structure as offset from the start of a process' address space.

    So, yes, char* is an integer. It refers to some (hopefully null-terminated) characters, but in itself it is an integer.

  • GeneralKnowledge (unregistered)

    The 'C' in "CVS" stands for "concurrent" - and not for "commented"(?) or something similar as the post suggests when it asks what the 'C' in "CVS" stands for.

    So yes, some comments with instructions on what to do might go right into the code.

  • Sigivald (unregistered)

    #5 is a WTF.

    #1-#4 all tell me "this is old VB-pre-.NET code".

    "Hungarian" notation used to be an alleged Best Practice.

    There WAS no decent threading solution in VB6 and earlier for background work while keeping UI going.

    (Oh, it was possible. But not worth it in anything normal.)

    It would be a WTF to do #1-#4 today. Turns out legacy code was written with the tools available at the time.

  • (cs) in reply to faoileag
    faoileag:
    ZoomST:
    faoileag:
    warlaan:
    But I agree that nowadays it is a WTF, because it only adds information that is supplied by the IDE and that can be faulty onace a data type is changed.
    What is this IDE you are speaking about?

    vi certainly does not impart type information to the developer that easily...

    Obviously you are not using the new vi for Windows 8. Surely it only uses a couple of GB of memory when launched, and needs a permanent internet connection...
    Does it have tiles? I don't want it if it doesn't have tiles!
    Ok, here's what's coming from MS for Win-8 developers:

    They will archive every piece of code ever written on their servers. When you point at some code in your editor, it pops up a separate tile for every conceivable chunk of code that could possibly complete whatever it is you are attempting to code. Then you can just point/drag the tile of choice onto your editor.

    What could be simpler?

  • Tractor (unregistered) in reply to GeneralKnowledge
    GeneralKnowledge:
    Integers of type char* and so on though ...

    ... are still integers since they reference a memory location. They do so by specifying the start of the referenced data structure as offset from the start of a process' address space.

    So, yes, char* is an integer. It refers to some (hopefully null-terminated) characters, but in itself it is an integer.

    Ok, let's make one thing clear: In C++ pointers are not integers. You can NOT implicitly convert from a pointer type to a non pointer type, or vice versa. You will need a reinterpret_cast for that.

    I doesn't matter one bit how pointers are represented internally. They CAN NOT BE USED AS INTEGERS. The compiler will SHOUT AT YOU if you try.

    So repeat after me: POINTERS ARE NOT INTEGERS IN C++.

    Don't believe me? Try this:

    void foo(int a) {}

int main() {
  char * bar = "I AM NOT AN INTEGER!";
  foo(bar); // Compiler will tell you that A POINTER IS NOT AN INTEGER.
}
  • Anon (unregistered) in reply to English Man
    English Man:
    Remy Porter:
    I'm tempted to flex on my "hungarian is evil" for the special case of pointers, only because pointers require a very different syntax.

    Tempted, but I won't. And the main reason that I won't, is that if the purpose and meaning of the variable isn't clear from its context, then your context is broken.

    What rot. Tell me whether a var named "view" is a pointer or an object or a reference?

    I keep hovering my mouse over it, but nothing happens, so I don't know.

    Try it in an IDE. And if you're not using a modern IDE, then you are doing it wrong.

  • Tractor (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    faoileag:
    Steve The Cynic:
    faoileag:
    In C++, pointers are occasionally used. Pointers point to memory locations, in other words: are integers.
    ... SNIP ...
    ... SNIP ...
    ... SNIP ...

    If you try to printf anything using format specifiers that don't match the types passed in, you are in for a surprise. On 16-bit platforms, int and long aren't the same size, so trying to match %d versus a long variable will go wrong. Some platforms have pointers that don't match the size of int, so printing an pointer with %d or %X will go wrong. And the behaviour of a program with this kind of mismatch is undefined, so running it on a DeathStation 9000 will cause millions of unwitting citizens to die in nuclear explosions. (All joking aside, if the idea of your code having undefined behaviour doesn't scare you ****less, there's something wrong with you.)

    Clear?

    If you are printf'ing ANYTHING you're doing C++ wrong.

    Also, POINTERS ARE NOT INTEGERS (see above post).

  • (cs)

    "All modern integrated development environments display variable types on demand"

    Obviously all you so-called "experts" never write any Office VBA code in Office 2010 or later?

  • (cs) in reply to Anon
    Anon:
    On Hungarian notation:

    Having 100 variables that all start with int makes intellisense a sad panda.

    This.

  • (cs) in reply to Cad Delworth
    Cad Delworth:
    "All modern integrated development environments display variable types on demand"

    Obviously all you so-called "experts" never write any Office VBA code in Office 2010 or later?

    No. What does it do?

  • Buddy (unregistered)

    Some beer would be good right about now.

  • (cs) in reply to Cad Delworth
    Cad Delworth:
    "All modern integrated development environments display variable types on demand"

    Obviously all you so-called "experts" never write any Office VBA code in Office 2010 or later?

    Keyword: modern. VBA was already on life support before Office 2010 ever launched. The emergence of Powershell pretty much sealed the deal, with system adminstrators now having a better scripting alternative than the old VBA scripting from the Windows Scripting Host.

    Nothing new is ever going to come out of it and that includes usability enhancements. It's just maintaining the status quo for backwards compatibility. I pity the poor souls having to maintain LoB 'applications' patchworked together in Excel.

  • Harrow (unregistered)

    ns_I vt_use na_Hungarian no_notation npa_all da_the na_time. ns_It vt_makes da_the no_parsing a_so a_much j_easier.

    -pn_Harrow.

  • getSomething() (unregistered) in reply to Anon
    Having 100 variables that all start with int makes intellisense a sad panda.

    Well, 100 getSomething-functions doesn't make me happy either. Some languages will let you use properties but in others you still need to call getters and setters explicitly... Yet it doesn't quite invoke the same emotion.

  • (cs) in reply to Remy Porter
    Remy Porter:
    Nope, JavaScript is even worse when you use Hungarian notation, because you have no way to guarantee that the type in the variable is the type the Hungarian notation claims it is, and it's trivially easy to make a mistake which causes JavaScript to change the type of a piece of data into something you don't think it should be.

    Just because somebody hands you a variable called "strFoo" doesn't mean it contains a string. I once inherited code that had a variable named "intProjectNumber". The variable held things like "QR-1554-PL".

    If there are no compile-time type checks, all Hungarian notation does is add noise to your code and a false sense of security.

    Hungarian notation is another premise in software development where the people are more important than the idea. The person who put "QR-1554-PL" into intProjectNumber should be taken out back and beaten with a garden hose. I don't care which you use, just use it consistently, and correctly.

  • AndyC (unregistered)

    Hungarian Notation is indeed a WTF. And every case where it might possibly convey useful information is always handled better by spelling it out in full in the variable name rather than relying on someone else's interpretation of some obscure letter code being the same. We're not living in the 80s anymore, there isn't any benefit in needlessly shortening variable names to the point of meaninglessness.

    However, the real WTF is any code that calls Application.DoEvents() - fundamentally that is always a bug.

  • ronpaii (unregistered) in reply to Cad Delworth
    Cad Delworth:
    "All modern integrated development environments display variable types on demand"

    Obviously all you so-called "experts" never write any Office VBA code in Office 2010 or later?

    Right click on a variable and select "Quick Info".

  • Ronald (unregistered) in reply to ronpaii
    ronpaii:
    Cad Delworth:
    "All modern integrated development environments display variable types on demand"

    Obviously all you so-called "experts" never write any Office VBA code in Office 2010 or later?

    Right click on a variable and select "Quick Info".

    Haha you know stuff about VBA!

  • Ronald (unregistered) in reply to Ragnax
    Ragnax:
    Cad Delworth:
    "All modern integrated development environments display variable types on demand"

    Obviously all you so-called "experts" never write any Office VBA code in Office 2010 or later?

    Keyword: modern. VBA was already on life support before Office 2010 ever launched. The emergence of Powershell pretty much sealed the deal, with system adminstrators now having a better scripting alternative than the old VBA scripting from the Windows Scripting Host.

    Nothing new is ever going to come out of it and that includes usability enhancements. It's just maintaining the status quo for backwards compatibility. I pity the poor souls having to maintain LoB 'applications' patchworked together in Excel.

    VBA was never for system administrators. It was for slightly above-average office workers who knew enough to be dangerous but not enough to be truly helpful.

  • (cs)

    1. So what does "CVS" stand for? GIYF unless there are many results returned. There were.

    2. As to Hungarian Notation, I find it useful. Some of the prefixes that I use are: f for flag. fClient means Is this a client? c for count. cClient means How many clients? s for size. h for handle, fh for file handle. x for index/offset.

    I find HN useful if I am dealing in more than one representation. e.g. iSomething is an integer, and strSomething is the string form.

    Sincerely,

    Gene Wirchenko

  • ronpaii (unregistered) in reply to Ronald
    Ronald:
    ronpaii:
    Cad Delworth:
    "All modern integrated development environments display variable types on demand"

    Obviously all you so-called "experts" never write any Office VBA code in Office 2010 or later?

    Right click on a variable and select "Quick Info".

    Haha you know stuff about VBA!

    I didn’t until the previous post peeked my curiosity.

  • Bobby bob Bob (unregistered) in reply to Remy Porter

    i like hungarian for working with windows controls in vb/c#. have all labels "lbl" and textboxes "txt" and all comboboxes "cbo". then when i do my initialisation, if i have to init something for all labels for example, i can just go lbl ctrl tab, then get them in order like that so i dont forget any. then i can do the same to make sure i set a datasource on all combobox, etc.

  • (cs) in reply to Anon
    Anon:
    On Hungarian notation:

    Having 100 variables that all start with int makes intellisense a sad panda.

    Because having all of your variables spread throughout the list instead of grouped together makes more sense.

Leave a comment on “Do Not Remove Complete!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article