Devrais-je arrêter de lutter contre la convention de dénomination d'espace de nom par défaut de Visual Studio?
Je travaille sur un projet MVVM. J'ai donc des dossiers dans mon projet, tels que Modèles, ViewModels, Windows, etc. À chaque fois que je crée une nouvelle classe, Visual Studio ajoute automatiquement le nom du dossier à la désignation de l'espace de nom au lieu de le conserver espace de noms de niveau. Ainsi, l’ajout d’une nouvelle classe au dossier ViewModels aurait pour résultat l’espace de nom, MyProject.ViewModels au lieu de MyProject.
Quand j'ai rencontré cela pour la première fois, cela m'a agacé. Les noms de mes classes sont assez clairs, contenant parfois même le nom du dossier (par exemple, ContactViewModel). Je me suis rapidement retrouvé en supprimant manuellement le nom du dossier sur les espaces de noms. J'ai même essayé à un moment de créer un modèle de classe personnalisé (voir cette question ), mais je ne pouvais pas le faire fonctionner, alors j'ai continué à le faire manuellement.
Je commence cependant à me demander si cette convention existe pour une bonne raison que je ne vois pas. Je pensais que ce serait utile si, pour une raison quelconque, vous aviez beaucoup de jeux de noms de classes identiques organisés en dossiers, mais cela ne semble pas être un scénario particulièrement courant.
Des questions:
- Pourquoi est-il habituel que les noms d'espaces de noms reflètent la structure des dossiers?
- Est-ce que vous respectez cette convention? Pourquoi?
Comme toi - je me suis battu pendant très longtemps. Ensuite, j'ai commencé à comprendre pourquoi j'avais créé des dossiers. Je me suis retrouvé en train de créer des dossiers pour représenter des espaces de noms et des packages plutôt que des compartiments arbitraires.
Par exemple, dans un projet MVVM, il peut être utile de placer les vues et les modèles de vue dans un espace de noms séparé. MVC aura un espace de noms séparé pour les modèles, les contrôleurs et les vues. Il est également avantageux de regrouper les classes en fonction de leurs caractéristiques.
Soudain, le projet semble plus organisé. Il est plus facile pour les autres développeurs de trouver où les fonctionnalités sont implémentées.
Si vous normalisez les pratiques de votre espace de noms, tous vos projets auront la même structure prévisible, ce qui sera un grand avantage pour la maintenance.
Si vous souhaitez des conseils avisés, je vous conseille d’acheter Directives pour la conception de framework: Conventions, expressions et modèles pour les bibliothèques .NET réutilisables qui vous donne tout ce que vous devez savoir sur l’équipe de conception de framework.
... lorsque vous nommez des espaces de noms, l'objectif est de créer suffisamment de clarté pour que le programmeur utilisant le framework puisse savoir immédiatement ce que le contenu de l'espace de noms est susceptible d'être ...
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
Et surtout
Ne pas utiliser le même nom pour un espace de noms et un type dans cet espace de noms
Fragmenter tous les 1/2 types en espaces de noms ne répondrait pas à la première exigence, car vous auriez un marais d'espaces de noms qui devraient être qualifiés ou utilisés si vous suiviez la méthode Visual Studio. Par exemple
Coeur - Domaine - Utilisateurs - Autorisations - les comptes
Souhaitez-vous créer
- MyCompany.Core.Domain.Users
- MyCompany.Core.Domain.Permissions
- MyCompany.Core.Domain.Accounts
ou juste
- MyCompany.Core.Domain
Pour Visual Studio, ce serait le premier. De même, si vous utilisez le nom de fichier/dossier en minuscule, vous envisagez de renommer la classe à chaque fois, ainsi que de créer un grand enchevêtrement d'espace de noms.
Cela relève en général du bon sens et de la manière dont vous vous attendez à voir les espaces de noms organisés si vous était un consommateur de votre propre API ou framework.
cela me gênait aussi, mais travailler avec et refactoriser des projets avec de grandes bases de code m'a vite appris le contraire. Ayant adopté le concept, je pense que c'est un très bon moyen de structurer votre code "physiquement" ainsi que logiquement. Lorsque vous avez un projet volumineux et que les espaces de noms ne correspondent pas aux dossiers, il devient difficile de localiser rapidement les fichiers. C'est aussi beaucoup plus difficile de se rappeler où sont les choses ...
De plus, si ReSharper le recommande, c'est probablement une bonne idée. Par exemple. R # se plaindra si l'espace de noms de votre classe ne correspond pas à son nom de dossier.
Une façon de ne pas suivre la convention consiste à créer le fichier dans le dossier racine du projet, puis à le déplacer dans le sous-dossier final.
Quoi qu’il en soit, c’est une convention que j’aime bien. Si je divise des types en dossiers, alors ces types ont probablement une sorte de regroupement conceptuel lié au dossier. Par conséquent, cela a un sens, leurs espaces de noms sont également similaires. Java adopte cette approche et l’applique avec son système de paquets. La plus grande différence est que VS ne fait que "vous le suggérer", puisque ni le langage ni le CLR ne l’imposent.
Les dossiers et les espaces de noms du système de fichiers représentent tous deux une hiérarchie. Il me semble parfaitement naturel de faire correspondre les deux. Je vais même plus loin et utilise une relation 1: 1 entre les fichiers et les classes. Je le fais même quand je programme dans d'autres langages tels que C++.
Maintenant que vous vous interrogez sur la relation entre ces deux hiérarchies, je me demande sérieusement ce que vous voudriez représenter par la hiérarchie du système de fichiers.
Bien que je convienne avec tout le monde qu'une structure physique correspondant à la structure logique est utile, je dois dire que je me bats également avec le nommage automatique de Visual Studio. Il y a une demi-douzaine de raisons pour lesquelles je dois renommer des classes:
- J'utilise un dossier "src" racine pour séparer visuellement mon code des ressources incorporées
- Je veux une capitalisation différente
- Je vais organiser mon code dans des sous-dossiers pour l'organisation dans un espace de noms
- J'aime séparer les interfaces des implémentations et des classes de base
- J'en ai envie
Pour ces raisons, je me suis résigné à devoir ajuster celles de chaque classe que je crée. Ma stratégie pour éviter ce problème consiste à copier un fichier contenant la déclaration d’espace de nom souhaitée, puis à en supprimer immédiatement le contenu.
Avant l'introduction des espaces de noms en C++, tous les types C se trouvaient dans l'espace de noms global. Les espaces de noms ont été créés pour séparer les types dans des conteneurs logiques. Le type auquel il est fait référence était donc clair. Ceci s'applique également à C #.
Les assemblages sont une décision de déploiement. Si vous examinez le cadre .Net, un assemblage donné contiendra plusieurs espaces de nom différents.
Les dossiers doivent organiser les fichiers sur le disque.
Les trois n'ont rien à voir les uns avec les autres, cependant, il est souvent pratique que le nom de l'assembly, l'espace de nom et les noms de dossier soient les mêmes. Notez que Java réduit les dossiers et les espaces de noms pour qu'ils soient identiques (ce qui limite la liberté du développeur d'organiser les fichiers et les espaces de noms).
Nous choisissons souvent d'organiser les fichiers d'un projet dans plusieurs dossiers, car il est plus facile pour moi ou mon équipe de naviguer dans les fichiers. Habituellement, cette organisation de fichiers n'a rien à voir avec la conception d'espace de noms que nous utilisons. Je souhaite que l’équipe de VS ne définisse pas par défaut que l’espace de nom soit identique au nom du dossier ou, au moins, redonne l’option pour que ce ne soit pas celui-ci par défaut.
Ne souffrez pas, changez le modèle pour les nouvelles classes ou corrigez l'espace de noms après la création du nouveau fichier.
Je pense qu’il existe effectivement des raisons valables d’avoir des structures différentes pour les espaces de noms et les dossiers de projets. Si vous développez une bibliothèque, la structure d’espace de noms doit avant tout servir les utilisateurs de votre API: elle doit être logique et facile à comprendre. D'autre part, la structure des dossiers devrait être principalement là pour vous faciliter la vie, le concepteur de l'API. Certains objectifs sont en effet très similaires, de sorte que la structure devrait également être logique. Mais il peut aussi y en avoir différents, par exemple que vous pouvez sélectionner rapidement des fichiers associés pour l’outillage ou qu’il est facile de naviguer. J'ai moi-même tendance, par exemple, à créer de nouveaux dossiers lorsqu'un certain seuil de fichier est atteint, sinon la recherche du fichier que je cherche prend trop de temps. Mais respecter les préférences du concepteur peut aussi signifier de respecter strictement l’espace de nom - si tel est leur préférence.
Donc dans l’ensemble, dans de nombreux cas, il est logique que les deux concordent, mais je pense qu’il existe des cas valables à écarter.
Par le passé, ce qui a été utile pour moi a été de créer un fichier (par exemple, WPF UserControl) à un emplacement unique pour obtenir l’espace de nom correct, puis de le déplacer dans le dossier "correct".
Je ressens également la douleur avec ce comportement «par défaut» dans Visual Studio.
Visual Studio essaie également de définir une correspondance espace de nom/répertoire lorsque vous placez vos fichiers LinqToSql .dbml dans leur propre répertoire. Chaque fois que je modifie le .dbml, je dois me rappeler de:
- ouvrez le fichier
.dbml.designer.cs - supprime le nom du répertoire/dossier de la déclaration
namespace
Il y a un moyen de arrêter ce comportement , cependant. Cela implique la création d'un modèle de classe personnalisé.
Bien que je convienne qu'il est pratique de faire correspondre la hiérarchie des espaces de noms à la hiérarchie des dossiers, c'est une bonne idée, je pense que le fait que Visual Studio ne semble pas prendre en charge la désactivation de cette fonctionnalité est dégoûtant. Visual Studio comporte de nombreuses applications et propose de nombreux styles de codage et méthodes de structuration des dossiers de fichiers source.
Supposons que des milliers de fichiers appartiennent à un espace de noms, mais le programmeur souhaite simplement les regrouper dans des dossiers afin de faciliter la navigation dans la hiérarchie. Est-ce vraiment une si mauvaise idée? Est-ce que cela rendra vraiment les choses tellement impossibles à maintenir que cela devrait être interdit par l'IDE ???
Disons que j'utilise Visual Studio pour travailler avec Unity. Maintenant, tous mes scripts sont dans l'espace de noms "Assets.Scripts". Non seulement il y a un espace de noms inutile Assets qui ne contient pas de script, mais "Assets.Scripts" n'a pas de sens - il ne décrit pas le projet ni la partie de projet auquel le fichier source appartient. Inutile.