You can grep for " {$". With this regex I
see no false positives and 272 case with 40 or more leading spaces
On Sun, 28 Aug 2016, 17:59 Zachary Turner via lldb-dev, <
lldb-dev@lists.llvm.org> wrote:
> Here it is
>
>
> 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 }'
> On Sun, Aug 28, 2016 at 9:54 AM Zachary Turner <ztur...@google.com> wrote:
>
>> I tried that, but most of the results (and there are a ton to wade
>> through) are function parameters that wrapped and align with the opening
>> paren on the next line.
>>
>> Earlier in the thread (i think it was this thread anyway) i posted a bash
>> incantation that will grep the source tree and return all lines with >= N
>> leading spaces sorted descending by number of leading spaces. The highest
>> was about 160 :)
>>
>> If you search lldb-dev for awk or sed you'll probably find it
>> On Sun, Aug 28, 2016 at 9:10 AM Chris Lattner <clatt...@apple.com> wrote:
>>
>>> Can you just grep for “^ “ or something?
>>> That seems like a straight-forward way to find lines that have a ton of
>>> leading indentation.
>>>
>>> -Chris
>>>
>>> On Aug 27, 2016, at 9:28 AM, Zachary Turner <ztur...@google.com> wrote:
>>>
>>> It will probably be hard to find all the cases. Unfortunately
>>> clang-tidy doesn't have a "detect deep indentation" check, but that would
>>> be pretty useful, so maybe I'll try to add that at some point (although I
>>> doubt I can get to it before the big reformat).
>>>
>>> Finding all of the egregious cases before the big reformat will present
>>> a challenge, so I'm not sure if it's better to spend effort trying, or just
>>> deal with it as we spot code that looks bad because of indentation level.
>>>
>>> On Sat, Aug 27, 2016 at 9:24 AM Chris Lattner <clatt...@apple.com>
>>> wrote:
>>>
>>>> On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev <
>>>> lldb-dev@lists.llvm.org> wrote:
>>>>
>>>> Back to the formatting issue, there's a lot of code that's going to
>>>> look bad after the reformat, because we have some DEEPLY indented code.
>>>> LLVM has adopted the early return model for this reason. A huge amount of
>>>> our deeply nested code could be solved by using early returns.
>>>>
>>>>
>>>> FWIW, early returns are part of the LLVM Coding standard:
>>>>
>>>> http://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code
>>>>
>>>> So it makes sense for LLDB to adopt this approach at some point.
>>>>
>>>> I don’t have an opinion about whether it happens before or after the
>>>> "big reformat", but I guess I agree with your point that doing it would be
>>>> good to do it for the most egregious cases before the reformat.
>>>>
>>>> -Chris
>>>>
>>>
>>> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
