• (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.

Leave a comment on “Dating in Hungarian”

Log In or post as a guest

Replying to comment #700279:

Log Out

« Return to Article