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.
if not (x > 5)
if (x > 5) == false { .. ]
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.
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.
Maybe yes, maybe no. The point is that adding "== true" makes it more clear and should therefore be done.
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.