I would definitely welcome more prolific usage of early returns, but I
don't think we can do that before the big reformat. At least some of
those changes will be pretty non-trivial and risky. I'd vote for
making these changes after the reformat. Hopefully the uglyness of the
code will also encourage people to do that more. :)
Another thing we can do to alleviate the nesting level problem is
split code into smaller functions. I see a lot of code which has huge
functions doing complicated things. If that was split into smaller
functions, the code would become much clearer (and less nested).
pl
On 28 August 2016 at 21:37, Tamas Berghammer via lldb-dev
<lldb-dev@lists.llvm.org> wrote:
> 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
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
