On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> *Near-Term Goal: Standardizing on LLVM-style clang-format Rules*
>
> We’ve heard from several in the community that would prefer to have a
> single code formatting style to further unify the two code bases. Using
> clang-format with the default LLVM conventions would simplify code
> migration, editor configuration, and coding habits for developers who work
> in multiple LLVM projects. There are non-trivial implications to
> reformatting a code base with this much history. It can obfuscate history
> and impact downstream projects by complicating merges. Ideally, it should
> be done once with as much advance notice as is practical. Here’s the
> timeline we’re proposing:
>
> *Today* - mechanical reformatting proposed, comment period begins
>
> To get a preview of what straightforward reformatting of the code looks
> like, just follow these steps to get a clean copy of the repository and
> reformat it:
>
>
> 1. Check out a clean copy of the existing repository
> 2. Edit .clang-format in the root of the tree, remove all but the line
> “BasedOnStyle: LLVM”
> 3. Change your current working directory to the root of the tree to
> reformat
> 4. Double-check to make sure you did step 3 ;-)
> 5. Run the following shell command: "find . -name "*.[c,cpp,h] -exec
> clang-format -i {} +"
>
>
> *Aug 20th* - comment period closes, final schedule proposed
> *TBD (early September?)* - patches land in svn
>
> The purpose of the comment period is to review the straightforward diffs
> to identify areas where comment pragmas should be used to avoid undesirable
> formatting (tables laid out in code are a classic example.) It’s also a
> time when feedback on the final timetable can be discussed, and any
> unforeseen implications can be discovered. We understand that LLDB tends
> toward relatively long names that may not always work well with the LLVM
> convention of wrapping at 80 columns. Worst case scenarios will be
> evaluated to determine the desired course of action.
>
One thing we will need to take a look at is functions which have a very
deep indentation level. They have the potential to be made really ugly by
clang-format. The default indentation will be reduced from 4 to 2, so that
will help, but I recall we had some lines that began very far to the right.
Here's a little bash command shows all lines with >= 50 leading spaces,
sorted in descending order by number of leading spaces.
grep -n '^ \+' . -r -o | awk '{t=length($0);sub(" *$","");printf("%s%d\n",
$0, t-length($0));}' | sort -t: -n -k 3 -r | awk 'BEGIN { FS = ":" } ; {
if ($3 >= 50) print $0 }'
It's less useful than I was hoping because most of the lines are noise
(line breaking in a function parameter list).
If there were a way to detect indentation level that would be better.
Mostly just to identify places that we should manually inspect after
running clang-format.
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
