studio - cambiar nombre a solucion c#

¿Las carpetas en una solución deben coincidir con el espacio de nombres?

Question

¿Las carpetas en una solución deben coincidir con el espacio de nombres?

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

Nombre del proyecto y espacio de nombre: MyCompany.Project.Section .

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

• Folder Vehicles tiene clases en el espacio de nombres MyCompany.Project.Section.Vehicles
• Folder Clothing tiene clases en el espacio de nombres MyCompany.Project.Section.Clothing
• etc.

Dentro de este mismo proyecto, hay otra carpeta deshonesta

• Carpeta BusinessObjects tiene clases en el espacio de nombres MyCompany.Project.Section

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 un conjunto mixto?

Answer 1

@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
}
}

Answer 2

Además, tenga en cuenta que si utiliza las plantillas incorporadas para agregar clases a una carpeta, se colocará de manera predeterminada 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 buena razón.

Las reglas que seguimos son:

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

Answer 3

Creo que el estándar, dentro de .NET, es tratar de hacerlo cuando sea posible, pero no crear estructuras innecesariamente profundas solo para cumplirlo como una regla dura. Ninguno de mis proyectos sigue la regla de estructura del espacio de nombres =================================================

En Java, no tienes elección. Llamaría a eso un caso clásico de lo que funciona en teoría versus lo que funciona en la práctica.

Answer 4

No.

Probé ambos métodos en proyectos pequeños y grandes, ambos con un único (yo) y un equipo de desarrolladores.

Encontré que la ruta más simple y más productiva era tener un solo espacio de nombres por proyecto y todas las clases entrar en ese espacio de nombres. Ahora puede colocar los archivos de clase en las carpetas de proyectos que desee. No hay problema con la adición de instrucciones de uso en la parte superior de los archivos, ya que solo hay un único espacio de nombres.

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

Tome esta advertencia FxCop por ejemplo:

CA1020: Evite espacios de nombres con pocos tipos
causa: un espacio de nombre 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 archivos nuevos en una carpeta genérica Project.General, o incluso en la raíz del proyecto hasta que tenga cuatro clases similares para justificar la creación de una nueva carpeta. ¿Eso sucederá 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 buena razón".

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

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

Choques de nombre

Seguro que la creación de múltiples espacios de nombres permite que el proyecto tenga dos clases con el mismo nombre. ¿Pero eso realmente es algo bueno? ¿Es quizás más fácil simplemente no permitir que eso sea posible? Permitir dos clases con el mismo nombre crea una situación más compleja en la que el 90% del tiempo las cosas funcionan de cierta manera y de repente te das cuenta de 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 fuente debe incluir ambos espacios de nombres. Ahora tiene que escribir el espacio de nombre completo en todas partes en ese archivo:

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

O lío con alguna declaración de uso desagradable:

using Rectangle = Project1.Window.Rectangle;

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

• clase Project1.ImageRectangle
• clase Project1.WindowRectangle

Y el uso es el mismo en todos lados, 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 mientras se escribe el código. No es el tiempo que realmente toma, es la interrupción en el flujo de tener que hacerlo y solo llenar los 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, entonces la ruta de la carpeta del proyecto está codificada de forma efectiva en cada archivo de origen. Esto significa que cualquier cambio de nombre o movimiento de un archivo o carpeta en el proyecto requiere que se modifique el contenido real del archivo. Tanto la declaración del espacio de nombres de los archivos en esa carpeta y el uso de las declaraciones en un montón de otros archivos que hacen referencia a las clases en esa carpeta. Si bien los cambios en sí mismos son triviales con las herramientas, generalmente resultan en una confirmación grande que consta de muchos archivos cuyas clases ni siquiera han cambiado.

Con un solo espacio de nombre en el proyecto, puede cambiar la estructura de la carpeta del proyecto como desee sin que se modifiquen los archivos fuente.

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

Desafortunado, pero me parece que la molestia de corregir el espacio de nombres es menor que la molestia de lidiar con ellos. También tengo el hábito de copiar pegando un archivo existente en lugar de usar Agregar-> Nuevo.

Intellisense y el navegador de objetos

El mayor beneficio en mi opinión de usar múltiples espacios de nombres en proyectos grandes es tener una organización extra cuando veo 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 los resultados del proyecto en todas las clases se muestra en una sola lista en lugar de dividirse en categorías. Sin embargo, personalmente, nunca me ha sorprendido o retrasado debido a la falta de esto, así que no creo 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 varios espacios de nombres en el proyecto para que el ensamblaje se vea limpio en las herramientas y la documentación.

Answer 5

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

Answer 6

Yo diría que sí.

En primer lugar, será más fácil encontrar los archivos de código reales siguiendo los espacios de nombres (por ejemplo, cuando alguien le envíe por correo electrónico una pila de llamadas de excepción). Si deja que sus carpetas se desincronicen con los espacios de nombres, la búsqueda de archivos en grandes bases de código se vuelve fatigosa.

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

Por supuesto, esto no hace falta decir que uno debe ser conservador con respecto a cuán profunda va la jerarquía de la carpeta x / espacio de nombres.