¿Deberían las carpetas en una solución coincidir con el espacio de nombres?

¿Deberían las carpetas en una solución coincidir con el espacio de nombres?

En uno de los proyectos de mi equipo, tenemos una biblioteca de clase que tiene muchas subcarpetas en el proyecto.

Nombre del proyecto y el espacio de nombres: MyCompany.Project.Section.

Dentro de este proyecto, hay varias carpetas que coinciden con la sección del espacio de nombres:

• La carpeta Vehiclestiene clases en el MyCompany.Project.Section.Vehiclesespacio de nombres
• La carpeta Clothingtiene clases en el MyCompany.Project.Section.Clothingespacio de nombres
• etc.

Dentro de este mismo proyecto, hay otra carpeta maliciosa

• La carpeta BusinessObjectstiene clases en el MyCompany.Project.Sectionespacio de nombres

Hay algunos casos como este donde las carpetas están hechas para "conveniencia organizacional".

Mi pregunta es: ¿Cuál es el estándar? En las bibliotecas de clases, ¿las carpetas suelen coincidir con la estructura del espacio de nombres o es una mezcla de bolsas?

Además, tenga en cuenta que si usa las plantillas integradas para agregar clases a una carpeta, por defecto se colocará en un espacio de nombres que refleje la jerarquía de carpetas.

Las clases serán más fáciles de encontrar y eso solo debería ser una razón suficientemente buena.

Las reglas que seguimos son:

• El nombre del proyecto / ensamblado es el mismo que el espacio de nombres raíz, excepto por el final .dll
• La única excepción a la regla anterior es un proyecto con un final de .Core, el .Core se elimina
• Carpetas es igual a espacios de nombres
• Un tipo por archivo (clase, estructura, enumeración, delegado, etc.) facilita la búsqueda del archivo correcto

No.

He probado ambos métodos en proyectos pequeños y grandes, tanto con un solo (yo) como con un equipo de desarrolladores.

Encontré que la ruta más simple y productiva era tener un solo espacio de nombres por proyecto y todas las clases van a ese espacio de nombres. A continuación, puede colocar los archivos de clase en las carpetas de proyectos que desee. No hay ningún problema con agregar declaraciones de uso en la parte superior de los archivos todo el tiempo, ya que solo hay un espacio de nombres único.

Es importante organizar los archivos fuente en carpetas y, en mi opinión, para eso deben usarse todas las carpetas. Exigir que estas carpetas también se asignen a espacios de nombres es innecesario, crea más trabajo y descubrí que en realidad era perjudicial para la organización porque la carga adicional alienta la desorganización.

Tome esta advertencia de FxCop por ejemplo:

CA1020: Evite los espacios de nombres con pocos tipos de
causa: un espacio de nombres que no sea el espacio de nombres global contiene menos de cinco tipos https://msdn.microsoft.com/en-gb/library/ms182130.aspx

Esta advertencia alienta el volcado de nuevos archivos en una carpeta genérica Project.General, o incluso la raíz del proyecto hasta que tenga cuatro clases similares para justificar la creación de una nueva carpeta. ¿Sucederá eso alguna vez?

Encontrar archivos

La respuesta aceptada dice "Las clases serán más fáciles de encontrar y eso solo debería ser una razón suficientemente buena".

Sospecho que la respuesta se refiere a tener múltiples espacios de nombres en un proyecto que no se asignan a la estructura de carpetas, en lugar de lo que estoy sugiriendo, que es un proyecto con un solo espacio de nombres.

En cualquier caso, si bien no puede determinar en qué carpeta se encuentra un archivo de clase desde el espacio de nombres, puede encontrarlo utilizando Ir a definición o el cuadro del explorador de soluciones de búsqueda en Visual Studio. Además, esto no es realmente un gran problema en mi opinión. No gasto ni siquiera el 0.1% de mi tiempo de desarrollo en el problema de encontrar archivos para justificar la optimización.

Choques de nombres

Claro que crear múltiples espacios de nombres permite que el proyecto tenga dos clases con el mismo nombre. ¿Pero es eso realmente algo bueno? ¿Es quizás más fácil simplemente evitar que eso sea posible? Permitir dos clases con el mismo nombre crea una situación más compleja en la que el 90% de las veces las cosas funcionan de cierta manera y de repente descubres que tienes un caso especial. Supongamos que tiene dos clases de Rectángulo definidas en espacios de nombres separados:

• clase Project1.Image.Rectangle
• clase Project1.Window.Rectangle

Es posible encontrar un problema que un archivo de origen necesita incluir ambos espacios de nombres. Ahora tiene que escribir el espacio de nombres completo en todas partes en ese archivo:

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

O jugar con alguna declaración desagradable usando:

using Rectangle = Project1.Window.Rectangle;

Con un solo espacio de nombres en su proyecto, se ve obligado a crear nombres diferentes, y diría que son más descriptivos, como este:

• clase Project1.ImageRectangle
• clase Project1.WindowRectangle

Y el uso es el mismo en todas partes, no tiene que lidiar con un caso especial cuando un archivo usa ambos tipos.

usando declaraciones

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

vs

using Project1;

La facilidad de no tener que agregar espacios de nombres todo el tiempo al escribir código. Realmente no es el tiempo que toma, es la interrupción en el flujo de tener que hacerlo y simplemente llenar archivos con muchas declaraciones de uso, ¿para qué? ¿Vale la pena?

Cambiar la estructura de la carpeta del proyecto

Si las carpetas se asignan a espacios de nombres, la ruta de la carpeta del proyecto está efectivamente codificada en cada archivo de origen. Esto significa que cualquier cambio de nombre o movimiento de un archivo o carpeta en el proyecto requiere que el contenido real del archivo cambie. Tanto la declaración del espacio de nombres de los archivos en esa carpeta como el uso de declaraciones en un montón de otros archivos que hacen referencia a clases en esa carpeta. Si bien los cambios en sí mismos son triviales con las herramientas, generalmente resultan en una gran confirmación que consta de muchos archivos cuyas clases ni siquiera han cambiado.

Con un solo espacio de nombres en el proyecto, puede cambiar la estructura de carpetas del proyecto como lo desee sin modificar los archivos fuente.

Visual Studio asigna automáticamente el espacio de nombres de un nuevo archivo a la carpeta del proyecto en el que se creó

Desafortunadamente, pero encuentro que la molestia de corregir el espacio de nombres es menor que la molestia de tratar con ellos. También tengo la costumbre de copiar y pegar un archivo existente en lugar de usar Agregar-> Nuevo.

Intellisense y buscador de objetos

El mayor beneficio en mi opinión de usar múltiples espacios de nombres en grandes proyectos es tener una organización adicional al ver las clases en cualquier herramienta que muestre clases en una jerarquía de espacios de nombres. Incluso documentación. Obviamente, tener solo un espacio de nombres en el proyecto da como resultado que todas las clases se muestren en una sola lista en lugar de dividirse en categorías. Sin embargo, personalmente nunca me he quedado perplejo o retrasado debido a la falta de esto, por lo que no considero que sea un beneficio lo suficientemente grande como para justificar múltiples espacios de nombres.

Aunque si estuviera escribiendo una gran biblioteca de clase pública , probablemente usaría múltiples espacios de nombres en el proyecto para que el ensamblaje se vea bien en las herramientas y la documentación.

Creo que el estándar, dentro de .NET, es intentar hacerlo cuando sea posible, pero no crear estructuras innecesariamente profundas solo para cumplirlo como una regla difícil. Ninguno de mis proyectos sigue la regla de estructura del espacio de nombres == el 100% del tiempo, a veces es más limpio / mejor romper esas reglas.

En Java no tienes otra opción. Yo lo llamaría un caso clásico de lo que funciona en teoría frente a lo que funciona en la práctica.

@lassevk: estoy de acuerdo con estas reglas y tengo una más para agregar.

Cuando tengo clases anidadas, todavía las divido, una por archivo. Me gusta esto:

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

y

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

Yo diría que sí.

Primero, será más fácil encontrar los archivos de código reales siguiendo los espacios de nombres (por ejemplo, cuando alguien le envía por correo electrónico una pila de llamadas de excepción). Si deja que sus carpetas no estén sincronizadas con los espacios de nombres, encontrar archivos en grandes bases de código se vuelve agotador.

En segundo lugar, VS generará nuevas clases que cree en carpetas con el mismo espacio de nombres de su estructura de carpetas principal. Si decide nadar en contra de esto, será solo un trabajo de plomería más que hacer diariamente al agregar nuevos archivos.

Por supuesto, esto no hace falta decir que uno debe ser conservador sobre cuán profunda es la jerarquía de carpetas / espacios de nombres.

Sí deberían, solo conduce a la confusión de lo contrario.

¿Cuál es el estándar?

No existe un estándar oficial, pero convencionalmente el patrón de mapeo de carpeta a espacio de nombres es el más utilizado.

En las bibliotecas de clases, ¿las carpetas suelen coincidir con la estructura del espacio de nombres o es una mezcla de bolsas?

Sí, en la mayoría de las bibliotecas de clases, las carpetas coinciden con el espacio de nombres para facilitar la organización.