Convention pour les noms de fichiers de Classes Génériques
Je veux être en mesure de faire la distinction entre un générique et régulière (non générique) version d'une classe. Un peu comme le .NET framework ne avec elle est générique et non des versions génériques de plusieurs de ses interfaces et de classes de collection. (La file d'attente, La File D'Attente(T))
De manière générale, j'aime suivre la convention d'une classe par fichier (comme en Java). Est-il une convention pour nommer les fichiers contenant une seule classe générique? Je suis surtout intéressé à la Windows (NTFS en particulier), mais il semble comme une bonne convention serait (au moins un peu) portable.
- Pourriez-vous nous donner un exemple d'une classe spécifique et générique type avec le même nom (qui n'est probablement pas une idée fantastique pour commencer?) L' .NET non-types génériques sont là que pour la compatibilité descendante.
- "Pourriez-vous donner un exemple d'une classe spécifique et générique type avec le même nom" - vous avez fourni une réponse vous-même: une bibliothèque de classe qui a besoin de rétro-compatibilité!
Vous devez vous connecter pour publier un commentaire.
Chez Microsoft, ils utilisent
ClassNameOfT.cs
.ClassName(Of T)
MyClass<TKey, TValue, TConversion, TCallback>
->MyClassOfTKeyOfTValueOfTConversionOfTCallback.cs
?Viens de trouver cette question après la recherche de ce que les conventions d'autres personnes utiliser la classe générique des noms de fichiers.
Dernièrement, j'ai été en utilisant
ClassName[T].cs
. J'aime vraiment cette convention, et je pense qu'il est supérieur aux autres pour les raisons suivantes:peu plus que ce qu'ils font avec l'
Microsoft convention (par exemple,
ClassNameOfT.cs
).les paramètres de type sans trop de
confusion:
Dictionary[TKey,
TValue].cs
J'ai emprunté cette convention de Boo's syntaxe générique, quoique légèrement modifié (Boo utilise
ClassName[of T]
).Certains développeurs semblent avoir une phobie des noms de fichiers qui contiennent rien de mais des lettres et des caractères de soulignement, mais une fois que vous pouvez obtenir passé que cette convention semble très bien fonctionner.
IFoo.cs
etIFoo[T].cs
. Lorsque l'extension fonctionne pour nettoyer le non-document générique, elle affecte toujours le générique plutôt... Étrange comportement.[]
caractères dans les noms de fichier ont une signification spéciale sur les systèmes de type UNIX (similaire à ce qu'ils signifient dans une regex), afin de les utiliser dans les noms de fichiers peuvent forcer les utilisateurs sur les systèmes de type UNIX pour échapper les noms de fichier.Je vois que ce sujet a été abandonné plus d'un an, mais je tiens à partager mon point de vue sur cette convention.
Tout d'abord, le fait d'avoir plusieurs classes qui ont le même nom, mais diffèrent dans la quantité de paramètres n'est pas toujours une affaire de rétro-compatibilité. Sûrement, vous ne le voyez pas très souvent, mais la nouvelle Action - et Func-classes de .NET ont été seulement conçu de cette façon, et je suis en train de mettre en place quelque chose de similaire.
Pour la clarté et la distinguabilité, j'utilise la convention suivante qui spécifie uniquement le nombre d'arguments génériques pour un type donné:
De cette façon, mes noms de fichiers séjour courts et simples, tout en communiquant clairement le nom de classe et le nombre différent de paramètres de type, au prix d'un simple supplément de dot (qui est, dans mon expérience, communément acceptée chose à faire dans un nom de fichier et est beaucoup mieux que d'une virgule et d'autres non-alpanumeric personnages, mais c'est juste une question de goût je suppose). Mettre les noms (ou les acronymes) des paramètres de type juste allonge les noms de fichiers alors qu'à ce niveau je ne suis pas vraiment intéressé par les noms réels des paramètres de type et de toute façon...
MyClass.InnerClass.cs
ou un exemple, une combinaison de médicaments génériquesMyClass_T2.InnerClass.cs
. (J'aime utiliser des points pour les classes internes, car elle reflète la façon dont ils sont référencés dans le code).N'utilisez pas de l'accent grave ` dans votre générique les noms de fichiers si vous utilisez Visual Studio 2008. Il y a un problème connu avec eux qui provoque des points d'arrêt à l'échec:
http://connect.microsoft.com/VisualStudio/feedback/details/343042/grave-accent-in-filename-causes-failure-to-recognize-target-language-breakpoints-fail
Tous les nouveaux Microsoft classes d'utilisation des médicaments génériques. Le
Queue
etArrayList
étaient là avant les génériques est sorti. Les génériques est la voie à suivre.La convention pour une classe par fichier unique a pour nom le nom du fichier après le nom de la classe (si le générique de pas). Pour MyClass, vous aurez MyClas.cs. Pour chaque nouvel espace de noms, vous devez créer un nouveau dossier. C'est la façon dont Visual Studio fonctionne également.
Comment sur:
et
Chaque fois que je l'ai fait dans le passé, j'ai toujours mis les deux types dans un fichier avec le non-type générique comme nom de fichier. Je pense que ce qui rend les choses assez clair que .NET n'a pas de conventions/restrictions sur un type de fichier, comme Java.
Mais si vous le devez, alors je suggère quelque chose comme j'ai ci-dessus, et à l'aide d'un suffixe de rendre les fichiers affichent ensemble dans n'importe quelle liste par ordre alphabétique (l'Explorateur de solutions, l'Explorateur Windows, etc.).
Voici une autre idée:
Cela vous permettrait de briser les différents types génériques par le nombre de paramètres de type générique ils ont accepté. C'est juste une pensée, même si, comme je pense toujours qu'il serait plus simple de mettre tous les types dans un seul fichier.
Je serais probablement les mettre dans des dossiers et d'utiliser le mécanisme d'espace de noms à la place. Vous pouvez comparer avec le Système.Collections vs Système.Les Collections.Génériques. D'autre part, si c'est plus fréquent que les classes d'utilisation des génériques, c'est peut-être mieux pour ceux qui ne le sont pas. C'est si vous voulez vraiment séparer les classes génériques en provenance d'autres classes. Personnellement j'ai l'habitude de ne pas la peine de le faire, car je ne vois vraiment pas pratique en bénéficier.
De réponses jusqu'à présent, il semble qu'il n'existe pas de consensus.
En utilisant le même nom de fichier dans un sous-espace de noms (et sous-dossier) "Génériques" (comme Système.Collecctions.Les génériques) est une option. Mais il n'est pas toujours souhaitable de créer un nouvel espace de noms.
Par exemple, dans un espace de noms avec les classes génériques qui sont maintenues pour assurer la compatibilité ascendante, mais marqué avec ObsoleteAttribute, il est probablement préférable de garder les versions génériques dans le même espace de noms.
Je pense qu'un suffixe est un moyen raisonnable d'y aller. J'ai adopté une convention d'utiliser les paramètres de type comme suffixe (donc: MyClassT pour Maclasse<T>, ou MyDictionaryKV pour Mondictionnaire<K,V>.
Personnellement, je ne voudrais pas utiliser de l'accent grave notation:
Pour la simple raison que j'ai peur de l'accent grave. Non seulement a-t-elle un effrayant nom , mais je suis pas certain de savoir comment elle sera traitée par les différents systèmes de fichiers, systèmes de contrôle de version et dans les Url. Donc, je préfère coller à la commune des caractères alphanumériques.
NameOfT.cs
semble être utilisé dans ASP.NET de Base, selon une recherche sur GitHub. 19 résultats. Référence.Également l'utilisation limitée dans CoreFX. 3 résultats. Référence.
Exemple:
J'aurais probablement deux dossiers dans le projet, quelque chose comme Gereric, NonGeneric ou quelque chose comme ça. Ils peuvent encore être dans le même espace de noms, et ils peuvent tous les deux ont le même nom de fichier. Juste une pensée...
Il m'arrive aussi de voir
ClassName{T}.cs
mais il est fréquent de nom ilClassNameOfT.cs
(comme mentionné avant que Microsoft l'utilise)EntityFrameworkCore projet(également Microsoft) utilise
ClassName`.cs