Re: [PATCH] Document bash style we prefer for if and functions
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:54:29
Possibly related (same subject, not in this thread)
- 2016-06-15 · [PATCH] Document bash style we prefer for if and functions · Heiko Voigt <hidden>
Heiko Voigt [off-list ref] writes:
quoted hunk
During discussion of other patches these preferences have been revealed. Lets add them to the guidelines. Signed-off-by: Heiko Voigt <redacted> --- 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
- 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.
quoted hunk
@@ -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