Pourquoi ne préfixons-nous pas les énumérations, les classes abstraites et les structures?

La communauté C # a utilisé de manière omniprésente le préfixe «I» pour désigner une interface que même les programmeurs les moins expérimentés savent utiliser.

Pourquoi alors ne préfixons-nous pas des énumérations, des classes abstraites ou des structures (éventuellement avec "E", "A" et "S" respectivement)?

Par exemple, si nous marquions toutes les classes abstraites avec un "A", cela fournirait des informations précieuses sur ce type qui, bien qu'elles puissent être déduites, ne sont pas immédiatement évidentes.

Veuillez noter que je ne préconise pas ce changement, j'essaie simplement de comprendre pourquoi nous ne faisons pas les choses de cette façon.

Ce fil explique pourquoi nous utilisons le préfixe "I" mais ne répond pas pourquoi nous n'utilisons pas d' autres préfixes.

Le point de la convention de dénomination pour les interfaces est de fournir une décision rapide et sans cervelle sur ce qu'il faut appeler l'interface que votre classe implémente. Si vous en avez une Frobnicator, mais devez déclarer une interface pour le découplage ou pour une autre raison, alors la décision de l'appeler ne IFrobnicatornécessite aucune réflexion consciente, et c'est bien.

Le même problème ne s'applique pas aux autres constructions que vous nommez. Les énumérations et les structures sont utiles, mais il n'est pas nécessaire de trouver un deuxième nom court, transparent et apparenté en plus du nom lui-même. Par conséquent, il n'y a aucune pression pour gifler un «E» sur le nom d'une énumération ou d'une structure.

(Les classes abstraites sont quelque peu similaires aux interfaces, car vous devez fournir une deuxième classe concrète pour faire quoi que ce soit, donc elles pourraient avoir acquis une convention de commencer par 'A', mais pour une raison quelconque, elles ne l'ont pas fait. Si Je suis autorisé à spéculer, je pense que le `` je '' étant une lettre particulièrement étroite aurait pu y avoir quelque chose à voir.)

Je pense qu'il n'est pas beaucoup utilisé car:

• la plupart du temps, cela n'a pas beaucoup d'importance s'il s'agit d'une énumération, d'une classe abstraite ou d'une structure
• si cela importe, je peux probablement le voir à partir de l'utilisation et le découvrir autrement assez rapidement
• si je le change en étant une énumération, une classe abstraite ou une structure, je dois aussi le renommer
• pour les gens qui ne connaissent pas la convention c'est du bruit pur.
• les gens pourraient simplement rejeter l'idée parce qu'ils ont appris à ne pas utiliser la notation hongroise. Il y a eu et il y a toujours des gens qui disent que vous ne devriez pas utiliser la notation Hungarion, sans faire la distinction entre les applications hongroises et les systèmes hongrois. Une belle discussion peut être trouvée dans cette question SO . Non seulement la première réponse est intéressante, mais il y a d'excellentes réponses et commentaires. De cette même question vient cet article de Joel Spolsky (faites défiler jusqu'au paragraphe "Je suis la Hongrie")

en bref: en général, la valeur ajoutée ne correspond pas au coût.

À partir de ce dernier point et d'une certaine interprétation, vous pourriez conclure. Les systèmes hongrois (type préfixe) sont mauvais et ne doivent pas être utilisés. Les applications en hongrois (type préfixe) sont utilisées.

En reprenant votre question, je pense que la notation que vous proposez est une forme d'applications hongroises et si vous sentez que la valeur ajoutée s'ajoute aux coûts et que vous l'implémentez de manière cohérente dans votre base de code, c'est très bien. Mais comme vous devez le considérer par projet, cela ne devrait pas être une règle générale.

Je suppose que les gens ont remarqué qu'il importait plus souvent pour les interfaces et c'est pourquoi il est devenu une règle générale pour les interfaces.

Juste une pensée (si tout va bien applicable):

Il y a une tendance évidente vers le «codage vers les interfaces» plutôt que vers des classes concrètes. "De nos jours", il semble presque plus avantageux d'avoir une convention de dénomination pour les classes, comme les démarrer avec un "C", plutôt que d'avoir la lettre "I" pour l'interface.

Je viens de terminer un projet Java dans lequel toutes les interfaces étaient en fait appelées Model. Oui, la convention de nom d'interface était de terminer le nom par 'Model' ... puis d'avoir une sorte de 'DataTransferObject / DTO' implémenter l'interface comme :

public interface SomethingModel{
}

public class Something implements SomethingModel{
    //lets not line up braces and make it hard to read
    //at least it saves one line
}

alors qu'en C #

public interface ISomething{}

public class SomethingModel : ISomething
{
   //i can read this
}

Recâbler mon cerveau pour garder cette blessure droite, mais je peux voir comment cela pourrait aider à penser en termes de programmation à l'interface.