Help us understand the problem. What is going on with this article?

変数名の付け方 違和感7選

はじめに

仕事柄、他人の書いたソース(主に発注先から引き取ったソース)を読む機会が多々あるが、その中でも読みづらさの原因の一つである「変数名の付け方」について、違和感を感じる頻度の高かったものをリストアップしてみた。

もちろん自分の書いたソースについても、あとから自分が見ずらくならないよう、自分自身も気を付けたいと思う。

以下、パターンを列挙する。

1. やたら省略されている

× res -> 〇result
△ prop -> 〇property
× pat -> 〇pattern
× enz -> 〇enzyme
× idx -> 〇index (2019/7/30追加)
× tbl -> 〇table(2019/8/24追加)

昔のマシンリソースが限られていた時代ならいざ知らず、現在では、可読性が大幅に下がるため、省略するメリットはほとんどない。
"prop"は、そこまで違和感はないが、一貫性という観点から"property"とした方が、より「違和感」を感じない。
"enz" にいたっては、めったに出くわさないような(おそらく)重要な単語を省略されても...と思う。

2. 微妙な綴りミス

× propaty -> 〇property
× canceld -> 〇canceled
× spacified -> 〇specified

"propaty" は最初から違和感を感じていたものの、あまり見かけるミスでもないため、綴りが間違えていることに気が付くのに時間がかかり、気づいた時には胸のつかえが取れすっきりした。"canceld"も、過去形にしたいのはわかるが、正しく書いてほしい。
最近の開発ツールは綴りミスも指摘してくれるものが多いため、それらを活用すればよい。

3. 具体性がなく目的が分かりづらい

× count -> 〇progressCount
× max -> 〇progressCountMax

小さなループや関数の中等、スコープが狭い場合はありだと思うが、大きなクラスのインスタンス変数等で使うのであれば、もう少し具体的に書かないと、当該箇所を読んでいるときに「何の変数だっけ」となってしまう。

これはプリミティブ型だけではなく、クラス型変数にもいえる。
例えばCalculationResult クラスのクラス型変数の名前としては、

× result -> 〇calculationResult

とのように具体的にすべきである。前者では、何のresultか即座にイメージできない。

4. 意味が逆

isValidというboolean型の変数名を付けたはいいが、妥当でない場合に"true"、妥当な場合に"false"が入るようになっていた。
論外としか言いようがない。こうなると確信犯的なものさえ感じるのだが...

boolean isValid = false;

if(!inputFile.exists()){
    isValid = true;
}

if(isValid){
  printUsage();
}

2019/7/30 追記
後日、元々のソースを見る機会があり、isValidではなくexitFlag なる名前だった。推測するに、別の目的に利用しようとして名前を変えたが、true/falseの意味は変えなかった、というオチのようである。元の開発者と、改変者は別人である。ザ、よくあるアンチパターン。少年よ、視点を高く持とう。

5. 型がイメージできない

自分はデータがどう処理されていくかをイメージしながらソースを読むことが多いため、変数名から目的と型が一目で分かることが望ましいと考えている。データ処理でよく使うものは、プリミティブ型以外では、配列、List、Map等がある。Listには〇〇List(〇〇はListに格納されるるものを表す名前)、Mapには〇〇△△Map(〇〇はMapのキーを表す名前、△△はMapの値を表す名前)などつけられていると分かりやすく感じる。

Map型に対して、以下の例を挙げる。

× names -> 〇 nameValidMap

後者は、少なくとも名前と何かの対応が格納されたマップということが分かるが、前者では全くわからない。リストと勘違いし、読み進むうちにあれ?っと思い、定義したた箇所に戻って確認というループを繰り返すことになる。

6. 単数、複数がイメージできない

前項と近いが、データの処理の流れを追うにあたり、その変数が"単数"のデータなのか"複数"のデータなのかの理解が重要である。
したがって単数データであれば単数形にし、配列やリストなど複数のデータを格納可能な変数は複数形にした方がとても分かりやすい。

7. 慣用的な名前をわざわざ変更している

Javaならおなじみのメイン関数である。こう書いてある。

public static void main(String[] option){
    
}

違和感を感じないだろうか。
そう、main関数の引数の名前は、"argv"と相場が決まっているにも関わらず、わざわざ別の名前に変更している。

main関数の引数には、プログラムの”引数”が格納されるのであり、"オプション"が格納されるわけではない(結果として格納されるとしても)

このoptionという変数はどこで定義されているんだろうと結構悩んでしまった。
慣用的に使う名前を変更するのであれば、よほどの積極的な理由が必要ではないだろうか。

おわりに

今格闘してるソースは他にも「空行の入れ方」、「変数のスコープの取り方」、「コメントの書き方」、「処理の順番」などの違和感が大量にあるのだが、別の機会にまとめたい。

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away