From:http://www.objectclub.jp/
コーディングの心得 五か条
コーディングは、本来、非常に知的な作業です。
長いプログラムを記述すること(ステップ数)によって生産性が評価されたのは、過去
の時代の出来事です。現在は、ク
ラスやメソッドの役割が明確で、ロジックが読みやすく、保守性に優れたプログラ�
を記述することが評価されます。
コーディング規約は、コードの書き方に関する一種のパターンと言うこともでき、
コードの保守性を向上させる具体的
な方法を示しています。したがって、規約の一つ一つの意図を理解し、守ることが重
要です。しかし、保守性に優れた
コードを作成するためには、コーディング規約を守ることに加えて、良いコードを記
述するための基本的な心構えをし
っかり心に留めておく必要があります。
本章では、この心構えを「コーディングの心得5 か条」として紹介します。
どの心得もごく当たり前に思えるかもしれません。しかし、これらの心得と照らして
既存のコードを参照すると、実践
されていないコードが意外と多いことに気づかれる方も多いのではないでしょうか。

特に、コーディング経験の浅いプログラマの方は、この「コーディングの心得 5 か
条」を理解し、コーディング時に
自分で考えて実践することをお勧めします。
コーディングの心得 五ヵ条
一．見やすさを重視せよ
一．ネーミングはわかりやすく
一．サンプルを鵜呑みにしない
一．同じコードを二度書かない
一．役割は一つに

◇見やすさを重視せよ
「良いコード」の基本は、「他の人が読んでもわかりやすいと感じられるコード」と
言えます。コードの見やすさは、
フォーマットはもちろん、ロジックの簡潔さやAPI の常識的な使い方などから生まれ
ます。コーディングにあたって
は、常に他の人の視点を意識しながら、見やすさに気を配って記述しましょう。
また、自分で記述したコードであっても、しばらくたってから読み返してみると理解
に時間がかかった経験はないでし
ょうか。「3 日前に書いたコードは他人のコードと同じ」ということも言われます。
見やすさを重視することは、他の
人のためだけでなく、自分のためにもなります。
◇ネーミングはわかりやすく
コーディングでは、様々な変数やメソッドなどにネーミング(名前付け)しなければな
りません。ネーミングとは、本来、
その対象の本質を表すような名前を考える作業です。大変難易度の高い作業ですが、
一方で適当に行ってもコードの動
作は変わらないため、人によっては手を抜きがちです。しかし、ネーミングの良し悪
しは、コードの可読性に非常に大
きな影響を及ぼします。
例えば、「C0001」というクラス名があるとします。これでは、何を表すクラスなの
かすぐにわかりません。また、「int
p = 5000;」という記述があるとします。プログラマに聞くと、変数名p は価格
(Price)の略だと言ったとします。であ
れば略さずに、「int price = 5000;」としたほうがわかりやすいと思いませんか？
「ネーミングはわかりやすく」の背景には、としたほうがわかりやすいと思いません
か？
「ネーミングはわかりやすく」の背景には、読んで内容が理解できるという意味で、
文章のようなプログラミングを行
うという考え方があります。
◇サンプルを鵜呑みにしない
サンプルコードを活用すること自体は、著作権等を侵害しなければ問題ないでしょ
う。問題なのは、その内容や背景を
理解しないまま、サンプルコードだけを鵜呑みにして、「おまじない」として表面的
に適用してしまうことです。
コードを「おまじない」ととらえていては、サンプルコードの間違いを気づかないま
ま適用してしまうこともあります。
例えば、ストリームのクローズ処理を行っていないサンプルコードであっても、それ
に気づかずに自分のコードに適用
してしまい、後で思わぬ障害を引き起こすということもありえます。サンプルコード
は、そこで説明する内容に絞った
コードが多いため、このような例はよく見られます。
また、サンプルコードをそのまま適用した結果、自分が記述すべきコードには必要の
ないコードが含まれてしまうこと
もあります。その場合、コードの可読性を下げる原因になります。
自分のコードは、自分で深く理解して記述しましょう。
◇同じコードは二度書かない
コードをコピー・ペーストしていませんか？コピー・ペーストしてしまうと、何らか
の修正をする際に、全ての個所に
同じ修正をする羽目になります。同じコードが現れるようならまとめて一つにし、外
に出してコールするような書き方
をすべきです。
同じコードをまとめる作業は、どちらかといえば、コーディング時よりリファクタリ
ング(ソフトウェアの外部的振る
舞いを変更せずに内部構造を改善する作業)で行われることが多いでしょう。しか
し、コーディング時からできるだけ
気をつけておきたいことです。
◇役割は一つに
メソッドの役割が明確で、かつ1 つであれば単体テストが行いやすくなります。つま
り、コードの「試験性」が高まり
ます。また、役割が一つであれば、後でコードを変更する際に修正箇所がわかりやす
いため、障害修正に要する時間が
短くなります。つまり、コードの「保守性」があがります。
例えば、「チェックをして実行する」機能を実現するために、checkAndDo()メソッド
が存在したとします。このメソッ
ドはcheck()メソッドとdo()メソッドに分割すべきです。なぜなら、checkAndDo()メ
ソッドのチェックロジックに誤り
があった場合、本来はdo()メソッドに書かれる内容まで把握する必要があるからで
す。分割してあれば、check()メソ
ッドだけの変更で済みます。
このことはクラスの設計にも言えることです。