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

Leave a comment on “Dating in Hungarian”

Log In or post as a guest

Replying to comment #700276:

Log Out

« Return to Article