ここでのベスト プラクティスが何であるかはわかりませんが、特にスコープが小さい場合は、短縮された変数名をよく見かけます。したがって、(単純な Ruby の例を使用するために) の代わりにdef add_location(name, coordinates)、 のようなdef add_loc(name, coord)ものが表示されdef add_loc(n, x, y)ます。略語を見ることに慣れている人は、長い名前に疲れてしまうのではないかと思います。
冗長性は読みやすさに役立ちますか?それとも、すべての人の目を傷つけるだけですか?—人々は長い名前よりも略語や短縮された名前を好みますか?
個人的には、最初に文脈を判断しなくても、実際に何かを意味する長い名前の方がずっと好きです。もちろん、カウンターなどの実際の意味を持たない変数には、意味のない小さな変数名 (iまたは などx) を使用しますが、それ以外の場合は、ほとんどの場合、冗長性が明確になります。これは、パブリック API の場合に特に当てはまります。
ただし、これはやり過ぎになる可能性があります。私は過去にいくつかの VB コードを見たことがあります。他のすべてと同様に節度を！
私は実際には常に長い変数名を使用していますが、最新の IDE とテキストエディターはすべて補完機能を備えているため、index代わりに if i を使用しても問題はありません。x私が持っている唯一の例外は、座標 b/cを扱うときyであり、そこで最も意味があります。
決して省略しないでください。
変数には、その目的を適切に伝えるできるだけ短い名前を付ける必要があります。
冗長すぎると構文が隠される傾向があり、構文は重要です。
プログラム (またはアプリケーション/システム) 全体で、変数には一貫したスタイルで名前を付ける必要があり、同様のものは同様に名前を付ける必要があります。言語コミュニティ内に規約が存在する場合は、やむを得ない理由がない限り、それに従う必要があります (キャメルケースRubyVariableNames は使用しないでください)。
略語を使用する場合はどこでも一貫して適用する必要があり、ドメイン固有の場合はどこかに記録する必要があります。誰かがコードに有効な時間を費やす場合、彼らはすぐに学習します。
変数に名前を付けるために 5 つまたは 6 つの単語を組み合わせる必要がある場合は、コードのにおいが気になり、作業しているルーチンが少し作業することでメリットが得られる可能性があることをお勧めします。
ただし、ほとんどの場合、落とし穴を認識していて、実際に何を書いているかを考えれば、コードが合理的である可能性が高くなります。取り組んでいる関数を新しい同僚に説明する自分を想像してみてください。言う必要が少ないと思うほど、コードはおそらく優れたものになります。
1 年後に自分のコードを読んでみてください。自己文書化変数名の値と、コード コメントの値 (および特にクリーン コードの値) の両方が表示されます。
他の誰かのソースコードを手に入れて、それを理解していないとき、「彼は私ほど優れたプログラマーではない」と考えるのは簡単ですが、自分のコードが読みにくいことに気付くと、次のようになります:考えてる？」
長期的には、冗長性は保守性に役立ちます。短い 1 行のスクリプトの場合、setLocationName の代わりに「setLocNm」を引き続き使用できます。
どんな愚か者でも、コンピューターが理解できるコードを書くことができます。優れたプログラマーは、人間が理解できるコードを書きます。 -マーティン・ファウラー
個人的には、冗長性は良いことだと思いますが、過度に冗長になりがちで、これは悪いことです。バランスがあり、略語もそのバランスに入ることができます。
これらは私の一般的なルールです：
i、j、kなどinstalling、doneなどfunction => funcたとえば、fun、f、またはfuncti回答を閲覧しましたが、以下がカバーされているかわかりません。ここに行く...
省略形であろうと冗長であろうと、必要以上の単語を使用しておらず、その意味が明白であることを確認してください。
ただし、このフィルタリングの後でも、識別子が冗長に見える場合は、設計に欠陥があります。
def initialize_report_template()
end
になるはずだった...
class ReportTemplate
def initialize()
end
end
長くするよりも短くすることを目指しますが、読者の理解は、毎回入力する怠惰に打ち勝たなければなりません。
他の人が言ったように、変数名の長さはロジックやアルゴリズムを曖昧にするべきではありません。たとえば、算術では、次のように書きます。
( 1 + 5 ) * 3 = 18
それよりも
three multiplied by the sum of one and five equals eighteen
表現に含まれる要素の明快さ以外のことに注意を引こうとしているからです。
私は変数を 1 ～ 3 語に抑える傾向があり、24 文字程度を超える場合にのみ省略します。変数の使用頻度が低いほど、変数名を長くしても構わないと思う傾向があります。より頻繁に使用される変数は短くします。
長い名前の方がはるかに優れています。あなたは、小さな範囲で略称をよく目にするとおっしゃいました。ソフトウェアが成長するにつれて、スコープが小さいままになると誰が言いますか?
もちろん、XCoordinateForCurrentLocationOfSelf はばかげた名前なので、妥当なものにしてください。特に、これまで取り組んだことのないプロジェクトに足を踏み入れた場合は、わかりやすい関数名と変数名を使用してくれた人に感謝するでしょう。
名前が読みにくくなったり、冗長になったりする場合は省略しても問題ないと思います。
例 1: 型が必要なすべての情報をすでに伝達しているメソッドへの引数。
例 2: 明らかに頻繁に使用される変数
StringBuilder sb = ...
sb.append(...
sb.append(...
return sb.toString();
例 3: 慣用的な略語。i、j、kはすでに言及されています。上記の "sb" はコード内の 1 つですが、各チームにはおそらくさらにいくつかあります。
Bugzilla のチーフ アーキテクトである Max Kanat-Alexander は、自身のブログで次のように述べています。
コード自体は、その意味の大きさに比例してスペースを占有する必要があります。
基本的に、多くの意味を持つ小さなシンボルは、コードを読みにくくします。あまり意味のない非常に長い名前も、コードを読みにくくします。意味の量と占めるスペースは、互いに密接に関連している必要があります。
http://www.codesimplicity.com/post/readability-and-naming-things/
これは、物事の命名に関する非常に洞察に満ちた投稿です。みんなに読んでもらいたい！
私はキルホッファーに同意します。私は、ほぼすべてのコンテキストで説明的な変数名を見ることを好みます。変数名が 20 文字を超える場合、通常は変数名に単語が含まれている場合は省略します (例: "SomeVeryLongVarValue")。
もちろん、私はできる限りハンガリー語表記法も使用しているので、見方によっては、変数名を過度にわかりやすいものにしようとする極端な陣営にいる可能性もあります。
私が略語を受け入れるのは、短期間だけスコープ内にあるローカル変数の場合だけです。
つまり、非常に読みやすいメソッドまたはコンストラクターでスコープに入る必要があります。
私はおそらく完全にブーイングされるだろうが、私はこの見解が確実に聞かれるようにしたかった.
変数名が長いほど、より説明的になりますが、プログラムの本来の意図を台無しにする可能性があります。API 要素では、使用されるコンテキストで明確で意味のある名前を付けることが重要であると感じています。
各関数またはメソッド内では、これはしばしば別の話です。私は書くことを減らし、非常に簡潔に保つようにしています。これは、アトウッド氏とこの気の利いた例によるスパルタンプログラミングとして知られています。はい、この例は明らかに改ざんされていますが、儀式を少し減らすと実際にプログラムが読みやすくなることを示しています。
幸運を。
ほとんどの人はサイトリーディングをします。単語を読んでから個々の文字を読むのにもはや時間がかかりません。したがって、常に意味のある名前を使用してください。それらは完全な7語の説明である必要がありますが、理解するのに十分な長さである必要があります。
add_loc（name、coord）は十分に長いので、それが何であるかを知ることができるので、受け入れることができます。add_loc（n、x、y）では、名前の代わりに「n」に反対します。XとYは座標の受け入れられた名前なので、私はXとYと一緒に暮らすことができました。
座標系に精通していない人にとっては、add_location（name、coordinates）がより意味のある場所であることがわかりました。
疑わしい場合は、長い名前を使用してください。
「殺人の謎を解明することは問題ありませんが、コードを解明する必要はありません。それを読むことができるはずです。」-スティーブC.マコネル
とはいえ、あなたや他の誰かが過度に明示的な変数名などを必要としていると思われる場合は、それらを自由に短縮してください。
人間が読めるように構文を使用してプログラミングする場合、変数名、メソッドなどの長さはまったく関係ありません。
通常、より冗長なほど良いです。適切な開発環境では、とにかくコード補完が必要なので、単に「add_L」+TAB を押してメソッド呼び出しを終了できます。
略語の主な問題は、すべての人が同じように略語を使うとは限らないことだと思います。そのため、多くの人と一緒に作業すると、コーディング時のエラーの可能性が高まるだけです。たとえば、SOMETHING_INTERFACE と呼ばれる定数がある場合、一部の開発者はそれを SOMETHING_INTFACE と省略し、他の開発者は SOMETHING_IFACE または SOMETHING_IF、SMTHING_IFACE と省略します...
2 つの単語だけで、多かれ少なかれ「論理的」な省略形を少なくとも半ダース使用できます。したがって、ほとんどの場合、省略形を使用せずに、自己文書化されたコードが必要な場合はより多くの理由を付けて記述する方がよいと思います。 .
非常に長い名前は煩わしい場合もありますが、補助変数を使用して非常にローカルなスコープで省略されることもあります。
ミニマリストのアプローチを取ることをお勧めします。コードが明確、簡潔、要点を保ったままであることを確認しながら、可能な限り少量を使用してください。
定数やグローバルなどの範囲外のものには、長い説明的な名前を付ける必要があります。非常に長い名前は、その存在が不要であることを知らせるのに十分な「におい」を与えることがあります. これは良いことです。なぜなら、1 - 人々がそれを避けるようになり、2 - コードをリファクタリングしてそれをなくすという圧力が高まるからです。