Found this at work today.

Can you tell me where's the problem ? I mean I can't see anything wrong in this code ?

I neither don't see the bad you're talking about. This is actually exactly the code I would write....

@moagggi ohh I thought that I am the only one 😂

return count == 0;

I'm outta here.

Does it work? Good. Then we don't have a problem.

@Letmecode @kamen yes there are many ways to write this code. The thing is that they are all correct in my opinion the difference is in execution time (probably milliseconds) and style

I thought return count == 0; would be the obvious simplification...

Although it is correct, I would prefer return count == 0;

These little things easily add up. If you dont try to keep stuff in one line you easily start having classes over 600 lines of code which end up being even bigger as time passes... in short... don't do this :)

Maybe planning to put something before "return false;"? I'm being naïve.

@Gauthier You should not do that. Only implement stuff when you actually need them

@olpe Sure, I wouldn't. It was not meant as an excuse, only a possible explanation.

return count == 0;
or
return !count == 0;

I'm just 15 years old and already cringe at the code in the image...

@Letmecode It seems you've been dealing with way too much shitty JS.

I mean yeah return code==0 is sophisticated and all, but this one is just so much easier to read

@filthyranter !count == 0
??
Not
count != 0
?

Aside from rewriting the statement to one line, the '==' can lead to problems down the line.

What if count is null? A string?

@Letmecode using double negative logic...how beautiful! This way the next developer can spend a minute to realize you should have written return count == 0;

@FuzzyMyztiq take it easy

@FuzzyMyztiq it's worse than that; this is JavaScript for the Mozilla Rhino engine. Variables could working with Java classes and therefore return Java objects. For example a Java string is not equal a JavaScript string, and so name.getValue() === "bob" will return false because they are not the same String object.

@kamen Better (if JS):

return !count;

@RazorSh4rk You're resorting to different data types and rely on JavaScript's casting, which is a dirty hack in my book. If it was up to me, I'd initialise the variable with whatever variable I need (e.g. 0).

Coupe de gras

@Gauthier Ah, yes. Even though you could alternatively use return !(count == 0)

@aamitkov
Boolean(0)

Can you run this code in you console?

Mhm, I believe it would still return false.

0 is the only number which is interpreted as false, which would return true in this case, every other number would be interpreted as true, which would be returned as false.

Or am I wrong?

count == 0
And
!count

Should have the same effect in this specific case.

@Letmecode

@RazorSh4rk Adding redundancy to code doesn't make it easier to read. Unless (in this case) the reader doesn't know that "count == 0" is a boolean expression, but then he should learn programming before attempting to read code.

return !count;

@uuppi Depends on whether you intend to add more checks later. If it's just a helper method (meant to be used more than once), then it's fine with "return count == 0" or rather "return count === 0" so that it fails if you pass it the wrong type.

@uuppi There is nothing wrong with return count == 0 && !getSomething()

As long as it can fit in one line its readable. Once you start having more conditions or you start feeling the need to split them into more lines thats when helper variable is good. ☺