Pregunta bastante simple: cuando tengo un objeto persistente, generalmente tiene una propiedad llamada ID (para clases abstractas).¿Cuál es la convención de nomenclatura adecuada para una "ID" de propiedad: ID o Id?
Entonces, ¿es la Id. O ID del convenio de nomenclatura?
por ejemplo.
public int ID { get; set; }
o
public int Id { get; set; }
aplausos :)
PS. Esto es para .NET por cierto. La conformación de FXCop sería una ventaja.
Normalmente voy con Identificador. Si realmente quiero mantenerlo corto (como parte de un identificador más largo, por ejemplo), uso Id, a menos que sea un parámetro o un miembro privado.
El .NET Framework Naming Guidelines decir esto:
Un acrónimo es una palabra que se forma a partir de las letras de las palabras en un término o frase. Por ejemplo, HTML es un acrónimo de Hypertext Markup Language. Debe incluir acrónimos en los identificadores solo cuando sean ampliamente conocidos y bien entendidos. Los acrónimos difieren de las abreviaturas en que una abreviatura acorta una sola palabra. Por ejemplo, ID es una abreviatura de identificador. En general, los nombres de las bibliotecas no deben usar abreviaturas.
Los dos abreviaturas que se pueden utilizar en los identificadores son ID y OK. En los identificadores de Pascal-cased deberían aparecer como Id y Ok. Si se usa como la primera palabra en un identificador de camel-cased, deberían aparecer como id y ok, respectivamente.
Alguien debería decirle esto a Microsoft. Estoy cansado de ver System.ApplicationId, Process.Id, Control.ID, SessionID, Attribute.TypeId, System.AppDomain.IsDomainIdValid() ... http://social.msdn.microsoft.com/Foros/es-ES/csharpgeneral/thread/dcb8e08b-026a-4903-a413-7dbdda131a82/ – jpierson
Prefiero ID, también en combinación con otras palabras (por ejemplo, CustomerID), pero estrictamente hablando eso va en contra de las convenciones de nomenclatura regulares.
Utilizamos ID internamente, porque Id me parece que habla psicología, pero FxCop se queja, como ID no es un acrónimo, es una abreviación (de Identidad/Identificador). De acuerdo con la regla de FxCop, solo los acrónimos que tienen dos caracteres pueden ser mayúsculas. Todo lo demás debería ser el caso adecuado.
Ponemos un atributo SuppressMessage en la propiedad ID, y todos están contentos.
Lo que quieras que sea, solo sé consistente. ID no es una palabra, es una abreviación de identidad. Cómo escribir abreviaturas es algo sobre lo que las personas discuten durante mucho tiempo. P.ej. es que
getResourceURL
o
getResourceUrl
en realidad se puede encontrar tanto en uso en diferentes marcos. Otro abbr popular. con un problema similar es UTF8.
Es importante ser coherente, porque de lo contrario la gente siempre tiene que buscar las mayúsculas correctas para cada método, si cada método lo maneja de una manera diferente.
Tengo mi propia convención para eso. Si el abbr. está al final del nombre, está en mayúscula, si está en otro lugar, sigue las reglas de notación de camello. P.ej.
getResourceURL
urlOfResource
compareUrlToString
¿Por qué? Me gusta abbr. para ser capitalizado La mayoría de las personas esperan que la URL o UTF se capitalicen. Sin embargo, si está en medio de un nombre, destruye la ventaja de la notación de camello. La ventaja de la notación de camello es que puede ver dónde comienza una nueva palabra mediante mayúsculas. Entonces compare:
compareURLToString
compareUrlToString
En el primer caso, no veo inmediatamente que la URL sea una palabra y A es la siguiente. La T podría ser parte de la URL (URLT) y ser una abreviatura diferente, así usaré la segunda forma. Si es al final, sin embargo, no tendrá un rol, no hay otra palabra, por lo que prefiero la forma en mayúscula. Me atengo a esta convención a lo largo de todo mi código.
Por aquí vemos cosas como "Id" u otros acrónimos como una palabra, y "Id" es fácil porque en el negocio bancario obtenemos muchas combinaciones de letras extrañas. Entonces lo tratamos como una palabra, solo con la primera letra en mayúscula, y así es como terminamos siendo definidos en nuestro documento interno de convenciones de codificación.
Pero la conclusión es: elegir lo que la convención es más cómodo para el equipo de desarrollo y otras personas que mira el código fuente y se pega con él.
Las directrices dicen "Id".
Afortunadamente, los chicos de .Net tuvieron la amabilidad de darnos "pautas de nombres" y no de "nombrar leyes";), básicamente, si consideras que romper una regla guía agrega más valor que seguirlo, entonces por todos los medios lo rompen, nadie lo responsabilizará si entienden tus razones (como proporciona más legibilidad y acentúa el significado del nombre)
En mi tienda usamos 'ID' incluso si las directrices dicen ' Id ', pero nadie, realmente se siente culpable por eso.
Como otros señalaron, Id está de acuerdo con las convenciones de .NET, pero de alguna manera no se siente bien, muchas personas usan ID (y aún viven).
No sé lo que el contenido de su campo será (números, cadenas, GUID), pero si desea omitir el problema puede simplemente utilizar otra convención .NET para los identificadores de objeto: Nombre
"ID" es una de las abreviaturas codificadas en reglas de nombres de FxCop que siempre se consideran escrituras incorrectas incluso si son partes de otras palabras. La única manera que encontré para anularlo es la adición de "ID" para acrónimos como():
<Dictionary>
<Acronyms>
<CasingExceptions>
<Acronym>ID</Acronym>
</CasingExceptions>
</Acronyms>
</Dictionary>
Se trabajó con FxCop 1,36. P.S. En general, creo que el "ID" es una alternativa mejor, pero a veces es imposible cambiar un nombre si se genera en base a archivos XML (o servicios web), que nosotros no controlamos
Oups, corta todas las etiquetas .. Debe ser un acrónimo con contenido de "ID" en Acronyms/CasingExceptions –
http://en.wiktionary.org/wiki/id#Abbreviation
Por qué lucha ¿eso?
Por lo que vale, el formateador de código automático StackOverflow parece preferir "Id" (ver la pregunta recientemente editada). Oh, prefiero Id también, principalmente por las razones citadas por @OregonGhost. –