ぞうのお勉強日記 bashスクリプト入門　その7

bashスクリプト入門　その7

bashスクリプト　入門編第7回目です。
問題点は解消されましたね。次はスクリプトの見栄えの問題です。

無料アクセス解析

前回の修正で、スクリプトは想定通り動作する様になり、「完成した」と言っても良いと思います。
ですが、「動作すれば良い」というものではありません。
今回は「メンテナンス性」と「可読性」と「拡張性」について考えてみたいと思います。

bashスクリプトは言うまでも無く、作業を楽にする為に書く物です。
一度書いた物をメンテナンス・拡張し、末永く使ってこそ、本当の楽が出来るという物です。
その為には、後々にそのスクリプトを見た時、処理内容が簡単に理解でき、拡張しやすい構造である事が重要です。
その為には最初に作成した段階で、その様な構造で作成してやる必要があります。
まず、メンテナンス性・可読性について考えましょう。

前回作成したスクリプトをもう一度見てみましょう。

#!/bin/bash 
V_OPTION=$1

if test "${V_OPTION}" = "bash"
then
    echo "Hello bash World!!"
elif test "${V_OPTION}" = "Linux"
then
    echo "Hello Linux OS!!"
else
    echo "Hello World!!"
fi

まず「test」文について考えて見ます。
「test」文は、今回のスクリプトの様な書き方もできますが、他の書き方もできます。
むしろ、今回の書き方は本流から逸れている様で、最近では余りこういう書き方をする人はいません。
理由は「可読性に優れていない」からです。一目見てどこからどこまでが条件式なのかが判り難いからです。
では、「test」文はどの様に書くのかというと、「[」と「]」で条件式を括る事で「test」文と同じ意味を持たせる事ができます。
実際は「test」というコマンドは「[」と同じ意味を持っていて、この「[」1文字で「test」コマンドとして扱われます。
試しに、「[」コマンドを探してみると、以下の様に存在する事が判ります。

[root@xen01 ~]# which [
/usr/bin/[
[root@xen01 ~]# ls -l /usr/bin/[
-rwxr-xr-x 1 root root 31080  5月 25 00:19 /usr/bin/[
[root@xen01 ~]#

※ちなみに、「]」というコマンドは存在しません。「]」はおまけ、と言うか、「[」文の終了として扱われているだけです。が、無いとエラーとなります。構文の一部と考えましょう。
では、「test」文を以下の様に書き換えて見ましょう。

#!/bin/bash 
V_OPTION=$1

if [ "${V_OPTION}" = "bash" ]
then
    echo "Hello bash World!!"
elif [ "${V_OPTION}" = "Linux" ]
then
    echo "Hello Linux OS!!"
else
    echo "Hello World!!"
fi

書き換える際、注意しなければならないのは、「[」の前後と「]」の前には必ず「スペース」が必要だと言うことです。
「[」はコマンドですので、当然と言えば当然なのですが、カッコの一部と考えてスクリプトを書いていると、
案外と忘れがちです。かならずスペースを空ける様にしましょう。

次はメンテナンス性について考えてみます。
このスクリプト、コメントが1行も存在しません。
処理内容が単純なので、慣れてくれば一目見て何をやっているスクリプトか判ると思いますが、
それでも、変数への値代入部分、条件判定のブロック毎ぐらいはコメントで処理を説明した方が良いでしょう。
私はこんなコメントを付けてみました。

#!/bin/bash 
## 変数初期化
V_OPTION=$1     ## 第一引数を代入

## 引数判定
## 第一引数がbashの場合、「Hello bash World!!」を出力
## 第一引数がLinuxの場合、「Hello Linux OS!!」を出力
## 第一引数が上記以外の場合、「Hello World!!」を出力

if [ "${V_OPTION}" = "bash" ]
then
    echo "Hello bash World!!"
elif [ "${V_OPTION}" = "Linux" ]
then
    echo "Hello Linux OS!!"
else
    echo "Hello World!!"
fi

業務でスクリプトを書いたりした場合、自分以外の人間がメンテナンスをする事が多かったりもしますので、
ある程度の処理概要が判る程度のコメントをつけた方が良いと思います。
自分だけしか使わないスクリプトであれば、そこまで細かい説明はいらないでしょう。
コメントをつける際のポイントですが、見易さを考えると、処理行毎にコメントを振る様な
やり方は好ましくありません。かなりゴチャゴチャして可読性が著しく落ちます。
処理ブロック毎に大まかな説明を書く感じにしましょう。

あとは、スクリプトのヘッダ部分に、そのスクリプトの情報を書いた方が良いでしょう。
一般的に書かれるのは、「スクリプトの処理概要」「作成日」「作成者」「バージョン」と言った所でしょうか。
大規模なスクリプトになると、「変更履歴」まで書かれている物があります。
「変更履歴」を書く事自体は否定しませんが、スクリプトソースに履歴を書いていくと、変更が多い場合膨大な履歴が書かれる事になります。
変更履歴は、別の方法で管理した方が良いでしょう。

次は「拡張性」についてです。
例えば、このスクリプトの場合、引数によって出力内容を変えていますが、
想定される引数の種類が増えた場合、どうなるでしょうか？
同じ様な「elif」文を書き連ねるのでしょうか？

本来、「第一引数」に入る値によって処理を変える、といった、「一対多」の判定の場合、
「if」文を使うのは好ましくありません。
理由はいくつかありますが、主に以下になります。
・可読性が落ちる
・処理速度が落ちる

可読性が落ちるのは、一つの判定に対して、同じ様な「elif」を書く割に、
条件文まで読まないと何を判定しているのかが明確に判らない為です。

処理速度は、2,3個ぐらいの判定では大差ありませんが、10個ぐらいになると、
顕著に違ってくる場合もあります。
「if」文の場合、目的の判定文まで、その他の判定をしないと辿り着けないからです。

その為、この様な「一対多」の判定の場合、「case」文を使用します。
「case」文は、一つの判定文で、複数の結果がある場合を想定した作りになっている為、
可読性に優れ、また、1回の判定で済む為、処理速度は「if」文を使用するよりも高速です。

次回は「case」文で、このスクリプトを実装しなおしてみましょう。