[llvm-dev] Variable names rule

Carey Williams via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 6 05:11:52 PST 2019


GCC does a very similar thing with s_, m_ etc.
https://www.gnu.org/software/gcc/codingconventions.html
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 04 February 2019 21:45
To: JD Jones
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Variable names rule

If we're talking about member variables, just put an m in front of it, problem solved.  You already have one for s_, and I didn't see you mention it but I assume you'd want g_ for globals, so m_ makes perfect sense for member variables and there's no question about UB at that point.

On Mon, Feb 4, 2019 at 1:27 PM JD Jones via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Yeah, I hated it too at first. It grew on me.  After about a week or so, it does make it easy to differentiate between different kinds of elements at a quick glance, can be more readable than a single or two character identifier, doesn't take up much horizontal space (considering LLVM allows only 80, that should be a consideration...unless that, too, is under discussion?)  can be very pronounceable, and when documentation is created from it, allows the reader of that documentation to quickly differentiate between different kinds of elements as well.

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Krzysztof Parzyszek via llvm-dev
Sent: Monday, February 4, 2019 2:51 PM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Variable names rule
Importance: Low

On 2/4/2019 2:29 PM, Tim Northover via llvm-dev wrote:
> On Mon, 4 Feb 2019 at 20:21, JD Jones <jjones at prc-hsv.com<mailto:jjones at prc-hsv.com>> wrote:
>> If _<lowerCaseLetter> violates a standard, please say which one. It does not violate the C++11 standard:
>
> If strictly adhered to, it doesn't, and I've never claimed any
> different. But coding standards are never strictly adhered to.
> Particularly not in a codebase like LLVM which already has a good
> handful in play for historical reasons. We can't expect reviewers to
> be perfect either, and violations of a leading underscore rule have a
> ridiculously high probability of producing malformed C++.
>
> It's simply not worth the aggro when there are plenty of other
> possibilities available that don't open us up for that failure mode.

IMO, any convention that contains leading or trailing underscores should be rejected outright. The primary purpose of a convention is to allow a person to differentiate between different kinds of elements with a quick glance. It should strive to make these elements appear different without sacrificing the readability. Prepending or appending a lone underscore is really making the identifier as similar to another one as possible, while still making it different from the language standard point of view, i.e. the opposite to what a useful convention should do.

-Krzysztof
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


--
This message is intended for the addressee only and may contain Paragon
Research Corporation (PRC) confidential or privileged information.  Use or
distribution of such confidential information is strictly prohibited
without the prior written permission of PRC.  If you have received this
message in error, please contact the sender immediately and delete the
message and attachments from your computer.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190206/070c852c/attachment.html>


More information about the llvm-dev mailing list