Re: [PATCH] Document bash style we prefer for if and functions
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 14, 2012, 21:09 UTC
- Message-ID
- <7vipcl89kg.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120814203931.GB33843@book.hvoigt.net>
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
...
donenot
if test ...; then
...
else ...;
fiwhile 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