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"'
* 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.