variables - see - ¿ID, id o id?
show duplicates stata (20)
Utilizo camelCase en los nombres de campo de mi código y de la base de datos, etc., pero con los campos que tienen Id al final, siempre resulta difícil de leer. Por ejemplo, itemId , itemId , unitId , etc. En estos casos, considero romper la convención y escribir itemID, teacherID, or unitID solo para mejorar la legibilidad.
¿Qué hace y qué es una práctica general y mejor para tratar este problema?
"Id" es ambiguo. ¿Es parte del modelo "ego" / "superego" de la psique humana? Probablemente no: probablemente estés intentando abreviar una palabra, como "Identidad" o "Identificación" o "Identificador".
Deshágase de la ambigüedad (y de la pregunta de la caja) al decidir qué quiere decir y luego no abrevie .
Aquí hay una muestra de lo que hago.
id
userId
getUserId
La clave es ser consistente.
Carné de identidad
Esta es mi respuesta subjetiva para la pregunta subjetiva.
Aunque he marcado esto como CW.
Con lo que se sienta cómodo, siempre y cuando permanezca coherente dentro de sus propios programas. (Si trabaja en un equipo, debe seguir las reglas del equipo o configurar algunas).
Un punto que no se ha mencionado es la importancia de obtener una buena fuente. Eso hará maravillas en la legibilidad de su programa y podría ser que su problema de convención sea en parte un problema de fuente:
Si no puede distinguir fácilmente la Id de ld (Id and ld) , debe cambiar la fuente y quizás también el tamaño de la fuente. Personalmente, me encanta Consolas.
Creo que la legibilidad es de suma importancia, y debería anular su convención si va a hacer que sea mucho más fácil de leer. Creo que los contras son mayores que los pros para apegarte a tus armas / convención si no puedes leerlo fácilmente (por mucho que los programadores odien romper las convenciones y los protocolos).
De hecho, prefiero "ID". Pero, como todos dicen, la consistencia es lo más importante.
Steve
Diferentes idiomas tienen diferentes pautas. Para .NET puede leer Pautas de diseño de marcos: Convenciones, expresiones idiomáticas y patrones para bibliotecas .NET reutilizables . Para Java puede leer Convenciones de código para el lenguaje de programación Java .
En Machine SUIF , Mike Smith y Glenn Holloway aplican con rigidez la convención del caso de que una letra mayúscula marca una nueva palabra. Entonces, aunque CPS es un acrónimo es transformToCps y no transformToCPS . Descubrí que, a largo plazo, su método funciona mejor que lo que hicimos en Quick C-- , donde solíamos hacer mayúsculas para casos como ID y CPS.
Estoy de acuerdo con las otras respuestas en que lo más importante es ser consistente.
Añadiría que, si no hay un estándar establecido para su base de código particular, debe seguir las convenciones establecidas por su idioma o plataforma. En Java, los acrónimos y otras palabras en mayúsculas no están capitalizadas para los identificadores:
id
url
getId()
setUrlParameters()
En Objective-C, es lo contrario. Es posible que tenga una variable "id" o "url" en minúsculas, pero también tiene clases como:
NSURL
NSURLRequest
Así que en Obj-C elegiría un nombre de método como:
setURLParameters:
FxCop / Code Analysis marcará la identificación como una abreviatura incorrecta, por lo que si desea evitar la desactivación de una regla, puede conformar y usar la identificación por ese motivo. Pero, de nuevo, esto realmente no importa, siempre y cuando usted sea consistente, como lo han señalado otros.
Hago lo que me da la gana. En general, su mejor práctica es errar a favor de la legibilidad en comparación con el cumplimiento de algún estándar abstracto.
Solo sé consistente.
ID en columnas de base de datos y propiedades de objetos. ID en los parámetros:
this.ID == id
Id es una abreviatura, no un acrónimo, así que lo escribo "Id". La interfaz de usuario es un acrónimo, y las siglas, las cortas, de todos modos, se escriben con mayúscula: "UI".
Id, como para el identificador. Las convenciones de nomenclatura sugeridas por Microsoft indican que esa es la práctica recomendada y que la compilación con análisis de código lo admitirá. Usaría ID si significara dos palabras que comienzan con I y D respectivamente y realmente se supone que no debe usar nombres que comiencen con letras minúsculas sino en parámetros.
No importa, siempre y cuando sea consistente a lo largo de su programa .
Dicho esto, me gustaría ir con "Id".
Prefiero usar la identificación y en nuestra empresa el estándar también es la identificación sobre la identificación. No creo que haya un problema con la identificación si le resulta más fácil de leer. Al compilador no le importa :) Yo uso la misma convención en mis columnas de ID de esquema.
Se pronuncia "ojo dee", no "id como en id, ego y superego", así que 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 se puede escribir de esa manera. Ah, y el caso del camello es la peor idea en la historia de la informática. :)
También uso camelcase y también lo uso si el nombre termina con Id.
Voy a ser votado aquí abajo, ¡pero no me importa!
es obviamente id Ideas desde lo profundo!
Yo uso guiones bajos en todos los nombres de mis tablas, por lo que user_id. Incluso si id es independiente, todo es minúscula.