以下、どっちがいいか。
void setScore(int score) {
this.score = score;
}
void setScore(int score) {
mScore = score;
}
もう、ええわ。
ありがとうございました。
Does Android team starts to abandon Hungarian Notation? : androiddev
「mハンガリアン記法」について自ブログでも発射!!
以前から反対していましたが
Someone, somewhere made the decision to use hungarian notation for Android Java sources. I think they owe the community an apology.
— Jake Wharton (@JakeWharton) 2014, 8月 7
ついに自ブログでも言及しています.
Just Say mNo to Hungarian Notation - Jake Wharton
「Androidのサンプルコードが利用している」
→ サンプルコードはAPSPで生まれそのAOSPスタイルに固執しているだけ.
「コードレビュー時に役に立つ」
→ 変更時に更新忘れしたものかもしれない.
「開発時に役立つ」
→ IDEがそれぞれ正しく表示してくれる.
→ 変更忘れが発生する.
「Google のようにコードを書きたい」
→ GoogleやAOSPの一部の会社はハンガリアン記法を禁止している.
WikiPedia をみてみる.
システムハンガリアンを使っているソースコードを修正してデータ型を変更した際、同時に変数名も変更するコストがかかる。変更を怠ると、たちまち不整合となり、保守の障害となるだけで一利もない。
C++やC# のような言語では型付けが存在するためにシステムハンガリアンを使用することによる利点はない。移植性を阻害する。
総称型、メタプログラミングとの相性が悪い。
いわゆる良書と呼ばれるようなC++本で、現在システムハンガリアンを採用している例が皆無。
かつてMFCにおいてハンガリアンを全面的に採用していたMicrosoft自身が、.NET Frameworkではハンガリアンを禁止している。
日本では、情報処理技術者試験などのC言語の問題でシステムハンガリアンが使用されていない。
結局,「IDEの進化」が大きく影響しているといえそう.
間違えたコードが機械的に検出される手法が利用可能ならば、間違えたコードが間違えて見える手法より明白に勝る。
エラー検出に関連する技術は、ハンガリアン記法が考案され成功を収めた当時と比べ大きく進歩している。
コードを間違える原因の中で、変数の意味（=型）の取り違えに由来するものが下位にあるとは言い難い。
なので, Android Studio での設定を.
[Preference] から.
技術も開発手法も変わっていくものなのですね.