Hi,
I suggest that the coding style should state that if either branch of
an 'if' statement needs braces, both branches should use them.
Regards
Oliver
Signed-off-by: Oliver Neukum <[email protected]>
----
--- a/Documentation/CodingStyle 2007-04-20 13:08:17.000000000 +0200
+++ b/Documentation/CodingStyle 2007-04-20 13:16:14.000000000 +0200
@@ -160,6 +160,21 @@
25-line terminal screens here), you have more empty lines to put
comments on.
+Do not unnecessarily use braces where a single statement will do.
+
+if (condition)
+ action();
+
+This does not apply if one branch of a conditional statement is a single
+statement. Use braces in both branches.
+
+if (condition) {
+ do_this();
+ do_that();
+} else {
+ otherwise();
+}
+
3.1: Spaces
Linux kernel style for use of spaces depends (mostly) on
Oliver Neukum napsal(a):
> Hi,
>
> I suggest that the coding style should state that if either branch of
> an 'if' statement needs braces, both branches should use them.
>
> Regards
> Oliver
> Signed-off-by: Oliver Neukum <[email protected]>
> ----
>
> --- a/Documentation/CodingStyle 2007-04-20 13:08:17.000000000 +0200
> +++ b/Documentation/CodingStyle 2007-04-20 13:16:14.000000000 +0200
> @@ -160,6 +160,21 @@
> 25-line terminal screens here), you have more empty lines to put
> comments on.
>
> +Do not unnecessarily use braces where a single statement will do.
> +
> +if (condition)
> + action();
> +
> +This does not apply if one branch of a conditional statement is a single
> +statement. Use braces in both branches.
Why, what's wrong with
if (condition) {
do_this();
do_that();
} else
otherwise();
? It's more readable/nicer in my eyes than
> +if (condition) {
> + do_this();
> + do_that();
> +} else {
> + otherwise();
> +}
> +
and not only in mine according to fast grep.
regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
Am Freitag, 4. Mai 2007 16:48 schrieb Jiri Slaby:
> Why, what's wrong with
> if (condition) {
> ????????do_this();
> ????????do_that();
> } else
> ????????otherwise();
>
> ? It's more readable/nicer in my eyes than
Than I am afraid we need to agree to disagree. But then I would
insist that neither side give the other a hard to time over this issue.
Regards
Oliver
Jiri Slaby <[email protected]> writes:
> Why, what's wrong with
> if (condition) {
> do_this();
> do_that();
> } else
> otherwise();
>
> ? It's more readable/nicer in my eyes than
I think so. And it means less lines #.
>> +if (condition) {
>> + do_this();
>> + do_that();
>> +} else {
>> + otherwise();
>> +}
Exception:
if (x) {
if (y)
foo1();
else
foo2();
} else
bar();
The braces after if(x) are needed so nobody thinks it's:
if (x)
if (y)
foo1();
else
foo2();
else
bar();
--
Krzysztof Halasa
Oliver Neukum napsal(a):
> Am Freitag, 4. Mai 2007 16:48 schrieb Jiri Slaby:
>> Why, what's wrong with
>> if (condition) {
>> do_this();
>> do_that();
>> } else
>> otherwise();
>>
>> ? It's more readable/nicer in my eyes than
>
> Than I am afraid we need to agree to disagree. But then I would
> insist that neither side give the other a hard to time over this issue.
Then I would just let it undefined to let subsys maintainers (or coders
themselves) to decide what they want in their subtree like ton of other things...
regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
On May 4 2007 16:48, Jiri Slaby wrote:
>>
>> +Do not unnecessarily use braces where a single statement will do.
>> +
>> +if (condition)
>> + action();
>> +
>> +This does not apply if one branch of a conditional statement is a single
>> +statement. Use braces in both branches.
>
>Why, what's wrong with
>if (condition) {
> do_this();
> do_that();
>} else
> otherwise();
>
>? It's more readable/nicer in my eyes.
I'll just point to an opinion:
http://lkml.org/lkml/2006/9/5/36 , lower half. ("Secondly, whenever...")
Jan
--