Intereting Posts

Identifiant de bundle et certificate push… Erreur de droit d’access aps-environment Pourquoi git stash -p échoue-t-il parfois? Transfert-encodage: gzip vs encodage-contenu: gzip Pourquoi utiliser des instructions do-while et if-else apparemment sans signification dans les macros? Le fichier .app apparaît en rouge (manquant) dans les nouveaux projets avec Xcode 4 TaskCompletionSource ou alternative non générique L’application référence des sélecteurs non publics dans Payload / .app / : decoder AWS Load Balancer avec une adresse IP statique Aucun mappage de sous-module trouvé dans .gitmodule pour un chemin qui n’est pas un sous-module Xamarin vs. Mono vs. Monodevelop Documentation JDK dans IntelliJ IDEA sur Mac OS X Comment le type mime d’un fichier téléchargé est-il déterminé par le navigateur? Quelles extensions Haskell (GHC) les utilisateurs devraient-ils utiliser / éviter? Visual Studio – raccourci pour accéder à l’explorateur de solutions Lier R et Julia?

Dois-je arrêter de lutter contre la convention de nommage par défaut de Visual Studio?

Je travaille sur un projet MVVM, j’ai donc des dossiers dans mon projet tels que Models, 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 noms. espace de noms de niveau. Ainsi, l’ajout d’une nouvelle classe dans le dossier ViewModels se traduirait par l’espace de noms MyProject.ViewModels au lieu de MyProject .

Quand je l’ai rencontré pour la première fois, cela m’a ennuyé. Mes noms de classe sont assez clairs, contenant parfois même le nom du dossier (par exemple, ContactViewModel ). Je me suis rapidement retrouvé à supprimer 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 continuez à le faire manuellement.

J’ai commencé à me demander si cette convention existe pour une bonne raison que je ne vois pas. Je pourrais voir cela utile si, pour une raison quelconque, vous aviez de nombreux ensembles de noms de classe identiques organisés dans des dossiers, mais cela ne semble pas être un scénario particulièrement courant.

Des questions:

Pourquoi est-il courant que les noms d’espaces de noms reflètent la structure des dossiers?
Respectez-vous cette convention? Pourquoi?

Comme toi – je me suis battu pendant longtemps. Ensuite, j’ai commencé à me demander pourquoi j’avais créé des dossiers. Je me suis retrouvé à créer des dossiers pour représenter des espaces de noms et des packages au lieu de compartiments arbitraires.

Par exemple, dans un projet MVVM, il peut être utile de placer des vues et des modèles de vue dans un espace de noms distinct. MVC aura un espace de noms distinct 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 se sent plus organisé. Il est plus facile pour les autres développeurs de trouver où les fonctionnalités sont implémentées.

Si vous standardisez vos pratiques d’espaces de noms, tous vos projets auront la même structure prévisible, ce qui sera un gros avantage pour la maintenance.

Si vous souhaitez des conseils avisés, je vous recommande d’acheter des directives de conception de structure: conventions, expressions idiomatiques et modèles pour les bibliothèques .NET réutilisables, ce qui vous permet de tout savoir de l’équipe de conception de la structure.

… le but lors de la dénomination des espaces de noms est de créer une clarté suffisante pour que le programmeur utilise le framework pour savoir immédiatement quel est le contenu de l’espace de nommage …

 .(|)[.][.]

Et surtout

N’utilisez pas le même nom pour un espace de noms et un type dans cet espace de noms

Fragmenter tous les types 1/2 dans des espaces de noms ne répondrait pas à la première exigence, car vous auriez un marais d’espaces de noms à qualifier ou à utiliser, si vous suiviez la méthode Visual Studio. Par exemple

Core – Domain – Utilisateurs – Autorisations – Comptes

Voulez-vous créer

MyCompany.Core.Domain.Users
MyCompany.Core.Domain.Permissions
MyCompany.Core.Domain.Account

ou juste

MyCompany.Core.Domain

Pour Visual Studio, ce serait le premier. Aussi, si vous utilisez des noms de fichiers / dossiers minuscules, vous envisagez de renommer la classe à chaque fois, ainsi que de créer un grand enchevêtrement d’espace de noms.

Il s’agit en grande partie du bon sens et de la manière dont vous vous attendez à voir les espaces de noms organisés si vous êtes consommateur de votre propre API ou de votre propre framework.

Cela m’a ennuyé aussi, mais travailler avec des projets avec des bases de code volumineuses m’a rapidement appris le contraire. Ayant adopté le concept, je pense que c’est un très bon moyen de structurer votre code aussi bien physiquement que logiquement. Lorsque vous avez un grand projet 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, alors 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.

En tout cas, c’est une convention que j’aime vraiment. Si je divise les types en dossiers, ces types ont probablement un type de regroupement conceptuel lié au dossier. Par conséquent, cela prend du sens, leurs espaces de noms sont également similaires. Java adopte cette approche et l’applique avec son système de package. La plus grande différence est que VS ne vous le “suggère” que parce que ni le langage ni le CLR ne l’appliquent.

Les dossiers du système de fichiers et les espaces de noms représentent tous deux une hiérarchie. Je semble parfaitement naturel de faire correspondre les deux. Je vais encore plus loin et j’utilise une relation 1: 1 entre les fichiers et les classes. Je le fais même lorsque je programme dans d’autres langues telles que C ++.

Maintenant que vous remettez en question la relation entre ces deux hiérarchies, je me demande sérieusement ce que vous souhaitez représenter par la hiérarchie du système de fichiers.

Bien que je sois d’accord 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 racine “src” pour séparer visuellement mon code des ressources incorporées
Je veux une capitalisation différente
Je vais organiser mon code en 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

Avec ces raisons, je me suis résigné à devoir les ajuster pour chaque classe que je crée. Ma stratégie pour éviter le problème consiste à copier un fichier contenant la déclaration d’espace de noms souhaitée, puis à supprimer immédiatement le contenu.

Avant l’introduction des espaces de noms en C ++, tous les types C étaient dans l’espace de noms global. Les espaces de noms ont été créés pour séparer les types dans des conteneurs logiques, de sorte qu’il était clair à quel type fait référence. Cela s’applique également à C #.

Les assemblées sont une décision de déploiement. Si vous examinez le framework .Net, un assembly donné contiendra plusieurs espaces de noms différents.

Le dossier doit 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, le nom de l’espace et le nom du dossier soient les mêmes. Notez que Java réduit les dossiers et les espaces de noms de la même manière (ce qui limite la liberté du développeur d’organiser les fichiers et les espaces de noms).

Souvent, nous choisissons d’organiser les fichiers d’un projet dans plusieurs dossiers, car il est plus facile pour moi ou pour mon équipe de naviguer dans les fichiers. Habituellement, cette organisation de fichiers n’a rien à voir avec la conception de l’espace de noms que nous utilisons. Je souhaite que l’équipe VS ne fasse pas par défaut de l’espace de noms le même que le nom du dossier ou au moins lui donne l’option de ne pas avoir ce paramètre 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 ressens également la douleur avec ce comportement par défaut dans Visual Studio.

Visual Studio essaie également de définir une correspondance espace-noms / répertoire lorsque vous placez vos fichiers LinqToSql .dbml dans leur propre répertoire. Chaque fois que je .dbml le .dbml , je dois me rappeler de:

Ouvrez le fichier .dbml.designer.cs
supprimer le nom du répertoire / dossier de la déclaration d’ namespace

Il y a un moyen d’ arrêter ce comportement , cependant. Cela implique la création d’un modèle de classe personnalisé.

Je pense qu’il existe des raisons valables d’avoir différentes structures pour les espaces de noms et les dossiers de projets. Si vous développez une bibliothèque, la structure de l’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 doit être principalement là pour vous simplifier la vie, le concepteur de l’ API . Certains objectives sont en effet très similaires, comme si la structure devait aussi être logique. Mais il peut aussi y en avoir différents, par exemple, vous pouvez rapidement sélectionner des fichiers associés pour l’outillage, ou il est facile de naviguer. J’ai moi-même par exemple tendance à créer de nouveaux dossiers lorsqu’un certain seuil de fichier est atteint, sinon cela prend trop de temps à localiser le fichier que je recherche. Mais respecter les préférences du concepteur peut également signifier suivre ssortingctement l’espace de nommage – si tel est leur choix.

Donc dans l’ensemble, dans de nombreux cas, il est logique que les deux correspondent, mais je pense qu’il y a des cas valables à dévier.

Ce qui a été utile dans le passé pour moi, c’est de créer un fichier (par exemple WPF UserControl) dans un seul endroit pour récupérer l’espace de noms, puis de le déplacer dans le bon dossier.

Bien que je reconnaisse que faire correspondre la hiérarchie des espaces de noms à la hiérarchie des dossiers est une bonne idée, je pense que le fait que Visual Studio ne semble pas prendre en charge cette fonctionnalité est répugnant. Visual Studio possède de nombreuses applications et il existe de nombreux styles de codage et méthodes de structuration des dossiers de fichiers sources parfaitement adaptés.

Disons qu’il y a des milliers de fichiers qui appartiennent à un espace de noms, mais le programmeur veut juste les regrouper dans des dossiers pour faciliter la navigation dans la hiérarchie. Est-ce vraiment une si mauvaise idée? Est-ce que cela rendra les choses tellement impossibles à entretenir qu’elles devraient être interdites 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 Assets inutile qui ne contient pas de scripts, mais “Assets.Scripts” n’a pas de sens – il ne décrit pas le projet ou la partie du projet auquel le fichier source appartient. Inutile.