visual studio programacion practicas para notacion nomenclatura indentación hungara convenciones codigos c# interface naming-conventions

studio - notacion hungara para c#



Convención de nomenclatura de interfaz (21)

Esto es algo subjetivo, por supuesto, pero no veo nada positivo en el prefijo de nombres de interfaz con una ''I''. Para mí, Thing es prácticamente siempre más legible que IThing .

Mi pregunta es, ¿por qué existe esta convención entonces? Claro, hace que sea más fácil distinguir interfaces de otros tipos. Pero, ¿no se extendería ese argumento a la retención de la notación húngara, que ahora está ampliamente censurada?

¿Cuál es su argumento para ese incómodo ''yo''? O, lo que es más importante, ¿qué podría ser de Microsoft?

Bueno, una consideración obvia sería el (muy común) par IFoo y Foo (al abstraer a Foo ), pero en general a menudo es fundamental saber si algo es una interfaz vs clase. Sí, es parcialmente redundante, pero IMO es diferente de cosas como sCustomerName ; aquí, el nombre mismo ( customerName ) debería ser suficiente para comprender la variable.

Pero con CustomerRepository , ¿es una clase o la interfaz abstracta?

También: expectativa; el hecho es, correcto o incorrecto, que es lo que espera la gente. Eso es casi una razón suficiente.

Creo que es mejor que agregar un sufijo "Impl" en tu clase concreta. Es una sola carta, y esta convención está bien establecida. Por supuesto, puedes usar cualquier nombre que desees.

El hecho es que todos lo entienden y parte de escribir un mejor código lo hace más fácil de leer y entender.

En mi opinión, este ''yo'' es solo ruido visual. IDE debe mostrar los nombres de clase y de interfaz de manera diferente. Afortunadamente, la biblioteca estándar de Java no utiliza esta convención.

Es popular que una GUI del sistema operativo use diferentes iconos para archivos y carpetas. Si todos comparten los mismos iconos, pero las carpetas tienen el prefijo "F", sería aceptable usar el mismo icono. Pero, como la velocidad de reconocimiento de imágenes de los seres humanos es más rápida que su velocidad de reconocimiento de palabras, nos hemos acostumbrado a los íconos.

Los programas de computadora como IDEs son completamente capaces de hacer aparente la interfaz de un archivo. Esto liberaría el espacio de nombres de diferentes niveles de abstracción que suceden en el mismo nombre. Por ejemplo, en "ICare", "I" describe la implementación y "Cuidado" describe las capacidades de la interfaz.

Supongo que la convención "yo" es tan popular porque no hemos podido pensar en nada mejor, pero su existencia es importante porque señala la necesidad que tenemos de conocer este tipo de información.

Es solo una convención que es la intención es evitar colisiones de nombres. C # no me permite tener una clase y una interfaz llamada Cliente, incluso si los nombres de archivo son Cliente e ICLIENTE, respectivamente. Me siento cómodo usando la convención; si tuviera que ofrecer una convención diferente, sugeriría usar "Contrato" como sufijo, por ejemplo, ClientContract.

Estoy seguro de que su pregunta fue el tema de muchas largas discusiones dentro del equipo de Microsoft que trabajaron en .NET Framework y sus estándares.

Creo que el ejemplo más revelador proviene de la fuente misma. A continuación, transcribo extractos de Framework Design Guidelines , un libro que recomiendo encarecidamente.

De Krzysztof Cwalina, gerente del programa CLR:

El único prefijo utilizado es "I" para las interfaces (como en ICollection ), pero eso es por razones históricas. En retrospectiva, creo que hubiera sido mejor usar nombres de tipos regulares. En la mayoría de los casos, a los desarrolladores no les importa que algo sea una interfaz y no una clase abstracta, por ejemplo.

Desde Brad Abrams, CLR y el gerente del programa .NET Framework:

Por otro lado, el prefijo "I" en las interfaces es un claro reconocimiento de la influencia de COM (y Java) en .NET Framework. COM popularizó, incluso institucionalizó, la notación de que las interfaces comienzan con "I." Aunque analizamos la posibilidad de desviarnos de este patrón histórico, decidimos llevar adelante el patrón ya que muchos de nuestros usuarios ya estaban familiarizados con COM.

De Jeffrey Richter, consultor y autor:

Personalmente, me gusta el prefijo "I" y me gustaría tener más cosas como esta. Los pequeños prefijos de un carácter hacen mucho para mantener el código escueto y, a la vez, descriptivo. [...] Uso prefijos para mis campos de tipo privado porque me parece muy útil.

Mi punto es que estaba en la mesa de discusión. Una ventaja que veo es que ayuda a evitar colisiones de nombres entre clases e interfaces, por lo que sus nombres pueden ser tanto descriptivos como compactos.

Personalmente, y tal vez por costumbre, me gusta el prefijo I , ya que abrecartas de manera sucinta las interfaces, lo que me permite tener correspondencia de nombres uno a uno con tipos de implementación. Esto brilla en los casos en que desea proporcionar una implementación base : IThing es la interfaz, la Thing es el tipo base (tal vez abstract ). Los tipos derivados pueden ser SomeThing . Me encanta poder usar una notación taquigráfica tan clara como el cristal.

La razón por la que lo hago es simple: porque esa es la convención. Prefiero simplemente seguirlo que hacer que todo mi código se vea diferente, lo que hace que sea más difícil de leer y aprender.

Las convenciones (y las críticas en su contra) tienen una razón detrás de ellas, así que vamos a descuidar algunas razones detrás de las convenciones

  • Las interfaces tienen el prefijo I para diferenciar los tipos de interfaz de las implementaciones ; por ejemplo, como se mencionó anteriormente, debe haber una manera fácil de distinguir entre Thing y su interfaz IThing por lo que la convención sirve para este fin.

  • Las interfaces tienen el prefijo I para diferenciarlo de las clases abstractas . Hay ambigüedad cuando ve el siguiente código:

    public class Apple: Fruit

    Sin la convención, uno no sabría si Apple estaba heredando de otra clase llamada Fruit , o si era una implementación de una interfaz llamada Fruit , mientras que IFruit lo haría obvio:

    public class Apple: IFruit

    Principio de menor sorpresa aplica.

  • No todos los usos de la notación húngara son censurados . Los primeros usos de la notación húngara significaban un prefijo que indicaba el tipo del objeto y luego el nombre de la variable o, a veces, un guión bajo antes del nombre de la variable. Esto fue, para ciertos entornos de programación (piense en Visual Basic 4 - 6) útil pero a medida que la programación orientada a objetos creció en popularidad, se volvió impráctico y redundante especificar el tipo. Esto se convirtió especialmente en un problema cuando se trataba de intellisense.

    Hoy la notación húngara es aceptable para distinguir elementos UI de datos reales y elementos UI asociados similares, por ejemplo, txtObject para un cuadro de texto, lblObject para la etiqueta que está asociada con ese cuadro de texto, mientras que los datos para el cuadro de texto son simplemente Object .

    También debo señalar que el uso original de la notación húngara no era para especificar tipos de datos (llamados notación húngara del sistema), sino más bien, especificando el uso semántico de un nombre de variable (llamado aposición húngara de aplicaciones). Lea más en él en la entrada de Wikipedia en la notación húngara .

No hay nada de malo en NO usar I convención para interfaces, solo sea consistente y asegúrese de que funcione no solo para usted sino para todo el equipo (si hay uno).

No sé exactamente por qué eligieron esa convención, tal vez en parte pensando en animar a la clase con "Yo" como en "Yo soy Enumerable".

Una convención de nomenclatura que estaría más en la línea del resto del marco sería incorporar el tipo en el nombre, como por ejemplo las clases xxxAttribute y xxxException, lo que lo convierte en xxxInterface. Sin embargo, eso es un poco largo, y después de todas las interfaces es algo separado, no solo otro grupo de clases.

Nombrar una interfaz debe tener un significado mucho más profundo que el hecho de si colocas o no una "I" al principio del nombre.

Ni "Fruit" ni "IFruit" tendrían mucho significado para mí como interfaz. Esto se debe a que se parece mucho más a una clase. Las clases definen cosas, mientras que las interfaces deben definir la funcionalidad.

La convención de nombres "I" ayuda a diferenciar entre clases e interfaces para que el desarrollo sea un poco más fácil. Y si bien no es necesario, sin duda ayuda a evitar dolores de cabeza de codificación orientados a objetos comunes. C #, como Java, solo permite la herencia de una sola clase base. Pero puede implementar tantas interfaces como desee. La advertencia es que, si hereda de una clase e implementa una o más interfaces, la clase base debe nombrarse primero (es decir, clase Trout: Fish, ISwimmer, IDiver ...).

Me gusta mucho nombrar mis interfaces basadas tanto en la funcionalidad que proporcionan como en el tipo de interfaz (es decir, interfaces animadas o inanimadas).

Si se centra en la funcionalidad que proporciona la interfaz, puede determinar rápidamente un nombre para la interfaz. También le ayuda a ver rápidamente si su interfaz define funciones no relacionadas.

Interfaces que definen objetos inanimados (es decir, cosas que no pueden actuar por sí mismas) ... Me gusta nombrarlos con ... capaz al final IPrintable (como Documento, Factura) IPlayable (como Instrument, MediaPlayer) ISavable (como Documento, Imagen) IEable (como Fruta, Carne de vaca) Idible (como Coche) IFlyable (como Plano)

Interfaces que definen objetos animados (es decir, cosas que actúan por su cuenta) ... Me gusta nombrarlos ... er al final ISwimer (como Fish, Dog, Duck) IDiver (como Fish, Duck) IFlyer ( como Pilot) IDriver (como NascarDriver)

Al final, la convención de nombres "I" ayuda a diferenciar entre interfaces y clases. Pero puede tener sentido agregar una lógica de nomenclatura adicional además de la "I" al comienzo.

Para separar las interfaces de las clases.

Además (esto es más una observación personal que la dictada desde lo alto), las interfaces describen lo que hace una clase. La ''I'' se presta a esto (estoy seguro de que es una construcción en gramática que sería genial para batir en este momento); una interfaz que describe las clases que validan sería "IValidate". Uno que describa el comportamiento de coincidencia sería "IMCAR".

Parece Hungarian ish para mí. El húngaro generalmente se considera una amenaza en los lenguajes fuertemente tipados.

Como C # es un producto de Microsoft y la notación húngara fue una invención de Microsoft, puedo ver dónde C # podría ser susceptible a su influencia.

Porque usualmente tienes un IThing y una Cosa. Entonces, en lugar de dejar que la gente venga con sus propias "convenciones" para esta situación recurrente, se eligió una convención uniforme y única para todos. Haciéndose eco de lo que otros dicen, el estándar de facto es razón suficiente para usarlo.

Puede agregar la palabra "Interfaz" como sufijo a su interfaz personalizada, por ejemplo "SerializerInterface". Para la clase abstracta, "Fruta", por ejemplo, "FruitAbstract" o puedes hacerla "AbstractFruit", solo sé consistente. Eso es bastante legible o sigue la convención de nomenclatura habitual.

Realmente no me gusta esta convención. Entiendo que ayuda con el caso cuando tienes una interfaz y una implementación que tendría el mismo nombre, pero me parece feo. Todavía lo seguiría si fuera la convención en la que estoy trabajando, por supuesto. La consistencia es el punto de las convenciones, y la consistencia es algo muy bueno.

Me gusta tener una interfaz que describa lo que hace la interfaz de la forma más genérica posible, por ejemplo, Validator . Una implementación específica que valida una cosa en particular sería un ThingValidator , y una implementación con alguna funcionalidad abstracta compartida por el Validator s sería un AbstractValidator . Haría esto incluso si Thing es lo único ... bueno ... lo que estoy validando, y Validator sería genérico.

En los casos en que solo una clase concreta tiene sentido para una interfaz, igual trato de describir algo específico sobre esa implementación en particular en lugar de nombrar la interfaz de manera diferente para evitar una colisión de nombres. Después de todo, escribiré el nombre de la interfaz con más frecuencia que el nombre de la implementación.

Sé que las directrices de Microsoft recomiendan usar la ''I'' para describirlo como una interfaz. Pero esto viene de las convenciones de nomenclatura de IBM, si no recuerdo mal, la inicial "I" para las interfaces y el siguiente * Impl para las implementaciones.

Sin embargo, en mi opinión, las convenciones de nomenclatura de Java son una mejor opción que la convención de nomenclatura de IBM (y no solo en Java, también para C # y cualquier lenguaje de programación OO). Interfaces describe lo que un objeto puede hacer si implementa la interfaz y la descripción debe estar en forma de verbo. Es decir Runnable, Serializable, Facturable, etc. En mi humilde opinión, esta es una descripción perfecta de lo que representa la interfaz.

Solo mis 2 centavos:

La razón por la que añado personalmente el sufijo "Interfaz" es porque es más fácil de leer que el prefijo "I" y porque los archivos en el sistema se enumeran "agrupados". Por ejemplo:

No tan bien:

Alien.php Host.php IAlien.php IHost.php IXenomorph.php Xenomorph.php

Mejor:

Alien.php AlienInterface.php Host.php HostInterface.php Xenomorph.php XenomorphInterface.php

Pero eso es solo gusto personal. Creo que siempre que uno use una convención de nomenclatura uniforme a lo largo de todo el proyecto, nada contradice el uso de su propia convención de nomenclatura.

Thing es un nombre más legible que IThing . Soy de la escuela de pensamiento de que deberíamos programar interfaces en lugar de implementaciones específicas. En términos generales, las interfaces deben tener prioridad sobre las implementaciones. Prefiero dar el nombre más legible a la interfaz en lugar de la implementación (es decir, mis interfaces se nombran sin el prefijo ''I'').