[lldb-dev] LLDB Evolution

[David Jones via lldb-dev]

On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> I've sampled the python code from the llvm repository, and it seems to
> be using a mixture of 4-, 2-, and even 8- character indent, with 4
> being the most prevalent. So, I think we can safely stay with status
> quo.
>
>
(Comment from the peanut gallery...)

Python does have a language-level style guide (PEP-8):

https://www.python.org/dev/peps/pep-0008/

If code is going to be reformatted, then it may be best to try to converge
on exactly the PEP-8 style. Speaking as a project "outsider" (i.e., not an
active contributor), but someone with Python background, anything that
diverges from standard Python style seems jarring (at least to me).



> It will take some editor tweaking to make it use the correct indent
> for different files, but it should be manageable.
>
> pl
>
> On 12 August 2016 at 18:13, Jim Ingham <jingham at apple.com> wrote:
> >
> >> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >>
> >> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
> >> <lldb-dev at lists.llvm.org> wrote:
> >>> I recommend approaching this in three steps:
> >>>
> >>> 1) get the less-controversial changes done that Greg was outlining.
> >>> 2) start a discussion in the llvm community about the concept of a
> >>> member/global prefix.
> >>> 2a) the community could agree that llvm-as-a-whole should move to
> prefixes
> >>> or otherwise change the camel case policy.
> >>> 2b) the community could agree that the existing policies are preferred
> >>> 3) LLDB moves to whatever is the end result of the discussion.
> >>>
> >>> I guess what I’m saying is that since the opinions about this are very
> >>> strong, and because we haven’t really had that debate in the LLVM
> community,
> >>> that it would be bad to proactively move to the LLVM style, simply to
> have
> >>> to move back later.  Iff the (sure to be extensive) community
> discussion
> >>> settles on the idea that prefixes are the wrong thing, then LLDB should
> >>> remove them to be consistent.
> >>>
> >>> -Chris
> >>
> >> +1
> >>
> >>
> >>
> >> In terms of the formatting of tests, I did some more research on this.
> >> I think the changes needed to be made to the test suite are generally
> >> trivial to fix (e.g. r278490), but I don't think we can avoid a manual
> >> intervention. CommentPragmas does not seem to be a silver bullet -- it
> >> does prevent clang-format from breaking the comment, but it does not
> >> prevent it from moving the whole comment to a new line. That said,
> >> when I reformatted the test sources with CommentPragmas set, the
> >> number of failures went down to 80 (from about 150)...
> >>
> >> I believe we should still perform the reformatting of the tests, at
> >> least to standardize on the 2 space indent (in fact we should consider
> >> doing the same for the python code as well, I don't know what's the
> >> situation there in llvm land), but it can be done later. It will make
> >> the period while the code is in flux longer, but hopefully not too
> >> long. Also the modifications will be independent of the main reformat,
> >> so it will still be true that a single source file only got
> >> reformatted once.
> >>
> >
> > My eyes put in a vote for not reformatting the Python to 2 space tabs.
> In C++, most IDE's do smart things with double-clicking on { to find the
> closing ones easing the task that two space indents makes somewhat harder.
> But since the spacing is the only nesting indicator in Python, it would be
> nice to keep that more visually apparent.
> >
> >> pl
> >> _______________________________________________
> >> lldb-dev mailing list
> >> lldb-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160815/a3d8fc16/attachment.html>