La pregunta más amplia:
¿Alguna vez has oído hablar de una norma tan impuesta? Si es así, ¿cuál fue la razón detrás de esto?
Sí, he oído hablar de esto, y el uso de nombres de objetos totalmente calificados evita las colisiones de nombres. Aunque es raro, cuando suceden, pueden ser excepcionalmente espinosos de entender.
Un ejemplo:
ese tipo de escenario probablemente se explica mejor con un ejemplo.
Digamos que tenemos dos Lists<T>pertenecientes a dos proyectos separados.
System.Collections.Generic.List<T>
MyCorp.CustomCollections.Optimized.List<T>
Cuando usamos el nombre del objeto totalmente calificado, queda claro cuál List<T>se está utilizando. Esa claridad obviamente tiene el costo de la verbosidad.
Y podría estar discutiendo: "¡Espera! ¡Nadie usaría nunca dos listas como esa!" Que es donde señalaré el escenario de mantenimiento.
Usted es un módulo escrito Foopara su corporación que utiliza la corporación aprobada, optimizada List<T>.
using MyCorp.CustomCollections.Optimized;
public class Foo {
List<object> myList = ...;
}
Más tarde, un nuevo desarrollador decide extender el trabajo que ha estado haciendo. Sin estar al tanto de los estándares de la compañía, actualizan el usingbloque:
using MyCorp.CustomCollections.Optimized;
using System.Collections.Generic;
Y puedes ver cómo las cosas van mal a toda prisa.
Debería ser trivial señalar que podría tener dos clases propietarias del mismo nombre pero en diferentes espacios de nombres dentro del mismo proyecto. Por lo tanto, no se trata solo de una colisión con las clases proporcionadas por .NET Framework.
MyCorp.WeightsAndLengths.Measurement();
MyCorp.TimeAndSpace.Measurement();
La realidad:
ahora, ¿es probable que esto ocurra en la mayoría de los proyectos? No en realidad no. Pero cuando trabajas en un proyecto grande con muchas entradas, haces todo lo posible para minimizar las posibilidades de que las cosas exploten en ti.
Los grandes proyectos con múltiples equipos contribuyentes son un tipo especial de bestia en el mundo de las aplicaciones. Las reglas que parecen irrazonables para otros proyectos se vuelven más pertinentes debido a los flujos de entrada al proyecto y la probabilidad de que los contribuyentes no hayan leído las pautas del proyecto.
Esto también puede ocurrir cuando dos grandes proyectos se fusionan. Si ambos proyectos tenían clases con nombres similares, verá colisiones cuando comience a hacer referencia de un proyecto a otro. Y los proyectos pueden ser demasiado grandes para refactorizar o la gerencia no aprobará el gasto para financiar el tiempo dedicado a la refactorización.
Alternativas:
Si bien no preguntó, vale la pena señalar que esta no es una gran solución al problema. No es una buena idea crear clases que colisionen sin sus declaraciones de espacio de nombres.
List<T>, en particular, debe tratarse como una palabra reservada y no como el nombre de sus clases.
Del mismo modo, los espacios de nombres individuales dentro del proyecto deben esforzarse por tener nombres de clase únicos. Tener que tratar de recordar con qué espacio de nombres Foo()está trabajando es una sobrecarga mental que es mejor evitar. Dicho de otra manera: tener MyCorp.Bar.Foo()y MyCorp.Baz.Foo()va a hacer tropezar a sus desarrolladores y es mejor evitarlos.
Como mínimo, puede usar espacios de nombres parciales para resolver la ambigüedad. Por ejemplo, si no puede renombrar ninguna de las Foo()clases, puede usar sus espacios de nombres parciales:
Bar.Foo()
Baz.Foo()
Razones específicas para su proyecto actual:
Actualizó su pregunta con los motivos específicos que recibió para su proyecto actual siguiendo ese estándar. Echemos un vistazo a ellos y realmente divaguemos por el sendero del conejito.
Es engorroso pasar el mouse sobre el nombre para obtener el tipo completo. Es mejor tener siempre visible el tipo totalmente calificado todo el tiempo.
"¿Incómodo?" Mmm no. Molesto tal vez. Mover unas onzas de plástico para cambiar el puntero en pantalla no es engorroso . Pero yo divago.
Esta línea de razonamiento parece más un encubrimiento que otra cosa. Por supuesto, supongo que las clases dentro de la aplicación tienen un nombre débil y debe confiar en el espacio de nombres para obtener la cantidad adecuada de información semántica que rodea el nombre de la clase.
Esta no es una justificación válida para nombres de clase totalmente calificados, quizás sea una justificación válida para usar nombres de clase parcialmente calificados.
Los fragmentos de código enviados por correo electrónico no tienen el nombre completo y, por lo tanto, pueden ser difíciles de entender.
Esta línea de razonamiento (¿continua?) Refuerza mi sospecha de que las clases actualmente están mal nombradas. Nuevamente, tener nombres de clase pobres no es una buena justificación para requerir que todo use un nombre de clase completamente calificado. Si el nombre de la clase es difícil de entender, hay mucho más mal que lo que pueden arreglar los nombres de clase completamente calificados.
Al ver o editar el código fuera de Visual Studio (Notepad ++, por ejemplo), es imposible obtener el nombre de tipo completo.
De todas las razones, esta casi me hizo escupir mi bebida. Pero de nuevo, me estoy desviando.
Me pregunto por qué el equipo edita o visualiza código con frecuencia fuera de Visual Studio. Y ahora estamos viendo una justificación que es bastante ortogonal a lo que los espacios de nombres deben proporcionar. Este es un argumento respaldado por herramientas, mientras que los espacios de nombres están ahí para proporcionar una estructura organizativa al código.
Parece que el proyecto propio sufre de convenciones de nomenclatura deficientes junto con desarrolladores que no están aprovechando lo que las herramientas pueden proporcionarles. Y en lugar de resolver esos problemas reales, han intentado aplicar una tirita sobre uno de los síntomas y requieren nombres de clase completamente calificados. Creo que es seguro clasificar esto como un enfoque equivocado.
Dado que hay clases mal nombradas, y suponiendo que no pueda refactorizar, la respuesta correcta es usar el IDE de Visual Studio para su máximo beneficio. Posiblemente considere agregar un complemento como el paquete VS PowerTools. Luego, cuando estoy mirando AtrociouslyNamedClass(), puedo hacer clic en el nombre de la clase, presionar F12 y ser llevado directamente a la definición de la clase para comprender mejor lo que está tratando de hacer. Del mismo modo, puedo hacer clic en Shift-F12 para encontrar todos los puntos en el código que actualmente tienen que usar AtrociouslyNamedClass().
Con respecto a las preocupaciones de herramientas externas, lo mejor que puede hacer es simplemente detenerlo. No envíe fragmentos de correo electrónico de un lado a otro si no están claros de inmediato a qué se refieren. No use otras herramientas fuera de Visual Studio, ya que esas herramientas no tienen la inteligencia que rodea el código que su equipo necesita. Notepad ++ es una herramienta increíble, pero no está hecha para esta tarea.
Así que estoy de acuerdo con su evaluación con respecto a las tres justificaciones específicas que se le presentaron. Dicho esto, lo que creo que le dijeron fue "Tenemos problemas subyacentes en este proyecto que no pueden / no abordarán y así es como los" solucionamos ". Y eso obviamente habla de problemas más profundos dentro del equipo que pueden servir como señales de alerta para usted.