Поліпшення імен змінних у наборі даних

Хорошими назвами змінних є:

а) коротка / проста введення,

б) легко запам'ятовується,

в) зрозуміла / комунікативна.

Я щось забуваю? Послідовність - це щось шукати. Я б сказав, що послідовні конвенції про іменування сприяють вищезгаданим якостям. Послідовність сприяє (б) простоті пригадування та (в) зрозумілості, хоча інші фактори часто важливіші. Існує чіткий компроміс між (a) довжиною іменем / простотою введення тексту (наприклад, всі малі літери) та (c) зрозумілістю.

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

Поки я перейменую змінні, я хочу зробити їх максимально корисними. Ось деякі питання, які я розглядав. Поки що я використовував лише малі регістри та уникав використання будь-яких тире чи підкреслення, і я використовував лише періоди для однієї дуже конкретної мети. Це має силу простоти та послідовності та не створює проблем для більшості змінних. Але оскільки речі стають складнішими, я спокушаюся порушити свою послідовність. Візьмемо, наприклад, мій змінний "talkprobmsum", його було б легше читати як "talkProbMSum" або ще краще "talk.prob.m.sum", але якщо я буду використовувати великі літери або крапки для розділення слів, то я не повинен робити це для всіх змінних?

Деякі змінні реєструються більше, ніж один раз, наприклад, змінні перегони, тому я додав .is або .ih, щоб вказати, що вони надходять із анкети в школі чи вдома. Але напевно є деякі повтори, про які я ще не знаю, чи було б краще додати посилання до набору даних до імені кожної змінної?

Мені потрібно згрупувати центр і стандартизувати багато змінних, як я це робив, додаючи .zms, що означає z-оцінка чоловіків та шкіл.

Будь-які загальні чи конкретні думки чи ресурси високо оцінюються. Дивіться у цьому сховищі деякий мій код та описову статистику зі списком змінних імен. Я коротко описав причину спільного використання цього коду тут , і він був трохи оприлюднений тут , але ці два останні посилання насправді не стосуються питання конвенцій про іменування змінних. Додано: Я редагував це легенько, в основному просто переміщуючи абзац, щоб спробувати уникнути певної плутанини, помітної в коментарях. Дякую за думки!

Додано 05.09.2016: Варто відзначити посібник зі стилів R Хедлі Вікхема та керівництво Google щодо стилю R ... Хедлі говорить:

Імена змінних та функцій повинні бути малими літерами. Використовуйте підкреслення (_), щоб розділити слова в імені.

Google каже:

Не використовуйте підкреслення (_) або дефіси (-) в ідентифікаторах. Ідентифікатори повинні бути названі згідно з наступними умовами. Кращою формою для імен змінних є всі маленькі літери та слова, розділені крапками (змінною. ім'я), але також приймається змінна назва; назви функцій мають початкові великі літери та відсутні крапки (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 замість лікарні та стоматолога .)

На завершення: стандартизація, центрування тощо проводяться, як правило, після очищення даних. Якщо немає очищення, то, можливо, варто подумати про те, хто аналізуватиме дані. Або, якщо ви також займаєтеся очищенням, вкажіть всі кроки, які ви зробили - наступні аналізи та інтерпретації можуть багато в чому залежати від цього.