Delphi Advent Calendar 2013 12/20 の記事です。
はじめに
プログラムを作成する上で、名前の付け方は重要だと思っています。
名前はどうでもいい、と言うすご腕プログラマはおられますが、私自身は凡人プログラマなので、名前の付け方を工夫することで、ソフト作成とその後のメンテナンス効率を高めたいと考えています。
視点
以下の視点を考慮して、名前をつけます。
- 見つけたいものがすぐに見つかること
- 関係ないものが検索結果に出ないこと
- 同じ種類のものは、同じ種類とすぐにわかるもの。
- ある種類のものを探すのが簡単なこと。
視点1に関して、これはそもそも名前の付け方を考慮する一番の理由と思います。
視点2に関して、Ctrl+Fなどで検索した時に関係ないものが表示されないほうが、よりその時の作業に集中できます。
視点3に関して、同じ種類のものを名前から判別することで、コード補完機能(Ctrl+Space)が有効に使えます。
視点4に関して、IDEの「構造ビュー」から該当部品を迅速に見つけることができるように。例えば、「ボタンのxxxがあったよな」という感じで「構造ビュー」から見つける時。
種類
名前の付け方は3つくらいに分けられると思います。
フォームのTButtonコンポーネントを例としてあげてみます。
先頭に種類を表す名前をつける (例: btnTest)
最後に種類を表す名前をつける (例: testBtn)
そもそも種類を表す名前をつけない (例: test)
種類1の利点は、コード補完機能を有効に使えます。btnだけ入力してCtrl+Spaceして、リストからすぐに該当部分を見つけられます。ただし、TButtonが30個もあるようなフォームになったら、リストから探すのが面倒にはなりますが。
種類1のもう一つの利点はIDEの「構造ビュー」において、同じ種類のものがかたまって表示されるので、探すのが楽になります。
種類2の利点は、種類1のようないわゆる「Yoda notation / ヨーダ記法(Blue is the sky)」とは異なり、物理的なものの名前(例: テストボタン)と似たような読み方となることです。ただ、それがコーディングにおいて便利なのかは、私自身はわかりません。
種類3の利点は、わかりません。
失敗例 (途中まで同じ名前)
種類以外にも名前をつける時に気を付けたいとおもった経験があります。似たようなものがある場合です。
- btnMon (最初に作ったもの)
- btnMonB (後で追加したもの)
- btnMonC (後で追加したもの)
上記のような名前のTButtonがあると、「btnMon」で検索した時、btnMonBもbtnMonCも検索されてしまう。これでは修正すべき該当部分を見つけるのが面倒になります。
btnMonBが追加される時点で、btnMonはbtnMonAなりにした方が、後々のソフト開発がやりやすくなります。
終わりに
しかしながら...命名規則の適用は状況によります。
単独で組むソフトの場合は、自分がプログラムしやすい命名規則にすることでコーディングをしやすくなります。
複数人で組むソフトの場合は、他者のソースと同じ命名規則にすることでソースの可読性が高まります。自分が担当する部分だけ独自の命名規則にしてしまうと、他の人がそのソースを見た時に、コードが読みづらくなります。
単独で組むソフト開発とチームで組むソフト開発の両方の作業がある時は、チームで組むソフト開発のルールに沿ったほうがいいかもしれませんね。二つのルールを切替えながら作業すると、混乱を生じてしまうので。
あとは、単独でソフトを開発し続ける場合、途中で命名規則を変えると昔のソースと最近のソースで規則が異なり、ソースコードが読みにくくなります。