Улучшение имен переменных в наборе данных

Хорошие имена переменных:

а) короткий / легкий для ввода,

б) легко запомнить,

в) понятный / коммуникативный.

Я забыл что-нибудь? Последовательность - это то, что нужно искать. Я бы сказал, что согласованные соглашения об именах способствуют достижению указанных выше качеств. Последовательность способствует (б) легкости запоминания и (в) понятности, хотя другие факторы часто более важны. Существует четкий компромисс между (а) длиной имени / простотой ввода (например, строчными буквами) и (в) понятностью.

Я уделяю много внимания этим вопросам, потому что тысячи людей используют данные, и я надеюсь, что многие будут использовать мой код для подготовки данных и облегчения некоторых видов анализа. Данные, полученные в результате Продольного исследования здоровья подростков, разбиты на несколько наборов данных. Моим первым шагом было взять 227 переменных в наиболее часто используемом наборе данных, перекодировать их, дать им более значимые имена. Оригинальные имена переменных - это такие вещи, как "aid", "s1", "s2", которые я переименовал в "aid2", "age" и "male.is". В других наборах данных есть тысячи других переменных, которые могут быть объединены в зависимости от целей исследователя.

Пока я переименовываю переменные, я хочу сделать их максимально полезными. Вот некоторые из вопросов, которые я рассмотрел. До сих пор я использовал только строчные буквы и избегал использования любых тире или подчеркиваний, и я использовал периоды только для одной очень конкретной цели. Это имеет преимущество простоты и последовательности, и не вызывает проблем для большинства переменных. Но когда все усложняется, у меня возникает соблазн нарушить мою последовательность. Возьмите, к примеру, мою переменную "talkprobmsum", было бы легче читать как "talkProbMSum" или еще лучше "talk.prob.m.sum", но если я собираюсь использовать заглавные буквы или точки для разделения слов, то я не должен делать это для всех переменных?

Некоторые переменные записываются более чем один раз, например, переменные расы, поэтому я добавил .is или .ih, чтобы указать, пришли ли они из школьной или домашней анкеты. Но есть, конечно, некоторые повторы, о которых я еще не знаю, лучше ли добавить ссылку на набор данных к имени каждой переменной?

Мне нужно сгруппировать и стандартизировать многие переменные, как я это сделал, добавив .zms, то есть z-показатель, по мужчине и по школе.

Любые общие или конкретные мысли или ресурсы приветствуются. Посмотрите этот репозиторий для некоторого моего кода и описательной статистики со списком имен переменных. Я кратко описал причину совместного использования этого кода здесь , и он был немного опубликован здесь , но последние две ссылки на самом деле не имеют отношения к проблеме соглашений об именовании переменных. Добавлено: я слегка отредактировал это, в основном просто перемещая абзац, чтобы попытаться избежать некоторой путаницы, очевидной в комментариях. Спасибо за мысли!

Добавлено 2016-09-05: Ее стоит отметить R Style Guide Hadley Уикхемы и руководство R Style от Google ... Hadley говорит:

Имена переменных и функций должны быть строчными. Используйте подчеркивание (_) для разделения слов в имени.

Google говорит:

Не используйте подчеркивания (_) или дефисы (-) в идентификаторах. Идентификаторы должны быть названы в соответствии со следующими соглашениями. Предпочтительной формой для имен переменных являются все строчные буквы и слова, разделенные точками (variable.name), но variableName также принимается; имена функций имеют начальные заглавные буквы и не имеют точек (FunctionName); константы именуются как функции, но с начальным k.

Лучший ответ на этот вопрос - это утка. По сути, не имеет большого значения, какие короткие имена переменных, если они где-то хорошо документированы в кодовой книге. Увы, поскольку у R нет собственных ресурсов для этого, люди склонны не беспокоиться. (Для меня этот недостаток - самый большой недостаток языка как статистического инструмента).

Существуют различные пакеты R, предоставляющие этот механизм, например, Hmiscкоторый вы используете, и memisc. Но на самом деле лучший вариант - сделать все это в виде пакета R. Таким образом, обработанные данные могут быть объектом с соответствующей страницей справки, которая описывает, как все теперь называется, и может присвоить кредит там, где он должен. Пакет также может предоставить необработанные данные и ваши функции обработки для людей, чтобы увидеть, что вы сделали, чтобы сделать конечный продукт.

Кроме того, предложение: вообще не включать производные данные, такие как переменные и их z-скоринговые версии, в конечный объект данных, если вы можете помочь, просто предоставьте функции, чтобы сделать это вместо этого. Производные данные - это просто проблема с точки зрения управления данными.

Вот небольшая вещь: я думаю, что лучше использовать подчеркивания, чем точки. Причина в том, что большинство языков программирования, в отличие от R, не поддерживают точки в идентификаторах, но почти все поддерживают подчеркивание. И я предполагаю, что вы хотите, чтобы ваш набор данных был полезен для людей, которые не используют R.

Прежде всего, спасибо за это - я уверен, что многие люди оценят это, хотя не многие будут знать, что вы это сделали.

Пользовательский интерфейс RStudio не (по крайней мере, с параметрами по умолчанию?) Не интерпретирует никакие разделители внутри имени переменной. Например, Eclipse рассматривает заглавные части как отдельные слова, поэтому вы можете использовать стрелки Ctrl + для быстрого редактирования кода в стиле Java, например ageStandardizedMaleSchool. Я не могу придумать более веские причины, чтобы предпочесть один разделитель другому, так что либо подчеркивание, либо заглавные буквы кажутся мне подходящими.

В общем, я предлагаю сделать имена переменных длиннее, а не придерживаться какой-то сложной схемы сокращений. Это легко сделать опечатки нравятся talk.prob.m.sumвместо talk.prob.sum.ms, и это трудно обнаружить и исправить ошибки трассировки в статистическом анализе. (В некотором роде: хорошая фраза, которую я читал в каком-то блоге, заключается в написании имен переменных, таких как скандинавские слова - SickHouse и ToothHealer вместо больницы и стоматолога .)

И последнее замечание: стандартизация, центрирование и т. Д. Обычно выполняются после очистки данных. Если нет очистки, то, возможно, подумайте о том, чтобы оставить это тому, кто будет анализировать данные. Или, если вы тоже делаете уборку, укажите все шаги, которые вы предприняли - последующие анализы и интерпретации могут сильно зависеть от этого.