Heiko Voigt <hvo...@hvoigt.net> writes:
> During discussion of other patches these preferences have been revealed.
> Lets add them to the guidelines.
>
> Signed-off-by: Heiko Voigt <hvo...@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
> - 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.
>
> @@ -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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
