All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH 9/8] CodingGuidelines: on splitting a long line
Date: Fri, 02 May 2014 13:51:55 -0700	[thread overview]
Message-ID: <xmqqiopnaopg.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1398894312-30763-1-git-send-email-gitster@pobox.com> (Junio C. Hamano's message of "Wed, 30 Apr 2014 14:45:04 -0700")


Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/CodingGuidelines | 55 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 02ca67c..4dd07c3 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -249,6 +249,61 @@ For C programs:
    Just do not mix styles in the same part of the code and mimic
    existing styles in the neighbourhood.
 
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferrable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferrable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
  - Some clever tricks, like using the !! operator with arithmetic
    constructs, can be extremely confusing to others.  Avoid them,
    unless there is a compelling reason to use them.
-- 
2.0.0-rc1-355-gd6d6511

  parent reply	other threads:[~2014-05-02 20:52 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
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 ` Junio C Hamano [this message]
2014-05-02 21:00   ` [PATCH 9/8] CodingGuidelines: on splitting a long line 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=xmqqiopnaopg.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.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 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.