5 ms·

> Has complexity or efficiency ever come up in a team discussion? Nope. Do we have use for high efficiency solutions at scale? Not particularly. Not only that

> Has complexity or efficiency ever come up in a team discussion? Nope. Do we have use for high efficiency solutions at scale? Not particularly. Not only that - I often see atrocious code. Stuff like comparing boolean expressions against true/false. Stuff that makes me question basic competence of the person writing it.

cguess 6y ago
> Stuff like comparing boolean expressions against true/false I do this sometimes if it makes the code clearer. Sometimes it's not 100% clear if you're just coming in that a function returns a boolean. Sometimes you just want to remind yourself and it sneaks past a code review. I've been coding for 20 years across a dozen plus languages, and some just handle truthiness differently and it's easier to just make sure (looking at you, Javascript). Sometimes null is false, sometimes it's not, sometimes an empty string is false, sometimes it's not. Any compiler, JIT, optimizer etc. will completely ignore the comparison anyways so there's 0 runtime issue with it.
- alpha_squared 6y ago
  > Sometimes it's not 100% clear if you're just coming in that a function returns a boolean I'd argue the function isn't named appropriately, then. > Sometimes you just want to remind yourself and it sneaks past a code review Remind yourself what, exactly? > dozen plus languages, and some just handle truthiness differently and it's easier to just make sure (looking at you, Javascript) I'd argue that it's on the developer to know and work with the language's semantics (and I say this as someone who's not a fan of JS). Trying to write code that is nearly language agnostic in semantics will leave out a whole lot of language-specific value.
  - RandoHolmes 6y ago
    > I'd argue the function isn't named appropriately, then. Maybe yes, maybe no. The point is that adding "== true" makes it more clear and should therefore be done.
    - coin 6y ago
      For strongly type languages (like Java), how can ==true make it more clear?
- RandoHolmes 6y ago
  > do this sometimes if it makes the code clearer. As do I, the above poster is just super judgemental and probably not a lot of fun to work with. An observation I've had over the years is that often times developers will come to conclusions that they ought not to. The idea that typing out "== false" indicates you don't understand bools is a non-sequitur.
  - xorcist 6y ago
    When could an extra "== true" or "== false" possibly make anything clearer? if not (x > 5) looks normal, if (x > 5) == false { .. ] is just confusing. Why would it matter if a function returned a boolean? It's either compared for truthiness, or the comparison for truthiness or compared for truthiness, even in the most dynamic languages.
MattGaiser 6y ago
Why is that so horrible? I prefer it because I am prone to missing the ! when tired (which is a problem as my project has complex conditionals). Functions are not always consistent about returning a Boolean either. Bad design/naming, but you work with what you have got.
- hinkley 6y ago
  Well, for one case, I’ve seen people work really hard to test a == b, or alternatively a != b when a and b are Booleans. I think some classes were not mandatory in school, or people hated that class.
RandoHolmes 6y ago
this attitude is elitism and needs to stop. I will sometimes compare against true/false, it doesn't mean I don't understand boolean logic, it means I feel like it's more clear. It could also be that I'm in a language with truthy values and I specifically only want to compare to real boolean values. You really need to stop and ask yourself why you're so judgemental about code. Because that's a you problem, not a them problem. If I ever had a co-worker try and tell me I don't understand boolean logic because I felt like typing it out was more clear I'd laugh in their face.
- gnusty_gnurc 6y ago
  No it’s not saying someone doesn’t understand Boolean logic. It’s visual noise. This isn’t an issue with truthiness either. I’m talking normal java code. Where if I see an if-statement, clearly the thing inside doesn’t need comparison against true or false unless you want to add another comparison just for fun and mental gymnastics.
  - fingerlocks 6y ago
    It’s the opposite of noise by making the logic more precise. Suppose you have unwrapped optionals or result types, or need to specifically handle a null type differently from a false. It’s also helpful when refactoring changes a function signature. Are you young or early in your career? I think the extra verbosity is something you come to appreciate the “the hard way” over the years.
    - gnusty_gnurc 6y ago
      > It’s the opposite of noise by making the logic more precise There's cases where this might make sense (when things like truthiness are unclear). But in any of the cases I've seen, it's where things are pretty obvious and even when things are explicitly boolean types. Write the boolean expression and if it doesn't fit or has lots of parts, define them separately above the conditional with clear names. People seem upset by this, but idk it seems like common sense. I'm not sure I understand how `if (someCondition == true) {...}` is preferable to `if (someCondition) {...}`
thdc 6y ago
If a case like this pops up, how about asking them why they did it like that and then making your judgement based on response instead of questioning their competence right away? Response 1: I thought it would be clearer with the explicit comparison. (fine, then you can bring in your own opinion and maybe have a nice discussion) Response 2: You don't need == true? I never knew. (bad) Another common scenario that is complained about: using `this` with instance variables when it's technically unnecessary.
- coin 6y ago
  The point is that "if" branches based on a boolean value. A comparison is just one way to produce a boolean value. There's nothing explicit by adding "==true". It just show a lack of understanding of "if".
  - gnusty_gnurc 6y ago
    Precisely. Thank you.
  - xorcist 6y ago
    If an extra "== true" can be considered more precise, would if ((conditional == true) == true) be even more precise?

cguess 6y ago

> Stuff like comparing boolean expressions against true/false I do this sometimes if it makes the code clearer. Sometimes it's not 100% clear if you're just coming in that a function returns a boolean. Sometimes you just want to remind yourself and it sneaks past a code review. I've been coding for 20 years across a dozen plus languages, and some just handle truthiness differently and it's easier to just make sure (looking at you, Javascript). Sometimes null is false, sometimes it's not, sometimes an empty string is false, sometimes it's not. Any compiler, JIT, optimizer etc. will completely ignore the comparison anyways so there's 0 runtime issue with it.

alpha_squared 6y ago
> Sometimes it's not 100% clear if you're just coming in that a function returns a boolean I'd argue the function isn't named appropriately, then. > Sometimes you just want to remind yourself and it sneaks past a code review Remind yourself what, exactly? > dozen plus languages, and some just handle truthiness differently and it's easier to just make sure (looking at you, Javascript) I'd argue that it's on the developer to know and work with the language's semantics (and I say this as someone who's not a fan of JS). Trying to write code that is nearly language agnostic in semantics will leave out a whole lot of language-specific value.
- RandoHolmes 6y ago
  > I'd argue the function isn't named appropriately, then. Maybe yes, maybe no. The point is that adding "== true" makes it more clear and should therefore be done.
  - coin 6y ago
    For strongly type languages (like Java), how can ==true make it more clear?
RandoHolmes 6y ago
> do this sometimes if it makes the code clearer. As do I, the above poster is just super judgemental and probably not a lot of fun to work with. An observation I've had over the years is that often times developers will come to conclusions that they ought not to. The idea that typing out "== false" indicates you don't understand bools is a non-sequitur.
- xorcist 6y ago
  When could an extra "== true" or "== false" possibly make anything clearer? if not (x > 5) looks normal, if (x > 5) == false { .. ] is just confusing. Why would it matter if a function returned a boolean? It's either compared for truthiness, or the comparison for truthiness or compared for truthiness, even in the most dynamic languages.

MattGaiser 6y ago

Why is that so horrible? I prefer it because I am prone to missing the ! when tired (which is a problem as my project has complex conditionals). Functions are not always consistent about returning a Boolean either. Bad design/naming, but you work with what you have got.

hinkley 6y ago
Well, for one case, I’ve seen people work really hard to test a == b, or alternatively a != b when a and b are Booleans. I think some classes were not mandatory in school, or people hated that class.

RandoHolmes 6y ago

this attitude is elitism and needs to stop. I will sometimes compare against true/false, it doesn't mean I don't understand boolean logic, it means I feel like it's more clear. It could also be that I'm in a language with truthy values and I specifically only want to compare to real boolean values. You really need to stop and ask yourself why you're so judgemental about code. Because that's a you problem, not a them problem. If I ever had a co-worker try and tell me I don't understand boolean logic because I felt like typing it out was more clear I'd laugh in their face.

gnusty_gnurc 6y ago
No it’s not saying someone doesn’t understand Boolean logic. It’s visual noise. This isn’t an issue with truthiness either. I’m talking normal java code. Where if I see an if-statement, clearly the thing inside doesn’t need comparison against true or false unless you want to add another comparison just for fun and mental gymnastics.
- fingerlocks 6y ago
  It’s the opposite of noise by making the logic more precise. Suppose you have unwrapped optionals or result types, or need to specifically handle a null type differently from a false. It’s also helpful when refactoring changes a function signature. Are you young or early in your career? I think the extra verbosity is something you come to appreciate the “the hard way” over the years.
  - gnusty_gnurc 6y ago
    > It’s the opposite of noise by making the logic more precise There's cases where this might make sense (when things like truthiness are unclear). But in any of the cases I've seen, it's where things are pretty obvious and even when things are explicitly boolean types. Write the boolean expression and if it doesn't fit or has lots of parts, define them separately above the conditional with clear names. People seem upset by this, but idk it seems like common sense. I'm not sure I understand how `if (someCondition == true) {...}` is preferable to `if (someCondition) {...}`

thdc 6y ago

If a case like this pops up, how about asking them why they did it like that and then making your judgement based on response instead of questioning their competence right away? Response 1: I thought it would be clearer with the explicit comparison. (fine, then you can bring in your own opinion and maybe have a nice discussion) Response 2: You don't need == true? I never knew. (bad) Another common scenario that is complained about: using `this` with instance variables when it's technically unnecessary.

coin 6y ago
The point is that "if" branches based on a boolean value. A comparison is just one way to produce a boolean value. There's nothing explicit by adding "==true". It just show a lack of understanding of "if".
- gnusty_gnurc 6y ago
  Precisely. Thank you.
- xorcist 6y ago
  If an extra "== true" can be considered more precise, would if ((conditional == true) == true) be even more precise?