En ce qui concerne les noms de variables de collection, il existe une convention selon laquelle les collections sont des systèmes multiples et leurs éléments sont singuliers. Cependant, si vous utilisez le pluriel en anglais, des problèmes surviendront si vous n'ajoutez pas simplement s. J'ai en fait vu le code suivant.
internal void Main()
{
//Processus d'acquisition de données commun appelé par chaque fonction(Ce que j'ai écrit)
var entities = GetData();
//Code rédigé par le responsable de la fonction
foreach (var entitie in entities)
{
}
}
/**Obtenez des données à partir d'un traitement commun.**/
private List<Entity> GetData()
{
var entities = new List<Entity>() { new Entity() { ID = 1, Name = "1" } };
return entities;
}
/**Classe d'entité générée par un traitement commun**/
private class Entity
{
internal int ID { get; set; }
internal string Name { get; set; }
}
Suite au fait que le responsable de la fonction écrive foreach à partir du bas du code de traitement commun que j'ai écrit, s est supprimé et le nom de la variable est intitulé. Pire encore, car chaque fonction devait être écrite pour chaque fonction, si bien que l'itie était produite en série par copie. J'étais inquiet à propos d'itie pendant environ 3 mois, alors je l'ai réparé en secret.
Par contre, bien qu'il s'agisse d'une simple faute d'orthographe, je pense que ce problème est dû à l'écriture par "japonais". Étant donné que les compétences en anglais varient d'une personne à l'autre, il faut supposer que certaines personnes ne peuvent pas utiliser correctement -es, -s, etc.
Dans le prochain projet, nous ajouterons simplement s. Il est facile de faire des erreurs et la correspondance entre les variables de la boucle foreach est claire. Entities => entity est plus lisible que entity => entity.
Je me demande quelles sont les conventions de dénomination de la collection. Je pense que c'est l'un des trois modèles.
internal void Main()
{
//Processus d'acquisition de données commun appelé par chaque fonction(Ce que j'ai écrit)
var entitys = GetData();
//Code rédigé par le responsable de la fonction
foreach (var entity in entitys)
{
}
}
/**Obtenez des données à partir d'un traitement commun.**/
private List<Entity> GetData()
{
var entitys = new List<Entity>() { new Entity() { ID = 1, Name = "1" } };
return entitys;
}
/**Classe d'entité générée par un traitement commun**/
private class Entity
{
internal int ID { get; set; }
internal string Name { get; set; }
}
Je pense qu'il est nécessaire d'avoir un historique pour arriver à cette conclusion, je vais donc l'ajouter.
Il n'y a aucun sentiment d'inconfort à faire une collection au pluriel, et comme le nom de variable ne contient pas d'informations de type telles que List, il n'est pas nécessaire de changer le nom de variable même si le type change.
Par exemple, si vous donnez un nom de type à un nom de variable (... List, ... Dict, etc.), il sera réécrit lorsque le type de collection changera. Si vous pouvez éviter le problème ici, vous pouvez utiliser la convention pour donner le nom du type au nom de la variable commentée.
Comme je l'ai écrit dans l'article original, j'ai simplifié la convention car certains programmeurs font des erreurs sans connaître le pluriel. C'est une règle qui abaisse la qualité du projet, mais comme la qualité des membres du projet est faible en premier lieu, le travail ne fonctionnera que s'il est ajusté à un niveau bas. J'ai reçu un avis que je devrais souligner dans la révision du code et tout réparer, mais la qualité des membres est trop faible et c'est impossible. La plupart des membres ne peuvent même pas se conformer à plus de la moitié des règles, il n'y a donc pas d'autre choix que de suivre les règles.
Comme je l'ai écrit dans Another article, c'est un groupe de personnes qui ne peut pas être corrigé par la révision du code. De plus, il n'y a pas d'option pour le cultiver car sa période de fabrication est limitée. En premier lieu Dans de nombreux cas, les règles ne peuvent pas être suivies et les révisions de code enfreignent trop les règles pour saisir une logique dangereuse.
Cette fois, j'écris sur les noms de variables de collection, mais par exemple, certains programmeurs ne comprennent pas le passé et les adjectifs avec des noms de variables de type booléen, donc le même problème se produit. Je voudrais le faire si je peux faire un compromis, mais ce n’est pas une bonne idée.
À la suite de diverses études, il peut être judicieux de faire le commentaire "Collection is ... List". Qu'il s'agisse de Liste ou Dictinaire, faire tout "... Liste" réduit considérablement les fautes d'orthographe, et je pense que le fardeau des membres du projet est faible. Étant donné que le type List est généralement extrêmement volumineux, cela peut être la règle la plus simple à suivre. (Au début, je pensais qu'il s'agissait d'attacher un type à une variable, donc mon commentaire de réponse n'est pas pertinent.)