予約語を避けるための意図的なスペルミス
私はよく、良くも悪くも予約語になった一般的な単語の意図的なスペルミスを含むコードをよく目にします。
klassまたはclazzforclass：_Class clazz = ThisClass.class_kountforcountin SQL：count(*) AS kount
個人的には、これにより読みやすさが低下します。私自身の練習では、より適切な名前を使用できなかったケースはあまり多くありませんでした— itemClassまたはrecordTotal。
Class のJavaDocsの例は、これをパラメーターで示しています。
_public <U> Class<? extends U> asSubclass(Class<U> clazz)_
これは合理的なユースケースを示していますか？
私見、これは非常に悪い考えです。予約語は理由で予約されており、これを行うと読みやすさが低下します。
2番目の点にも完全に同意します。変数にclassという名前を付けることは、たとえそれができたとしても、tmpまたはaと同じように悪いことになります。どんなクラス？何のクラス？名前はわかりやすいものにする必要があります。
Pythonの スタイルガイド は、この問題を具体的に指摘し、次のことを示唆しています。
パブリック属性名が予約済みのキーワードと競合する場合は、属性名に単一の末尾アンダースコアを追加します。これは、略語や破損したスペルよりも望ましい方法です。
これは、特定の言語のセマンティクスと競合しないことを前提として、かなり良い一般的なルールのようです。
string stringVariable = "";
上記のコードでは、使用目的の変数については何もわかりません。
class Klass
同じ問題
string UserNameString = "bmackey"
上記のコードでは、変数名にキーワード文字列を追加する必要はありません。変数名で型を識別する必要がある場合は、コードが長すぎます。凝縮リファクタリング。
個人的には、それはあなたのコードスタイルにとって完全に有効なオプションだと思います。
それらは予約語であるため、コンパイラが言語機構または変数のどちらを意味するのかを決定する必要はありません。それを念頭に置いて、それは彼らがexpect人が予約語のような変数の必要性を持っていることを意味します。
JDK 1.6 R21にバンドルされているソースを調べると、「clazz」が917回見つかりました。どうやら、彼らはそれが許容できるスタイルだと思った。
あなたのチームはそれについてどう思いますか？悪いと思っても、チームの他の9人が良いと思ったら、弾丸を噛んで受け入れなければなりません。何が問題で何が問題であるかについてのコミュニケーションがあり、あなたがそれらを見るときにあなたが見る問題を持ち出している限り、それは問題ないはずです。
あなたのチームがコードスタイルについてどのように感じているかは、私の意見やこの投稿の他の誰かよりも重要です。これは、これや他のコードスタイルの決定にも当てはまります。
予約語を避けるための意図的なスペルミスは悪い考えです。
スペルミスは正しいスペルと区別するのが難しいため、コードが読みにくくなります。
スペルミスは覚えにくいため、一貫性のないいくつかのスペルミスがコード内で競合する可能性が高く、コードの書き込みや読み取りが難しくなります。
予約語は、問題自体ではなく、問題の解決に使用される言語を指します。変数名は、問題に関連する概念を指す必要があります。
したがって、次のように、代替の説明的な名前を選択するか、満足のいく代替が存在しない場合はqualify予約語を選択することをお勧めします。
public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
Class<?> benchmarkedClass = ClassUtils.loadClass(benchmark.generatedClass());
return findBenchmarkMethod(benchmarkedClass, benchmark.generatedMethod());
}
Class clazz「いい名前を付けようとする気になりませんでした」のようなにおいがします。変数は常に何かを表しており、良い名前はそれを表します。 clazzは、たとえば、どんな状況でも可能な最高の名前だとは想像しません。それはクラスへの参照ですか-> class_reference、これはクラスオブジェクトのコピーです-> class_copyなど。
Java.lang.SecurityManager.checkMemberAccess(Class<?> clazz, int which)
Parameters
clazz -- the class that reflection is to be performed on.
ここでclazzはチェックが実行されるターゲットクラスなので、
checkMemberAccess(Class<?> target, int which)
パラメータが何のために使用されるかを、clazzよりもはるかによく説明します。
変数に予約済みの名前を使用している場合、その名前は不適切な名前です。教室用ソフトウェアのクラスなど、正当な名前であっても。
不十分な名前の変数は、よく考えられていないか、コードがカジュアルであることを示しています。保守しているソフトウェアの一部にあるその他の問題に注意してください。
意図的なつづりの間違いや略語はよい考えだと思います注意深く一貫して使用した場合。
Javaで検討してください：
class X { public X() { } }
X x = new X();
x.getClass; // Wha? How does "get" help anything?
x.class; // Best, but requires more lexer/parser work
x.klass; // At least as good as getClass
x.clazz; // Same
スペルミスを使用する場所は、予約語が明らかに仕事に最適な語であるところです。 2つの場所がありますnotスペルミスを使用したい場合があります。
- いい名前を考えたくない
- ダミー変数が必要なだけで、わかりやすい名前は必要ありません
最初のケースでは、遅延が高品質のコードを作成するための優れたポリシーであることはめったにありません。 2番目のケースでは、本当に短い変数を選択します。それは数学者がいつもしていることであり、プログラマーはインデックスのためにしています。それが本当に単なるダミー変数である場合、インデックスに対してこれを行うことに制限する理由はありません：
boolean isMyName(String testName) { return myName.equals(testName); }
boolean isMyName(String s) { return myName.equals(s); }
Date nextMeeting(Klass klass) { return /* something */ }
Date nextMeeting(Klass k) { return /* something */ }
メソッドやコードの構造がそこに何があるべきかを教えてくれれば、短い変数名で何も失うことはありません。
Classクラスのインスタンスを実際に操作するリフレクションを行うときに、Class klassの正当な使用を見てきました。
私はよく、良くも悪くも予約語になった一般的な単語の意図的なスペルミスを含むコードをよく目にします。
クラスのクラスまたはクラス：クラスclazz = ThisClass.class
sQLでのカウントのカウント：count（*）AS kount
個人的には、これにより読みやすさが低下することがわかります。私自身の練習では、より適切な名前を使用できなかった場合、itemClassやrecordTotalなどのケースはあまり多くありません。
しかし、あまりにも一般的で、私だけではないかと思わずにはいられません。誰もがこの実践について尊敬されているプログラマーからアドバイスまたはさらに良い引用された推奨事項を持っていますか？
ローカル変数と仮引数の場合、それは問題ではありません。
意図的に誤解を招く、または煩わしく気を散らすものでない限り、どのような名前でもかまいません。あなたの例では：
public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}
単一のローカル変数が「clazz」、「klass」、「cls」、または単に「c」であるかどうかは関係ありません。私はおそらく式をインライン化するでしょう：
return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
benchmark.generatedMethod());
変数名の長さは、変数のスコープに関連している必要があります。短いメソッドのローカル変数（およびそれらはすべて短いはずです）の場合、非常に短い名前で問題ありません。
創造的なスペルの1つの利点は、検索能力の向上です。一般的な単語よりも、完全なコード検索を行う方が、一般的な単語を検索するよりもはるかに簡単だと私は思います。例として、私は以前kzpg.comを所有していました。グーグルは今、あなたはほんの数のヒットを見るでしょう。それはユニークであり、それゆえ非常に見つけやすいです。
しかし、ある程度、この質問は実質よりも意見の1つだと思います。私は個人的にフォースで育ちました。人は自分の指を救うために非常に創造的になることを学びました。結局、ソースベースには多かれ少なかれ64万文字がありました。したがって、仕事を終わらせるには、言葉を短くすることが重要でした。
スペルミスは常に悪い考えだと思います。それはあなたの読者にとって単にいいことではありません。 1つには、単語klassを見つけたときに何かを見逃したのではないかと思います。 （それらはclassを意味しましたか、それとも海賊を意味しましたか？）少なくとも私にとって、私が認識するすべてのスペルミスはイライラしています。
予約されたWordが実際に変数について知られている唯一の重要なものである非常に少数のケースでは、次の代替手段を使用します。
関数の引数の場合は、
aClassの代わりにclassを使用します。ローカル変数またはメンバー変数の場合は、
myClassではなくclassを使用してください。アクセサーの場合は、
getClass()ではなくclass()を使用してください。
もちろん、追加された接頭辞は意味がありません。そのため、最後の手段としてのみ使用する必要があります。しかし、少なくともそれは読者のメンタルパーサーに干渉せず、予約語を回避するためのフェイルセーフな方法です。