• Kuli (unregistered)

    What are the acceptable values for this comment field?

  • whosdr (unregistered)

    Frist maybe? Pperhaps it used to contain text such as 1st, 2nd 3rd etc.

  • Venetian Binding (unregistered)

    Gasp. Redundancy is redundant. How very lame. And not at all WTFish. How very lame. Gasp. Lame.

  • (cs)

    This is merely a Why-the-F?

    It's not wrong, foolish or dangerous; merely a waste of the devs precious hours on Gods Earth.

    Which you have compounded by posting it on the inter-webs; and I have heaped waste on by commenting...

    Oh the humanity !

  • MP (unregistered)

    'dob_dd' for Date Of Birth Drop Down? List of titles/values looks like it would be used to populate a drop down field.

    Don't know whether or not that's good practice in an excel spreadsheet, but doesn't seem like such a WTF if this is the case..

  • (cs)

    I guess it's possible that the sheets were spit out of some automated process that didn't differentiate between the useful and the not-useful.

    I guess someone should have looked over them and sense-checked them but including everything is probably better than losing something important...

    Not exactly a WTF...

  • (cs) in reply to MP
    MP:
    'dob_dd' for Date Of Birth Drop Down? List of titles/values looks like it would be used to populate a drop down field.
    or "Date of Birth - Day (two digit format)". Which they screwed up in the example by formatting the "values" column with leading-zero suppression.
  • (cs)

    Obligatory: what happens in this system if I would, say, select 31st of February as my DoB?

  • faoileag (unregistered) in reply to Unisol
    Unisol:
    Obligatory: what happens in this system if I would, say, select 31st of February as my DoB?
    It would assume you are William O'Malley and that you are 161 years of age, counting the years, not the birthdays.
  • (cs)

    I choose to believe this was spite documentation, in response to some process monkey making a big stink about the docs not being detailed enough.

    "This 'cusip' filed. How am I supposed to know what that is?" "Well, it's a standard term in the industry we're building this for. I'm pretty sure our users..." "We have to document everything!" "Really. Everything?" "Yes, everything!" "Ugh, ok fine. Here you go. Documentation for everything."

    Theory B could be if the documentation is auto-generated by the same tool that auto-generates the UI.

  • faoileag (unregistered) in reply to vt_mruhlin
    vt_mruhlin:
    I choose to believe this was spite documentation, in response to some process monkey making a big stink about the docs not being detailed enough.

    "This 'cusip' filed. How am I supposed to know what that is?" "Well, it's a standard term in the industry we're building this for. I'm pretty sure our users..." "We have to document everything!" "Really. Everything?" "Yes, everything!" "Ugh, ok fine. Here you go. Documentation for everything."

    "No, no, no, this isn't good enough! You only listed already asigned CUSIPs. But what happens when a new stock or bond is put on the market? Then the documenation will be incomplete! Go back ro your cubicle and make it future proof!"

  • (cs)

    TRWTF is the black-on-dark-blue color schema. But at least it makes the text hard enough to read that I can't be sure whether it's comic sans or not.

  • Charlie D (unregistered)

    TRWTF is Comic Sans

  • Rupee Everet (unregistered)

    This could easily be used for data validation if you wanted to test with real data (e.g. drop down containing values).

    No WTF. Not even a little

  • anon (unregistered) in reply to Charlie D
    Charlie D:
    TRWTF is Comic Sans

    This. Oh and the choice of background colour.

  • EvilSnack (unregistered)

    It could be that one of the purposes of the table is to support automatic GUI control generation. This becomes a drop-down list with only the named values, and there is a label for each such value.

    It's a worthy exhibit for the Museum of Re-Invented Wheels, but otherwise it is unremarkable.

  • hobbes (unregistered) in reply to Roby McAndrew
    Roby McAndrew:
    This is merely a Why-the-F?

    It's not wrong, foolish or dangerous; merely a waste of the devs precious hours on Gods Earth.

    Which you have compounded by posting it on the inter-webs; and I have heaped waste on by commenting...

    Oh the humanity !

    I'm not entirely convinced this is so trivial a problem. Those are accepted values, and you are making the assumption that they intelligently catch 2/31/1977 as an unacceptable value.

    Where I Ryan, I'd be checking into that, expecting the worst.

  • q.kontinuum (unregistered)

    Only half a WTF... Sure, this excel sheet is not exactly helpful. But defining allowed values is generally not a bad idea, and being tasked to do that, it might be a lot quicker to just add this crappy sheet than start re-negotiating the requirements with superiors to be allowed to put in a text instead.

  • faoileag (unregistered) in reply to hobbes
    hobbes:
    I'm not entirely convinced this is so trivial a problem. Those are accepted values, and you are making the assumption that they intelligently catch 2/31/1977 as an unacceptable value. Where I Ryan, I'd be checking into that, expecting the worst.
    The article is a bit ambiguous actually: "Ryan recently received ... documentation ... regarding a third-party API Then, later: "an Excel spreadsheet that listed the accepted values for each input field"

    For an API you wouldn't use the term "input field". For a website however you would (ok, you might call a form on a website an API if you were scraping the results).

    So I assume the "acceptable values" represent the subset of N that may be entered as date of birth in a form on a website.

    What the website does in terms of input validation is an altogether different matter. Facebook falls back to the last day in february of the year if you enter 31 as dob_dd and then enter february as the month.

    In a similar situation other websites throw away both day and month.

    Should Ryan check? No, not really. Should Ryan ensure his data does not feed February 31st to that "API"? Definitely.

    But he should do that because one never should "trust" an API to correctly deal with incorrect data when one can avoid feeding incorrect data to the API in the first place.

  • verisimilidude (unregistered)

    Surely the proper implementation for an enterprise solution: Prevents the users from not knowing what values are expected in this field and allows future changes to take place easily. Imagine having to change all those range tests when here we can simply remove a few rows if, say the 15th of the month were to be dropped from all months.

  • SN (unregistered)

    I'm pretty sure TRWTF here is the reason why this was created.

    There's a lot of really crappy code posted on this site. It's not that much of a stretch to believe that some dev out there complained about this at some point. We've all been there. "This isn't complete" then you get the details and it's something asinine like this.

  • (cs)

    this remind me of a project manager who taught us db design. always leave extra columns in table. call them extra1, extra2, extra3. then when we need them we can rename them. for added amusing value, call them extratext1, extraint1, extracdec1, extradate1.

  • Jim the Tool (unregistered)

    Christ, what an asshole.

  • sol (unregistered)

    the real wtf is that there is no handling of months with < 31 days

  • faoileag (unregistered) in reply to Nagesh
    Nagesh:
    this remind me of a project manager who taught us db design. always leave extra columns in table. call them extra1, extra2, extra3. then when we need them we can rename them
    Why rename them? Simply add some documentation like "column extradate1 contains the date <when_something_happened>". That way you save an ALTER TABLE and create valuable documentation as a sign that your processes are well managed!
  • faoileag (unregistered) in reply to sol
    sol:
    the real wtf is that there is no handling of months with < 31 days
    How do you know?

    This is just a screenshot of an Excel spreadsheet pretending to be documentation. How should that spreadsheet "handle" months with < 31 days? It doesn't even know the concept of "month".

    And we have no knowledge of the system receiving dob_dd and what that system does with it.

  • Walky_one (unregistered) in reply to faoileag
    faoileag:
    The article is a bit ambiguous actually: "Ryan recently received ... documentation ... regarding a third-party API Then, later: "an Excel spreadsheet that listed the accepted values for each input field"

    For an API you wouldn't use the term "input field". For a website however you would (ok, you might call a form on a website an API if you were scraping the results).

    You can never be sure about that. Maybe it's one of those famous "man in the middle" communication API's (e.g. you've got a user who is shown the output of one application and has to copy it into an input form of a different application).
  • faoileag (unregistered) in reply to Walky_one
    Walky_one:
    Maybe it's one of those famous "man in the middle" communication API's (e.g. you've got a user who is shown the output of one application and has to copy it into an input form of a different application).
    Ah, the "Transfer Monkey" pattern that somehow never made it into the list of Structural Patterns.
  • Jake (unregistered) in reply to anon

    Color with a U (and no K) is TRWTF.

  • Ol;dCoder (unregistered) in reply to faoileag
    faoileag:
    sol:
    the real wtf is that there is no handling of months with < 31 days
    How do you know?

    This is just a screenshot of an Excel spreadsheet pretending to be documentation. How should that spreadsheet "handle" months with < 31 days? It doesn't even know the concept of "month".

    And we have no knowledge of the system receiving dob_dd and what that system does with it.

    If this is an Excel spreadsheet, it is likely to have its own idea of what a "month" is, and you can guarantee that it isn't going to match yours.

  • OldCoder (unregistered) in reply to sol
    sol:
    the real wtf is that there is no handling of months with < 31 days
    And? What about all those months > 31 days?
  • Quality Expert (unregistered)

    If any of you knew what you were doing, you would recognize this instantly. For automated code testing tools, it is necessary to have as input a table of all possible good values.

    What is not shown is the equally necessary table of all possible invalid values, which you use to verify the software will not accept any of them. Perhaps there is a size limitation for articles on this lame site?

  • Bottom Problems (unregistered) in reply to Quality Expert
    Quality Expert:
    If any of you knew what you were doing, you would recognize this instantly. For automated code testing tools, it is necessary to have as input a table of all possible good values.

    What is not shown is the equally necessary table of all possible invalid values, which you use to verify the software will not accept any of them. Perhaps there is a size limitation for articles on this lame site?

    Are you intentionally being thick?

  • verisimilidude (unregistered)

    Surely the proper implementation for an enterprise solution: Prevents the users from not knowing what values are expected in this field and allows future changes to take place easily. Imagine having to change all those range tests when here we can simply remove a few rows if, say the 15th of the month were to be dropped from all months.

  • Doctor_of_Ineptitude (unregistered) in reply to da Doctah
    da Doctah:
    MP:
    'dob_dd' for Date Of Birth Drop Down? List of titles/values looks like it would be used to populate a drop down field.
    or "Date of Birth - Day (two digit format)". Which they screwed up in the example by formatting the "values" column with leading-zero suppression.

    I am no web developer, but won't the drop down thing being this way might help in Internationalization (different scripts write numerals differently) in that the title is different when requested language is different and the automated documentation generation tool that generated this doc simply put the values in title according the language settings of the developer?

  • Scourge of programmers. (unregistered)

    There is no excuse for programmers like this. Flog them at an early age, so they don't do silly things like this.

  • cowardly man (unregistered)

    What's wrong with this?

    It's easier and faster in a document to use boiler plate to write the document if possible. Not doing what the author of the document did could only result in a peer review comment and have INCREASED potential for confusion.

    Possible peer review comment: "Why is this page of the document formatted differently than the other 100 pages?"

    For this to be a WTF in the submitters opinion shows me that the submitter probably is fresh out of school or possibly doing an internship.

  • cowardly man (unregistered) in reply to cowardly man

    I should add that the only thing that cost the submitters company more money is the time the submitter spent on the clock submitting this. So maybe I am in error and the original author inadvertently wasted company time and money.

  • (cs) in reply to da Doctah
    da Doctah:
    MP:
    'dob_dd' for Date Of Birth Drop Down? List of titles/values looks like it would be used to populate a drop down field.
    or "Date of Birth - Day (two digit format)". Which they screwed up in the example by formatting the "values" column with leading-zero suppression.

    The values with the leading-zero are in the "dob_d" sheet.

  • QJo (unregistered) in reply to da Doctah
    da Doctah:
    MP:
    'dob_dd' for Date Of Birth Drop Down? List of titles/values looks like it would be used to populate a drop down field.
    or "Date of Birth - Day (two digit format)". Which they screwed up in the example by formatting the "values" column with leading-zero suppression.

    Maybe they have a generic function for presenting the date, which includes possibilities for presenting the date in ordinal (1st, 2nd, 3rd) and also as numerals (1, 2, 3...) and even perhaps in Roman (I, II, III, IV ...) In order to make the code compact, the name of the table is determined by some fancy conditionals (fancy, that is, to the proto-programmer who vomited this stuff).

  • (cs)

    My suspicion: that's not documentation. That's source code.

  • (cs) in reply to flabdablet 
        protected bool IsValidExcelDate(string value)
    {
        double placeholder;
        return double.TryParse(value, out placeholder);
    }
  • (cs) in reply to chubertdev
    chubertdev:
        protected bool IsValidExcelDate(string value)
    {
        double placeholder;
        return double.TryParse(value, out placeholder);
    }

    Has this been tested or you just decided to prove how clever you are?

  • (cs)

    Would the list of acceptable inputs for last name contain every last name on the planet including all variations in spelling?

  • Quality Expert (unregistered) in reply to eric76
    eric76:
    Would the list of acceptable inputs for last name contain every last name on the planet including all variations in spelling?
    Of course, except for those names that include SQL statements or punctuation.
  • Fedaykin (unregistered)

    Weak ass WTF.

    I can tell you exactly what happened. Someone was tasked with documenting all valid input ranges, and instead of wasting time arguing against it, took the 30 seconds necessary to provide this information in the accepted format.

    Kind of silly that it happened at all, but not at all a WTF.

  • gnasher729 (unregistered)

    Just recently had to look at RFC 822 and the definition of base-64 encoding, and they do enumerate all 65 characters that have meaning in base-64 encoded text, which are A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 + / and =. So there is precedent for that kind of thing.

    And here are the legal single character time zones for dates in RFC 822 (read carefully): A B C D E F G H I K L M N O P Q R S T U V W X Y Z. All 25 of them. Not 26 :-)

  • Yazeran (unregistered) in reply to gnasher729
    gnasher729:
    Just recently had to look at RFC 822 and the definition of base-64 encoding, and they do enumerate all 65 characters that have meaning in base-64 encoded text, which are A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 + / and =. So there is precedent for that kind of thing.

    And here are the legal single character time zones for dates in RFC 822 (read carefully): A B C D E F G H I K L M N O P Q R S T U V W X Y Z. All 25 of them. Not 26 :-)

    Oh come on, the authors just made sure that the time zones could be used with the playfair cipher :-)

    Yours Yazeran.

    Plan: To go to Mars one day with a hammer

  • Jonathan (unregistered) in reply to Jake
    Color with a U (and no K) is TRWTF.

    Bolour?!

    (wv: persto, interj. bheold! Synonym: viola)

  • David Emery (unregistered)

    I had this discussion once:

    Me: What's the range of values for this 'integer' parameter?
    Him: It's infinite. Me: Really? If you took every single bit of memory in this computer and constructed an integer value with that many bits, the answer would still be -finite and bounded.- Him: But integers are infinite! Me: Not when they're represented in the physical memory of a computer. And when an integer value is passed as a parameter to some function, it's a lot more finite than that.

Leave a comment on “Accepted Values for Days of the Month”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article