[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shell variable references - coding style

From: Bruno Haible
Subject: Re: shell variable references - coding style
Date: Wed, 13 Mar 2019 20:04:40 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; )

Pavel Raiskup wrote:
> Is there a gnulib/GNU-preferred way to do this, defined somewhere?  I'd
> like to avoid such mistakes in future

There is no GNU-preferred style, nor a gnulib-preferred style. Just for the
gnulib-tool program there is a preferred style.

2019-03-13  Bruno Haible  <address@hidden>

        gnulib-tool: Clarify the coding style.
        Suggested by Pavel Raiskup <address@hidden>.
        * gnulib-tool: Add comment about coding style.

diff --git a/gnulib-tool b/gnulib-tool
index 34d198f..a41522b 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -19,6 +19,29 @@
 # This program is meant for authors or maintainers which want to import
 # modules from gnulib into their packages.
+# CODING STYLE for this file:
+# * Indentation: Indent by 2 spaces. Indent case clauses by 2 spaces as well.
+# * Shell variable references: Use double-quote around shell variable
+#   references always (except when word splitting is explicitly desired),
+#   even when you know the double-quote are not needed.  This style tends to
+#   avoid undesired word splitting caused by omitted double-quotes (the
+#   number one mistake in shell scripts).
+#   When the referenced variable can only have a finite number of possible
+#   values and these values are all simple words (e.g. true and false), it's
+#   OK to omit the double-quotes.
+# * Backquotes:
+#   - Use backquotes like in `command`, not $(command).
+#   - Don't use `command` inside double-quotes. Instead assign the result of
+#     `command` to a variable, and use the value of the variable afterwards.
+# * Functions:
+#   - All functions that don't emulate a program or shell built-in have a name
+#     that starts with 'func_'.
+#   - Document the implicit and explicit arguments of all functions, as well
+#     as their output variables and side effects.
+# * Use  test condition  instead of  [ condition ].
+# * Minimize the use of eval; when you need it, make sure the string to be
+#   evaluated has a very simple syntactic structure.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]