If the main points you disagree with are variable naming conventions (which
clang-format makes no attempt to address), then is it worth discussing a
transition towards full-compliance with LLVM style *except* with regards to
variable naming conventions?
On Wed, Aug 20, 2014 at 9:50 AM, Greg Clayton <gclay...@apple.com> wrote:
> My biggest issues with the LLVM coding style are:
> - no easy way to identify class instance variables. I would prefer to see
> "m_" or at least "_" as a prefix for all instance variables.
>
> An example that stops us from being able to enable the warning for hidden
> local variables comes from iterator_range.h:
>
> iterator_range(IteratorT begin_iterator, IteratorT end_iterator)
> : begin_iterator(std::move(begin_iterator)),
> end_iterator(std::move(end_iterator)) {}
>
>
> And another:
>
> DiagStatePoint(DiagState *State, FullSourceLoc Loc)
> : State(State), Loc(Loc) { }
>
> The name of the ivars match the argument names.
>
> - I would prefer type names formatted in a specific way (LLDB uses camel
> case) and variables in another way (LLDB uses lower case separated by '_').
> Without this types, variables, and instance variables all look the same.
>
>
>
> > On Aug 19, 2014, at 10:35 PM, Chandler Carruth <chandl...@google.com>
> wrote:
> >
> >
> > On Tue, Aug 19, 2014 at 5:03 PM, Chris Lattner <clatt...@apple.com>
> wrote:
> > On Aug 19, 2014, at 10:16 AM, Zachary Turner <ztur...@google.com> wrote:
> >
> > > I brought this up in a thread on lldb-commits, but since it is of more
> general interest, I want to make a thread here as well.
> > >
> > > Can we have clear direction on LLDB coding style?
> >
> > Just to toss out a controversial opinion here, I consider it a bug that
> LLDB doesn’t follow the documented LLVM coding standard. This only drives
> a wedge between LLDB and the rest of the LLVM community.
> >
> > I want to strongly, emphatically agree.
> >
> > Coding standards are most valuable when consistent across a broad,
> shared body of code. We need more contributors in LLDB, and one place to
> get them is from the existing large pool of LLVM developers. We should be
> lowering the barriers there, especially for easy things like coding
> standards.
> >
> > Also, as we are actively developing convention, standard, and formatting
> tools, the cost of changing this is going down and the value to the
> *existing* developers of using the common coding standard is going up.
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
