judgement call, the decision based more on real world
constraints people face than what the paper standard says.
+ - Fixing style violations while working on a real change as a
+ preparatory clean-up step is good, but otherwise avoid useless code
+ churn for the sake of conforming to the style.
+
+ "Once it _is_ in the tree, it's not really worth the patch noise to
+ go and fix it up."
+ Cf. http://article.gmane.org/gmane.linux.kernel/943020
+
Make your code readable and sensible, and don't try to be clever.
As for more concrete guidelines, just imitate the existing code
- We use tabs for indentation.
- - Case arms are indented at the same depth as case and esac lines.
+ - Case arms are indented at the same depth as case and esac lines,
+ like this:
+
+ case "$variable" in
+ pattern1)
+ do this
+ ;;
+ pattern2)
+ do that
+ ;;
+ esac
- Redirection operators should be written with space before, but no
space after them. In other words, write 'echo test >"$file"'
redirection target in a variable (as shown above), our code does so
because some versions of bash issue a warning without the quotes.
+ (incorrect)
+ cat hello > world < universe
+ echo hello >$world
+
+ (correct)
+ cat hello >world <universe
+ echo hello >"$world"
+
- We prefer $( ... ) for command substitution; unlike ``, it
properly nests. It should have been the way Bourne spelled
it from day one, but unfortunately isn't.
"then" should be on the next line for if statements, and "do"
should be on the next line for "while" and "for".
+ (incorrect)
+ if test -f hello; then
+ do this
+ fi
+
+ (correct)
+ if test -f hello
+ then
+ do this
+ fi
+
- 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 () {
+ - We prefer a space between the function name and the parentheses,
+ and no space inside the parentheses. The opening "{" should also
+ be on the same line.
+
+ (incorrect)
+ my_function(){
+ ...
+
+ (correct)
+ my_function () {
+ ...
- As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
- [::], [==], nor [..]) for portability.
+ [::], [==], or [..]) for portability.
- We do not use \{m,n\};
- We do not use -E;
- - We do not use ? nor + (which are \{0,1\} and \{1,\}
+ - We do not use ? or + (which are \{0,1\} and \{1,\}
respectively in BRE) but that goes without saying as these
are ERE elements not BRE (note that \? and \+ are not even part
of BRE -- making them accessible from BRE is a GNU extension).
"char * string". This makes it easier to understand code
like "char *string, c;".
+ - Use whitespace around operators and keywords, but not inside
+ parentheses and not around functions. So:
+
+ while (condition)
+ func(bar + 1);
+
+ and not:
+
+ while( condition )
+ func (bar+1);
+
- We avoid using braces unnecessarily. I.e.
if (bla) {
of "else if" statements, it can make sense to add braces to
single line blocks.
- - We try to avoid assignments inside if().
+ - We try to avoid assignments in the condition of an "if" statement.
- Try to make your code understandable. You may put comments
in, but comments invariably tend to stale out when the code
* multi-line comment.
*/
+ Note however that a comment that explains a translatable string to
+ translators uses a convention of starting with a magic token
+ "TRANSLATORS: " immediately after the opening delimiter, even when
+ it spans multiple lines. We do not add an asterisk at the beginning
+ of each line, either. E.g.
+
+ /* TRANSLATORS: here is a comment that explains the string
+ to be translated, that follows immediately after it */
+ _("Here is a translatable string explained by the above.");
+
- Double negation is often harder to understand than no negation
at all.