From: John Snow <jsnow@redhat.com>
To: Markus Armbruster <armbru@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, "Andreas Färber" <afaerber@suse.de>,
"Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] CODING_STYLE: update line length and mixed declaration rules
Date: Tue, 25 Aug 2015 15:22:12 -0400 [thread overview]
Message-ID: <55DCC064.3070502@redhat.com> (raw)
In-Reply-To: <876143jklh.fsf@blackfin.pond.sub.org>
On 08/25/2015 02:20 PM, Markus Armbruster wrote:
> Paolo Bonzini <pbonzini@redhat.com> 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.
>
next prev parent reply other threads:[~2015-08-25 19:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 7:29 [Qemu-devel] [PATCH] CODING_STYLE: update line length and mixed declaration rules Paolo Bonzini
2015-06-19 7:53 ` Thomas Huth
2015-06-19 7:55 ` Paolo Bonzini
2015-06-19 8:09 ` Andreas Färber
2015-06-19 8:38 ` Paolo Bonzini
2015-08-25 18:20 ` Markus Armbruster
2015-08-25 19:22 ` John Snow [this message]
2015-08-26 8:27 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55DCC064.3070502@redhat.com \
--to=jsnow@redhat.com \
--cc=afaerber@suse.de \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).