bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5951: [PATCH] doc: document our code formatting policy regarding cur


From: Jim Meyering
Subject: bug#5951: [PATCH] doc: document our code formatting policy regarding curly braces
Date: Fri, 16 Apr 2010 08:30:12 +0200

...
> Thanks.  I removed those two lines and made this change below:
>
>   -It seems safe not to require curly braces in this case,
>   +It is safe not to require curly braces in code like this,
>    since the further-indented second body line makes it obvious
>    that this is still a single-statement body.

One more tweak:
(only the first hunk has a wording change.
The others are just re-flowed. )

>From 36cc6ac787d3c8f98c88cfe14c42fe27027b785b Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Fri, 16 Apr 2010 08:21:32 +0200
Subject: [PATCH] doc: tweak HACKING

* HACKING (Curly braces): Tweak a sentence.  Filter a few
paragraphs through "fmt".
---
 HACKING |   32 ++++++++++++++++----------------
 1 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/HACKING b/HACKING
index 18e9c54..a6589d3 100644
--- a/HACKING
+++ b/HACKING
@@ -263,16 +263,16 @@ Do this instead:
          single_line_stmt ();
        }

-There is one exception: when the second body line is not
-at the same indentation level as the first body line.
+There is one exception: when the second body line is not at the same
+indentation level as the first body line.

      if (expr)
        error (0, 0, _("a diagnostic that would make this line"
                       " extend past the 80-column limit"));

-It is safe not to require curly braces in code like this,
-since the further-indented second body line makes it obvious
-that this is still a single-statement body.
+It is safe to omit the braces in the code above, since the
+further-indented second body line makes it obvious that this is still
+a single-statement body.

 To reiterate, don't do this:

@@ -292,13 +292,13 @@ Do this, instead:
            }
        }

-However, there is one exception in the other direction, when
-even a one-line block should have braces.
-That occurs when that one-line, brace-less block
-is an "else" block, and the corresponding "then" block *does* use braces.
-In that case, either put braces around the "else" block, or negate the
-"if"-condition and swap the bodies, putting the one-line block first
-and making the longer, multi-line block be the "else" block.
+However, there is one exception in the other direction, when even a
+one-line block should have braces.  That occurs when that one-line,
+brace-less block is an "else" block, and the corresponding "then" block
+*does* use braces.  In that case, either put braces around the "else"
+block, or negate the "if"-condition and swap the bodies, putting the
+one-line block first and making the longer, multi-line block be the
+"else" block.

     if (expr)
       {
@@ -308,10 +308,10 @@ and making the longer, multi-line block be the "else" 
block.
     else
       x = y;    // BAD: braceless "else" with braced "then"

-This is preferred, especially when the multi-line body is more
-than a few lines long, because it is easier to read and grasp
-the semantics of an if-then-else block when the simpler block
-occurs first, rather than after the more involved block:
+This is preferred, especially when the multi-line body is more than a
+few lines long, because it is easier to read and grasp the semantics of
+an if-then-else block when the simpler block occurs first, rather than
+after the more involved block:

     if (!expr)
       x = y;                  /* more readable */
--
1.7.1.rc1.269.ga27c7






reply via email to

[Prev in Thread] Current Thread [Next in Thread]