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> 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] On Behalf Of > Krzysztof Parzyszek via llvm-dev > Sent: Monday, February 4, 2019 2:51 PM > To: 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> 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 > 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 > 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/20190204/6d94197b/attachment.html>
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>
<<Joke Follows; please do not flame>> "m_" stands for "Microsoft-wannabe" From: Carey Williams [mailto:Carey.Williams at arm.com] Sent: Wednesday, February 6, 2019 7:12 AM To: JD Jones <jjones at prc-hsv.com>; Zachary Turner <zturner at google.com> Cc: llvm-dev at lists.llvm.org; nd <nd at arm.com> Subject: Re: [llvm-dev] Variable names rule 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 <mailto:llvm-dev-bounces at lists.llvm.org> > on behalf of Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > Sent: 04 February 2019 21:45 To: JD Jones Cc: llvm-dev at lists.llvm.org <mailto: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 doesnot 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 -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190206/d3c8b087/attachment.html>