Perlなら「サンプルコードPerl入門」

2008-06-16

よいサブルーチンを作成するための心がけ

  1. Perl
  2. サブルーチン
  3. よりサブルーチンの作り方

 サブルーチン作成に関するわたしの考えを殴り書きしました。

見出し

  1. 引数と戻り値について理解する。
  2. 小さなサブルーチンを作成する。
  3. サブルーチンに柔軟性を持たせる。
  4. 呼び出しの階層を浅く保つ。
  5. 機能を実現するサブルーチンを作成する。
  6. ユーザーを意識する。
  7. 将来を楽にすることを考える。
  8. 完全な抽象化は求めない。

1. 引数と戻り値について理解する

 サブルーチンを理解するためには、引数の受け取り方と、戻り値の返却のし方を覚えれば十分です。なぜなら、引数を受け取ってから、戻り値を返却をするまでは、今まで学習したプログラミングとなんら変わることがないからです。引数と戻り値の扱いを、覚えたら、すぐに実践に移りましょう。

 サブルーチン作成で、難しいのは、以下の4点です。

  1. 何をサブルーチンにするか
  2. どのような名前をつけるか
  3. 引数を何にするか
  4. 戻り値を何にするか

 正しい書き方と呼べるサブルーチンは存在しないので、場面に応じて一生懸命考えながらつくる必要があります。

2. 小さなサブルーチンを作成する

 小さなサブルーチンは、30行程度までのサブルーチンです。大きなサブルーチンは、100行程度までのサブルーチンです。これを超えるならば、サブルーチンに関する考え方が、間違っています。複数の機能を詰め込みすぎの可能性があります。

 大きすぎるサブルーチンは、ひとつの機能を実現できていませんから、再利用が困難になります。処理をまとめただけの、意味のないサブルーチンになってしまいます。小さなサブルーチンを作るように心がけるほうが、うまくいきます。ひとつの機能を実現することを意識しながら、小さなサブルーチンを作るよう心がけます。

 ただし、大きすぎるサブルーチンが常に間違っているというわけではありません。そのサブルーチンを使う頻度が、ものすごく多いならば、そのサブルーチンには意味があります。それが、十分役立っているなら、再利用性や機能性を犠牲にしていても良い場合がときどきあります。ただし、やみくもに、大きなサブルーチンを作るのは避けましょう。それが、本当に意味があるかどうか、考えましょう。

3. サブルーチンに柔軟性を持たせる

 サブルーチンを柔軟なものにするには、引数にハッシュを用いて、オプションを指定できるようにします。たとえば、区切り文字を自由に指定できるだとか、出力に改行文字をつけるかどうかであるとか、そういう部分を、オプションで指定できます。引数の指定で、戻り値を変更できるということは、サブルーチンに柔軟性をもたせることになります。

 ただ、柔軟にしすぎると、サブルーチンを作成するのが大変です。そのオプションは、将来に役立つ可能性が高いかということを考えます。オプションを追加するということは、ロジックが複雑になり、試験するコストがかかるということです。そのコストに見合うだけの、将来の見返りの可能性を考えましょう。見返りがないときは、オプションにする必要はないわけです。

4. 呼び出しの階層を浅く保つ

 深すぎるサブルーチンは、作らないほうがよいです。サブルーチンから、サブルーチンを呼んで、またそのサブルーチンから別のサブルーチンを呼ぶと、可読性が著しく下がります。深い位置で呼んでもよいサブルーチンは、高度に汎用的で、再利用可能なサブルーチンだけにします。

 たしかにサブルーチンの呼び出し階層を深めれば、深めるほど、機能は抽象化されます。ただし、サブルーチン作成のコストがかかることを意識しましょう。抽象化は、良いことばかりではないです。管理するコストと可読性を下げるというマイナスの影響も大きいです。

 以下のような書き方は、推奨しません。なるべくfunc1の深さで、サブルーチンを実現します。必要があれば、func2の深さにしてもかまいません。が、func3の深さにならないようにします。func3が、プログラミングの中で、何回も使われ、再利用可能なサブルーチンである場合は、func3を作成しても良いかもしれません。

func1(); # func1 の呼び出し

sub func1{
  func2(); # func2 の呼び出し
}

sub func2{
  func3(); # func3 の呼び出し
}

sub func3{
  # 本当に汎用的で、再利用可能なサブルーチンだけは、深い階層で呼ばれてもよい。
}

5. 機能を実現するサブルーチンを作成する

 サブルーチンが、再利用可能であるということは、思ったほど多くはありません。実際にプログラミングをしてみればわかることですが、最初に作るプログラミングというのは、まず汎用性がありません。なぜなら、汎用的なことを目的にプログラミングしないからです。たとえば、特定のテキストファイルを処理して、そこから、特定の文字列を抜き出す場合は、再利用可能なサブルーチンを作れるはずがありません。あなた専用の特別なサブルーチンができるだけです。

 それでもサブルーチンは作る価値があります。再利用可能でないからサブルーチンを作らないというのはよいことではないです。ひとつの機能の実現としてサブルーチンを作ることが必要です。そうすれば、コードの可読性があがり、サブルーチンの再利用の可能性が生まれます。最初のうちは、再利用できるサブルーチンを作ることは、あまり気にしないで、ひとつの機能を実現するサブルーチンを作成することを主眼におきましょう。

6. ユーザーを意識する

 サブルーチンは、利用されるために使われます(もちろん自分を含めて)。ということは、名前はわかりやすくなくてはなりません。どのような機能を実現しているかがわからなくてはなりません。名前が機能をしっかり表現していなくてはなりません。引数はわかりやすいか、戻り値はわかりやすいかということを考えます。

 サブルーチンを作るときは、たとえ自分だけが利用するときでも、ユーザーに対するインターフェイスを作成しているのだという気持ちで作るのが良いと思います。

7. 将来を楽にすることを考える

 サブルーチンを作ることは、正直疲れます。時間と手間がかかります。サブルーチンを作らなくても、プログラムは動きます。でも、サブルーチンの作成は、ひとつの投資なのです。将来を楽にするための投資です。いまきちんと作っておけば、将来の仕様の変更や、環境の変化に柔軟に対応することができます。だから、サブルーチン作成はめんどうでも、きっちりと意識して行いましょう。

 実は、サブルーチンを作る技術がなかったり、サブルーチンの作成を怠ったりして、保守性が最悪の水準に陥ったプログラムが、世の中にごろごろしています。工夫やアイデアではなくて、マンパワーや根性が試されるプログラムが多いです。プログラマーが、疲れ果ててしまう原因のひとつでもあります。

 プログラマーの明るい未来のためにもよいサブルーチン作成を心がけます。

8. 完全な抽象化は求めない

 まったく反対のことをいいますが、サブルーチン作成にこだわりすぎて、いつまでたっても完成しないプログラムには、意味がありません。どこまで、抽象化できるかということは、抽象化のための技術力と、きづかいと、時間の制約とにかかっています。

 抽象化するための技術力がないとそもそも、抽象化できません。将来の保守を楽にしようというきづかいがないと、抽象化はできません。納期がぎりぎりで、作っては動かさないといけないという状況が続くと抽象化はできません。

 抽象化は、バランスの上に成り立っています。抽象化は、たいていは良いことですが、徹底的に抽象化を求めてしまうと、そこでプログラミングが止まってしまって、実現したいことが実現できなくなります。多くの抽象化のためにプログラミングが完成しないくらいなら、完成するほうを選びます。ただし、なるべく抽象化する気持ちは持っておいたほうが良いです。

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証