public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [RFC] Change coding style rule: 80 column "hard limit" for ChangeLogs
Date: Wed, 08 Jan 2014 20:21:00 -0000	[thread overview]
Message-ID: <CADPb22R2ES=5S6sqUwfaRHcmCJCa5ssLWqgV3ZBaf1yUkJtA0g@mail.gmail.com> (raw)
In-Reply-To: <20140108114544.GN3802@adacore.com>

On Wed, Jan 8, 2014 at 3:45 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> That would not achieve the goal of one limit only,
>> unless ChangeLogs have a hard limit of 80, and 74 is the soft limit.
>>
>> [I'm treating "hard" as "do not violate unless there's a compelling reason",
>> and "soft" as a guideline. btw, I can no longer think of that word without also
>> thinking of Pirates of the Caribbean. :-)]
>>
>> > Other than the opinion above, it's not really all that important to me.
>> > So I'm good with whatever reasonable limit the group decides. We just
>> > need to make sure we document the decision, with reference to the
>> > discussion.
>>
>> I'm not overly fond of anything below 80 (well, 79, but I certainly
>> don't reject patches that use 80).
>
> I'm really easy, so I don't mind your proposal.
>
> Just for the record, to me, "soft" means "stay within the limit unless
> you have a reasonable reason to exceed", while "hard" means "do not
> exceed unless you just cannot do otherwise". As you can see, slightly
> stronger barriers. But I know also that it's really nitpicking, so
> I tend to worry too much about soft violations when reviewing patches,
> making that soft barrier a little softer :-). But I pay attention to
> that limit myself when modifying the code.

So how about a 74 soft limit and 80 hard limit for everything (modulo
things like .exp files where we try to keep things under 80 but  some
lines are just long and best left as is).

soft = "stay within the limit unless you have a reasonable reason to
exceed, and we're not nitpicky on what reasonable is"

hard = "do not exceed unless you just cannot do otherwise, and while
there are exceptions, we are quite nitpicky on this one"

Even that wording doesn't preclude different interpretations.  I'm
happy to tweak it.  The high order bits for me are the same numbers
for everything, and not being nitpicky on adherence to the soft limit.

If there are no objections, I will tweak your coding style cheat sheet
wiki (just trying to save you the trouble, it's your page, feel free
to edit as desired), and update other docs (the CodingStandards wiki
doesn't exist, I'll create it and add something to get it going).

  reply	other threads:[~2014-01-08 20:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-03 22:50 Doug Evans
2014-01-04  7:22 ` Eli Zaretskii
2014-01-05  4:00   ` Joel Brobecker
2014-01-06 17:56     ` Doug Evans
2014-01-08 11:45       ` Joel Brobecker
2014-01-08 20:21         ` Doug Evans [this message]
2014-01-08 21:42           ` Sergio Durigan Junior
2014-01-09  2:34           ` Joel Brobecker

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='CADPb22R2ES=5S6sqUwfaRHcmCJCa5ssLWqgV3ZBaf1yUkJtA0g@mail.gmail.com' \
    --to=dje@google.com \
    --cc=brobecker@adacore.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).