Not Dates, but Hours



  • We all know that Dates are something special. But Bernie's coworker thinks that also Hours are really special:

    public IEnumerable<string> Hours
    {
        get
        {
            DateTimeFormatInfo dateTimeInfo = DateTimeFormatInfo.GetInstance(CultureInfo.CurrentCulture);
            List<string> hours = new List<string>();
            if (dateTimeInfo.DateSeparator == "/")
            {
                for (int i = 0; i < 10; i++)
                {
                    hours.Add("0" + i + " AM");
                }
                for (int i = 10; i < 13; i++)
                {
                    hours.Add(i + " AM");
                }
                for (int i = 1; i < 12; i++)
                {
                    hours.Add(i + " PM");
                }
            }
            else
            {
                for (int i = 0; i < 10; i++)
                {
                    hours.Add("0" + i + ":00");
                }
                for (int i = 10; i < 24; i++)
                {
                    hours.Add(i + ":00");
                }
            }
            return hours;
        }
    } 
    

    Also note that he uses a DateSeparator to distinguish between hours with or without AM/PM. And while it is 02 AM, it is 2 PM. And 00 AM doesn't look so valid either...



  • @berniethebernie There is sooooo much special in that code.



  • I just undefined'd so hard I think I broke my nose...



  • Another stupid wheel-reinventing exercise. Any date/time library worth the name will have ways for format time any way you could want to: 12 or 24 hours, with or without padding 0's...
    Prescribed treatment: ruthless application of cluebat, cluehammer or the like, as often as necessary, for as long as necessary.



  • @khudzlin Yeah, if only there was some kind of DateTimeFormatInfo class that could be used there.



  • @khudzlin It's worse than that, really; the code monkey in question is trying to mop the floor by firing an ICBM at it. Let's unpack this:

    First, the code monkey in question (henceforth referred to as "Dumbass") declares what I can only presume is an instance variable inside some class, or more specifically, a property. The property name starts with a capital letter, which is kind of a no-no for variable names in most C# style guides, but that's not too important by itself and besides, properties are usually an exception to that rule anyway.

    Dumbass declares this property as type IEnumerable<string>, which is the first sign that this is going off the rails right there - I don't know a lot about Dot-Nyet, but if those memories I haven't yet repressed are correct, the IEnumerable<T> interface is meant to allow iteration over a collection class.

    Note that it is an interface, not a class itself. This means that the variable would have to be assigned some kind of concrete collection of strings at some point, right?

        List<string> some_hours = new List<string>();
        // do something here that populated said list...
        foo.Hours = some_hours;
    

    I should point out that as implemented it doesn't matter what that collection generic might be, so long as it implements IEnumerable<> and the specific instance of it holds strings, which you might expect to prove to be a bit of a problem. But I digress.

    So, it takes a collection. Since there is no setter, we have to assume that it is getting set by the class somewhere else, either in the c'tor or in the instance methods. No sign of this here, but it could just be that @BernieTheBernie didn't think it was necessary to show it.

    Or that's what you would expect. <Insert ominous music here>

    The property does, however, have a getter. Or at least something it claims is a getter. It isn't a getter, in fact it doesn't reference the contents of the property at all, but sure, let's make it a getter.

    So what does our 'getter' do first? Why it calls a method to get a piece of data that one would reasonably to be a constant during a given process's running time, the user's preferred time format information. OK, so it is possible it will get changed from one cal to another, but why fetch it here, every time you access this property?

    Then it creates a List<string> called hours and initializes it. Funny, isn't that the same name as the property, just all-lowercase? That's odd. And why are you creating it in the getter, of all places?

    Well, Dumbass is creating it here because Dumbass doesn't actually want a property variable at all, you see. Now, it could be that Dumbass' PHB told him this had to be a property, durn it, that's what the spec says and you better get it right. But we don't know.

    What we cann say is that this is really a type of property known elsewhere as a 'slot': a logical data source, which can be treated as a property regardless of the underlying implementation. Slots are a common alternative to properties, seen in languages such as Self and Common Lisp, but AFAICT they aren't idiomatic in C#.

    So what is this really-a-method doing? Why, it is building a List of the hours of the day, of course. Let me repeat that: this returns an exhaustive list of all the hours of the day, in the format not quite gotten earlier. Gee, that sounds useful! I have to rebuild every time I access this not-a-variable? Even better!

    Wait, 'not quite gotten'? Well, yeah; the code makes some rather odd assumptions about the date format from DateTimeFormatInfo, you see, namely that if the current data format uses a solidus ('/') to separate the parts of the date, then obviously it is a USAian system and the user will want this in 12-hour AM/PM format, because there's no such thing in the US as Military Time. Brillant!

    As for the errors in the formatting itself, well shit, those are almost fucking quaint in light of the overall undefined-ery of the rest of this...



  • @scholrlea My favorite part (all the C# specific stuff is basically Greek to me) was splitting up the AM loop.


  • Impossible Mission - B

    @scholrlea said in Not Dates, but Hours:

    First, the code monkey in question (henceforth referred to as "Dumbass") declares what I can only presume is an instance variable inside some class, or more specifically, a property. The property name starts with a capital letter, which is kind of a no-no for variable names in most C# style guides, but that's not too important by itself and besides, properties are usually an exception to that rule anyway.

    A property isn't a variable. Upper-case names are a no-no for locals, but it's idiomatic to use upper-case names for class members, (methods and properties, for example,) especially public ones.



  • @masonwheeler OK, I may have misunderstood or misremembered C# properties; I used the language very briefly and stayed the fuck away from it after that, because IMAO it is like Java but somehow even worse. The way they were explained to me was that they were basically public state variables with automatic accessors and mutators which hide behind the normal assignment and referencing syntax, meant to ensure consistency when assigning to or reading from the. The way you say this makes me think that they are just another name for slots - they can be backed by variables, but don't have to be. That does help explain a few things. I do have to admit that 'property' is a better name for them, in that case, but it does make me think that I am not the only one to get misinformation on that.


  • Impossible Mission - B

    @scholrlea said in Not Dates, but Hours:

    So, it takes a collection. Since there is no setter,

    since there is no setter, it doesn't take anything. It is of a collection type. The getter returns an enumerable. (Which isn't necessarily a collection; it could be a method that uses yield return.)

    The property does, however, have a getter. Or at least something it claims is a getter. It isn't a getter, in fact it doesn't reference the contents of the property at all, but sure, let's make it a getter.

    Property != field. If you assume that there must necessarily be a "the contents of" you're already wrong.

    Then it creates a List<string> called hours and initializes it. Funny, isn't that the same name as the property, just all-lowercase?

    Yes, and that's annoying.

    And why are you creating it in the getter, of all places?

    But it's a local variable inside the getter (not a class member) that's being used to hold the returned collection.

    What we cann say is that this is really a type of property known elsewhere as a 'slot': a logical data source, which can be treated as a property regardless of the underlying implementation.

    Also known as "properties" in the CLR world. You seem to be confusing "properties" with "fields".

    AFAICT they aren't idiomatic in C#.

    Depends on the type of class you're working with. For POCOs they aren't, but on more complicated business logic, non-field-backed properties ("slots") aren't uncommon.

    None of this is to say that this code isn't a big mass of undefined. But it's not a undefined for the reasons you're calling out. You're criticizing this like someone who never actually uses C# and isn't familiar with the CLR or its idioms.


  • Impossible Mission - B

    @scholrlea said in Not Dates, but Hours:

    IMAO it is like Java but somehow even worsea lot better

    C# basically started out as "make something like Java but with the advantage of hindsight to fix the problems that make Java so ugly."

    The way they were explained to me was that they were basically public state variables with automatic accessors and mutators which hide behind the normal assignment and referencing syntax, meant to ensure consistency when assigning to or reading from the

    That's trivial properties. A property is simply a typed "slot" with at least one and possibly both of [getter, setter]. Trivial properties are common, but so are the other kind.



  • @scholrlea Properties are pretty much exactly what you describe as "slots", with a specially-named accessor method or a specially-named mutator method or both, and (with "autoprops" in C# 2.0 and above) optionally a specially-named instance field. The advantage is that, while field access is always direct and has the same visibility for access and mutation, properties' getters and setters are full separate methods that have all the capabilities you get with that -- separate visibility, overriding, and the ability to write your own code.

    The disadvantage is that you pay the performance penalty of a virtual function call, potentially several, and people can do stupid things like have a mutating accessor, or forget to memoize results, or...



  • OK, well, I retract my ignorant comments. I will say, however, that 'a better Java' makes no sense to me, because if you wanted something better than Java you wouldn't copy Java.


  • Impossible Mission - B

    @scholrlea said in Not Dates, but Hours:

    OK, well, I retract my ignorant comments. I will say, however, that 'a better Java' makes no sense to me, because if you wanted something better than Java you wouldn't copy Java.

    You're conflating "something better than Java" with "a better Java." Why can't a better X be "X without the warts" as opposed to "something entirely dissimilar from X"?

    Microsoft wanted to attract the Java developers, so they built something that looks a lot like Java, but under the hood was a lot more like Delphi. (Unsurprising, since the guy they got to build it was the guy who originally made Delphi!) It fixes a bunch of Java's deficiencies (no value types, no unsigned integers, b0rked generics, checked exception cancer, no delegates) while retaining a syntax that's similar enough that Java developers don't have much trouble moving over.



  • @scholrlea said in Not Dates, but Hours:

    OK, I may have misunderstood or misremembered C# properties; I used the language very briefly and stayed the fuck away from it after that, because IMAO it is like Java but somehow even worse.

    Wow.

    Wha...

    I...

    But...

    ...

    Wow.


  • Notification Spam Recipient

    @scholrlea said in Not Dates, but Hours:

    I used the language very briefly and stayed the fuck away from it after that, because IMAO it is like Java but somehow even worse.

    undefined

    C# is like Java except better in literally every way. You are a confusing individual.



  • Since I've never programmed in C#, what would the correct library solution look like? Does this DateTimeFormatInfoclass have a method that gives you the formatted string for all hours and you replace all of this with one call? Or does it have something that formats one hour so you can just loop over it 24 times?

    What I see as obviously wrong is checking the date separator (seems to be TRundefined), 0 AM instead of 12 PM, and the inconsistent zero-padding between AM/PM. And I guess there's other time formats besides 12h and 24h.
    Splitting up the loop to zero-pad instead of calling a format function seems pretty meh.
    Doing all of this in a getter without memoization: probably not worth the effort.



  • @pie_flavor I am not going to defned my opinions to anyone, and if anyone out there thinks that one language in regular use today that is objectively better than another, they are crazier than I am. And I am a fucking Lisp Weenie.

    I know of one language out of all of the ones ever designed which is objectively better than others, and it isn't Lisp. So what is it? Ada.

    No, seriously. It hits on every button one might want, as far as the language itself is concerned. it is a astonishingly well thought out.

    It is also ugly as sin to me, and to nearly every other programmer i know. Fewer programmers would choose to use it for general development than would choose to use Emacs Lisp, which even Lispers see as a step below Visual Basic for Applications. It is objectively better for software engineering, but it is a catastrophe in terms of being subjectively acceptable.

    I am not saying the Java is better than C# - I am saying I dislike C# more than I dislike Java, though honestly, I think they both are wretched on every level. But that's how I see them. You are under no obligation to agree, any more than I am under any obligation to agree with you.


  • Impossible Mission - B

    @pie_flavor said in Not Dates, but Hours:

    You are a confusing individual.

    This is to be expected of one whose brain has been damaged by overexposure to Lisp.


  • Notification Spam Recipient

    @scholrlea You have clearly done no research whatsoever (as you have admitted, in fact). There is a grand total of zero advantage, objectively, to using Java over C#, other than the obvious one of a certain package/framework that you need being in Java and not C#. There are a hell of a lot of advantages to using C# over Java. I am extremely curious what experience you could possibly have had in C# that makes you hate Java less than it.
    When I say it is better in every way, I do not mean that Java has feature X, C# has feature Y, and I prefer Y to X. I mean that Java has feature X, and C# also has feature X, and systems that work with and integrate with feature X, and features XA, XB, XC which are all optional to use but make X even easier to use, and Java has none of this.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.