qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] scripts/checkpatch.pl: Modify the line length limit of the c


From: Markus Armbruster
Subject: Re: [PATCH] scripts/checkpatch.pl: Modify the line length limit of the code
Date: Mon, 09 Nov 2020 10:01:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 6 Nov 2020 at 16:08, Markus Armbruster <armbru@redhat.com> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> > Personally I just don't think checkpatch should be nudging people
>> > into folding 85-character lines, especially when there are
>> > multiple very similar lines in a row and only one would get
>> > folded, eg the prototypes in target/arm/helper.h -- some of
>> > these just edge beyond 80 characters and I think wrapping them
>> > is clearly worse for readability.
>>
>> The warning's intent is "are you sure this line is better not broken?"
>> The problem is people treating it as an order that absolves them from
>> using good judgement instead.
>>
>> I propose to fix it by phrasing the warning more clearly.  Instead of
>>
>>     WARNING: line over 80 characters
>>
>> we could say
>>
>>     WARNING: line over 80 characters
>>     Please examine the line, and use your judgement to decide whether
>>     it should be broken.
>
> I would suggest that for a line over 80 characters and less than
> 85 characters, the answer is going to be "better not broken"
> a pretty high percentage of the time; that is, the warning
> has too many false positives, and we should tune it to have fewer.
>
> And the lure of "produce no warnings" is a strong one, so
> we should be at least cautious about what our tooling is
> nudging us into doing.

CODING_STYLE.rst: "Lines should be 80 characters; try not to make them
longer."  I'd like to keep the tooling we have to help us with trying
not to make them longer.

If we have lost the ability to differentiate between "warning" and
"error", call it something else.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]