if (p == nullptr) style conventions?

Does LLVM/clang have any style convention preferring:

if (p)

over

if (p != nullptr)

?

or it's converse:

if (!p)

over

if (p == nullptr)

?

I didn't find anything in the existing style guide and I've gotten
a request for readability-simplify-boolean-expr in clang-tidy to
make such simplifications.

PS: Mail filters are blocking my messages, so ignore this, its
only for them. Lorem ipsum dolor sit amet, consectetur adipiscing
elit. Phasellus consequat ullamcorper mollis. Sed blandit semper tortor
ultricies dictum. Proin hendrerit et quam in sagittis. Maecenas vel
blandit ante, in auctor sem. Phasellus condimentum leo vel finibus
viverra. Duis fermentum sollicitudin est, ac iaculis lectus auctor vel.
Nam condimentum nulla feugiat, venenatis nibh a, elementum nulla. Nulla
vitae malesuada eros. Nulla cursus maximus ligula non hendrerit.

Curabitur lobortis nulla vel sapien posuere, id aliquam orci
bibendum. Vestibulum at vulputate risus. Proin in purus commodo,
tempus lectus vitae, faucibus nunc. Aenean congue faucibus elit, sit
amet facilisis nibh ultrices eget. Nam pulvinar leo ac nunc ultricies,
nec tincidunt nulla tincidunt. Etiam placerat felis tellus, ut ultricies
nunc ultricies quis. In placerat sapien nec ultricies mattis. Integer
sed tempor orci, ac imperdiet orci. Integer ac augue et augue convallis
faucibus.

Does LLVM/clang have any style convention preferring:

if (p)

over

if (p != nullptr)

?

or it's converse:

if (!p)

over

if (p == nullptr)

?

I don't believe there's any documented (or commonly enforced implicit)
convention here.

I tend towards p/!p, personally. (one place where it's worth being more
explicit is in function arguments - "func(p)" where func takes a boolean is
a bit subtle, "func(p != nullptr)" seems better there, unless the names of
the function/p/etc are /really/ obvious)

In article <CAENS6EvMeS=FUTf49-ar+zBSUr9BqfraSHuuGd+7xYRiuwDfhg@mail.gmail.com>,
    David Blaikie <dblaikie@gmail.com> writes:

I don't believe there's any documented (or commonly enforced implicit)
convention here.

I tend towards p/!p, personally. (one place where it's worth being more
explicit is in function arguments - "func(p)" where func takes a boolean is
a bit subtle, "func(p != nullptr)" seems better there, unless the names of
the function/p/etc are /really/ obvious)

Yes, I'm only talking about the case where a pointer compared to
nullptr is in the conditional expression of an if statement. I agree
that it is a little too subtle when it is an implicit conversion to
bool for a function argument.

This came up in discussion around the check I've added to clang-tidy
that simplifies boolean expressions and the question was whether or
not there should be a readability check that simplifies

if (p != nullptr)

to

if (p)

and simplify

if (p == nullptr)

to

if (!p)

In the case of an if statement, I think this idiom is well established
in the C/C++ community and many would find the explicit comparison to
nullptr to be needlessly verbose.

However, I didn't want to do something that would chafe against
LLVM/clang coding conventions and I couldn't find the conventions
stated explicitly anywhere.

In article <CAENS6EvMeS=
FUTf49-ar+zBSUr9BqfraSHuuGd+7xYRiuwDfhg@mail.gmail.com>,
    David Blaikie <dblaikie@gmail.com> writes:

> I don't believe there's any documented (or commonly enforced implicit)
> convention here.
>
> I tend towards p/!p, personally. (one place where it's worth being more
> explicit is in function arguments - "func(p)" where func takes a boolean
is
> a bit subtle, "func(p != nullptr)" seems better there, unless the names
of
> the function/p/etc are /really/ obvious)

Yes, I'm only talking about the case where a pointer compared to
nullptr is in the conditional expression of an if statement. I agree
that it is a little too subtle when it is an implicit conversion to
bool for a function argument.

I doubt (but data could be used to sway me) there's sufficient convention
one way or another to make it a check - but the thing about checks is that
they can be used by people who feel they enforce what they want, and not
used by those who don't, so the bar is pretty low to what can be
implemented as a check - and teams/products/etc can opt in to those that
are consistent.

I doubt LLVM itself would opt in to such a convention immediately, nor
would we probably worry enough to have a conversation to decide - we'd
probably just leave the status quo. It's not really something that requires
consistency or particularly harms readability.

In article <CAENS6EvMeS=
FUTf49-ar+zBSUr9BqfraSHuuGd+7xYRiuwDfhg@mail.gmail.com>,
    David Blaikie <dblaikie@gmail.com> writes:

> I don't believe there's any documented (or commonly enforced implicit)
> convention here.
>
> I tend towards p/!p, personally. (one place where it's worth being more
> explicit is in function arguments - "func(p)" where func takes a
boolean is
> a bit subtle, "func(p != nullptr)" seems better there, unless the names
of
> the function/p/etc are /really/ obvious)

Yes, I'm only talking about the case where a pointer compared to
nullptr is in the conditional expression of an if statement. I agree
that it is a little too subtle when it is an implicit conversion to
bool for a function argument.

I doubt (but data could be used to sway me) there's sufficient convention
one way or another to make it a check - but the thing about checks is that
they can be used by people who feel they enforce what they want, and not
used by those who don't, so the bar is pretty low to what can be
implemented as a check - and teams/products/etc can opt in to those that
are consistent.

I believe when I did the conversions from 0 to nullptr, I squashed a lot of
explicit comparisons in if statements. I left them for bool conversions in
things like function arguments or returns.

In article <CAF7ks-Ozy5n=9eiVzmdTBCNp+fbmEZiv+otbjKK+Jz1b=QYaTA@mail.gmail.com>,
    Craig Topper <craig.topper@gmail.com> writes:

I believe when I did the conversions from 0 to nullptr, I squashed a lot of
explicit comparisons in if statements. I left them for bool conversions in
things like function arguments or returns.

So two votes for squishing 'if (p != nullptr)' to 'if (p)' and so far
no votes against...

PS: Mail filters are blocking my messages, so ignore this, its
only for them. Lorem ipsum dolor sit amet, consectetur adipiscing
elit. Phasellus consequat ullamcorper mollis. Sed blandit semper tortor
ultricies dictum. Proin hendrerit et quam in sagittis. Maecenas vel
blandit ante, in auctor sem. Phasellus condimentum leo vel finibus
viverra. Duis fermentum sollicitudin est, ac iaculis lectus auctor vel.
Nam condimentum nulla feugiat, venenatis nibh a, elementum nulla. Nulla
vitae malesuada eros. Nulla cursus maximus ligula non hendrerit.

Curabitur lobortis nulla vel sapien posuere, id aliquam orci
bibendum. Vestibulum at vulputate risus. Proin in purus commodo,
tempus lectus vitae, faucibus nunc. Aenean congue faucibus elit, sit
amet facilisis nibh ultrices eget. Nam pulvinar leo ac nunc ultricies,
nec tincidunt nulla tincidunt. Etiam placerat felis tellus, ut ultricies
nunc ultricies quis. In placerat sapien nec ultricies mattis. Integer
sed tempor orci, ac imperdiet orci. Integer ac augue et augue convallis
faucibus.

I personally find if (p) easy to grok, but for whatever reason I haven’t internalized the if (!p) pattern; I always have to think twice about if (!p) and mentally expand it into if ((!p) != 0) and simplify to find if (p == 0). Just my weirdness probably.

– Sean Silva