Mejora de nombres de variables en un conjunto de datos


11

Los buenos nombres de variables son:

a) corto / fácil de escribir,

b) fácil de recordar,

c) comprensible / comunicativo.

¿Estoy olvidando algo? La consistencia es algo a tener en cuenta. La forma en que lo diría es que las convenciones de nomenclatura consistentes contribuyen a las cualidades anteriores. La consistencia contribuye a (b) la facilidad de recordar y (c) la comprensibilidad, aunque a menudo otros factores son más importantes. Existe una clara compensación entre (a) longitud del nombre / facilidad de escritura (por ejemplo, todo en minúsculas) y (c) comprensibilidad.

Estoy invirtiendo un poco de pensamiento en estos temas porque miles de personas están usando los datos y espero que muchos usen mi código para preparar los datos y facilitar algunos tipos de análisis. Los datos, del Estudio longitudinal de la salud de los adolescentes, se desglosan en múltiples conjuntos de datos. Mi primer paso fue tomar las 227 variables en el conjunto de datos más comúnmente usado, recodificarlas, darles nombres más significativos. Los nombres de variables originales son cosas como "aid", "s1", "s2", a las que renombré "aid2", "age" y "male.is". Hay miles de otras variables en los otros conjuntos de datos que pueden fusionarse dependiendo de cuáles son los objetivos del investigador.

Mientras renombre las variables, quiero que sean lo más útiles posible. Estos son algunos de los problemas que he considerado. Hasta ahora, solo he usado minúsculas y evité usar guiones o guiones bajos, y solo he usado puntos para un propósito muy específico. Esto tiene la virtud de la simplicidad y la coherencia, y no causa problemas para la mayoría de las variables. Pero a medida que las cosas se vuelven más complejas, tengo la tentación de romper mi consistencia. Tomemos, por ejemplo, mi variable "talkprobmsum", sería más fácil de leer como "talkProbMSum" o mejor aún "talk.prob.m.sum", pero si voy a usar letras mayúsculas o puntos para separar las palabras, entonces ¿No debería hacerlo para todas las variables?

Algunas variables se registran en más de una vez, por ejemplo, las variables de raza, por lo que agregué .is o .ih para indicar si provienen del cuestionario en la escuela o en el hogar. Pero seguramente hay algunas repeticiones que aún no conozco, ¿sería mejor agregar una referencia al conjunto de datos al nombre de cada variable?

Necesito centrar en grupo y estandarizar muchas variables, la forma en que lo hice es agregando .zms que significa puntaje z por hombre y por escuela.

Cualquier pensamiento o recurso general o específico es muy apreciado. Vea este repositorio para algunos de mis códigos y estadísticas descriptivas con una lista de nombres de variables. Describí brevemente la razón para compartir este código aquí , y se publicitó un poco aquí , pero estos dos últimos enlaces no son realmente relevantes para el tema de las convenciones de nombres variables. Agregado: edité esto a la ligera, principalmente moviendo un párrafo, para tratar de evitar algo de la confusión evidente en los comentarios. Gracias por los pensamientos!

Añadido 09.05.2016: Vale la pena señalar Guía de estilo de Hadley R Wickham y la Guía de Estilo de Google R ... Hadley dice:

Los nombres de las variables y funciones deben estar en minúsculas. Use un guión bajo (_) para separar las palabras dentro de un nombre.

Google dice:

No use guiones bajos (_) o guiones (-) en los identificadores. Los identificadores deben nombrarse de acuerdo con las siguientes convenciones. La forma preferida para los nombres de las variables son todas letras minúsculas y palabras separadas con puntos (variable.name), pero también se acepta variableName; los nombres de las funciones tienen letras mayúsculas iniciales y no tienen puntos (FunctionName); las constantes se nombran como funciones pero con una k inicial.


+1 para configurar un repositorio público para compartir entre los investigadores, aunque esta pregunta realmente pertenece a Stack Overflow.
nico

66
¿Por qué esta pregunta sería mejor en SO, @nico? Para mí, no parece ser sobre programación o incluso sobre R, sino más bien sobre prácticas apropiadas para documentar y usar datos.
whuber

44
@whuber: entiendo tu punto. Sin embargo, al leer la pregunta, lo vi como "¿cómo debo llamar a mis variables?", Lo que para mí suena más como un asunto de programación y no sobre estadísticas ... Pensándolo bien, también es cierto que la audiencia aquí está más cerca de aquello que usará los datos reales que los de SO.
nico

2
+1, creo que esta es una gran pregunta y felicitaciones por hacer esto
gung - Vuelva a instalar a Monica

2
Creo que esto debería permanecer abierto.
gung - Restablece a Monica

Respuestas:


4

La mejor respuesta a esta pregunta es esquivarla. Básicamente, no importa mucho cuáles sean los nombres cortos de las variables, siempre que estén bien documentadas en un libro de códigos en alguna parte. Por desgracia, dado que R no tiene recursos nativos para esto, las personas tienden a no molestarse. (La falta es, para mí, la falla más grande en el lenguaje como herramienta estadística).

Hay varios paquetes R que proporcionan esta maquinaria, por ejemplo, la Hmiscque usa, y memisc. Pero realmente la mejor opción es convertir todo en un paquete R. De esa manera, los datos procesados ​​pueden ser un objeto con una página de ayuda correspondiente que describe cómo se llama todo ahora y puede asignar crédito a su vencimiento. El paquete también puede exponer los datos sin procesar y sus funciones de procesamiento para que las personas vean lo que hizo para hacer el producto final.

Además, una sugerencia: no puede incluir datos derivados como variables y sus versiones con puntuación z en el objeto de datos final si puede ayudarlo, solo proporcione las funciones para hacerlo. Los datos derivados son solo problemas desde el punto de vista de la gestión de datos.


Usted dice que los nombres de las variables no importan mucho, siempre y cuando estén bien documentados ... No quiero hacer una montaña de una colina de mole, pero creo que importan hasta cierto punto. Los nombres de variables que son difíciles de recordar o difíciles de escribir tienen un costo real en el tiempo del investigador. Especialmente si los mismos miles de investigadores están utilizando los mismos nombres de variables. Sin embargo, gracias por tus otros consejos :)
Michael Bishop

4

Aquí hay una pequeña cosa: creo que es mejor usar guiones bajos que puntos. La razón es que la mayoría de los lenguajes de programación, a diferencia de R, no admiten puntos en los identificadores, pero casi todos los subrayados. Y supongo que desea que su conjunto de datos sea útil para las personas que no usan R.


1

En primer lugar, gracias por hacerlo. Estoy seguro de que muchas personas lo apreciarán, aunque no muchos sabrán que lo hiciste.

La interfaz de usuario de RStudio no interpreta (al menos con las opciones predeterminadas) ningún separador dentro del nombre de la variable. Por ejemplo, Eclipse trata las partes en mayúscula como palabras separadas, por lo que puede usar las teclas Ctrl + para editar rápidamente el código de estilo Java ageStandardizedMaleSchool. No puedo encontrar mejores razones para preferir un separador sobre otro, por lo que me parecen bien los subrayados o las mayúsculas.

En general, sugiero que los nombres de las variables sean más largos, en lugar de apegarse a algún esquema de abreviatura complejo. Es fácil hacer errores tipográficos como en talk.prob.m.sumlugar de talk.prob.sum.ms, y es difícil detectar y rastrear errores en el análisis estadístico. (Algo relacionado: un buen dicho que he leído en algún blog es escribir sus nombres variables como palabras escandinavas: SickHouse y ToothHealer en lugar de hospital y dentista ).

En una nota final: la estandarización, el centrado, etc. generalmente se realizan después de la limpieza de datos. Si no hay limpieza, entonces tal vez considere dejar eso a quien analice los datos. O, si también está haciendo la limpieza, indique todos los pasos que ha tomado; los análisis e interpretaciones posteriores pueden depender mucho de eso.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.