Pregunta

Pregunta bastante simple: cuando tengo un objeto persistente, generalmente tiene una propiedad llamada ID (para clases abstractas).

Entonces ... ¿es la ID o ID de la convención de nomenclatura?

ej.

public int ID { get; set; }

o

public int Id { get; set; }

salud :)

PS. Esto es para .NET por cierto. FXCop conformat sería una ventaja.

¿Fue útil?

Solución

Normalmente voy con Identificador . Si realmente quiero que sea breve (como parte de un identificador más largo, por ejemplo), uso Id, a menos que sea un parámetro o un miembro privado.

Las .NET Framework Naming Guidelines dicen 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 Lenguaje de marcado de hipertexto. Debe incluir siglas 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 biblioteca no deben usar abreviaturas.

     

Las dos abreviaturas que se pueden usar en los identificadores son ID y OK. En los identificadores en mayúsculas de Pascal deberían aparecer como Id y Ok. Si se usa como la primera palabra en un identificador en camello, deben aparecer como id y ok, respectivamente.

Otros consejos

Sea lo que sea que te guste, solo sé consistente. ID no es una palabra, es una abreviatura de identidad. Cómo escribir abreviaturas es algo sobre lo que las personas discuten durante mucho tiempo. P.ej. es

getResourceURL

o

getResourceUrl

en realidad ambos se pueden encontrar en uso en diferentes marcos. Otro abbr popular. con un problema similar es UTF8.

Es importante ser coherente, porque de lo contrario las personas siempre tienen que buscar la capitalización correcta para cada método, si cada método lo maneja de manera diferente.

Tengo mi propia convención para eso. Si el abbr. está al final del nombre, todo está en mayúscula, si está en otro lugar, sigue las reglas de notación de camellos. Por ejemplo,

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 con mayúsculas. Entonces compara:

compareURLToString
compareUrlToString

En el primer caso, no veo de inmediato que la URL es una palabra y To es la siguiente. La T podría ser parte de la URL (URLT) y ser una abreviatura diferente, por lo tanto, usaré la segunda forma. Sin embargo, si está al final, no jugará un papel, no se sigue ninguna otra palabra, por lo tanto, prefiero la forma en mayúscula. Me apego a esta convención en todo mi código.

Las pautas dicen " Id " ;.

Afortunadamente, los chicos de .Net tuvieron la amabilidad de darnos "pautas de nomenclatura". y no "nombrar leyes" ;), así que, básicamente, si siente firmemente que romper una regla de la directriz agrega más valor que seguirla, entonces, infórmela, nadie lo responsabilizará si comprende sus razones (como si proporcionara más legibilidad y acentúa el significado del nombre)

En mi tienda usamos 'ID' incluso si las pautas dicen 'Id', pero nadie, realmente se siente culpable por ello.

Como otros señalaron, Id es correcto según las convenciones de .NET, pero de alguna manera no se siente bien, por lo que muchas personas usan ID (y aún viven).

No sé cuál será el contenido de su campo (números, cadenas, guías), pero si desea omitir el problema, simplemente puede usar otra convención .NET para identificadores de objetos: Nombre

Usamos ID internamente, porque Id me parece que habla psicología, pero FxCop se queja, ya que ID no es un acrónimo, es una abreviatura (para Identidad / Identificador). De acuerdo con la regla FxCop, solo los acrónimos que tienen dos caracteres de largo pueden tener mayúsculas. Todo lo demás debe ser el caso adecuado.

Ponemos un atributo SuppressMessage en la propiedad ID, y todos están contentos.

" ID " es una de las abreviaturas codificadas en las reglas de nomenclatura de FxCop que siempre se consideran mal escritas, incluso si son parte de otras palabras. La única forma que encontré para anularlo es agregando " ID " Acrónimos como ():

<Dictionary>
<Acronyms>
   <CasingExceptions>
        <Acronym>ID</Acronym>
  </CasingExceptions>
</Acronyms>
</Dictionary>

Funcionó con FxCop 1.36. PD En general, creo que '' Id '' es una mejor alternativa, pero a veces es imposible cambiar un nombre si se genera en base a archivos XML (o servicios web) que no controlamos

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 habituales.

Por aquí vemos cosas como "Id" u otras siglas 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 de convenciones de codificación interna.

Pero la conclusión es: elija qué convención es más cómoda para el equipo de desarrolladores y otras personas que miran el código fuente y se adhieren a él.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top