Regarding collection variable names, there is a convention that collections are multiple systems and their elements are singular. However, the plural form in English causes problems if it is not simply added with s. I have actually seen the following code.
internal void Main()
{
//Common data acquisition process called by each function(What i wrote)
var entities = GetData();
//Code written by the person in charge of the function
foreach (var entitie in entities)
{
}
}
/**Get data from common processing.**/
private List<Entity> GetData()
{
var entities = new List<Entity>() { new Entity() { ID = 1, Name = "1" } };
return entities;
}
/**Entity class generated by common processing**/
private class Entity
{
internal int ID { get; set; }
internal string Name { get; set; }
}
As a result of having the person in charge of the function write foreach from the bottom of the common processing code I wrote, s is deleted and the variable name is entitie. Also, the worst thing is that foreach had to be written for each function, so entitie was mass-produced by copying. I was worried about entitie for about 3 months, so I fixed it secretly.
On the other hand, although it is a simple misspelling, I think this problem is due to the writing by "Japanese". Since English skills vary from person to person, it should be assumed that some people cannot use -es, -s, etc. properly.
In the next project, we will make it a convention that only adds s. It's hard to make mistakes, and the correspondence between variables in the foreach loop is clear. Entities => entities are more readable than entities => entities.
I'm wondering what the naming conventions for collections are. I think it's one of three patterns.
internal void Main()
{
//Common data acquisition process called by each function(What i wrote)
var entitys = GetData();
//Code written by the person in charge of the function
foreach (var entity in entitys)
{
}
}
/**Get data from common processing.**/
private List<Entity> GetData()
{
var entitys = new List<Entity>() { new Entity() { ID = 1, Name = "1" } };
return entitys;
}
/**Entity class generated by common processing**/
private class Entity
{
internal int ID { get; set; }
internal string Name { get; set; }
}
I think it is necessary to have a background to reach this conclusion, so I will add it.
There is no sense of discomfort in making the collection plural, and since the variable name does not have type information such as List, it is not necessary to change the variable name even if the type changes.
For example, if you give a type name to a variable name (... List, ... Dict, etc.), it will be rewritten when the collection type is changed. If you can avoid the problem here, you can use the convention to give the type name to the commented variable name.
As I wrote in the original article, I simplified the convention because some programmers make mistakes without knowing the plural. It is a rule that lowers the quality of the project, but since the quality of the project members is low in the first place, work will not work unless it is adjusted to a low level. I received an opinion that I should point out in the code review and fix everything, but the quality of the members is too low and it is impossible. Most members cannot even comply with more than half of the rules, so there is no choice but to follow the rules.
As I wrote in another article, it is a group of people who cannot be fixed by the code review. In addition, there is no option to grow it because it has a limited manufacturing period. In the first place Code reviews often violate the rules and can't pick up dangerous logic.
This time, I'm writing about collection variable names, but for example, some programmers don't understand past participles and adjectives with bool type variable names, so the same problem occurs. I would like to have a compromised convention, but there is no good idea.
As a result of various studies, it may be a good idea to make the comment "Collection is ... List". Whether it is List or Dictinary, making all "... List" greatly reduces spelling mistakes, and I feel that the burden on project members is low. Considering that the List type is usually overwhelmingly large, it can be the easiest rule to follow. (At first, I thought it was about attaching a type to a variable, so my reply comment is irrelevant.)