Convenciones generales de nomenclatura
Nota:
Este contenido se ha copiado con permiso de Pearson Education, Inc. de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2ª edición. Esa edición se publicó en 2008 y el libro se ha revisado completamente en la tercera edición. Parte de la información de esta página puede estar obsoleta.
En esta sección se describen las convenciones generales de nomenclatura relacionadas con la elección de palabras, las directrices sobre el uso de abreviaturas y acrónimos y las recomendaciones para evitar el uso de nombres específicos de un lenguaje.
Elección de palabras
✔️ ELIJA nombres de identificador fáciles de leer.
Por ejemplo, una propiedad denominada HorizontalAlignment es más legible en inglés que AlignmentHorizontal.
✔️ FAVORECE la legibilidad sobre la brevedad.
El nombre de propiedad CanScrollHorizontally es mejor que ScrollableX (una referencia oculta al eje X).
❌ NO use caracteres de subrayado, guiones ni ningún otro carácter no alfanumérico.
❌ NO use la notación húngara.
❌ EVITE el uso de identificadores que entren en conflicto con palabras clave de lenguajes de programación ampliamente utilizados.
Según la regla 4 de Common Language Specification (CLS), todos los lenguajes compatibles deben proporcionar un mecanismo que permita el acceso a los elementos con nombre que usan una palabra clave de ese lenguaje como identificador. C#, por ejemplo, usa el signo @ como mecanismo de escape en este caso. Sin embargo, se sigue recomendando evitar palabras clave comunes porque es mucho más difícil usar un método con la secuencia de escape que uno sin él.
Uso de abreviaturas y acrónimos
❌ NO use abreviaturas ni contracciones como parte de los nombres de identificador.
Por ejemplo, use GetWindow en lugar de GetWin.
❌ NO use acrónimos que no se acepten ampliamente, e incluso si lo están, solo cuando sea necesario.
Evitar nombres específicos de un lenguaje.
✔️ UTILICE nombres semánticamente interesantes en lugar de palabras clave específicas del lenguaje para los nombres de tipo.
Por ejemplo, GetLength es mejor que GetInt.
✔️ UTILICE un nombre de tipo CLR genérico, en lugar de un nombre específico del lenguaje, en los casos excepcionales en los que un identificador no tiene ningún significado semántico más allá de su tipo.
Por ejemplo, un método que se convierte Int64 debe denominarse ToInt64, no ToLong (porque Int64 es un nombre CLR para el alias específico de C# long). En la tabla siguiente se presentan varios tipos de datos base mediante los nombres de tipo CLR (así como los nombres de tipo correspondientes para C#, Visual Basic y C++).
| C# | Visual Basic | C++ | CLR |
|---|---|---|---|
| sbyte | SByte | char | SByte |
| byte | Byte | unsigned char | Byte |
| short | Short | short | Int16 |
| ushort | UInt16 | unsigned short | UInt16 |
| int | Integer | int | Int32 |
| uint | UInt32 | unsigned int | UInt32 |
| long | Long | __int64 | Int64 |
| ulong | UInt64 | unsigned __int64 | UInt64 |
| float | Single | float | Single |
| double | Double | double | Double |
| bool | Boolean | bool | Boolean |
| char | Char | wchar_t | Char |
| string | String | String | String |
| object | Object | Object | Object |
✔️ UTILICE un nombre común, como value o item, en lugar de repetir el nombre de tipo, en los casos poco frecuentes en los que un identificador no tiene ningún significado semántico y el tipo del parámetro no es importante.
Asignación de nombres a las nuevas versiones de las API existentes
✔️ UTILICE un nombre similar a la API anterior al crear nuevas versiones de una API existente.
Esto ayuda a resaltar la relación entre las API.
✔️ AGREGUE mejor un sufijo en lugar de un prefijo para indicar una nueva versión de una API existente.
Esto ayudará a la detección al examinar la documentación o al usar IntelliSense. La versión anterior de la API se organizará cerca de las nuevas API, ya que la mayoría de los exploradores e IntelliSense muestran los identificadores en orden alfabético.
✔️ CONSIDERE utilizar un identificador nuevo, pero significativo, en lugar de agregar un sufijo o un prefijo.
✔️ UTILICE un sufijo numérico para indicar una nueva versión de una API existente, especialmente si el nombre existente de la API es el único nombre que tiene sentido (es decir, si es un estándar del sector) y si agregar un sufijo significativo (o cambiar el nombre) no es una opción adecuada.
❌ NO utilice el sufijo "Ex" (o similar) para que un identificador lo distinga de una versión anterior de la misma API.
✔️ UTILICE el sufijo "64" al introducir versiones de las API que funcionan en un entero de 64 bits (un entero largo) en lugar de un entero de 32 bits. Solo debe seguir este enfoque cuando exista la API de 32 bits existente. no lo haga para las nuevas API con solo una versión de 64 bits.
Portions © 2005, 2009 Microsoft Corporation. Todos los derechos reservados.
Material reimpreso con el consentimiento de Pearson Education, Inc. y extraído de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition (Instrucciones de diseño de .NET Framework: convenciones, expresiones y patrones para bibliotecas .NET reutilizables, 2.ª edición), de Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la serie Microsoft Windows Development.