threads / patch / 31253

patchDocument bash style we prefer for if and functions

Subject: [PATCH] Document bash style we prefer for if and functions

## tl;dr

4 messages between Aug 14, 2012 and Aug 15, 2012. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Heiko Voigt· Aug 14, 2012, 20:39 UTC · lore

During discussion of other patches these preferences have been revealed. Lets add them to the guidelines.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
 Documentation/CodingGuidelines | 6 ++++++
 1 file changed, 6 insertions(+)

Show changes to Documentation/CodingGuidelines +6 −0

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 4557711..0a07990 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -76,11 +76,16 @@ For shell scripts specifically (not exhaustive):
 
  - We do not use Process Substitution <(list) or >(list).
 
+ - We prefer "then" on the next line for if statements.
+
  - We prefer "test" over "[ ... ]".
 
  - We do not write the noiseword "function" in front of shell
    functions.
 
+ - We prefer a space between the function name and the parentheses.
+   E.g.: my_function ()
+
  - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
    [::], [==], nor [..]) for portability.
 
@@ -97,6 +102,7 @@ For shell scripts specifically (not exhaustive):
    interface translatable. See "Marking strings for translation" in
    po/README.
 
+
 For C programs:
 
  - We use tabs to indent, and interpret tabs as taking up to

-- 
1.7.12.rc2.11.g5d52328

Junio C Hamano· Aug 14, 2012, 21:09 UTC · re: Heiko Voigt · lore

Re: [PATCH] Document bash style we prefer for if and functions

Heiko Voigt <hvoigt@hvoigt.net> writes:

Show 18 quoted lines

> During discussion of other patches these preferences have been revealed.
> Lets add them to the guidelines.
>
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> ---
>  Documentation/CodingGuidelines | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 4557711..0a07990 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -76,11 +76,16 @@ For shell scripts specifically (not exhaustive):
>  
>   - We do not use Process Substitution <(list) or >(list).
>  
> + - We prefer "then" on the next line for if statements.
> +

This is not limited to "if". An easy rule of thumb is to write the control structure _without_ using semicolon.

That is:

	if test ...
        then
            ...
	else
	    ...
	fi

	while test ...
        do
        	...
	done

not

	if test ...; then
            ...
	else ...;
        fi

        while test ...; do
	    ...
	done

Show 8 quoted lines

>   - We prefer "test" over "[ ... ]".
>  
>   - We do not write the noiseword "function" in front of shell
>     functions.
>  
> + - We prefer a space between the function name and the parentheses.
> +   E.g.: my_function ()
> +

Also opening "{" on the same line, i.e.

	myfunc () {

>   - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
>     [::], [==], nor [..]) for portability.
>

Show 6 quoted lines

> @@ -97,6 +102,7 @@ For shell scripts specifically (not exhaustive):
>     interface translatable. See "Marking strings for translation" in
>     po/README.
>  
> +
>  For C programs:

Probably not needed, as there is no such double space between C and Documentation sections.

>  
>   - We use tabs to indent, and interpret tabs as taking up to

Heiko Voigt· Aug 15, 2012, 17:06 UTC · re: Junio C Hamano · lore

[PATCH v2] add some bash style we prefer

During discussion of other patches these preferences have been revealed. Lets add them to the guidelines.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
Here an updated version of the patch.

On Tue, Aug 14, 2012 at 02:09:35PM -0700, Junio C Hamano wrote:

Show 10 quoted lines

> Heiko Voigt <hvoigt@hvoigt.net> writes:
> > @@ -97,6 +102,7 @@ For shell scripts specifically (not exhaustive):
> >     interface translatable. See "Marking strings for translation" in
> >     po/README.
> >  
> > +
> >  For C programs:
> 
> Probably not needed, as there is no such double space between C
> and Documentation sections.

Sorry about that whitespace noise.

Cheers Heiko

 Documentation/CodingGuidelines | 8 ++++++++
 1 file changed, 8 insertions(+)

Show changes to Documentation/CodingGuidelines +8 −0

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 4557711..e70d110 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -76,11 +76,19 @@ For shell scripts specifically (not exhaustive):
 
  - We do not use Process Substitution <(list) or >(list).
 
+ - We prefer writing all control structures without semicolon on the
+   same line. E.g. "then" should be on the next line for if statements.
+   The same applies to while, for, ...
+
  - We prefer "test" over "[ ... ]".
 
  - We do not write the noiseword "function" in front of shell
    functions.
 
+ - We prefer a space between the function name and the parentheses. The
+   opening "{" should also be on the same line.
+   E.g.: my_function () {
+
  - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
    [::], [==], nor [..]) for portability.

-- 
1.7.12.rc2.11.g5d52328

Junio C Hamano· Aug 15, 2012, 17:55 UTC · re: Heiko Voigt · lore

Re: [PATCH v2] add some bash style we prefer

Heiko Voigt <hvoigt@hvoigt.net> writes:

Show 6 quoted lines

> During discussion of other patches these preferences have been revealed.
> Lets add them to the guidelines.
>
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> ---
> Here an updated version of the patch.

Thanks.

Show 43 quoted lines

>
> On Tue, Aug 14, 2012 at 02:09:35PM -0700, Junio C Hamano wrote:
>> Heiko Voigt <hvoigt@hvoigt.net> writes:
>> > @@ -97,6 +102,7 @@ For shell scripts specifically (not exhaustive):
>> >     interface translatable. See "Marking strings for translation" in
>> >     po/README.
>> >  
>> > +
>> >  For C programs:
>> 
>> Probably not needed, as there is no such double space between C
>> and Documentation sections.
>
> Sorry about that whitespace noise.
>
> Cheers Heiko
>
>  Documentation/CodingGuidelines | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 4557711..e70d110 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -76,11 +76,19 @@ For shell scripts specifically (not exhaustive):
>  
>   - We do not use Process Substitution <(list) or >(list).
>  
> + - We prefer writing all control structures without semicolon on the
> +   same line. E.g. "then" should be on the next line for if statements.
> +   The same applies to while, for, ...
> +
>   - We prefer "test" over "[ ... ]".
>  
>   - We do not write the noiseword "function" in front of shell
>     functions.
>  
> + - We prefer a space between the function name and the parentheses. The
> +   opening "{" should also be on the same line.
> +   E.g.: my_function () {
> +
>   - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
>     [::], [==], nor [..]) for portability.