• TheCPUWizard (unregistered)

    Though the code at present does not show it, the char array split allows for better processing of " to" "to" "to " " to ".....

  • (nodebb)

    @Remy: Formatting blooper for Niels H*

    Also: Startdate being the end is a really bad data model smell.

  • (nodebb)

    1. Bad naming ✅️

    2. Wrong type ✅️

    3. Invalid data ✅️

    4. Incorrect usage of API ✅️

    I approve of this WTF. Pretty good

  • Michael R (unregistered)

    Create a view in the DB and let the DB do let the heavy lifting.

    But the story reminds me of when I was working for a major funds manager. We had a table in the DB with an int column aptly named "day_of_week". I had a look in the table and expected values 0 .. 6 (or maybe 1 .. 7) but oddly enough spotted values like 15, 18 etc. I asked one of the seniors what happened there. His reply:"Ah, that column, erm, yes, cough, someone gave it a wrong name when we started it. And then it was too late to change everything.". Instant classic.

  • (nodebb) in reply to Mr. TA

    @Mr. TA : You forgot one:

    1. Homebrew date parsing...
  • akozakie (unregistered)

    I have a different explanation I have seen in the wild - learning while working. He noticed how overloaded it was and wanted to experiment with that. Tried a few options. Satisfied he wanted to move on with the code. As it happens, the result of his last experiment was... usable, so instead of changing to a more correct solution, he grabbed the right index and continued. The resulting code worked, so job done.

    There's nothing strictly wrong with learning while working, as long as it doesn't waste more time than it saves in the long run. But if you have no code reviews and programmers can make architectural decisions... you end up with accidentally working "learning experiments" in production, and things like tools and libraries chosen based on "I always wanted to learn this one, and I think I can make it do what is needed here".

    I've seen this. The library choices were really wrong, but (brutally forced) did the job, the whole thing worked, so noone cared - except us, who had to support the monster.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    I had the check the docs on int.Parse() to see if it'd be able to handle "08" or "09" correctly: a lot of parsers would try to parse those as octal and then throw an exception when they saw a non-octal digit; but in this case it seems that the parser does not support octal and will correctly strip the leading zeroes, so to my surprise that's not an additional WTF.

  • LZ79LRU (unregistered) in reply to akozakie

    I second this. I do this sort of thing all the time. Especially when experimenting with the API of some new or otherwise odd library we have to use by management fiat.

    I make a point of calling all my variables for such testing really stupid things like "bob" so as to make sure they can't possibly pass code review.

  • (nodebb)

    Hey, at least they didn't use the horrid MM-DD-YYYY date format, so that's something... Otherwise, pretty good WTF overall.

  • AC (unregistered)

    Presumably also coded before the introduction of LINQ, since Temp1.First() and .Last() would make this nonsense a bit more clear.

  • LZ79LRU (unregistered) in reply to tom103

    Indeed. The only acceptable date input formats are UTC ISO YYYY-MM-DD or the French Revolutionary Calendar.

  • Sauron (unregistered)

    Someone had to write code to parse that data, and that someone did the job and then left.

    There is a good reason why that someone left.

  • (nodebb) in reply to AC

    Note: Before the introduction of Linq to the person who wrote it, not necessarily before the introduction of it to the world.

  • Duke of New York (unregistered)

    The queries belch me up. / The parser spits me out. / From schemas tragic I am born again. / And now I'm with you now / Inside your world of woe.

    — Parsing Temp Strings, "The End is the Start is the End"

  • (nodebb)

    Oh boy... sometimes I wonder who those people are writing stuff like that.

  • Lurk (unregistered) in reply to MaxiTB

    Who are they? At some point in our "careers" all of us. :)

  • (nodebb)

    Seeing the "ToCharArray" makes me think they've come from C++, where different methods in different libraries want strings in different ways (std::string, char*, just as starters).

  • NotAThingThatHappens (unregistered)

    Period.Split(" to ".ToCharArray(), StringSplitOptions.RemoveEmptyEntries) would have made it briljant.

  • Broken Fixes (unregistered)

    The next "enhancement" will be to add StringSplitOptions.RemoveEmptyEntries so they get a two-element array, and it handles leading and trailing spaces as well.

Leave a comment on “End this Date Now”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article