2010-09-17 17 views
11

Tengo la tarea de elegir un nombre que, en efecto, será el nombre interno de nuestra arquitectura. Me tomo esta responsabilidad en serio, ya que he trabajado con muchos espacios de nombres "malos" y no quiero infligir uno a los demás.¿Qué debería saber al elegir un nombre de espacio de nombres?

¿Qué hace que un "nombre de usuario" sea "malo" para mí?

En cuanto a los factores humanos:

  • un acrónimo que es esencialmente de significado: DDL, MOS, etc
  • Un espacio de nombres que choca con una común de otro proveedor, como Office o Text o IO
  • Un espacio de nombre que es difícil de deletrear o pronunciar para hablantes de inglés no nativos porque es una palabra extranjera o un nombre propio: Vancouver

y así sucesivamente.

Me siento cómodo eligiendo un espacio de nombres en términos de capacidad descriptiva y mnemotécnica. Me pregunto cuáles son las consecuencias técnicas de nombres de espacios de nombres. Por ejemplo, ¿qué problemas pueden surgir del espacio de nombres _, que es un nombre de espacio de nombres legal de C#? ¿Qué tal una sola letra, como e? ¿Hay espacios de nombres que den cabida a CodeDom o Reflector? ¿Algunos espacios de nombres que son legales en C# causan problemas en otros lenguajes .Net? ¿Es posible elegir un espacio de nombres que no sea compatible con Mono por algún motivo? ¿Ha trabajado con un espacio de nombres que le dificultó la vida por razones relacionadas con el compilador, Visual Studio o el sistema de archivos de Windows (o Linux)?

Gracias por leer y gracias de antemano por cualquier ayuda!

+1

OMI, C# espacios de nombres son perfectos, por lo que sólo tiene que copiarlos. En lugar de 'System', utilizo el nombre de la empresa o el nombre del producto. Y eso es todo lo que cambio. – BrunoLM

+0

@BrunoLM: Perfecto es una palabra muy fuerte, pero estoy de acuerdo. Los espacios de nombres de MS están bastante bien pensados ​​y organizados. Pero también podría ver la forma en que Java reúne espacios de nombres. Viniendo de un fondo .NET creo que la organización de Java es aún mejor, en mi humilde opinión. –

+0

Me encanta que alguien haya hecho esta pregunta. Al principio pensé, es una cosa tan pequeña; pero en realidad, como desarrolladores de software, siempre debemos esforzarnos por tomar buenas decisiones de diseño. Este es un ejemplo perfecto de eso. Y sé que muchas bibliotecas tienen nombres de espacios de nombres incomprensibles. –

Respuesta

18

Para cuestiones no técnicas, lea las Pautas de diseño de marcos. Ellos tienen muchos buenos consejos. En breve:

  • Comience con el nombre de una empresa.
  • elegir nombres estables (independientes de la versión). FrobCorp.FrobozzleV2.Utilities es malo.
  • elegir nombres que reflejen el propósito del código en lugar de la política de la organización que lo produjo. FrobCorp.AdvancedResearchDivision.CambridgeOffice es malo; la División de Búsqueda Avanzada podría renombrarse mañana y la oficina de Cambridge podría ser reubicada.
  • use PascalCase a menos que eso viole su marca. FrobCorp.jFrobozzle se ve terrible, pero FrobCorp.Jfrobozzle se ve aún peor.
  • usan plurales cuando corresponde
  • y así sucesivamente.

Hay muchos más buenos consejos en las directrices que no he reproducido aquí. Ve a leerlos.

Sin embargo, parece que tienes las cosas no técnicas caídas. Uno de los consejos en las directrices es "no nombrar un tipo igual que su espacio de nombres". Ese es un buen consejo no solo porque hacerlo es confuso para los lectores; hay una buena razón técnica también.

Por las razones técnicas por las que el nombramiento de un tipo de la misma como espacio de nombres es una idea terrible, ver mis artículos sobre el tema:

http://blogs.msdn.com/b/ericlippert/archive/tags/namespaces/

+0

Esta es una respuesta de jonrón. –

+0

La pauta sobre no tener el mismo nombre para el espacio de nombre se hizo a menudo por un programador aquí y cuando lo mencioné varias veces, he sido menospreciado por él simplemente porque tiene la palabra programador en su título. Me dijo que esas pautas están ahí para las personas promedio, las personas avanzadas pueden romperlas cuando lo consideren conveniente. Y agregó que incluso MS realmente no los usa ellos mismos. De todos modos, ¿qué hacer en este tipo de situaciones en las que sé que la calidad del código sufre a causa de la ignorancia? Como sabes una vez que se produce el cambio, es más arriesgado cambiarlo más tarde. –

+2

@Joan: es importante saber la diferencia entre una "regla" y una "pauta", y saber cuándo es el momento adecuado para pasar por alto las normas o directrices en pos de un objetivo mayor. ¡Eso, sin embargo, no hace una apelación a la autoridad un argumento sensato! Microsoft ha violado ocasionalmente estas pautas, y muchas de esas violaciones se mencionan en las Pautas de diseño de marcos comentadas como ejemplos de "por qué nunca debe hacer esto, porque nuestro error nos causó mucho dolor". Brad Abrams da el ejemplo de Microsoft poniendo un detalle organizacional en un espacio de nombres como un cuento de advertencia. –

0

Asegúrese de que el espacio de nombres comience de la manera más exclusiva posible, para evitar el tipo de colisión que ha descrito. por ejemplo:

YourCompanyName.subnamespace.subsubnamespace 
YourLastName.YourFirstName.subnamespace.subsubnamespace 
-2

Ir con el nombre de cualquier unidad que está en dentro de su empresa

+0

¿Por qué * motivo técnico *? Algo que involucra al sistema de desarrollo de .Net, no a los seres humanos –

+0

Ninguno, que yo sepa. Es simplemente la convención. Sea testigo de Microsoft, Crystal, etc. – Beth

+0

Consulte la respuesta de Erik Lipper sobre por qué esta es una mala idea. –

0

No se esfuerce demasiado duro para hacerlo bien la primera vez. No importa qué tan listo o limpio creas que sea tu convención y estructura de nombres, estarás cambiando el nombre y cambiando las cosas. Así es como es.

Para los principiantes es muy importante asegurarse de que haya pocas posibilidades de colisión en su nombre base. Más adelante podrá refactorizar fácilmente el espacio de nombres con herramientas como ReSharper et al.

Cuestiones relacionadas