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

コレクション変数の命名規約

More than 1 year has passed since last update.

コレクション変数の命名規約

コレクション変数名については、コレクションを複数系、その要素を単数形にするという規約がある。ただし、英語で複数形にすると、単純にsをつけるだけではない場合、問題が発生する。実際に以下のようなコードを見たことがある。

       internal void Main()
        {
            // 各機能で呼び出す共通データ取得処理(私が書いたもの)
            var entities = GetData();
            // 機能担当者が書いたコード
            foreach (var entitie in entities)
            {
            }
        }

        /** 共通処理からデータを取得する。 **/
        private List<Entity> GetData()
        {
            var entities = new List<Entity>() { new Entity() { ID = 1, Name = "1" } };
            return entities;
        }

        /** 共通処理で生成するエンティティクラス **/
        private class Entity
        {
            internal int ID { get; set; }
            internal string Name { get; set; }
        }

私が書いた共通処理のコードの下から機能担当者にforeachを書いてもらった結果、sを消してentitieという変数名にしている。また、最悪なことにforeachは各機能で書く必要があったためコピーでentitieが量産されてしまった。3ヶ月ぐらいentitieが気になったため、こっそり修正した。

一方、単純なスペルミスではあるものの、この問題は「日本人」が書いていることに起因しているとは思う。英語のスキルは個人によって差があるので-es, -sなどの使い分けができない人も想定するべきである。

問題点を踏まえた後の命名規約

次のプロジェクトではsをつけるだけの規約にする。
間違えもおきにくい上、foreachループ内での変数の対応関係が明確である。
entities=>entityよりはentitys=>entityのほうが可読性は高くなる。

コレクションの命名規約を周りはどうしているのか気になるところである。
3パターンのいずれかだと思う。
1. 厳密な複数形(-es,-s)と単数形にする。
2. 複数系は単数形にsをつけるだけにする。
3. 自由

        internal void Main()
        {
            // 各機能で呼び出す共通データ取得処理(私が書いたもの)
            var entitys = GetData();
            // 機能担当者が書いたコード
            foreach (var entity in entitys)
            {
            }
        }

        /** 共通処理からデータを取得する。 **/
        private List<Entity> GetData()
        {
            var entitys = new List<Entity>() { new Entity() { ID = 1, Name = "1" } };
            return entitys;
        }

        /** 共通処理で生成するエンティティクラス **/
        private class Entity
        {
            internal int ID { get; set; }
            internal string Name { get; set; }
        }

追記 2017/03/11

この結論に至った経緯が必要と考えたので、追記する。

コレクション変数名に英語の複数形(s,es)を使用する利点

コレクションを複数形にすることは違和感がない上、変数名にListなど型情報を持たないので、型が変わったとしても変数名を変える必要がない。

例えば、変数名に型名をつける場合(...Listや...Dictなど)、コレクションの型変更が発生すると、すべて書き換えることになる。
ここの問題を回避できるのであれば、コメントいただいた変数名に型名をつける規約でも良い。

コレクション変数名にsをつけるだけに変更した経緯

元の記事に書いている通り、複数形が分からずに間違えるプログラマがいるので規約を単純化した。プロジェクトの質を下げるような規約だが、そもそもプロジェクトメンバーの質が低いので、低いレベルに合わせないと仕事が回らない。
コードレビューで指摘して全て修正させるべきだという意見をいただいたが、メンバーの質が低すぎて、不可能な状況となっている。
大半のメンバーが規約の半分以上を守ることすらできないので、守れる規約にせざるを得ない現状がある。

プロジェクトメンバーの質と規約

別の記事に書いたとおり、コードレビューの指摘では直らない人たちの集まりになっている。
また、製造期間のみの期限つきであるため、育てるという選択肢はない。そもそも
規約が守れないことが多く、コードレビューは規約違反が多すぎて、危ういロジックを拾うことができない。

今回はコレクション変数名について記事にしているが、例えばbool型の変数名では過去分詞や形容詞が分からないプログラマもいるので、同じような問題が発生する。
妥協できる規約にできればそうしたいものの、なかなか良い案はない。

追記 2017/12/16

いろいろと検討した結果、コメントにいただいた「コレクションは...List」にするという案は良いかもしれない。ListであろうとDictinaryであろうと全て「...List」にするのはスペルミスも大幅に減り、プロジェクトメンバーへの負担が低い気がする。
普通はList型が圧倒的に多いことを考えれば、一番守りやすい規約になり得る。
(当初、型を変数につけるという話だと思ってしまったので、私の返信コメントが的外れな内容になっている)

目次

csharpisthebest
C#が大好きな業務SE。業務で使用する言語はVBやjavaが多いので残念。
Why not register and get more from Qiita?
  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
No 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
ユーザーは見つかりませんでした