Documentation/CodingGuidelines: spell out more shell guidelines
In earlier days, "imitate the style in the neibouring code" was sufficient to keep the coherent style, but over time some parts of the codebase have drifted enough to make it ineffective. Spell some of the guidelines out. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Heiko Voigt committed
Aug 15, 2012 at 19:06 UTC
03b05c7db5473329f433c5a3b87965d6fa0f691f
1 file changed
+8
Documentation/CodingGuidelines
+8
@@ -76,11 +76,19 @@ For shell scripts specifically (not exhaustive):
76
77
- We do not use Process Substitution <(list) or >(list).
78
79
+ - Do not write control structures on a single line with semicolon.
80
+ "then" should be on the next line for if statements, and "do"
81
+ should be on the next line for "while" and "for".
82
+
83
- We prefer "test" over "[ ... ]".
84
85
- We do not write the noiseword "function" in front of shell
86
functions.
87
88
+ - We prefer a space between the function name and the parentheses. The
89
+ opening "{" should also be on the same line.
90
+ E.g.: my_function () {
91
+
92
- As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
93
[::], [==], nor [..]) for portability.
94