Veri kümesindeki değişken adlarını geliştirme

İyi değişken isimleri:

a) kısa / yazması kolay,

b) hatırlaması kolay,

c) anlaşılabilir / iletişimsel.

Bir şey unutuyor muyum? Tutarlılık aranacak bir şeydir. Benim ifade ettiğim yol, tutarlı adlandırma sözleşmelerinin yukarıdaki niteliklere katkıda bulunmasıdır. Tutarlılık (b) geri çağırma kolaylığına ve (c) anlaşılabilirliğe katkıda bulunur, ancak diğer faktörler genellikle daha önemlidir. (A) ad uzunluğu / yazma kolaylığı (örneğin, tümü küçük harf) ve (c) anlaşılabilirlik arasında açık bir denge vardır.

Binlerce insan veri kullanıyor çünkü bu konularda adil bir düşünce yatırım yapıyorum ve umarım birçok veri hazırlamak ve bazı analiz türlerini kolaylaştırmak için kodumu kullanacaktır . Ergen Sağlığı Boylamsal Çalışmasından elde edilen veriler, birden çok veri kümesine ayrılmıştır. İlk adım, en sık kullanılan veri kümesindeki 227 değişkeni almak, bunları yeniden kodlamak, daha anlamlı adlar vermekti. Orijinal değişken adları, "aid2", "age" ve "male.is" olarak yeniden adlandırdığım "aid", "s1", "s2" gibi şeylerdir. Diğer veri kümelerinde, araştırmacının hedeflerinin ne olduğuna bağlı olarak birleştirilebilecek binlerce başka değişken vardır.

Değişkenleri yeniden adlandırdığım sürece, onları olabildiğince yararlı hale getirmek istiyorum. İşte düşündüğüm konulardan bazıları. Şimdiye kadar sadece küçük harf kullandım ve herhangi bir tire veya alt çizgi kullanmaktan kaçındım ve sadece belirli bir amaç için dönemler kullandım. Bu sadelik ve tutarlılık erdemine sahiptir ve çoğu değişken için sorun yaratmaz. Ama işler daha karmaşık hale geldikçe, tutarlılığımı kırmaya cazip geliyorum. Örneğin, değişkenim "talkprobmsum" olarak, "talkProbMSum" veya daha iyisi "talk.prob.m.sum" olarak okumak daha kolay olurdu, ancak kelimeleri ayırmak için büyük harf veya nokta kullanacaksam tüm değişkenler için yapmamalı mıyım?

Bazı değişkenler birden fazla kez kaydedilir, örneğin .is veya .ih gibi yarış değişkenleri okul içi veya ev içi anketten gelip gelmediklerini belirtmek için ekledim. Ama kesinlikle farkında olmadığım bazı tekrarlar var, her değişkenin adına veri kümesine bir referans eklemek daha iyi olur mu?

Bir çok değişkeni grup ortalamam ve standartlaştırmam gerekiyor, bunu yaptığım yol erkek ve okul tarafından z-skoru anlamına gelen .zms eklemektir.

Herhangi bir genel veya özel düşünce veya kaynak büyük beğeni topluyor. Bazı kodlarım ve değişken adlarının listesini içeren açıklayıcı istatistikler için bu veri havuzuna bakın . Kısaca bu kodu paylaşımı nedenini tarif burada ve biraz kamuoyuna burada , ama bu son iki bağlantılar değişken adlandırma kuralları konusuna gerçekten alakalı değildir. Eklendi: Yorumlarda açıkça görülen karışıklıklardan kaçınmak için bunu hafifçe düzenledim, çoğunlukla sadece bir paragrafı hareket ettirdim. Düşünceleriniz için teşekkürler!

2016/09/05 Eklendi: belirterek Onun değerinde Hadley Wickham'ın R Stil Kılavuzu'na ve Google'ın R Stil Kılavuzu'na ... Hadley diyor ki:

Değişken ve işlev adları küçük harf olmalıdır. Bir ad içindeki kelimeleri ayırmak için alt çizgi (_) kullanın.

Google diyor:

Tanımlayıcılarda alt çizgi (_) veya kısa çizgi (-) kullanmayın. Tanımlayıcılar aşağıdaki kurallara göre adlandırılmalıdır. Değişken adları için tercih edilen form, küçük harflerle ve noktalarla ayrılmış değişkenlerdir (değişken.adı), ancak değişkenAdı da kabul edilir; işlev adları başlangıçta büyük harf kullanır ve nokta içermez (İşlevAdı); sabitleri benzer işlevler olarak adlandırır, ancak bir başlangıç ​​k ile.

Bu soruya verilecek en iyi yanıt, onu ördek etmektir. Temel olarak, bir yerde bir kod defterinde iyi belgelendiği sürece, değişkenlerin kısa isimlerinin ne olduğu önemli değildir. Ne yazık ki, R'nin bunun için yerel bir kaynağı olmadığından insanlar rahatsız etmiyor. (Benim için eksiklik, istatistiksel bir araç olarak dilde en büyük başarısızlıktır).

Bu makineleri sağlayan çeşitli R paketleri vardır, örneğin Hmisckullandığınız ve memisc. Ama gerçekten en iyi seçenek, her şeyi bir R paketine dönüştürmektir. Bu şekilde işlenen veriler, her şeyin şu anda ne çağrıldığını açıklayan ve zamanı geldiğinde kredi atayabilen ilgili yardım sayfasına sahip bir nesne olabilir. Paket ayrıca, insanların nihai ürünü yapmak için ne yaptığınızı görmeleri için ham verileri ve işleme işlevlerinizi gösterebilir.

Ayrıca, bir öneri: yardımcı olabilirseniz, son veri nesnesine değişkenler ve bunların z-puanlı sürümleri gibi türetilmiş verileri dahil etmeyin, bunun yerine işlevler sağlayın. Türetilmiş veriler, veri yönetimi açısından sorun yaratır.

İşte küçük bir şey: Bence alt çizgi kullanmak noktalardan daha iyidir. Bunun nedeni, R'nin aksine çoğu programlama dilinin tanımlayıcılardaki süreleri desteklememesi, ancak neredeyse tümünün alt çizgileri desteklemesi. Ve veri kümenizin R kullanmayan insanlar için yararlı olmasını istediğinizi düşünüyorum.

Her şeyden önce, bunu yaptığınız için teşekkür ederim - eminim birçok kişi bunu yaptığınızı bilmese bile, birçok insan bunu takdir edecektir.

RStudio kullanıcı arabirimi (en azından varsayılan seçeneklerle?) Değişken adındaki ayırıcıları yorumlamaz. Örneğin, Eclipse büyük / küçük harfleri ayrı kelimeler olarak ele alır, böylece Ctrl + oklarını kullanarak Java tarzı kodu hızlı bir şekilde düzenleyebilirsiniz ageStandardizedMaleSchool. Bir ayırıcıyı diğerine tercih etmek için daha iyi bir neden bulamıyorum, bu yüzden alt çizgi veya kapaklar bana iyi geliyor.

Genel olarak, bazı karmaşık kısaltma şemasına bağlı kalmak yerine değişken adlarını daha uzun hale getirmenizi öneririm. Bunun talk.prob.m.sumyerine yazım hataları yapmak kolaydır talk.prob.sum.msve istatistiksel analizde hataları tespit etmek ve izlemek zordur. (Biraz ilgili: Bazı bloglarda okuduğum güzel bir deyim, İskandinav kelimeleri gibi değişken adlarınızı yazmaktır - hastane ve diş hekimi yerine SickHouse ve ToothHealer .)

Son bir not: standartlaştırma, merkezleme vb. Genellikle veri temizlendikten sonra yapılır. Herhangi bir temizlik yoksa, verileri analiz edecek olana bırakmayı düşünebilirsiniz. Ya da temizliği kendiniz de yapıyorsanız, attığınız tüm adımları belirtin - sonraki analizler ve yorumlar buna çok bağlı olabilir.