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. Tim. -- 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.
On Mon, 4 Feb 2019 at 20:03, JD Jones <jjones at prc-hsv.com> wrote:> Sorry, I'm not sure I follow.In conventional English usage, acronyms always use upper-case. All other coding conventions deal with that situation gracefully (or at least not terribly). If someone strictly follows the coding convention you might end up with a weird identifier (m_tlaThatDoesSomething, m_tLAThatDoesSomething, ...); if they favour English over coding you get (m_TLAThatDoesSomething). The leading underscore is unique in turning that last case into something that violates the language standard, and for me that's enough to eliminate it from contention. I strongly discourage its use in any C or C++ project. Tim.
If _<lowerCaseLetter> violates a standard, please say which one. It does not violate the C++11 standard: •Reserved in any scope, including for use as implementation macros: •identifiers beginning with an underscore followed immediately by an uppercase letter •identifiers containing adjacent underscores (or "double underscore") •Reserved in the global namespace: •identifiers beginning with an underscore •Also, everything in the std namespace is reserved. (You are allowed to add template specializations, though.) -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Monday, February 4, 2019 2:17 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 20:03, JD Jones <jjones at prc-hsv.com> wrote:> Sorry, I'm not sure I follow.In conventional English usage, acronyms always use upper-case. All other coding conventions deal with that situation gracefully (or at least not terribly). If someone strictly follows the coding convention you might end up with a weird identifier (m_tlaThatDoesSomething, m_tLAThatDoesSomething, ...); if they favour English over coding you get (m_TLAThatDoesSomething). The leading underscore is unique in turning that last case into something that violates the language standard, and for me that's enough to eliminate it from contention. I strongly discourage its use in any C or C++ project. Tim. -- 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.