[llvm-dev] Variable names rule

JD Jones via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 4 12:03:09 PST 2019

Hi Tim,

Sorry, I'm not sure I follow.  Are you maybe thinking that if the identifiers were tagged to specify scope, people would still be trying to use acronyms or single letters? So that, what in future code might be F, would instead be _f and that would be worse than f_ or s_f?   I was thinking instead F would be (for new or modified code) _function or _fnctn or _func  (as an object of type Function). Again, sorry -- I don't see how prepended underscore is worse than an appended one. Could you supply some examples, please?

-----Original Message-----
From: Tim Northover [mailto:t.p.northover at gmail.com] 
Sent: Monday, February 4, 2019 1:37 PM
To: JD Jones <jjones at prc-hsv.com>
Cc: Robinson, Paul <paul.robinson at sony.com>; clattner at nondot.org; Michael Platings <Michael.Platings at arm.com>; llvm-dev <llvm-dev at lists.llvm.org>; nd <nd at arm.com>
Subject: Re: [llvm-dev] Variable names rule

On Mon, 4 Feb 2019 at 17:20, JD Jones via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> ·         Non-static data members:           _<lowerCaseLetterThenCamelCase> (This was allowed by the C++ standard I last read. It’s _<UpperCase> that is reserved)

This is about the one thing I'd be truly unhappy to see us adopt (for any situation). I think the interaction with acronyms is just too pathological. You get a really weird identifier or UB, possibly without even knowing it.


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.

More information about the llvm-dev mailing list