[webkit-dev] !!Tests for equality comparison

[Maciej Stachowiak]

I think allowing both forms is worse than mandating one form. It's true that in different situations one or the other may read better, but it's distracting to have differences that are matters of author taste rather than conveying meaningful information. "This is a numeric check, not a boolean or null check" is info, but "this kinda feels numbery to whoever wrote the code" is not.

 - Maciej 

> On Apr 28, 2017, at 6:02 AM, Antti Koivisto <koivisto at iki.fi> wrote:
> 
> This is a good change as long as we are just relaxing the rule rather than mandating ==. I think ! makes a lot of sense when testing for emptiness: 
> 
> if (!container.size())
>    ...
> 
> if (!count)
>    ...
> 
> but == should be used for testing things where 0 is just another number, like indexes:
> 
> if (index == 0)
>    ...
> 
> 
>    antti
> 
> 
> On Fri, Apr 28, 2017 at 11:00 AM, Keith Miller <keith_miller at apple.com <mailto:keith_miller at apple.com>> wrote:
> Is there any opposition to relaxing this rule? Speak now or forever hold your piece! (not really but I would be curious to hear opposition). 
> 
> Cheers,
> Keith
> 
>> On Apr 27, 2017, at 10:32 PM, Carlos Garcia Campos <carlosgc at webkit.org <mailto:carlosgc at webkit.org>> wrote:
>> 
>> El jue, 27-04-2017 a las 16:06 -0700, JF Bastien escribió:
>>> Hello C++ fans!
>>> 
>>> The C++ style check currently say:
>>> Tests for true/false, null/non-null, and zero/non-zero should all be
>>> done without equality comparisons
>>> 
>>> I totally agree for booleans and pointers… but not for integers. I
>>> know it’s pretty much the same thing, but I it takes me slightly
>>> longer to process code like this:
>>> 
>>> int numTestsForEqualityComparison = 0:
>>> // Count ‘em!
>>> // …
>>> if (!numTestsForEqualityComparison)
>>>   printf(“Good job!”);
>>> 
>>> I read it as “if not number of tests for equality comparison”. That's
>>> weird. It takes me every slightly longer to think about, and I’ve
>>> gotten it wrong a bunch of times already. I’m not trying to check for
>>> “notness", I’m trying to say “if there were zero tests for equality
>>> comparison”, a.k.a.:
>>> 
>>> if (numTestsForEqualityComparison == 0)
>>>   printf(“Good job!”);
>>> 
>>> So how about the C++ style let me just say that? I’m not suggesting
>>> we advise using that style for integers everywhere, I’m just saying
>>> it should be acceptable to check zero/non-zero using equality
>>> comparison.
>> 
>> I agree, it's also quite confusing when using strcmp, because !strcmp
>> means the strings are equal. It's not only more difficult to read, I've
>> seen patches with wrong strcmp checks because of that.
> 
> I also think this could be solved by #defining a success a C call positive result that is 0 (e.g. CCallSuccess), regardless of the choice we make here.
> 
>> 
>>> 
>>> !!Thanks (i.e. many thanks),
>>> 
>>> JF
>>> 
>>> p.s.: With you I am, fans of Yoda comparison, but for another day
>>> this will be.
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20170428/009e2c91/attachment.html>