[llvm-dev] Variable names rule
JD Jones via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 4 12:03:09 PST 2019
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?
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