[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] CODING_STYLE: update line length and mixed decl
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH] CODING_STYLE: update line length and mixed declaration rules |
Date: |
Wed, 26 Aug 2015 10:27:02 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
John Snow <address@hidden> writes:
> On 08/25/2015 02:20 PM, Markus Armbruster wrote:
>> Paolo Bonzini <address@hidden> writes:
>>
>>> On 19/06/2015 10:09, Andreas Färber wrote:
>>>>>> -Lines are 80 characters; not longer.
>>>>>> +Lines should be 80 characters; try not to make them longer.
>>>>>> +
>>>>>> +Sometimes it is hard to do, especially when dealing with QEMU subsystems
>>>>>> +that use long function or symbol names. Even in that case, do not make
>>>>>> +lines _much_ longer than 80 characters.
>>>> Anthony had always allowed sensible exceptions to that rule, so +1 for
>>>> reformulating it here.
>>>>
>>>> However, I would suggest that in that case we should lower the
>>>> recommendation/warning to 78 chars, with the rationale of not only the
>>>> actual code but also two-way diffs (79 chars plus ±/space) and
>>>> three-way diffs (78 chars plus 2x ±/space) fitting into standard 80x24
>>>> windows.
>>>
>>> Good idea.
>>
>> I personally prefer a slightly lower limit, to keep quoted patches in
>> e-mail neatly under 80. How much writability to trade for readability
>> is subjective, and I won't argue against 78.
>>
>
> As long as we don't update the checkpatch tool to whine about this,
> since it might break a good amount of existing context, and this will
> just inconvenience everyone and provide no real benefit.
>
> Maybe if you can have it warn only for NEW lines and not for context,
> but if that's not possible I'm against shortening the existing limit.
>
> IMO: The 80 char width rule makes good sense, but forcing the margins
> even smaller on today's clearly-no-longer-a-terminal devices is just a
> little too much.
The reason for line length limit isn't antiquated hardware or antiquated
habits, it's us antiquated human beings: we tend to have trouble
following long lines with our eyes (I sure do). Typographic manuals
suggest to limit columns to roughly 60 characters for exactly that
reason[*]. Four levels of indentation plus 60 characters of actual text
yields 76.
> Of course, gently prodding people to reconsider their line length if
> they are reliably approaching 75+ is another issue entirely... it just
> shouldn't reflect as non-success via checkpatch.
I think that's what Paolo's patch does. Namely:
line shorter than the soft limit: fine
line between soft and hard limit: warn
line longer than the hard limit: error
He kept the soft limit at 80, and set the hard limit to 90. Andreas
suggested to lower the soft limit a bit, and I suggested to lower it a
bit more.
[...]
[*] https://en.wikipedia.org/wiki/Column_(typography)#Typographic_style