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

[PATCH 7/8] CodingGuidelines: on comparison

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 30, 2014, 21:45 UTC
Message-ID
<1398894312-30763-8-git-send-email-gitster@pobox.com>
In-Reply-To
<1398894312-30763-1-git-send-email-gitster@pobox.com>
See http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/CodingGuidelines | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 21e4272..86fb9f6 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -212,6 +212,32 @@ For C programs:
  - Double negation is often harder to understand than no negation
    at all.
 
+ - 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,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   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.
+
  - 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: David KastrupNext: Jeff King
Message 23 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.