• TheCPUWizard (unregistered)

    The first one has some utility in being able to set breakpoints....

    note; If you don't like the classic ternary operation how about "??" and "?." [I believe they all have their place]

  • (nodebb)

    If only there were methods for asking if a list was empty…

  • kktkkr (unregistered)

    You know that pattern where basic string operations like atoi get reinvented in the form of a switch statement? Yeah, "fix" it by replacing every conditional with ?:. Bonus points for automating this process!

  • Martin Milan (unregistered)

    The first one definitely has value - if you need to change the boolean expression on the test you only have to do it in one place, rather than 46...

  • (nodebb)

    Sorry, but not enough info to check the WTF level of this. For example what if this is a method in a class that wraps the license object.

  • Ashley Sheridan (google) in reply to Helix

    Are you actually kidding? The > expression will return a boolean, so you don't need a ternary. I can't think of a single language in which this is not the case.

  • GWO (unregistered) in reply to Helix

    The problem isn't the existenc of hasFeatures(). It's that the whole thing could be rewritten in one line.

    For clarity write:

    boolean hasFeatures() { return (license.getFeatures().size() > 0); }

    For brevity:

    boolean hasFeatures() { return (license.getFeatures().size()); }

  • @GWO (unregistered)

    Or preferably

    return license.getFeatures().isEmpty();

  • Greg (unregistered) in reply to @GWO

    Or if you want it to be correct

    return ! license.getFeatures().isEmpty();

  • poniponiponi (unregistered)

    I proudly abuse the hell out of ternaries. I admit they're not the most readable things, but they're still better than an entire eight line if-else construction for simple things.

  • Quite (unregistered)

    No, you fools! You can't use ternaries here! It's wrong.

    boolean hasFeatures() { Boolean returnValue = new Boolean(); try { if (license.getFeatures().isEmpty().equals ((new Boolean (Boolean.FALSE)).getValue())) { returnValue = Boolean.TRUE; endif; if (! license.getFeatures().isEmpty().equals ((new Boolean (Boolean.FALSE)).getValue())) { returnValue = Boolean.FALSE; endif; } catch {Exception e) { returnValue = null; } return returnValue; }

    Brillant!

  • lordofduct (unregistered)

    The boolean stuff I see at times boggles my mind...

    If bInProduction = False Then ''do stuff Else ''do other stuff End If

    Or my all time favourite I saw recently:

    If dto.Order.IsNotNothing() And dto.OrderId.IsNotNothing() And dto.Order > 0 And dto.OrderId > 0 Then ''do stuff End If

    Note that 'Order' and 'OrderId' are of type Integer IsNotNothing is a .net extension method that wraps around the single line of code: Return obj IsNot Nothing They literally created a function so as to not need to put a space between IsNot and Nothing... ??? And the ultimate best part, Order will only ever be the values 0 or 1!

  • Brook (unregistered)

    The first one has plenty of value - in fact, it can be more WTF to not wrap complex conditionals in a method (or property, or extension method depending on your language).

    1. The code reads a lot nicer, no need for comments explaining a complex conditional logic.
    2. Avoid DRY violations (as mentioned by @MartinMilan)
    3. Easier breakpointing (as pointed out by @CPUWizard)

    I think situations for #1 OR #2 alone are enough to warrant a function representing conditional logic.

    The only thing WTF about this code is the way they are writing their conditional logic and returning the result. Which is pretty damn WTF tbf.

  • Jeremy Lindgren (vita10gy) (google) in reply to Martin Milan

    Exactly. This is how coding should be done. It's also much more self commenting to do if(user.isActive())) than if(user.getExpireDate() < time())

    The fact that it's simple today shouldn't be the point.

    Addendum 2016-06-01 09:56: On second thought though I think they just mean the

    if(boolean){ return true;} else {return(false);}

    thing

    as opposed to just

    return boolean;

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    There are 10 kinds of people in the world: those who understand how boolean expressions work, and those who don't.

    Also, the bonus of abusing ternary expressions is that they can have surprising order of precedence issues!

    And there should be a special circle of hell for people who always put parens in their return statements, even constants like return(0). IT'S NOT A FUNCTION YOU BLOODY MORONS STOP WRITING IT LIKE ONE.

  • Brian Boorman (google) in reply to I dunno LOL ¯\(°_o)/¯

    I guess someday I'm going to that special circle in hell. Either that or "I dunno LOL ¯(°_o)/¯" is going to have an aneurysm and nobody will care about it again.

  • Sumireko (unregistered)

    It's about time that we've introduced affirmative action for code. Anyone have a list of the least used commands? I think we should use every command equally.

  • Angela Anuszewski (google) in reply to Sumireko

    Sumireko, are you advocating wider use of goto? Bringing that one back should be fun.

  • Carl Witthoft (google) in reply to TheCPUWizard

    Just to be extra-nerdy, if you install R and install the 'sos' package, there's a ??? operator

  • george gonzalez (google)

    Could be a bit worse. A few years back someone wrote a ray-tracer for the IOCC. With no Ifs, or for or while loops, just ternaries and recursion. Urp.

  • Herby (unregistered)

    History lesson: The ? : operator(s) comes from Algol 60, which one could use 'if' then' 'else' in the same way (inside an expression. One could say: a := if b < c then d else e; While needless use of the ?: operator(s) is a crime in and of itself, it has some uses, and might even be a bit easier to read than the Algol-60 version.

    Life goes on.

  • Corey Jones (google) in reply to Brian Boorman

    I will care. But every language is different, so a blanket statement can't really be made about them that'd apply to all languages.

    And while everyone thinks they have "their own style", I tend to side with Douglas Crockford on this issue. There is ultimately a correct way of writing a method with white-space/parenthesis/etc. in a given language based on the syntax of that language. Deviations from the "correct" spacing/parenthesis/etc. may not have an adverse effect on the programs performance or its ability to compile, but those variation can (and often do) detract from the readability of the program by other developers (or perhaps by you in 6mo?).

    These are the least-important types of errors if you ask just about anyone in the industry, but given enough entropy and layered-on bug fixes, it can become a massive problem. This isn't to say that parenthesis in a return statement are the end of the world, but they're a symptom of a larger problem that is often ignored or not recognized as a problem until it's too late.

  • NotBugItsFeature (unregistered) in reply to Martin Milan

    I think you missed the point. It has nothing to do with performing a single Boolean operation in a function; it has everything to with with not just returning the result of the conditional. There is no need to do the return true/false. Just return the result of the test.

  • TimothyB (unregistered) in reply to Herby

    This seems to work in Ruby (hoping I get line breaks in...):

    a = if b < c
    d
else
    e
end
  • Brian Boorman (google) in reply to Corey Jones

    Style is an argument that is pointless to make, because there will never be one camp. Are you the type that would also argue over whether line indents should be multiples of 3 or of 4 characters?

    I'm also the guy who places parenthesis around every macro #define. Because the first time you debug a problem that turned out to be because of macro expansion in an expression causing an "precedence of operators" should be the last time you ever fall victim to that problem.

  • NoLand (unregistered)

    var i = { think = function(object) { return { "is": ((function isSimple(what) { return (Boolean(what.keys) === false || what.keys().length === 0) ? true: false; })(object).valueOf() != 0 ? false : true) ? "mischievous" :"evil"}; } }; i.think(this).is;

  • Foo AKA Fooo (unregistered) in reply to NoLand

    Which just goes to show that any feature can be abused. Though in this case I think the nested functions contribute much more confusion than the ternaries.

  • thosrtanner (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    And in C+, return (x) can produce different behaviour to return x as it uses a different way of looking up x. So no possibility of disastrous confusion there.

  • gnasher729 (unregistered)

    if (condition) return true; else return false; allows you to set a breakpoint on one of the two return statements, or add a logging statement, if one of the two return values would be unusual.

  • Anonymous (unregistered)

    I'm currently dealing with the same sort of insanity on one of my projects. Right now, I am having to convince a coworker that a function (literally) named:

    bool returnTrueIfFileIsUncompressedBinaryOrCompressedBinary(const std::string &fileName) {
    ...
}

    is poorly named... WTF.

  • Norman Diamond (unregistered)

    And there should be a special circle of hell for people who always put parens in their return statements, even constants like return(0). IT'S NOT A FUNCTION YOU BLOODY MORONS STOP WRITING IT LIKE ONE.

    Funny, I feel the same way about putting parentheses around the expression in an if or while statement. Sure those are because a language designer got tired of saving keystrokes after defining = to be assignment and == to be comparison. Just because the language designer forgot to make redundant parentheses mandatory in a return statement is no excuse for programmers to be inconsistent in coding style.

    (Even though I'm inconsistent in coding style since I don't put redundant parentheses in return statements, that doesn't mean I have an excuse.)

  • Norman Diamond (unregistered)

    I'm also the guy who places parenthesis around every macro #define. Because the first time you debug a problem that turned out to be because of macro expansion in an expression causing an "precedence of operators" should be the last time you ever fall victim to that problem.

    Should be, but won't be. You see, some Linux driver developer decided he/she didn't need parentheses around a few macro #defines, but got lucky because the macros weren't actually used anywhere. I posted it to the linux-scsi mailing list a few years ago, and no one cared. No matter how many times you or I debug problems caused by precedence of operators in macro expansions, we should not expect any of them to be the last time.

  • Microsoft (unregistered)

    return license.getFeatures().isEmpty();

    OK, what hacker leaked the source code of the Edge browser? Or is it from Cortana? Either way, we're going to sue you.

  • isthisunique (unregistered)

    It could be worse. He could have put in a completely useless else statement.

  • Jolyon (unregistered)

    The real WTF is of course

    if (someBooleanExpression == true) { <do something> }

    which I encounter all over some code which I have inherited...

  • (nodebb) in reply to Jolyon

    @Jolyon Perhaps true is not a keyword, and it is defined in a macro or something.........

    I'm a little surprised that no one has mentioned the hidden tl;dr code that always returns true.

  • One is the loneliest number (unregistered)

    So who is a lone developer supposed to do a code review with?

  • John Pettitt (google)

    That said in Javascript I find myself writing this sort of code

    const flag = functionThatReturnsSomthingTruthyOrUndefined() ? true : false;

    Becasue I've been bitten in the past assigning the result of the function to a flag and having somebody else in another part of the program use flag === true and the code fail (or JSON encoding an object and seeing a string instead of the bool they expected)

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    I don't know if there's bad stuff with using it in Javascript, but !! is a good way in C to ensure that you actually have nothing but a 0 or 1 value, and not some other "truthy" value.

  • Des (unregistered) in reply to Brook

    What possible reason is there not to write the first one as:

    boolean someFunction() { return someBooleanExpression; }

    ?

  • Norman Diamond (unregistered)

    So who is a lone developer supposed to do a code review with?

    A rubber duck.

  • Norman Diamond (unregistered)

    TRWTF is failure to use the correct operator.

    return somebooleanexpression ? true : false : filenotfound;

  • Fedaykin (unregistered)

    Nothing WTF about the first example. It's perhaps silly, but not a WTF. As others have pointed out, it's more readable (to some) and easier to debug. The second is clearly a WTF, but the general concept is not.

    However, the REAL WTF here is the complete and utter lack of null checking when doing boolean expressions like in the second example with nested object/function dereferencing. It make the result NOT boolean, but rather true, false or NPE.

  • Calvin H (unregistered) in reply to GWO

    I agree with GWO on this, I don't see a problem with the function existing ( hasFeatures() ), this approach is used a lot in game programming (isAlive(), isEnemy(), isVisible(), etc). The issue is that the function could have been written in one line/simplified greatly. The use of a ternary operator is also nice.

  • Joe (unregistered) in reply to @GWO

    Actually you still need to negate the boolean value to return false if the list is empty, given the method hasFeatures is asking if the list is NOT empty ergo. return !license.getFeatures.isEmpty ();

  • Guest (unregistered)

    I've seen similar code where the true and false of the ternary operator were swapped (effectively negating the value). Kept me on my toes rewriting that code, I can tell you.

Leave a comment on “Returnary”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article