変数・関数の命名規則は一貫性を持たせる必要がある

注意: この記事は1年以上前に掲載されたものです。情報が古い場合がありますのでお気を付け下さい。

アプリやシステムの開発を行っていると、命名規則でよく揉める。場合によってはそれで開発全体が停滞するといったことすらありえる。これはかなりの害悪であるため、それを防ぐことに注力しなければならない。ここでは私なりの対処法を書いてみたい。

言語・フレームワークのガイドラインがあるならそれに従う

まず、JavaやC#(.NET Framework)、Objective-CやSwift(Cocoa Framework)といった、ガイドラインがある言語およびフレームワークの場合は、基本的にそれに従う。こうすることによって、ベースとなる言語仕様やフレームワークの書き方と統一でき、不自然さがなくなり、なおかつ一貫性も確保できるようになるからである。

これは、自身がスネークケースの方がわかりやすいと考えていたとしても、言語やフレームワークのガイドラインではキャメルケースを指定した場合はキャメルを用いる必要があることも意味している。逆も然りである。

ガイドラインがない場合

一方、C言語やC++などでは明確かく統一されたガイドラインが無い。一応、これらの言語は標準ライブラリーの型・関数は全て小文字、マクロは全て大文字だが、それ以外は独自にとりきめる必要がある。ただ、ベースとなるライブラリーやフレームワークがある場合はそれに従うべきだろう。

それ以外の場合は、標準ライブラリーとマクロとの兼ね合いから大文字と小文字を混在させるような使い方が望ましいといったところだろうか。

最も重要なのは分かりやすいということ

とはいえ、上記のことは割と些細なことだったりする。最も重要なのは「それが分かりやすいか」である。そのクラス、メソッドが開発者にとって分かりやすいかどうかを明確にする必要がある。

関数コードのような暗号めいたものは基本的にわからず、別のドキュメントを見なければならないということで、生産性に悪影響を与える。それを防ぐには、それが何を意味しているのか、分かりやすい言葉で書くことである。

当然ながら、一貫していることが必要である。

最後に

命名規則はなかなか揉める要素になっており、合意形成を確立しづらいところもある。とはいえ、一貫性がないと混乱を引き起こすため、明確にしないといけない。

開発にはいろいろ面倒なところがあるが、ぜひとも乗り越えていきたいところである。

タイトルとURLをコピーしました