33

someBoolean = (condition1 && condition2 ) ? true : false;

O.M.G....

Comments
  • 1
  • 18
    better then

    bool valid = false;
    If(condition1 == true){
    if(condition2 == true){
    valid = true;
    }
    else{
    valid = false;
    }
    }
    else{
    valid = false;
    }

    My eyes bleed most days.
  • 11
  • 1
    @C0D4 I see this too often at work, it makes me wanna cry.
  • 2
    @C0D4 you and me both.
  • 1
    One day I found a line like that in our codebase… immediately checked git blame cause I wanted to know who the duck does that: it was me myself.

    Though in my defense, judging from the date, it must’ve been one of my first commits ever to any codebase. And then I was left to wonder how nobody mention it at PR..
  • 0
  • 2
    @100110111 "oh, I know this man. It's me!"
  • 2
    if (isApp || true) ...
  • 1
    This makes sense if condition2 is not a boolean
  • 0
    @bioDan it just cannot not be a boolean.
  • 0
    @iiii why not?
  • 1
    What's so wrong with it, assuming that boolean is reused somewhere?
  • 0
    @Shadowleaf seriously, you don’t see what’s wrong with that? Hint: it’s not the assignment…
  • 1
    @100110111 You mean unnecessary brackets? Otherwise not really...
  • 1
    @bioDan because it will be converted to boolean to get a boolean result anyway. So it's either a boolean ot trivially convertible to boolean
  • 2
    @Shadowleaf the tested result is already a boolean. There's to need to test it and return a boolean yet again.
  • 1
    @Shadowleaf you’re either real green or in the wrong business, then.
  • 1
    @Shadowleaf the true/false implicitly returned is redundant.

    x = (condition1 && condition2)

    Is more then enough.
  • 1
    @iiii so tell me what does the following evaluate to?

    const areYouSureImBool = (true && {})

    const areYouSureImBool2 = (true && '')

    const areYouSureImBool3 = (true && [])
  • 1
    @bioDan if you end up with a situation like that, your code is already shit
  • 1
    @100110111 im not saying its not, im just saying there are cases where its valid to be that explicly in JS
  • 3
    @100110111 btw, its only speculation but i bet you can find shit in 85% of code bases
  • 1
    @100110111 For some reason was looking what's wrong with comparisons, not type. Guess i need to wake up before posting.
  • 1
    @bioDan I guess that’s a way to handle those cases, yes. Does lead to the question whether JS is ever a valid language choice, really. 😏
  • 0
    @bioDan let's not talk about shitscript
  • 1
    @iiii this post is about shitcode, its in the tags

    i hope you now understand there are use cases where its valid, and that it depends on the type of the second condition.

    JS is a weak and dynamic type programming language, lamentably there are cases where this is a valid solution.
  • 1
    @bioDan shit code but not shitscript 🙃
  • 0
    @bioDan I would argue that checking an array, for example, for emptiness should be made with an 'empty' method, and not via automatic conversion to boolean.
Add Comment