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
next prev 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$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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