c# - utiliza - ¿Debería dejar de luchar contra la convención de nombres de espacio de nombres predeterminada de Visual Studio?

un espacio de nombres no puede contener directamente miembros como campos o métodos (10)

Estoy trabajando en un proyecto de MVVM, así que tengo carpetas en mi proyecto como Modelos, Modelos de Vista, Windows, etc. Cada vez que creo una nueva clase, Visual Studio agrega automáticamente el nombre de la carpeta a la designación del espacio de nombres en lugar de simplemente mantener el proyecto. nivel de espacio de nombres. Entonces, agregar una nueva clase a la carpeta ViewModels daría como resultado el espacio de nombre, MyProject.ViewModels lugar de solo MyProject .

Cuando me encontré con esto por primera vez, me molestó. Los nombres de mi clase son bastante claros, a veces incluso contienen el nombre de la carpeta en ellos (por ejemplo, ContactViewModel ). Rápidamente me encontré a mí mismo eliminando manualmente el nombre de la carpeta en los espacios de nombres. Incluso intenté en un momento crear una plantilla de clase personalizada (ver esta pregunta ), pero no pude lograr que funcionara, así que continué haciéndolo manualmente.

Empecé a preguntarme si esta convención existe por una buena razón que simplemente no veo. Podría ver que es útil si, por algún motivo, tienes muchos grupos de nombres de clases idénticos organizados en carpetas, pero eso no parece ser un escenario particularmente común.

Preguntas:

¿Por qué es una convención común que los nombres de los espacios de nombres reflejen la estructura de las carpetas?
¿Acatas esta convención? ¿Por qué?

Antes de que se introdujeran los espacios de nombres en C ++, todos los tipos de C estaban en el espacio de nombres global. Los espacios de nombres se crearon para segregar tipos en contenedores lógicos, por lo que quedó claro a qué tipo se hace referencia. Esto también se aplica a C #.

Los ensamblados son una decisión de implementación. Si observa el marco .Net, un ensamblaje dado contendrá múltiples espacios de nombres diferentes.

La carpeta debe organizar los archivos en el disco.

Los tres no tienen nada que ver entre sí, sin embargo, a menudo es conveniente que el nombre del ensamblado, el espacio de nombres y el nombre de la carpeta sean los mismos. Tenga en cuenta que Java colapsa las carpetas y espacios de nombres para que sean lo mismo (lo que limita la libertad del desarrollador para organizar archivos y espacios de nombres).

A menudo optamos por organizar los archivos de un proyecto en varias carpetas porque es más fácil para mí o para mi equipo navegar por los archivos. Por lo general, esta organización de archivos no tiene nada que ver con el diseño del espacio de nombres que utilizamos. Desearía que el equipo de VS no cambiara el nombre del espacio de nombres para que sea el mismo que el nombre de la carpeta o al menos devuelva la opción para que no sea el valor predeterminado.

No sufra, cambie la plantilla para las nuevas clases o corrija el espacio de nombres una vez que se haya creado el nuevo archivo.

Creo que hay razones válidas para tener diferentes estructuras para espacios de nombres y carpetas de proyectos. Si está desarrollando una biblioteca, la estructura del espacio de nombres debe servir ante todo a los usuarios de su API: debe ser lógica y fácil de entender. Por otro lado, la estructura de la carpeta debe estar allí principalmente para facilitarle la vida, el diseñador de la API . Algunos objetivos son muy similares, como que la estructura también debería ser lógica. Pero también puede haber otros diferentes, por ejemplo, que puede seleccionar rápidamente archivos relacionados para herramientas, o que es fácil de navegar. Yo mismo, por ejemplo, tiendo a crear nuevas carpetas cuando se alcanza un determinado umbral de archivo, de lo contrario, lleva demasiado tiempo encontrar el archivo que estoy buscando. Pero respetar las preferencias del diseñador también puede significar seguir estrictamente el espacio de nombres, si esa es su preferencia.

Entonces, en general, en muchos casos tiene sentido que ambos coincidan, pero creo que hay casos válidos para desviarse.

Lo que ha sido útil en el pasado para mí fue crear un archivo (por ejemplo, WPF UserControl) en un lugar para obtener el espacio de nombre correcto y luego moverlo a la carpeta "derecha".

Esto también me molestó, pero trabajar con proyectos de refacturación con grandes bases de código me enseñó rápidamente lo contrario. Habiendo adoptado el concepto, creo que es una muy buena forma de estructurar su código "físicamente" y lógicamente. Cuando tiene un proyecto grande y los espacios de nombres no coinciden con las carpetas, es difícil localizar los archivos rápidamente. También es mucho más difícil recordar dónde están las cosas ...

Además, si ReSharper lo recomienda, entonces probablemente sea una buena idea. Por ejemplo, R # se quejará si el espacio de nombre de su clase no coincide con el nombre de su carpeta.

Igual que tú, luché contra esto por mucho tiempo. Entonces comencé a considerar por qué creé carpetas. Empecé a crear carpetas para representar espacios de nombres y paquetes en lugar de segmentos arbitrarios.

Por ejemplo, en un proyecto de MVVM, podría ser útil colocar vistas y ver modelos en un espacio de nombres separado. MVC tendrá un espacio de nombre separado para Modelos, Controladores y Vistas. También es beneficioso para las clases grupales según su característica.

De repente, el proyecto se siente más organizado. Es más fácil para otros desarrolladores encontrar dónde se implementan las características.

Si estandariza sus prácticas de espacio de nombres, todos sus proyectos tendrán la misma estructura predecible, lo que será una gran ganancia para el mantenimiento.

Las carpetas del sistema de archivos y los espacios de nombres representan una jerarquía. Me parece perfectamente natural que coincida con los dos. Voy incluso un paso más allá y uso una relación 1: 1 entre archivos y clases. Incluso lo hago cuando programo en otros idiomas como C ++.

Ahora que cuestionas la relación entre estas dos jerarquías, realmente me pregunto qué te gustaría representar mediante la jerarquía del sistema de archivos.

Si bien estoy de acuerdo con todos los demás, que una estructura física que coincida con la estructura lógica es útil, debo decir que también lucho con el auto-nombramiento de Visual Studio. Hay media docena de razones por las que tengo que cambiar el nombre de las clases:

Uso una carpeta raíz "src" para separar visualmente mi código de los recursos integrados
Quiero diferente capitalización
Organizaré mi código en subcarpetas para la organización dentro de un espacio de nombres
Me gusta separar las interfaces de las implementaciones y las clases base
Tengo ganas

Con muchísimas razones, me he resignado a tener que ajustarlas para cada clase que creo. Mi estrategia para evitar el problema es copiar un archivo que tenga la declaración del espacio de nombres que deseo, y luego eliminar de inmediato el contenido.

Si bien estoy de acuerdo en que la coincidencia de la jerarquía del espacio de nombres con la jerarquía de carpetas es útil, y una buena idea, creo que el hecho de que Visual Studio no parece ser compatible con el cambio de esta característica es desagradable. Visual Studio tiene muchas aplicaciones, y hay muchos estilos de codificación y formas de estructurar las carpetas de archivos de origen que están perfectamente bien.

Digamos que hay miles de archivos que pertenecen a un espacio de nombres, pero el programador solo quiere agruparlos en carpetas para facilitar la navegación de la jerarquía. ¿Es realmente una mala idea? ¿Esto realmente hará las cosas tan inmanejables que debería estar prohibido por el IDE?

Digamos que estoy usando Visual Studio para trabajar con Unity. Ahora, todos mis scripts están en el espacio de nombres "Assets.Scripts". No solo hay un espacio de nombres de Activos inútiles que no contiene scripts ahora, sino que "Assets.Scripts" no tiene sentido; no describe a qué proyecto o parte del proyecto pertenece el archivo fuente. Inútil.

Si desea obtener algunos consejos sólidos, le recomiendo comprar las Pautas de diseño de marcos: Convenciones, modismos y patrones para bibliotecas .NET reutilizables, que le brinda todo lo que necesita saber del equipo de diseño del marco actual.

... el objetivo al nombrar espacios de nombres es crear suficiente claridad para que el programador que utiliza el marco de trabajo sepa de inmediato cuál es el contenido del espacio de nombres ...

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Y lo más importante

No use el mismo nombre para un espacio de nombres y un tipo en ese espacio de nombres

Fragmentar cada 1/2 tipos en espacios de nombres no cumpliría con el primer requisito, ya que tendría un pantano de espacios de nombres que tendrían que ser calificados o utilizados, si seguía el método de Visual Studio. Por ejemplo

Núcleo - Dominio - Usuarios - Permisos - Cuentas

¿Podrías crear

MyCompany.Core.Domain.Users
MyCompany.Core.Domain.Permissions
MyCompany.Core.Domain.Accounts

o solo

MyCompany.Core.Domain

Para el modo de Visual Studio, sería el primero. Además, si utiliza minúsculas de nombres de archivos / carpetas, está buscando cambiar el nombre de la clase cada vez, así como hacer que un gran espacio de nombres se enrede.

La mayor parte es de sentido común y realmente depende de cómo esperas ver los espacios de nombres organizados si fueras un consumidor de tu propia API o framework.

También siento el dolor con este comportamiento ''por defecto'' en Visual Studio.

Visual Studio también intenta establecer una coincidencia de espacio de nombres / directorio cuando coloca sus archivos LinqToSql .dbml en su propio directorio. Cada vez que edito .dbml , tengo que recordar que:

abra el archivo .dbml.designer.cs
eliminar el directorio / nombre de la carpeta de la declaración del namespace

Sin embargo, hay una manera de detener este comportamiento . Implica la creación de una plantilla de clase personalizada.

Una forma de no seguir la convención es crear el archivo en la carpeta raíz del proyecto y luego moverlo a la subcarpeta final.

De todos modos, es una convención que realmente me gusta. Si estoy dividiendo tipos en carpetas, probablemente esos tipos tengan algún tipo de agrupamiento conceptual relacionado con la carpeta. Por lo tanto, termina teniendo algún sentido, sus espacios de nombres también son similares. Java toma este enfoque y lo impone con su sistema de paquete. La mayor diferencia es que VS solo lo "sugiere", ya que ni el lenguaje ni el CLR lo imponen.