On Wed, Oct 8, 2014 at 7:20 PM, Nick Kledzik <kledzik at apple.com> wrote:> The lld conventions for ivars is a leading underscore followed by a > lowercase letter. The reserved identifiers are a leading underscore > followed by an uppercase letter. There is no conflict. >And I didn't say that there was. They are *close*. Too close. People make mistakes and get it wrong.> > On the other hand the LLVM conventions prevents the use of the -Wshadow > which catches real bugs. >I don't think this is inherently true. I would have no trouble working to fix existing shadows in LLVM and turn on the warning.> > > > However, I care much less about the particular naming convention than that > we have a consistent naming convention. And changing LLD to LLVM's style > and then later changing LLVM's style (and all the subprojects) will not > appreciably increase the amount of churn required to the project as a > whole. So I don't think we should hold up progress in the pursuit of > perfection here. > > > So you are saying, let’s make lld’s code worse and maybe someday make > lld’s and llvm’s code better. >That's a very LLD-centric way of looking at it. I'm saying let's make the entire LLVM project better by being more consistent between subprojects. Maybe someday we can make that consistent state also a better state. But avoiding consistency until that arrives is, in my opinion, blocking progress in the name of perfection. I would rather incremental progress.> > Why not hold off on changing lld until the broader naming convention is > decided, then change lld to that? lld has been using these conventions for > years. What is the rush? >The rush is that more and more people would *like* to start contributing to LLD. But they have to continually try to remember to deal with the inconsistencies between the two codebases. That wastes peoples time and discourages new contributors.> Besides, if you strip the distinctive name from ivars, it will be hard to > automatically add that back. >The primary hope of changing all of LLVM's naming conventions is the ready availability of Clang-based tools to manage the migration. Such tools don't need distinctive names, they *know* which names are member variables. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141008/15a6871c/attachment.html>
On Thu, Oct 9, 2014 at 3:31 AM, Chandler Carruth <chandlerc at google.com> wrote:> > On Wed, Oct 8, 2014 at 7:20 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >> The lld conventions for ivars is a leading underscore followed by a >> lowercase letter. The reserved identifiers are a leading underscore >> followed by an uppercase letter. There is no conflict. > > > And I didn't say that there was. They are *close*. Too close. People make > mistakes and get it wrong.I like how LLD style improves upon LLVM style, but the concern about reserved identifiers is very real. May I suggest a variation: use a trailing underscore for member variables instead of a trailing underscore? Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
On Thu, Oct 9, 2014 at 2:17 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:> On Thu, Oct 9, 2014 at 3:31 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > > > On Wed, Oct 8, 2014 at 7:20 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> > >> The lld conventions for ivars is a leading underscore followed by a > >> lowercase letter. The reserved identifiers are a leading underscore > >> followed by an uppercase letter. There is no conflict. > > > > > > And I didn't say that there was. They are *close*. Too close. People make > > mistakes and get it wrong. > > I like how LLD style improves upon LLVM style, but the concern about > reserved identifiers is very real. May I suggest a variation: use a > trailing underscore for member variables instead of a trailing > underscore? > >I've been bitten by the following autocomplete: struct Foo { Foo(int count) : count_(count_) {} int count_; }; When this happened to me, it was very difficult to track down. Now, we might have a warning that protects against that though. -- Sean Silva> Dmitri > > -- > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141009/ce51259e/attachment.html>