qemu-devel
[Top][All Lists]
Advanced

[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: John Snow
Subject: Re: [Qemu-devel] [PATCH] CODING_STYLE: update line length and mixed declaration rules
Date: Tue, 25 Aug 2015 15:22:12 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0


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.

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.

>>> Either way, can you please decouple the two changes?
>>
>> Sure, didn't want to spam people with a series on what is mostly an RFC.
> 
> Looking forward to your respin.
> 



reply via email to

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