[cfe-dev] if (p == nullptr) style conventions?
dblaikie at gmail.com
Tue May 26 10:41:03 PDT 2015
On Tue, May 26, 2015 at 10:28 AM, Richard <legalize at xmission.com> wrote:
> In article <CAENS6EvMeS=
> FUTf49-ar+zBSUr9BqfraSHuuGd+7xYRiuwDfhg at mail.gmail.com>,
> David Blaikie <dblaikie at 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
> > a bit subtle, "func(p != nullptr)" seems better there, unless the names
> > 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
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.
> 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)
> if (p)
> and simplify
> if (p == nullptr)
> 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.
> "The Direct3D Graphics Pipeline" free book <
> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
> The Terminals Wiki <http://terminals.classiccmp.org>
> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev