• (nodebb)

    The frist thing I noticed was the discrepancy between using Convert.TodateTime(string) in one place and DateTime.Parse(string) in another. The only difference is that if the argument is null, Convert() returns DateTime.MinValue whereas DateTime.Parse() throws ArgumentNullException

    Good bet the devs in question a) didn't know that and b) aren't trying to null-guard. They just hate being consistent in anything they do. Just like with their f-ed up naming. Maybe "hate" is too strong a word. Perhaps better said they're too haphazard a thinker to be consistent.

    In terms of quality, haphazard thinking and software development go together about like water and electricity. In terms of commonality, it's more like peanut butter and jelly. Sigh.

  • (nodebb)

    I was actually consider stop reading after Convert.ToDateTime but they lost me at ) with no CultureInfo in sight. At this point it really doesn't matter what the rest of the article has to say, because there's no coming back from that point.

  • DanielOfMyr (unregistered)

    I worked many years in a big engineering company, one with 100k people and B$ of revenues, where SAP was used to manage working hours in a decimal number format

  • 516052 (unregistered) in reply to DanielOfMyr

    To be fair if you are charging by the hour just keeping the hours logged rather than some sort of date structure makes perfect sense.

  • (nodebb) in reply to MaxiTB

    I always say .NET's conversions should have defaulted to InvariantCulture instead of localized stuff.

  • (nodebb)

    You hate Hungarian Notation, well, I hate Hungarian Notation and ASP.NET webforms. 😆

  • (nodebb) in reply to Medinoc

    Yeah, and InvariantCulture should have defaulted to ISO standards than some random local nonsense pretty much nobody in the world uses :-) But eh, .net is far from perfect by any means even though it is superior in many ways over it's direct and even indirect competitors.

  • Lukiko (unregistered)

    Our old codebase had something worse than Hungarian Notation. Essentially instead of prefixing the variable name with a type abbreviation, the abbreviation WAS the name. So you get floating point variables called f and f2 and strings called s deep in the business layer. Some people also used Hungarian Notation for local variables on top of that. So you end up with descriptive names such as lsl for a local string list.

    Incidentally the original concept behind Hungarian Notation was good. It was supposed to encode the "kind" of a value, not the type. For example you could have two ints: hMax and wMax. The prefixes standing for height and width. This makes a line of code like hNew = wMax look wrong, because it probably is. But people misunderstood this concept and thought the prefix should encode the type...

  • (author) in reply to Lukiko

    There's the whole systems vs. apps Hungarian, but honestly it still just makes things cloudy. Even in your example: height_max is just a better name. I will grant, it's not entirely bad, if you look at the original paper, because char * could be either a string or a pointer to a single character, and you have no idea which. So szMyString for a null terminated string does make at least some sense, but even then, a typedef is going to be my preference.

    In my ideal world, which isn't elegant in every language, hMax = wMax should be a compile error, if I truly don't want to mix those types together.

  • (nodebb)

    I once worked in a startup where I had to use COM and OLE Automation and I still have nightmares from that.

    The APIs were awful for sure, but the worse was the PHB who kept on my back with "but the MS regional sales manager said it was easy and <insert buzzwords with no relevant meaning>, so why aren't you done yet?"

    Mostly because I had no spec and was working with a moving goal post that changed each time the boss was giving a demo to his VC friends.

  • Hmmmm (unregistered)

    The rant-to-lines ratio is big on this one. The lovely cherry on top is the simple one-liner that could have been used all along, although I get the creeping feeling it wouldn't clean the app up that much.

  • TS (unregistered)

    OLE Automation may be horrific to developers, but as a user it's incredibly powerful and useful. I once wrote a simple VB script that pulls some data from Access, does some mangling in Excel, draws contours of the results in Surfer, and pastes the resulting picture into a Word document with a suitable caption, all with a single button press. When you've got dozens of these to produce, it saves a lot of time and a lot of errors. And each tool is being used for the thing it's best at.

  • (nodebb)

    I'm coming to like Hungarian notation just because it sets Remy off, and the results can be interesting/fun to read. As a programming thing, yes, I get the extreme distaste.

  • (nodebb)

    I hate Hungarian Notation

    As you've said many times before. What's weird here is that more than half of the article isn't you hating on HN, nor on the weird mixture of AHN (indicative of a weak type system) and SHN (indicative of a freight sect based on a misunderstanding of the original purpose of HN, that is, AHN), but rather the weird (in a more general sense) naming of certain of the variables and functions, and the cock-eyed history of Excel and 123 spreadsheet values.

    But wart-only HN (as mentioned by Lukiko) is a mortal sin, whether it's AHN or SHN or some weird hybridised combination.

  • (nodebb)

    This is making my days of FORTRAN seem relatively painless, in that the compiler allowed a maximum of six characters for variable names and function names. No one could waste even a single letter as a type prefix.

  • (nodebb)

    I remember when six characters was enforced by the LINKER. And by enforced, I mean you could give it longer names, but it'd just ignore the rest of them. That really killed your C programs attempting to use exotic function names like 'calc_max_height' and 'calc_max_width'.

  • scragar (unregistered) in reply to Lukiko

    The original paper for Hungarian notation says to use it for things that you can't easily tell in other ways, and their examples included:

    Indicating if a variable was sanitised for the DB or not(because SQL by concat was a thing). Indicating if a variable had been validated(so you know if you have vDateOfBirth then it's a date of birth that has been validated to be a valid date in the right range for a date of birth, while uvDateOfBirth has yet to be verified). Identifying how the data needs to be handled different to other variables, for example API credentials that automatically make any data containing them unsafe to include in logs the user may access.

    This also was supposed to persist, if you validated the DOB before you saved it then the field in the DB should reflect that it's verified, if for some reason anyone ever found themselves writing unverified info to a verified field that's obviously wrong and anyone reviewing the code should be able to tell.

        "UPDATE User SET vDOB = {uvsDOB}"

    UV = unverified, it should never be written to a verified field. We should have a verification process that writes it into a verified variable and then save that.

    Things like the source of information and does it contains secrets are hard for humans to figure out from the code, a couple of characters make it very clear which is super useful.

    Height or width are things you're going to include in the variable name anyway, but not many people make the distinctions on where and how you can use the data the variables hold which leads to a lot of bad data or leaks.

  • (nodebb)

    It's just a long-winded way of saying I. Hate. Sauerkraut.

  • Officer Johnny Holzkopf (unregistered)

    When I was in school, we had several locked-down Windows 3.1 systems that could only start "defined" programs (i. e., those we were allowed to use). Using OLE, it was possible to embed a "program call" into a document, as we were allowed to use the word processor, and that neat trick gave us the ability to embed a call to a "non-allowed" program, such as the MS-DOS prompt, the file manager (winfile.exe) or the program manager (progman.exe). The people from the support company that were paid big money to lock down the system were absolutely clueless. And in the end, the members of our school's own computer club became the actual system administrators for the whole school. Saved money, kept things running, and we learned much more than anybody could expect...

  • A Human (unregistered) in reply to Officer Johnny Holzkopf

    Reminds me of how years ago, my school blocked youtube.com, but one of my mates found out you could watch youtube by going to powerpoint > insert > video > online video. Recently, he moved to a new school where the computers are locked down very tightly. You can't run any exe you want. But there's a folder in /c/windows/ that is user writable. Just copy your illegal programs (i.e. a minecraft launcher and a portable browser with a free vpn extension) to that folder and they run. Then the it department blocked that folder from file explorer. Then they figured out that people who do an it class at the school can use python's os.system to copy the files there.1

  • (author)

    for things that you can't easily tell in other ways

    Choose a language with a good type system and lean on it. The compiler will take care of the telling for you. HN is a solution to a problem that has been eliminated by graphical IDEs and strong types properly used.

  • (nodebb)

    This may shock people, but I actually liked COM. Didn't go deep enough in it to do actual OLE, though.

    Addendum 2026-06-12 03:44: Still like it, in fact.

  • (nodebb)

    The Hungarian notation is awful, sure, but in this case it's a minor part of the WTF. The real WTF is the whole OLE date mess.

  • Scragar (unregistered) in reply to Lyle Seaman

    Hungarian notation as most people use it was never required.

    Even when it was first proposed the major examples weren't the type of a variable, you could always just look at the top of a function to see the variables type(this was 1972, there were no classes back then, just global scope or local scope), it was always stuff that a casual glance wouldn't tell you: is a string null terminated, is the input validated to be of the right format, does it contain sensitive data to keep out of logs, is it sanitised, etc.

    The way it was proposed makes a lot of sense, but the problem is it's hard to convince people to use it correctly(and even Microsoft who he worked for and told them how to use it did it incorrectly deciding to use both approaches before eventually just using the version he advocated against).

    If people used it correctly the world then it does help catch bugs and make software better, used wrong as many people do then it's just clutter, but because anyone who has read the paper sees the value in it and advocates for doing the right thing a lot of people who don't read the paper are convinced the bad implementation is somehow good.

  • (nodebb)

    i work as a part time DBA in a very large company... why i understand you put vw_ in front of a view name (so you actually know it's a view without having to look it up), we have lots of tables starting with tbl_ . Seems a bit overkill to me.. and moreover, fields start with an abbreviation of the table name (something like agt_ for agent... but i would think it should be fld_agt_ to be in line with table name)...

  • Craig (unregistered) in reply to Lyle Seaman

    Leaning on the type system is great right up until the point where you need to interact with a vaguely-typed runtime library (side-eye to some .NET point-based APIs that make it impossible to use a type system differentiation between device-independent and device-dependent coordinates).

  • Cmdr Javik (unregistered)

    Even being turned into a husk by Reapers are preferable to this torture.

Leave a comment on “Dating in Hungarian”

Log In or post as a guest

Replying to comment #700304:

Log Out

« Return to Article