ヒトリ歩き

愚痴とかいろいろ書きます

シェルスクリプトのコーディングスタイルを統一しよう

ShellScript StyleGuide 品質 保守

プロジェクト内でコーディングルールは決まってますか？
Javaだとcheckstyle、PythonだとpyLintといったツールを使っていると思います。

では、シェルスクリプトではどうでしょうか？

シェルスクリプトは、Javaのcheckstyleのようなコーディングスタイルをチェックするツールはないため、各個人の力量任せになっているのではないでしょうか？
私が関わる業務でも、シェルスクリプトに関しては個人任せになっています。
個人任せだとコーディングの記述は、人によってバラバラですし、統一感もなく、保守性が低くなります。
シェルスクリプトもJavaのようにコーディングルールがあれば、コードの記述が統一することができ、保守性も向上します。
ですが、シェルスクリプトのコーディングルールを１から決めるとなると、工数がかかります。

というわけで。

そんな時は、Shell Style Guideを活用しましょう！！

google.github.io

Shell Style Guide とは

Googleで使用されているShellScriptのコードスタイルガイドです。
シェルスクリプト以外にも、Java、C++、Pythonといったメジャーな言語のスタイルガイドがあります。

google.github.io

実際にスタイルガイドを使ってみたら、コードが見やすくなった

スタイルガイドに書かれている内容を意識してコーディングしてみたところ、シェルスクリプトが以前より見やすくなりました。

特に良かったと思うスタイルを紹介します。

1行の最大文字数を80文字にする

長いコマンドラインを80文字以内にすることで、可読性が向上します。
長々とコマンドが書かれていると読みにくいですよね。

パイプラインが1行に収まらない時は、1行ずつにする。

パイプラインが長く続くと見るのも大変ですが、パイプラインを1行に1つずつにするだけで、見た目がスッキリします。
この記述に変えた時は、行継続文字(¥文字)を書くのを忘れてよくエラーになってました。

# this is not
command1 | command2 | command3 | command4 | command5

# this is preferred
command1 ¥
  | command2 ¥
  | command3 ¥
  | command4 ¥
  | command5

while、forと同じ行に ; do を記述する。 ; then も同じく。

; do や ; then のためだけに改行せずに、1行にまとめて書いた方が分かりやすいです。
次の行にTrueの処理があるので可読性がよくなります。

# this is not
if [[ -z $x ]]
then
  echo "OK"
fi

# this is preferred
if [[ -z $x ]] ; then
  echo "OK"
fi

local変数を使用する。

関数内で使用する変数を、local変数とすることで誤って、グローバル変数に値を設定することを防ぐことができます。
また、コードを読む際にも、関数内に閉じた変数であることがすぐに分かります。
この変数ってグローバル変数だったっけ？というのを防げます。

# this is not
function getname() {

    name="echo $1"

}

# this is preferred
function getname() {

    local name
    name="echo $1"

}

スタイルがあった方が、可読性だけでなく、保守性も向上する。

コードスタイルを統一することで、可読性が向上するだけでなく、保守者も保守しやすくなります。
維持管理の経験がありますが、個人任せのシェルスクリプトを見ていた時は嫌気がしていました。
コードスタイルが統一されているだけで、維持管理はしやすいです。

シェルスクリプトのコードスタイルがないプロジェクトは、Shell Style Guide でコーディングルールを統一しましょう。
そして、これからもShell Style Guideを活用して、シェルスクリプトの品質を高めていきたいと思います。