Les dossiers d’une solution doivent-ils correspondre à l’espace de noms?

Les dossiers d’une solution doivent-ils correspondre à l’espace de noms?

Dans l’un des projets de mes équipes, nous avons une bibliothèque de classes contenant de nombreux sous-dossiers dans le projet.

Nom du projet et espace de noms: MyCompany.Project.Section .

Dans ce projet, plusieurs dossiers correspondent à la section d’espace de noms:

  • Dossier Vehicles a des classes dans l’espace de noms MyCompany.Project.Section.Vehicles
  • Dossier Clothing a des classes dans l’espace de noms MyCompany.Project.Section.Clothing
  • etc.

Dans ce même projet, se trouve un autre dossier malhonnête

  • Dossier BusinessObjects a des classes dans l’espace de noms MyCompany.Project.Section

Il existe quelques cas comme celui-ci où les dossiers sont créés pour une “commodité organisationnelle”.

Ma question est la suivante: quelle est la norme? Dans les bibliothèques de classes, les dossiers correspondent-ils généralement à la structure de l’espace de noms ou s’agit-il d’un système mixte?

Notez également que si vous utilisez les modèles intégrés pour append des classes à un dossier, il sera par défaut placé dans un espace de noms reflétant la hiérarchie des dossiers.

Les cours seront plus faciles à trouver et cela seul devrait être des raisons suffisantes.

Les règles que nous suivons sont les suivantes:

  • Le nom du projet / assemblage est identique à l’espace de noms racine, à l’exception de la fin du fichier .dll
  • Seule exception à la règle ci-dessus est un projet avec une fin .Core, le .Core est supprimé
  • Les dossiers correspondent aux espaces de noms
  • Un type par fichier (classe, struct, enum, delegate, etc.) facilite la recherche du fichier approprié

Je pense que la norme, au sein de .NET, est d’essayer de le faire lorsque cela est possible, mais pas de créer des structures inutilement profondes simplement pour y adhérer en tant que règle ssortingcte. Aucun de mes projets ne suit la règle de structure de l’espace de nommage == 100% du temps, parfois c’est juste plus propre / mieux pour sortir de ces règles.

En Java, vous n’avez pas le choix. J’appellerais cela un cas classique de ce qui fonctionne en théorie par rapport à ce qui fonctionne dans la pratique.

Non.

J’ai essayé les deux méthodes sur des projets de petite et grande envergure, à la fois avec single (moi) et une équipe de développeurs.

J’ai trouvé que l’itinéraire le plus simple et le plus productif était d’avoir un seul espace de noms par projet et que toutes les classes entraient dans cet espace de noms. Vous êtes alors libre de placer les fichiers de classe dans les dossiers de projet de votre choix. Ajouter des instructions en haut des fichiers ne pose aucun problème car il n’y a qu’un seul espace de noms.

Il est important d’organiser les fichiers sources en dossiers et à mon avis, tous les dossiers doivent être utilisés. Exiger que ces dossiers mappent également sur les espaces de noms est inutile, crée plus de travail et j’ai trouvé que cela était réellement dangereux pour l’organisation car le fardeau supplémentaire encourageait la désorganisation.

Prenez cet avertissement FxCop par exemple:

CA1020: Évitez les espaces de noms avec peu de types
cause: un espace de noms autre que l’espace de noms global contient moins de cinq types https://msdn.microsoft.com/en-gb/library/ms182130.aspx

Cet avertissement encourage le vidage de nouveaux fichiers dans un dossier Project.General générique, ou même la racine du projet jusqu’à ce que vous ayez quatre classes similaires pour justifier la création d’un nouveau dossier. Est-ce que cela arrivera jamais?

Recherche de fichiers

La réponse acceptée dit “Les cours seront plus faciles à trouver et cela seul devrait être des raisons assez bonnes.”

Je pense que la réponse fait référence à avoir plusieurs espaces de noms dans un projet qui ne correspondent pas à la structure des dossiers, plutôt que ce que je suggère, à savoir un projet avec un seul espace de noms.

Dans tous les cas, alors que vous ne pouvez pas déterminer le dossier dans lequel se trouve un fichier de classe à partir de l’espace de noms, vous pouvez le trouver à l’aide de l’option Aller à la définition ou de l’explorateur de solution de recherche dans Visual Studio. De plus, ce n’est pas vraiment un gros problème à mon avis. Je ne consacre même pas 0,1% de mon temps de développement au problème de la recherche de fichiers pour justifier son optimisation.

Nom des affrontements

Bien sûr, la création de plusieurs espaces de noms permet au projet d’avoir deux classes portant le même nom. Mais est-ce vraiment une bonne chose? Est-ce que c’est peut-être plus facile de refuser cela? Autoriser deux classes du même nom crée une situation plus complexe où 90% du temps, les choses fonctionnent d’une certaine manière et puis soudain, vous trouvez que vous avez un cas particulier. Supposons que vous ayez deux classes Rectangle définies dans des espaces de noms distincts:

  • classe Project1.Image.Rectangle
  • classe Project1.Window.Rectangle

Il est possible de rencontrer un problème pour lequel un fichier source doit inclure les deux espaces de noms. Maintenant, vous devez écrire l’espace de noms complet partout dans ce fichier:

 var rectangle = new Project1.Window.Rectangle(); 

Ou déranger avec une déclaration utilisant méchant:

 using Rectangle = Project1.Window.Rectangle; 

Avec un seul espace de noms dans votre projet, vous êtes obligé de trouver des noms différents, et je dirais plus descriptif, comme ceci:

  • class Project1.ImageRectangle
  • classe Project1.WindowRectangle

Et l’utilisation est la même partout, vous n’avez pas à gérer un cas particulier lorsqu’un fichier utilise les deux types.

en utilisant des déclarations

 using Project1.General; using Project1.Image; using Project1.Window; using Project1.Window.Controls; using Project1.Shapes; using Project1.Input; using Project1.Data; 

contre

 using Project1; 

La facilité de ne pas avoir à append d’espaces de noms tout le temps lors de l’écriture du code. Ce n’est pas le temps qu’il faut vraiment, c’est le temps de devoir le faire et de remplir des fichiers avec beaucoup de déclarations – pour quoi? Est-ce que ça vaut le coup?

Modification de la structure du dossier de projet

Si les dossiers sont mappés aux espaces de noms, le chemin du dossier de projet est effectivement codé en dur dans chaque fichier source. Cela signifie que tout changement de nom ou de déplacement d’un fichier ou d’un dossier dans le projet nécessite la modification du contenu du fichier. La déclaration de l’espace de noms des fichiers dans ce dossier et l’utilisation des instructions dans tout un tas d’autres fichiers qui font référence aux classes dans ce dossier. Bien que les modifications elles-mêmes soient sortingviales avec les outils, cela se traduit généralement par une grande validation composée de nombreux fichiers dont les classes n’ont même pas été modifiées.

Avec un seul espace de noms dans le projet, vous pouvez modifier la structure du dossier de projet comme vous le souhaitez sans qu’aucun fichier source ne soit lui-même modifié.

Visual Studio mappe automatiquement l’espace de noms d’un nouveau fichier dans le dossier du projet qu’il a créé.

Malheureusement, je trouve que corriger l’espace de nommage est moins compliqué que d’y faire face. J’ai aussi pris l’habitude de copier coller un fichier existant plutôt que d’utiliser Add-> New.

Navigateur Intellisense et Objet

Le plus grand avantage à mon avis d’utiliser plusieurs espaces de noms dans les grands projets est d’avoir une organisation supplémentaire lors de l’affichage des classes dans n’importe quel outil affichant des classes dans une hiérarchie d’espaces de noms. Même documentation. De toute évidence, le fait d’avoir un seul espace de noms dans le projet permet d’afficher toutes les classes dans une seule liste plutôt que de les diviser en catégories. Cependant, personnellement, je n’ai jamais été déconcerté ou retardé à cause d’un manque de cela, donc je ne trouve pas un avantage suffisant pour justifier plusieurs espaces de noms.

Bien que si j’écrivais une grande bibliothèque publique, j’utiliserais probablement plusieurs espaces de noms dans le projet pour que l’assemblage soit soigné dans les outils et la documentation.

@lassevk: Je suis d’accord avec ces règles et j’en ai encore une à append.

Lorsque j’ai des classes nestedes, je les sépare toujours, une par fichier. Comme ça:

 // ----- Foo.cs partial class Foo { // Foo implementation here } 

et

 // ----- Foo.Bar.cs partial class Foo { class Bar { // Foo.Bar implementation here } } 

Je dirais oui.

Tout d’abord, il sera plus facile de trouver les fichiers de code réels en suivant les espaces de noms (par exemple, quand quelqu’un vous envoie par courrier électronique une stack d’appels d’exception nue). Si vous laissez vos dossiers se désynchroniser avec les espaces de noms, trouver des fichiers dans de grandes bases de données devient fatiguant.

Deuxièmement, VS générera de nouvelles classes que vous créez dans des dossiers avec le même espace de noms de la structure de dossiers parent. Si vous décidez de nager contre cela, ce ne sera qu’un travail de plomberie supplémentaire à effectuer chaque jour lors de l’ajout de nouveaux fichiers.

Bien sûr, cela va sans dire qu’il faut être prudent quant à la profondeur de la hiérarchie des dossiers / espaces de noms xis.

Oui, ils ne devraient que mener à la confusion sinon.

Quelle est la norme?

Il n’y a pas de norme officielle, mais classiquement, le modèle de mappage de dossier à espace de noms est le plus utilisé.

Dans les bibliothèques de classes, les dossiers correspondent-ils généralement à la structure de l’espace de noms ou s’agit-il d’un système mixte?

Oui, dans la plupart des bibliothèques de classes, les dossiers correspondent à l’espace de noms pour faciliter l’organisation.