All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 7/8] CodingGuidelines: on comparison
Date: Fri, 02 May 2014 11:18:34 -0700	[thread overview]
Message-ID: <xmqqk3a4avt1.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140501213657.GC14441@sigill.intra.peff.net> (Jeff King's message of "Thu, 1 May 2014 17:36:57 -0400")

Jeff King <peff@peff.net> writes:

> On Wed, Apr 30, 2014 at 02:45:11PM -0700, Junio C Hamano wrote:
>
>> See http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126
>> 
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Don't you often complain about submitters referencing a discussion
> in a commit message without providing some context or summary?

Yes, but the summary of the discussion would be identical to the new
text added by the patch to the documentation tree in this case, so I
didn't find a good introductory text before "See $URL".  Perhaps

    This comes up from time to time.  See $URL for the original
    discussion.

but I do not know if that is much better.

>> + - There are two schools of thought when it comes to comparison,
>> +   especially inside a loop. Some people prefer to have less stable
>> +   value on the left hand side and more stable value on the right hand
>> +   side, e.g. if you have a loop that counts variable i down to the
>> +   lower bound,
>
> Grammar: /(less|more) stable/the &/
>
>> +   Both are valid, and we use both, even though we tend to see the
>> +   former the more preferable, the more "stable" the more stable side
>> +   becomes (comparison with a constant, "i > 0", is an extreme
>> +   example).  Just do not mix styles in the same part of the code.
>> +
>
> I had trouble parsing the first sentence. Maybe:
>
>   Both are valid, and we use both. However, the more "stable" the stable
>   side becomes, the more we tend to prefer the former (comparison with a
>   constant[...]

Thanks.  That is much better.

  reply	other threads:[~2014-05-02 18:18 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-30 21:45 [PATCH 0/8] Update the CodingGuidelines Junio C Hamano
2014-04-30 21:45 ` [PATCH 1/8] CodingGuidelines: typofix Junio C Hamano
2014-05-01 14:09   ` David Kastrup
2014-05-01 17:51     ` Junio C Hamano
2014-05-01 21:27       ` Jeff King
2014-05-02 18:31         ` Junio C Hamano
2014-05-02 20:33           ` Jeff King
2014-05-02 20:37             ` Felipe Contreras
2014-05-02 20:53               ` David Kastrup
2014-04-30 21:45 ` [PATCH 2/8] CodingGuidelines: give an example for case/esac statement Junio C Hamano
2014-04-30 21:45 ` [PATCH 3/8] CodingGuidelines: give an example for redirection Junio C Hamano
2014-04-30 22:14   ` [PATCH v2 " Junio C Hamano
2014-04-30 21:45 ` [PATCH 4/8] CodingGuidelines: give an example for control statements Junio C Hamano
2014-04-30 21:54   ` Stefan Beller
2014-04-30 22:03     ` Junio C Hamano
2014-05-01 14:12   ` David Kastrup
2014-05-01 18:00     ` Junio C Hamano
2014-04-30 21:45 ` [PATCH 5/8] CodingGuidelines: give an example for shell function preamble Junio C Hamano
2014-04-30 21:45 ` [PATCH 6/8] CodingGuidelines: call the conditional statement "if ()", not "if()" Junio C Hamano
2014-05-01 14:14   ` David Kastrup
2014-05-01 18:11     ` Junio C Hamano
2014-05-01 18:36       ` David Kastrup
2014-04-30 21:45 ` [PATCH 7/8] CodingGuidelines: on comparison Junio C Hamano
2014-05-01 21:36   ` Jeff King
2014-05-02 18:18     ` Junio C Hamano [this message]
2014-05-02 20:31       ` Jeff King
2014-05-02 20:45         ` Junio C Hamano
2014-04-30 21:45 ` [PATCH 8/8] CodingGuidelines: once it is in, it is not worth the code churn Junio C Hamano
2014-05-02 20:51 ` [PATCH 9/8] CodingGuidelines: on splitting a long line Junio C Hamano
2014-05-02 21:00   ` brian m. carlson

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=xmqqk3a4avt1.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.