コード習慣の命名規範

良い名前を選択
名前には2つのターゲットがあります.
明確:この名前が何に関連しているかを知っておく必要があります正確:この名前は何と関係がないか知っておく必要があります1つのネーミングが上記の2つのターゲットを完了すると、残りの文字は余分になります.次に、開発時のネーミングの原則を示します.
変数やパラメータタイプを表す単語を名前に含める必要はありません
Javaなどの静的タイプ言語を使用する場合、開発者は通常変数のタイプを知っています.方法の実装は一般的に短いため,推定が必要なタイプのローカル変数を表示したり,code reviewなどの静的解析器が使用できない場合でも,少ない数行のコードを多く見ることで変数のクラス型を知ることができる.
したがって、タイプ説明を変数名に追加するのは余計です.ハンガリーの命名法を捨てなければなりません.以下のようにします.

//    :
String nameString;
DockableModelessWindow dockableModelessWindow;

//   :
String name;
DockableModelessWindow window;

特に集合については,名詞の単数形ではなく名詞の複数形を用いてその内容を記述することが望ましい.開発者がコレクションに格納されているコンテンツをより気にしている場合、変数ネーミングはこの点を反映しなければならない.

//    :
List holidayDateList;
Map employeeRoleHashMap;

//   :
List holidays;
Map employeeRoles;

この点はメソッドのネーミングにも同様に適用されます.メソッド名は、そのパラメータおよびパラメータのタイプを記述する必要はありません.パラメータリストには、これらが説明されています.

//    :
mergeTableCells(List cells)
sortEventsUsingComparator(List events,
    Comparator comparator)

//   :
merge(List cells)
sort(List events, Comparator comparator)

省略ネーミングで曖昧さを解消するための単語ではありません
一部の開発者は、この変数に関するすべての情報を名前に詰める傾向があります.名前は識別子にすぎないことを覚えておいてください.変数がどこで定義されているかを教えてあげるだけです.読者が知りたいすべてのオブジェクトに関する詳細を伝えるために使用されるわけではありません.これはやるべきことを定義したものです.名前は定義を見つけるだけです.recentlyUpdatedAnnualSalesBid(最近更新された年間販売入札)という識別子を見たら、次のように質問します.
最近更新された年間販売入札は存在しますか?
更新されていない最近の年間販売入札はありますか?
最近更新された非年間の販売入札はありますか?
最近更新された年間非販売の入札はありますか?
最近更新された年間非入札販売はありますか?
上記のいずれかの質問の答えが「存在しない」ということは、ネーミングに無駄な単語が導入されていることを意味します.

//    :
finalBattleMostDangerousBossMonster;
weaklingFirstEncounterMonster;

//   :
boss;
firstMonster;

もちろん、これは少し過ぎたと思うかもしれません.例えば、第1例の識別子をbid，に簡略化すると、少しぼやけてしまいます.しかし、その後の開発で名前が衝突したり不明確になったりすると、修飾語を追加して改善することができます.逆に、最初から長い名前をつけていたら、後で簡略化することはできません.
省略ネーミングでコンテキストから取得できる単語
私は文章の中で「私」を使うことができます.読者はこれがBob Nystromが作ったブログであることを知っているからです.私の愚かな萌えの顔はそこにかかっていて、私は私の名前を言う必要はありません.書き込みコードも同様で、クラス内のメソッド/属性とメソッド内の変数は、重複することなくコンテキストに存在します.

// Bad:
class AnnualHolidaySale {
  int _annualSaleRebate;
  void promoteHolidaySale() { ... }
}

// Better:
class AnnualHolidaySale {
  int _rebate;
  void promote() { ... }
}

実際には、ネーミングネストされた階層が多ければ多いほど、関連するコンテキストが多くなり、短くなります.すなわち、1つの変数の役割ドメインが小さいほど、名前が短くなります.
名前に意味のない単語を省略
私はよく多くのゲーム開発で意味のない単語を含む名前を見ます.一部の開発者は名前に少し厳粛に見える単語を追加するのが好きです.コードを重要にしたり、自分をもっと重要にしたりすることができると思います.
実際には、実際の意味がなく、いくつかの言葉があります.ただ、いくつかのセットです.たとえば、data、state、amount、value、manager、engine、object、entity、instanceなどです.
良い命名は読者の頭の中で絵を描くことができる.ある変数を「manager」と命名すると、その変数が何をしているのかに関する情報を読者に伝えることはできません.パフォーマンス評価に使用されますか?昇給を管理していますか?
名前をつけるときは、この単語の意味を消しても変わらないのではないでしょうか.もしそうなら、思い切って取り除きましょう~~
実例——ワッフル
以上の命名原則が実際にどのように応用されているかを知るために、以上のすべての原則に違反した反例がある.この例は私が実際にreviewしたコードと同じように心が砕けます...

//          
class DeliciousBelgianWaffleObject {
  void garnishDeliciousBelgianWaffleWithStrawberryList(
      List strawberryList) { ... }
}

まず、パラメータリストからstrawberryのリストを処理する方法を知ることができます.そのため、メソッド名から削除することができます.

class DeliciousBelgianWaffleObject {
    void garnishDeliciousBelgianWaffle(
        List strawberries) { ... }
}

プログラムにおいしくないベルギーのワッフルや他の国のワッフルが含まれていない限り、これらの無駄な形容詞を取り除くことができます.

class WaffleObject {
  void garnishWaffle(List strawberries) { ... }
}

メソッドはWaffleObjectクラスに含まれているので、メソッド名にはWaffleの説明は必要ありません.

class WaffleObject {
  void garnish(List strawberries) { ... }
}

明らかにオブジェクトであり、何事もオブジェクトである.これは伝説の「オブジェクト向け」の意味であるため、Objectを付ける必要はありません.

class Waffle {
  void garnish(List strawberries) { ... }
}

はい、これでだいぶよくなりました.
以上、私がまとめたかなり簡潔な命名原則です.ネーミングに多くの労力を費やす必要はないと思う人もいるかもしれませんが、ネーミングは開発過程で最も基本的な任務の一つだと思います.
——————————————————私は萌え萌えの境界線です————————————————
感覚変数や方法の命名は、簡単に見えるが、実際には難しい.特に簡潔明瞭で可読性の高い命名をしたい.自分もよくdata、xxxlistという名前を使っていますが、作者の言うことは正しいです.前者は意味がなく、後者は少しうるさいです.しかし,集合型の変数については,名詞複数の命名を統一することは混同しやすい.例としてAppleクラスでは,ListとMapの2つの集合型の変数が存在する可能性がある.個人的にはListタイプの変数は名詞複数で命名できると思いますが、Mapタイプの変数はvalueByKey形式で命名できるので区別しやすいと思います.