naming conventions - tabla - ¿Deberíamos poner unidades de medidas en nombres de atributos?
unidades de medida de longitud (14)
Donde la unidad de medida no es inmediatamente aparente, creo que debe ir un paso más allá e incluir la unidad de medida en el nombre. Length_mm, por ejemplo, debería ayudar a recordar a los desarrolladores que es mejor convertir la longitud en mm si el usuario acaba de ingresarla en pulgadas.
Puede ir un paso más allá (en su código, no en la base de datos) y tiene un tipo de longitud, que se ocupa de la unidad de medida y de las posibles conversiones. Este es el enfoque del patrón de "Cantidad" en el libro "Patrones de análisis" de Martin Fowler.
Creo que la mayoría de nosotros estamos de acuerdo en que es una buena idea usar un nombre descriptivo para las variables , los atributos del objeto y las columnas de la base de datos. Si desea almacenar un nombre, también puede llamar al Name del atributo para que las personas sepan qué poner en él.
Donde la unidad de medida no es inmediatamente aparente, creo que debe ir un paso más allá e incluir la unidad de medida en el nombre. Length_mm , por ejemplo, debería ayudar a recordar a los desarrolladores que es mejor convertir la longitud en mm si el usuario acaba de ingresarla en pulgadas.
Mi administrador de base de datos, sin embargo, me acaba de decir que incluir las unidades de medida en los nombres de columna de la base de datos es "mal visto" . Creo que eso es una locura , pero tal vez haya algún riesgo que los DBAs sepan que yo no.
Lánzame una línea, aquí: ¿deberíamos incrustar unidades de medida en nuestros nombres de atributos? ¿Por qué? Por qué no?
Creo que poner unidades en tus identificadores es un gran olor de diseño. Seguramente significa que eligió el idioma equivocado: si las unidades son tan importantes para el proyecto, será mejor que use un lenguaje cuyo sistema de tipos sea capaz de representarlas.
Definitivamente quiere unidades de medida en alguna parte . No sé si los nombres de las columnas son un buen lugar o si el esquema es mejor. Pregunta al administrador de tu base de datos
- ¿Dónde se almacena la información sobre las unidades de medida?
- ¿Cómo puedo acceder a las unidades programáticamente?
Si las respuestas son "no es" o "no puedes", queja con amargura: no tienen derecho a negarte la convención de tu nombre. De lo contrario, todo puede ser más feliz si trabaja dentro del sistema.
PD: Me gusta mucho el soporte para unidades de medida que han puesto en F #.
El enfoque ideal es, si es posible, utilizar un tipo que no deje ambigüedad en cuanto a la medición. Por ejemplo, en .NET en lugar de decir int periodInSeconds , sería mucho mejor utilizar el TimeSpan period .
El lenguaje F # en realidad tiene unidades de medida como parte del sistema de tipo, por lo que puede declarar tipos en unidades como 10<m/s> y 5<s> e incluso realizar cálculos sobre ellos de modo que sean aproximadamente 10<m/s> * 5<s> daría como resultado 50<m> . Mira aquí para más información .
Entonces, si es posible, le diría que use un tipo que transmita su intención, pero si eso no es posible, probablemente debería codificar la medida en el nombre. Es mejor y más obvio que un comentario.
He trabajado mucho en la base de datos, y no dejaría de prestarle atención en absoluto, ni tampoco me enteré de que fruncir el ceño.
Es mejor que las propiedades extendidas, lo cual no es evidente para el desarrollador casual. Es mejor que en un documento separado, porque muchos desarrolladores no los leerán, y ciertamente no en gran detalle. Si las unidades están configuradas, tenerla en el nombre parece una buena idea. Si eso cambia, cuando se agrega el campo de la unidad, cambie el nombre del campo de medición.
La convención de nombrar todas mis columnas en el formato:
{name}_in_{unit}
ayudó para un proyecto, ya que estaba usando unidades si, en realidad me permitió inferir el tipo de datos de columna y, en general, simplifiqué mi estilo de escritura.
length_in_m
speed_in_ms-1
color_in_nm
hubo algunas excepciones que manejé con _at_time o number_of_:
started_at_time updated_at_time number_of_rotations
NO, el nombre del atributo está separado de su unidad de medida.
Si llama a una longitud variable_mm, entonces está vinculado a mm.
¿Qué sucede si utiliza un int de 32 bits para almacenar length_mm, eventualmente la longitud en mm puede llegar a ser mayor que 62,000, o lo que sea que el límite sea en 32bit ints? No puede cambiar a m porque ha vinculado su longitud variable a length_mm.
No coloque unidades de medida (o tipo de columna) en los nombres de columna de su base de datos.
Muchas bases de datos tienen la capacidad de documentar / comentar columnas de alguna manera (en SQL Server es sp_addextendedproperty), sugeriría que es un lugar más apropiado.
No ponemos unidades de medida en los nombres de columna en nuestra base de datos. Sin embargo, tenemos un documento de diccionario de datos donde se describen todas las columnas y relaciones.
Sí. Debieras.
La clave, como @ [Charles Bretana] señaló, es la legibilidad y que los otros usuarios de la tabla o los desarrolladores que le siguen saben lo que está usando.
Incluiría absolutamente las unidades / medidas en un nombre de campo; en mi negocio no puede adivinar lo que encontrará en el contexto o nombre: un campo titulado MarketValue: ¿eso es millones, miles o unidades? Dólares, Euros, Libras, $ MONEDA? ¿Es ese valor un porcentaje, una razón? ¿Absoluto o relativo? Diario, mensual, año calendario, año financiero? Esa marca de tiempo, ¿qué zona horaria es?
Su primera, última y única tarea al proporcionar datos es asegurarse de que no se use de forma incorrecta porque el consumidor no pudo averiguar lo suficiente al respecto. Como desarrolladores, arrojar "Meter", "USD", "GMT", "PerCent" o lo que sea en un nombre de campo no es nada mal.
Hay olores enormes que deben resolverse antes de que el pequeño soplo de nombres de campo necesite estandarizarse.
Si tiene una UOM consistente para las cosas, entonces la política de su DBA es correcta.
Por ejemplo, si los tiempos son SIEMPRE en minutos, etc.
Si la UOM puede cambiar, entonces debe almacenarla en otra columna, junto con la cantidad.
Dicho esto, tiendo a ponerme de tu lado en esto. La claridad supera a la mayoría de las cosas, incluido esto. Prefiero ver DurationMinutes que Duration y tengo que adivinar qué es la UOM.
Tengo que decir que odio que los nombres de variables "descriptivos" se conviertan en nombres de variables "increíblemente detallados".
Mi alternativa preferida es usar nada más que los nombres de unidad de medida en funciones cortas. P.ej.
function velocity(m, s) {
return m/s;
}
No necesita decir "length_m" porque en este contexto, es obvio que solo las longitudes se pueden medir en metros.
Una vez dicho esto. Si estuviera escribiendo un sistema donde los errores de las unidades de medida fueran realmente peligrosos, probablemente usaría el sistema de tipos y definiría una clase de longitud que siempre se convertiría en una unidad estándar para cualquier cálculo. Tal vez incluso diferentes subclases para Pies, Metros, etc.
Esta es la razón por la cual el Mars Climate Orbiter se estrelló en la superficie a 350 metros / seg cuando se planeó manejar solo 350 pies / seg (o algo así).
Aunque "Nunca digas ''Nunca'' o ''Siempre''" es, en general, una buena regla general, aquí voy a doblar mi regla y decir que creo que debes "siempre" dejar en claro en qué unidades se encuentra un valor numérico.
Creo que esta es una buena idea en cualquier lugar donde haya espacio para la ambigüedad.
Por ejemplo, con la clase de temporizador de alto rendimiento que utilizamos, sigo teniendo que comprobar si el método GetElapsed () devuelve segundos o milisegundos o algo más. Si se llamara GetElapsedMilliseconds (), eso salvaría la confusión.
El único inconveniente es que si quisieras cambiar de opinión ... pero en ese caso cualquier cliente debería saber sobre el cambio de todos modos.
F # tiene un giro interesante al permitir que las unidades de medida se especifiquen en el sistema de tipos. Vea esta publicación en el blog y otra pregunta sobre el ¿Son unidades de medida exclusivas de F #?