726

15. コーディングスタイル

727

この章では Live システムで利用されているコーディングスタイルについて述べます。

728

15.1 互換性

729

• Avoid "bashisms", the codebase must be POSIX compliant and thus universally compatible.

730

• Furthermore it must comply with the version of the POSIX specification chosen by the current Debian Policy.

731

• 'sh -n' と 'checkbashisms' によりスクリプトをチェックできます。

732

• シェルコードが全て確実に 'set -e' で動作するようにしてください。

733

15.2 インデント

734

• 常にスペースよりもタブを使います。

735

• Keep case branch terminators (";;") aligned with the "content" of the branch, rather than the branch "entry".

736

良い例:

737

case "${1}" in
         foo)
                 foobar
                 ;;

         bar)
                 foobar
                 ;;
esac

738

15.3 改行

739

• Generally, lines should be 80 chars at maximum.

740

• Placement of keywords like then and do should be chosen with good judgement with respect to clutter and readability. For small bits of code in particular it should be preferred to have them on the same line as the prior keyword they relate to (if; for; etc). Only place on the next line where it makes good sense to do so; typically this might only be to comply with maximum line length restrictions. One situation where they should always be placed on the next line is where what they follow is broken up onto multiple lines, and thus it being on a new line creates clear separation between that and the body of code following it. I.e. :

741

Preferred:

742

if foo; then
         bar
fi

for FOO in $ITEMS; do
         bar
done

if [ "${MY_LOCATION_VARIABLE}" = "something" ] && [ -e "${MY_OUTPUT_FILE}" ]
then
         MY_OTHER_VARIABLE="$(some_bin ${FOOBAR} | awk -F_ '{ print $1 }')"
fi

if [ "${MY_FOO}" = "something" ] && [ -e "path/${FILE_1}" ] ||
   [ "${MY_BAR}" = "something_else" ] && [ ${ALLOW} = "true" ]
then
         foobar
fi

743

Less ideal:

744

if [ "${MY_LOCATION_VARIABLE}" = "something" ] && [ -e "${MY_OUTPUT_FILE}" ]; then
         MY_OTHER_VARIABLE="$(some_bin ${FOOBAR} | awk -F_ '{ print $1 }')"
fi

745

Horrible:

746

if [ "${MY_LOCATION_VARIABLE}" = "something" ] && [ -e "${MY_OUTPUT_FILE}" ] || [ "${MY_LOCATION_VARIABLE}" = "something-else" ] && [ -e "${MY_OUTPUT_FILE_2}" ]; then
         MY_OTHER_VARIABLE="$(some_bin ${FOOBAR} | awk -F_ '{ print $1 }')"
fi

747

• Prefer placing the opening brace of a function on a new line (for consistency with established style), and keep the braces aligned with the function name:

748

良い例:

749

Foo ()
{
         bar
}

750

Bad (inconsistent with existing style):

751

Foo () {
         bar
}

752

Awful:

753

Foo ()
         {
         bar
         }

754

15.4 変数

755

• 変数は常に大文字です。

756

• Config variables used in live-build should start with an LB_ prefix.

757

• Local function variables should be restricted to local scope.

758

• live-config 中のブートパラメータにつながる変数は LIVE_ で始めます。

759

• live-config 中の他の変数は全て _ で始めます。

760

• 変数は大括弧「{}」で囲みます。例えば $FOO ではなく ${FOO} とします。

761

• Always protect variables with quotes to respect potential whitespaces (except where necessary to achieve correct word splitting): write "${FOO}" not ${FOO}.

762

• 一貫性を保つため、変数に値を割り当てるときは常に引用符を使います:

763

悪い例:

764

FOO=bar

765

良い例:

766

FOO="bar"

767

• If multiple variables are used, prefer quoting the full expression:

768

Typically bad:

769

if [ -f "${FOO}"/foo/"${BAR}"/bar ]; then
         foobar
fi

770

良い例:

771

if [ -f "${FOO}/foo/${BAR}/bar" ]; then
         foobar
fi

772

15.5 その他

773

• Prefer "|" (without the surround quotes) as a separator in calls to sed, e.g. "sed -e 's|foo|bar|'" (without "").

774

• Don't use the test command for comparisons or tests, use "[" and "]" (without ""); e.g. "if [ -x /bin/foo ]; ..." and not "if test -x /bin/foo; ...".

775

• Use case wherever it makes code more readable than conditional checks (if foo; ... and tests without the actual if keyword, e.g. [ -e "${FILE}" ] || exit 0).

776

• Use "Foo_bar" style names for functions, i.e. a capital first letter, then all lowercase, with sensible use of underscores for better readability.