2009-04-23 22 views
22

Utilizo camelCase en mis nombres de campo de código y base de datos, etc., pero con los campos que tienen Id al final, siempre resulta difícil de leer. Por ejemplo, itemId, teacherId, unitId, etc. En estos casos, considero romper las convenciones y escribir itemID, teacherID, or unitID solo para una mejor legibilidad.ID, id o Id?

¿Qué hace y cuál es la mejor práctica general para tratar este problema?

Respuesta

10

Hago lo que me gusta. En general, su mejor práctica es equivocarse a favor de la legibilidad frente al cumplimiento de algún estándar abstracto.

Simplemente sea consistente.

+0

CW sueño duran solo unos segundos. – OscarRyz

+0

c'est la vie, etc. etc. ;-) – Shog9

5

Uso camelcase, también y también lo uso si el nombre termina con Id.

3

Id

Esta es mi respuesta subjetiva para la pregunta subjetiva.

Aunque lo he marcado como CW.

+2

El problema con Id es cómo luce el I similar a t sin capital. Entonces unitId es bastante ambiguo para leer –

+0

En esta fuente es similar. Al usar una fuente monoespaciada (que trato de usar en todas partes donde codigo) no funciona. –

+0

O una minúscula l. Incluso en fuentes monoespaciadas, puede haber problemas. –

0

Prefiero usar Id y en nuestra empresa el estándar también es Id. Más ID. No creo que haya un problema al usar ID si le resulta más fácil de leer. Al compilador no le importa :) Uso la misma convención en mis columnas de Id del esquema.

1

Creo que la legibilidad es de suma importancia, y debe anular su convención si va a hacer que sea mucho más fácil de leer. Creo que los contras superan a los profesionales por apegarse a tus armas/convenciones si no puedes leerlos fácilmente (tanto como nosotros los programadores odiamos romper las convenciones y los protocolos).

9

Id, en cuanto al identificador. Las convenciones de nomenclatura sugeridas por Microsoft indican que esa es la práctica recomendada y la compilación con análisis de código lo respaldará. Utilizaría ID si fuera dos palabras comenzando respectivamente con I y D, y realmente no se supone que use nombres que comiencen con letras minúsculas, sino en parámetros.

+0

ID significa "Identificación de dígitos". Es posible crear un acrónimo para cualquier cosa. ;) –

+0

De acuerdo. Todos los proyectos no triviales deberían usar el Análisis de código (FxCop) que sugerirá "Id" en lugar de "ID". –

+0

No creo que el OP haya mencionado a Microsoft. –

6

No importa, siempre y cuando sea coherente en todo su programa.

Dicho esto, me gustaría ir con "Id".

+0

Estoy de acuerdo con ambas afirmaciones, sea coherente y vaya con 'Id' porque ... 404 –

21

Aquí hay una muestra de lo que hago.

id 
userId 
getUserId 

La clave es ser consistente.

+0

Agregué el CW cuando vi cuántos más tenían. –

+1

¡Todos los chicos geniales lo están haciendo! –

+0

@Daniel seguro que están :) –

3

Uso guiones bajos en todos mis nombres de tabla, por lo usuario_id. Incluso si id es independiente, todo está en minúsculas.

43

Id es una abreviatura, no un acrónimo, por lo que caso "Id". UI es un acrónimo, y los acrónimos, de todos modos cortos, se capitalizan: "UI".

+5

La mejor respuesta aquí; sorprendió que nadie haya votado a favor esto. +1 :) – bryan

+2

FWIW, algunos sugerirían (como lo hacen las Pautas de diseño de .NET Framework) que solo los acrónimos de dos letras estén completamente en mayúscula, todos los acrónimos más largos se escriben en mayúscula como palabras normales. Por ejemplo, DeferIO y XmlReader. Tiene un enfoque razonable y legible. Pero Id sigue siendo Id. :) –

+0

También FWIW ID es la abreviatura oficial según el diccionario. Sugeriría que si lo hace, también debería usar Ui y Url. – slifty

12

En realidad prefiero "ID". Pero, como todos dicen, la consistencia es lo más importante.

Steve

+5

Uso "ID", rompe consistencia pero es más legible. – awaisj

+0

Sí, creo que es más legible, y por eso lo uso. Pero si siempre usa "ID" (por ejemplo, "ID de usuario", "ID de comentario"), ¿por qué rompe la coherencia? –

+4

Puede querer decir que el resto del código es camalCase e ID es lo único que no es –

1

En Machine SUIF, Mike Smith y Glenn Holloway rígidamente hacer cumplir el Convenio caso de que una letra mayúscula marca una nueva palabra. Entonces, aunque CPS es un acrónimo, es transformToCps y no transformToCPS. He descubierto que, a la larga, su método funciona mejor que lo que hicimos en Quick C--, donde generalmente hicimos mayúsculas para casos como ID y CPS.

2

Voy a ser votado aquí, pero no me importa!

es obviamente id. ¡Ideas desde lo profundo!

1

FxCop/Code Analysis indicará que el ID es una mala abreviatura, por lo que si desea evitar la deshabilitación de una regla, puede conformarla y usar Id por ese motivo. Pero, de nuevo, esto realmente no importa, siempre y cuando seas consecuente, como han señalado otros.

1

Lo que sea que se sienta cómodo con el tiempo que permanezca constante dentro de sus propios programas. (Si trabajas en equipo, debes seguir la regla del equipo o configurar algunos).

Un punto que no se ha mencionado es la importancia de obtener una buena fuente. Eso hará maravillas a su facilidad de lectura del programa y podría ser que su problema convención es en parte un problema de fuente:

Si no puede distinguir fácilmente Id de ld(Id and ld), debe cambiar la fuente y tal vez la fuente tamaño también. Personalmente, me encanta Consolas.

1

Estoy de acuerdo con las otras respuestas de que lo más importante es ser coherente.

Yo agregaría que, si no hay un estándar establecido para su código particular, debe seguir las convenciones establecidas por su idioma o plataforma. En Java, acrónimos y otras palabras en mayúsculas son en minúsculas para los identificadores:

id 
url 
getId() 
setUrlParameters() 

En Objective-C, es todo lo contrario. Es posible que tenga un "id" en minúsculas o variable "URL", pero también hay clases, tales como:

NSURL 
NSURLRequest 

Así que en Obj-C que elegiría un nombre de método como:

setURLParameters: 
+0

Las constantes con mayúscula en C se ven muy feas. PHP también ha heredado algunos de estos. –

2

¡Es pronunciado "ojo dee", no "id como en id, ego y superego", entonces ID, no Id. Ese es mi voto, de todos modos. El hecho de que sea una abreviatura, en lugar de un acrónimo, es irrelevante, debido a la forma en que se pronuncia. Se pronuncia como si fuera un acrónimo, por lo que también puede escribirse de esa manera. Ah, y camel case es la peor idea en la historia de la informática. :)

0

"Id" es ambiguo. ¿Es parte del modelo "ego"/"superego" de la psique humana? Probablemente no: probablemente intente abreviar una palabra, como "Identidad" o "Identificación" o "Identificador".

Deshacerse de la ambigüedad (y la pregunta carcasa) al decidir lo que quiere decir y luego no abreviar.

1

ID en columnas de base de datos y propiedades de objeto.id en parámetros:

this.ID == id