クラス名、変数名、関数名などのシンボル名の命名に悩むことはよくあると思います。
ソフトウェア設計、コードの改善等を扱った書籍でも名前付けはそれだけで丸々1章割かれるぐらい大切で難しいテーマですが、今回は省略についての私の考えを述べたいと思います。
シンボル名は長過ぎる場合には省略した名前付けをされる場合がありますが、省略は適切に行われないと可読性に大きな影響を及ぼすため、慎重になる必要があります。
基本は省略しない
シンボル名をとにかく短くつけようとするコードはよくあります。例えば以下のような省略は実際の開発現場でもよく見られます。
// cの意味が把握できない
auto c = std::chrono::system_clock::now();chronoのcか、clockのcではないか？という推測はできますが本当のところは分かりません。そのどちらかだったとしても、クラス名や名前空間名以外の情報がなく、変数の使用目的が分かりません。
特にC/C++などのシステム向け言語の場合、かつては短い名前が好まれたため、このような命名の文化が強く残っているコードも多いです。
省略元の意味を推測するのには少なからず時間がかかるため、省略が多用されているコードを読むのはやはり時間的コストがかかってきます。基本的に他人の書いたコードの理解というのは難しいもので、コードにはなるべく理解を助ける情報を多く残した方がいいというのが私の基本的な考え方です。
迷ったなら無理に省略せず、多少冗長と感じるぐらいでも問題となる例は少ない（むしろ読むうえでメリットの方が大きい）ように思います。長過ぎる名前を後から短くすることは容易ですが、短すぎて意味が推測できないシンボルに適切な名前を与えるのは難しいです。
今回の例であれば、省略をせず、さらに変数の使用目的が分かるように書くのが基本だと思います。
// 実は処理時間の計測に使うための開始時刻だった
auto start_time = std::chrono::system_clock::now();長い場合のデメリットとしては入力が煩雑になるということが考えられますが、現代のエディタは補完が優秀なのでそこまで手間ではないと思いますし、入力の手間を惜しんで可読性を落とすことの方が後々への影響は大きいです。
競技プログラミングなど、コーディングにかかる時間が大切な場面もあると思いますが、一般的な製品のコードでは「長すぎる」ぐらいでも構わないと思います。
繰り返しになりますが、長すぎると思えば後から適切な名前に変更すれば良いだけなので、まずは「情報を盛り込む」ことを意識すると良いと思います。
シンボルのアクセスレベルやスコープで考える
例えば関数内のローカル変数のように、スコープが短い場合はある程度の省略は許容できると思います。逆にスコープが広いもの、クラス名やインターフェイス（公開されるメンバ等）は省略すべきではないと考えます。
例えば以下のようなクラスがあった時、クラス名から使い方がすぐには想像できません。
// IFの意味が掴めない
class IFReader()
{
}このクラスは架空のもので、IniFileReaderという意図で考えましたが、実際にこのようにアクセスレベルが広いシンボルで大きな省略が行われる例はよくあります。
アクセスレベルが広いということは他の多くの開発者が目にするということですが、その度にIFとはどういう意味だろう？と考え、ドキュメントを読みに行くかもしれません。あるいはInterfaceの略と誤解され、誤った使い方をされる可能性すらあります。
公開されるような名称は開発チーム全体に与える影響も大きいので、このような場合には省略を避けるだけでなく、名前の設計を時間をかけて丁寧に行うべきだと思います。
一般的な省略語は用いても問題ない
informationをinfo、demonstrationをdemoと省略するなど、プログラミングに限らず一般的に使われる省略語は使っても問題ないと思います。
もちろん「一般的」の程度には気をつけなければいけませんし、省略した場合に他の単語と見分けがつかなくなるような場合にも注意が必要です。
省略の方が一般的な場合にはむしろ省略を行う
例えばPythonにおいて、numpyやmatplotlibはasを使って省略したパッケージ名が与えられるのが一般的です。
import numpy as np
import matplotlib.pyplot as plt逆に省略されていないコードをあまり見たことがありません。このような場合にはむしろ常識に合わせるべきだと思います。
他にもAI(Artificial Intelligence)やCSV(Comma Separated Values)などの単語もむしろ略語の方が一般的と思われる表現なので、これらも省略して構わないでしょう。
まとめ
どんな良い設計、高度なデザインパターンを採用していても名前付けが良くないと理解が難しいコードになってしまいます。
一方で分かりやすく、十分に情報が詰め込まれた名前付けは誰が読んでも有益な情報になります。初学者が読んでもベテランの人が読んでも、無駄になることはありません。
「省略を避ける」というのは良い名前付けの1つの側面に過ぎませんが、良いコードを書く上での最初の一歩になると思います。
コメント