git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 9/8] CodingGuidelines: on splitting a long line

From
Junio C Hamano <gitster@pobox.com>
Date
May 2, 2014, 20:51 UTC
Message-ID
<xmqqiopnaopg.fsf@gitster.dls.corp.google.com>
In-Reply-To
<1398894312-30763-1-git-send-email-gitster@pobox.com>
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
Previous: Junio C HamanoNext: brian m. carlson
Message 29 of 30 in “Update the CodingGuidelines”
  1. 0/8 Update the CodingGuidelinesJunio C Hamano, Apr 30, 2014
  2. 1/8 CodingGuidelines: typofixJunio C Hamano, Apr 30, 2014
  3. David KastrupMay 1, 2014
  4. Junio C HamanoMay 1, 2014
  5. Jeff KingMay 1, 2014
  6. Junio C HamanoMay 2, 2014
  7. Jeff KingMay 2, 2014
  8. Felipe ContrerasMay 2, 2014
  9. David KastrupMay 2, 2014
  10. 2/8 CodingGuidelines: give an example for case/esac statementJunio C Hamano, Apr 30, 2014
  11. 3/8 CodingGuidelines: give an example for redirectionJunio C Hamano, Apr 30, 2014
  12. 3/8 CodingGuidelines: give an example for redirectionJunio C Hamano, Apr 30, 2014
  13. 4/8 CodingGuidelines: give an example for control statementsJunio C Hamano, Apr 30, 2014
  14. Stefan BellerApr 30, 2014
  15. Junio C HamanoApr 30, 2014
  16. David KastrupMay 1, 2014
  17. Junio C HamanoMay 1, 2014
  18. 5/8 CodingGuidelines: give an example for shell function preambleJunio C Hamano, Apr 30, 2014
  19. 6/8 CodingGuidelines: call the conditional statement "if ()", not "if()"Junio C Hamano, Apr 30, 2014
  20. David KastrupMay 1, 2014
  21. Junio C HamanoMay 1, 2014
  22. David KastrupMay 1, 2014
  23. 7/8 CodingGuidelines: on comparisonJunio C Hamano, Apr 30, 2014
  24. Jeff KingMay 1, 2014
  25. Junio C HamanoMay 2, 2014
  26. Jeff KingMay 2, 2014
  27. Junio C HamanoMay 2, 2014
  28. 8/8 CodingGuidelines: once it is in, it is not worth the code churnJunio C Hamano, Apr 30, 2014
  29. 9/8 CodingGuidelines: on splitting a long lineJunio C Hamano, May 2, 2014
  30. brian m. carlsonMay 2, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.