• that other guy (unregistered)

    function fristorno($in) { if($in == 'FRIST') return 'FRIST'; else return 'NO'; }

  • throbi (unregistered)

    Genius!

  • (nodebb)

    function yesorno($in) { if($in == 'YES') return 'YES'; else if($in == 'NO') return 'NO'; else return 'FILE_NOT_FOUND'; }

  • (nodebb)

    I do find it amusing and a little sad how companies tend to lie about a ton of stuff but technically say the truth to hoodwink candidates. It's like, do you think this person is going to feel good about your company, let alone stay when they realize that you misled them about virtually everything you told them to try and hire them?

  • LCrawford (unregistered)

    print yesorno("Will I win the Lottery today?");

    NO

  • Zach (unregistered) in reply to DocMonster

    If they need the job, then yes they will stay at least until they find another job

  • Guest (unregistered) in reply to DocMonster

    The worst part is that many of them think they're telling the truth. it's only when you get into the weeds after being hired you find out that they're delusional about what they're doing.

  • Brian (unregistered)

    Hmm...

    yesorno('yes') = 'NO' yesorno('true') = 'NO' yesorno('Y') = 'NO'

    Yep, seems like they've got a great handle on the old string-as-bool pattern.

  • Brian Boorman (google)

    TRWTF though is the Delphia had to dig into somewhere between 15 and 30 include files to find it. Because, you know, grepping for the string "function yesorno(" is beyond her skill set.

  • not a robot (unregistered) in reply to Brian

    why do you assume that yesorno('true') must return 'YES'?

  • (nodebb)

    It’s less spaghetti code or even a big ball of mud, and more a career killing meteorite.

    I look at that snippet and keep thinking “a career-killing coprolite”…

  • ooOOooGa (unregistered)

    As a job applicant, I have always been told that lying during the application and interview process is grounds for termination. Does the same apply for the company?

  • (nodebb)

    That indentation, by the way, is typical of about 30% of the codebase, maybe less. You wouldn’t expect any sort of consistency in this kind of code, would you?

    This is very typical of old languages -- specifically COBOL -- where it usually makes sense to do indentations that way for readability:

    123456 UPDATE-EMPLOYEE PROCEDURE. 123457 MOVE SCR-COMPANY TO DB-COMPANY. 123458 MOVE SCR-EMPLOYEE-NBR TO DB-EMPLOYEE-NBR. 123459 MOVE SCR-EMPLOYEE-NAME TO DB-EMPLOYEE-NAME. 123460 MOVE SCR-EMPLOYEE-ADDRESS TO DB-EMPLOYEE-ADDRESS. 123461 MOVE SCR-EMPLOYEE-CITY TO DB-EMPLOYEE-CITY. 123462 MOVE SCR-EMPLOYEE-STATE TO DB-EMPLOYEE-STATE. 123463 MOVE SCR-EMPLOYEE-ZIP TO DB-EMPLOYEE-ZIP. 123464 PERFORM DB-EMPLOYEE-UPDATE.

    That looks a lot better than:

    123456 UPDATE-EMPLOYEE PROCEDURE. 123457 MOVE SCR-COMPANY TO DB-COMPANY. 123458 MOVE SCR-EMPLOYEE-NBR TO DB-EMPLOYEE-NBR. 123459 MOVE SCR-EMPLOYEE-NAME TO DB-EMPLOYEE-NAME. 123460 MOVE SCR-EMPLOYEE-ADDRESS TO DB-EMPLOYEE-ADDRESS. 123461 MOVE SCR-EMPLOYEE-CITY TO DB-EMPLOYEE-CITY. 123462 MOVE SCR-EMPLOYEE-STATE TO DB-EMPLOYEE-STATE. 123463 MOVE SCR-EMPLOYEE-ZIP TO DB-EMPLOYEE-ZIP. 123464 PERFORM DB-EMPLOYEE-UPDATE.

    This code is indented this way because the people who wrote it have been writing code since the 1970s, and they haven't changed their styles. But this is nothing compared to the WTFery of the yesorno function.

    Addendum 2019-02-14 10:20: Sorry about the formatting. It totally messes up my point. Will try to find what I did wrong.

  • (nodebb)

    What I was trying to say is that this:

       MOVE SCR-COMPANY                                               TO DB-COMPANY.
       MOVE SCR-EMPLOYEE-NBR                                     TO DB-EMPLOYEE-NBR.
    

    Looks better than this:

       MOVE SCR-COMPANY TO DB-COMPANY. 
       MOVE SCR-EMPLOYEE-NBR TO DB-EMPLOYEE-NBR.
    

    Especially when there's like 300,000 lines of it.

    Addendum 2019-02-14 10:24: I did not mean for the right side to be right-justified. Giving up on this, lol.

  • (nodebb)

    Inquiring minds want to know: what did all the calling routines do when their output string was replaced with either "YES" or "NO" ?
    Same minds want to know if there are a bunch of other little functions that get called a lot, such as TrueIsYes($in) if $in =="True" return "YES" .

  • Andrew (unregistered)

    It's been a considerable amount of time since I've done PHP and so I don't recall what happens if one tries to compare 'YES' with an integer or anything else not a string. Up front, I agree, this function is silly. It does have the quality that 'YES' is 'YES' and anything, and I mean anything, else is false. As I recall, PHP is case sensitive so 'yes' != 'YES'.

  • Lucas Ieks (google)
    function yesorno($in) { if ($in == 'YES') return 'YES'; else if ($in == 'NO') return 'YES'; else return 'NO'; }
    
  • (nodebb) in reply to DocMonster

    After having been put through that a few times, I've decided there's a certain level of sadism involved. If you've ever heard the saying about Microsoft not being a software company but an abuse company that happens to deliver its abuse through software, it's the same sort of relationship here.

  • get off my lawn (unregistered)

    If there's no standard the values for YES and NO almost always vary between every coder and every project - I had one system where it was J or N because the original writer was German - so I can see someone thinking it'd be a good idea to add a sub which took that sort of binary and rationalised it.

  • Barf4Eva (unregistered) in reply to Lucas Ieks

    Your implementation makes more sense for this function name :D

  • DCL (unregistered) in reply to Bananafish

    It's typical of how some people write code, not typical of COBOL per se.

  • El Bananna (unregistered)

    function yesorno($in) { return 'YESORNO';} //100% guaranteed to be correct.

  • dusoft (unregistered)

    Seems pretty consistent to me... if you are using some kind of fixed columns CSV :-)

  • Chris (unregistered)

    Just remember guys, "NO" means "NO". As does "Maybe", "I'm not sure", and "I don't think I'm ready yet". Also, "yeah, why not?" and even "Absolutely, YES! OH GOD YES!"

  • PHPLite (unregistered) in reply to Guest

    I disagree, any company where this could happen is suffering from other fatal errors. If HR is so detached from developers that it doesn't even know there are things going wrong then... the company itself is just a big ball of mud.

  • (nodebb) in reply to PHPLite

    The structure of company codebases tends to reflect the structure of the company itself.

  • Little Bobby Tables (unregistered)

    I suggest that their program (having evolved from a COBOL jobbie) was predicated upon the supposition that certain fields are either YES or NO. Then it was discovered that the database contained fields where it was either YES or blank. Or something. And it was decided that it was easier to write a quick-and-dirty clean-up function on that data to force it to be YES or NO.

    I am currently working on an app which is similarly built upon a decades-old database which (because it "works") has never been replaced by something more up-to-date and performant, and so practically our entire work consists of implementing more and more tortuous workrounds to get around limitations of the data held in this database. (Hey, don't knock it, it's a job for life, or at least until retirement, which is almost visible over the horizon.) And one of these limitations is that boolean values are held as text strings of the form "Yes" and blank. At least, in one particular access point. In others it's "Yes" and "No", and in others it's "1" and "0", and in others it's "0" and "1", and ... The routine to tidy them up is more or less comprehensive, and offers a flag (enum based) to determine which of these behaviours is to be applied for the specific case in question. Oh for the simplicity of OP's "YES" and blank.

  • Appalled (unregistered)

    In my COBOL days, I'd run across unaligned code all the time. If I couldn't read the shit (90%) of the time I'd run all my SPF Mass Changes and TSO Clists and get everything lined up and readable. I'd then do a compile and and binary compare (IEBCOMPR , which worked but sucked if there were differences, (or I talked 2 places into buying Comparex). Once the binaries were identical my only remaining hurtle would be everybody yelling at me for fucking around with their code. "You don't like it? Then start doing it right". Even better, if it was still unreadable or unmanageable, it was time for the REFACTOR (and parallel test and compare with a month of Production data). Yep, their mass mess of spaghetti would magically turn into something perfectly repeatable, functionally descriptive, and maintainable for a change. I would be able to finish the development task in half the time, including Reformat and Refactor overhead. And it would really piss the hell out of the other programmers and managers. I was asked repeatedly to stop. I never did and was never fired and several people started coding to MY standards knowing what would happen if I ever needed to work on their stuff.

  • get off my lawn (unregistered) in reply to Appalled

    Hopefully as soon as someone touched code you worked on they would reformat it differently.

  • Anonymous Coward (unregistered)

    "hurtle", lol.

    I guess that's more descriptive if you don't clear it.

  • Klaus (google) in reply to Appalled

    I agree, that code that hard-codes a "if case then value" mapping is often more readable, if the values are aligned.

    I don't agree with reformatting everything; It will likely be a pain for diffs and merges, if only because they now require advanced tools.

    Addendum 2019-02-15 15:17: To be fair though, I find it rather horrifying, that "consider whitespace irrelevant" isn't a common standard option, given simple cases like "DOTHIS" turning into "if(THIS) { DOTHIS } else { DOTHAT }".

  • Andreal (unregistered)

    They've just pivoted to Ruby. It's only natural to start by using Ruby-style two-space indentations.

  • Matt (unregistered) in reply to Anonymous Coward

    Wasn't there a Dr Seuss book about a turtle name hurtle?

Leave a comment on “Getting to YES”

Log In or post as a guest

Replying to comment #503339:

« Return to Article