Menghibur Arkeologi: Panduan Gaya R Di Bawah Kaca Pembesar

Seperti yang Anda ketahui, kode dibaca lebih sering daripada yang tertulis. Sehingga setidaknya orang selain penulis dapat membacanya, dan ada panduan gaya. Untuk R, ini mungkin, misalnya, manual Hadley.

Panduan gaya bukan hanya perjanjian diam-diam antara pengembang - banyak aturan memiliki latar belakang yang aneh. Mengapa panah <- lebih baik daripada tanda sama dengan = , mengapa orang tua R tidak menyukai garis bawah, bagaimana panjang garis yang disarankan terkait dengan kartu punch, dan banyak lagi - lebih.

Penafian: Panduan Gaya R
Tidak seperti Python, R tidak memiliki standar tunggal. Karenanya, tidak ada panduan tunggal. Selain panduan Hadley (atau versi tidyverse yang diperluas ), ada yang lain, seperti Google atau Bioconductor .

Namun, panduan Hadley dapat dianggap yang paling umum (seperti cek RStudio bawaan, misalnya), yang sangat difasilitasi oleh popularitas perpustakaan yang dibuat oleh Hadley sendiri (dplyr, ggplot, tidyr, dan lainnya dari koleksi tidyverse).

1. Operator penugasan: <- vs =


Semua panduan yang tersedia merekomendasikan penggunaan operator non-standar <- , tetapi tidak dengan tanda sama dengan = , yang umum untuk bahasa modern lainnya. Tiga operator lain ( <<- , -> , ->> ) bahkan tidak disebutkan (seperti yang ada di versi sebelumnya := ). Tampaknya, mengapa kita perlu panah non-standar ini?

Sejarah mengungkapkan kartu kepada kita: di R, panah itu berasal dari S, yang pada gilirannya mewarisinya dari APL. Di APL, ini memungkinkan kami untuk membedakan tugas dari kesetaraan. Dalam R, operator persamaan adalah standar, sehingga perbedaannya berbeda. Jika panah pada awalnya adalah operator penugasan, maka tanda yang sama hanya memberikan nilai pada parameter yang disebutkan. Pada tahun 2001, tanda sama dengan menjadi operator penugasan, tetapi tidak pernah menjadi identik dengan panah.

Apa yang memungkinkan kami untuk mempertimbangkan = penggantian penuh untuk panah? Pertama-tama, = bagaimana operator penugasan hanya bekerja di tingkat atas. Misalnya, di dalam fungsi, semuanya akan berfungsi seperti sebelumnya:

 mean(x = 1:5) # [1] 3 x # Error: object 'x' not found mean (x <- 1:5) # [1] 3 x # [1] 1 2 3 4 5 

Di sini = hanya menetapkan parameter fungsi, sementara <- juga memberikan nilai ke variabel x. Kita dapat mencapai efek yang sama dengan menempatkan operasi penugasan dalam tanda kurung (tidak, ini masih bukan Lisp) :

 mean ((x = 1:5)) # [1] 3 x # [1] 1 2 3 4 5 

... atau dalam kawat gigi:

 mean ({x = 1:5}) # [1] 3 x # [1] 1 2 3 4 5 

Selain itu, panah diutamakan di atas tanda sama dengan:

 x <- y <- 1 # OK x = y = 2 # OK x = y <- 3 # OK x <- y = 4 # Error in x <- y = 4 : could not find function "<-<-" 

Ekspresi terakhir gagal karena sama dengan (x <- y) = 4 , dan parser mengartikannya sebagai

 `<-<-`(x, y = 4, value = 4) 

Dengan kata lain, kami mencoba melakukan operasi yang salah: pertama tetapkan x ke y dan kemudian coba tetapkan x dan y ke 4. Ekspresi akan diproses tanpa kesalahan hanya jika Anda mengubah prioritas operasi dengan tanda kurung: x <- (y = 4) .

2. Jarak


Panduan ini merekomendasikan penempatan spasi antar operator (kecuali, tentu saja, tanda kurung siku,:, :: dan :: :), serta sebelum braket pembuka. Jelas, ini adalah bagian dari standar pengkodean GNU. Namun, klausa ini terkait erat dengan penggunaan <- sebagai operator penugasan. Sebagai contoh

 x <-1 

Apa ini X kurang dari -1? Atau atur x ke 1?

Namun, ruang ekstra tidak lebih baik daripada yang hilang, misalnya:

 x <- 0 ifelse(x <-1, T, F) # [1] TRUE x <- 0 ifelse(x < -1, T, F) # [1] FALSE 

Dalam kasus pertama, tidak ada ruang antara < dan - , yang menciptakan operator penugasan.

3. Nama fungsi dan variabel


Panduan gaya tidak setuju pada pertanyaan nama: panduan Hadley merekomendasikan garis bawah untuk semua nama; Google Guide - pemisahan berdasarkan titik untuk variabel dan gaya unta dengan huruf kecil pertama untuk berbagai fungsi; Bioconductor merekomendasikan lowerCamel untuk fungsi dan variabel. Tidak ada persatuan dalam komunitas R dalam masalah ini, dan semua gaya yang mungkin dapat ditemukan:

 lowerCamel period.separation lower_case_with_underscores allowercase UpperCamel 

Tidak ada gaya seragam bahkan untuk nama R dasar (misalnya, nama nama dan baris. Nama adalah fungsi yang berbeda!). Jika Anda tidak memperhitungkan allowercase yang tidak dapat dibaca (hanya pengguna Matlab yang dapat menyukainya), ada tiga gaya paling populer: lowerCamel, huruf kecil dengan _, dan huruf kecil dengan pemisahan titik.



Popularitas gaya yang berbeda untuk nama fungsi dan parameter (satu nama dapat sesuai dengan gaya yang berbeda). Sumber: Kinerja Rasmus BΓ₯Γ₯th pada useR! 2017.

Hal yang sama di tahun 2012

Sumber: Baath (2012). " Keadaan Konvensi Penamaan di R ". The R Journal Vol. 4/2, P. 74-75.

Pemisahan point-to-point mengingatkan pada penggunaan metode dalam pemrograman berorientasi objek, tetapi secara historis umum. Sangat umum bahwa gaya khusus ini dapat dianggap benar-benar R'vsky. Sebagai contoh, sebagian besar fungsi dasar menggunakannya secara khusus (dan semua orang hanya bertemu dengan data.table dan as.factor).

Tapi pemisahan _ adalah salah satu gaya yang paling tidak populer (dan di sini Hadley bertentangan dengan mayoritas). Bagi banyak pengguna R, garis bawah akan menjengkelkan: dalam ekstensi Statistik Emacs Speaks yang populer, ia digantikan secara default dengan operator penugasan <- . Dan pengaturan default, tentu saja, hampir tidak ada yang berubah.

Namun, pengaruh Emacs ESS masih merupakan penjelasan dari kategori "ekor mengibas anjing." Ada alasan yang lebih kuno: dalam versi R yang lebih lama, garis bawah identik dengan panah <- . Misalnya, pada tahun 2000 Anda dapat memenuhi ini:

 #      R c <- c(1,2,3,4,5) mean(c) [1] 3 c_mean <- mean(c) c [1] 3 

Di sini, alih-alih membuat variabel c_mean R menetapkan nilai 3 terlebih dahulu ke mean variabel, dan kemudian ke variabel c. Dalam R modern, metamorfosis seperti itu, tentu saja, tidak akan terjadi.

Karena tidak populernya, _ fungsi gaya ini hampir tidak ditemukan di antara yang dasar:

 #  3.5.1  25  grep("^[^\\.]*$", apropos("_"), value = T) 

Akhirnya, gaya lowerCamel sulit dibaca ketika menggunakan nama panjang:

 # ! GrossNationalIncomePerCapitaAtlasMethodCurrentUnitedStatesDollars 

Dengan demikian, dalam hal nama, rekomendasi panduan tidak dapat dianggap tidak ambigu; setelah semua, ini adalah masalah selera (selama ada konsistensi dalam hal ini).

4. kurung kurawal


Menurut panduan ini, baris baru harus mengikuti kurung kurawal pembukaan, dan yang penutupan harus di jalur yang terpisah (kecuali yang lain mengikutinya). Yaitu sesuatu seperti ini:

 if (x >= 0) { log(x) } else { message("Not applicable!") } 

Semuanya di sini tidak terlalu menarik: ini adalah gaya lekukan standar K&R, yang berasal dari bahasa C dan buku terkenal oleh Kernigan dan Ritchie "Bahasa Pemrograman C" (atau K&R dengan nama penulis).

Asal usul gaya ini juga cukup jelas: ini memungkinkan Anda untuk menyimpan garis, sambil mempertahankan keterbacaan. Untuk komputer awal, ruang vertikal terlalu mewah. Misalnya, C dikembangkan pada PDP-11, di terminal yang hanya ada 24 jalur. Dan saat mencetak buku K&R, gaya ini menghemat kertas!

5. 80 karakter string


Panjang garis yang disarankan menurut panduan ini adalah 80 karakter. Angka ajaib 80 ditemukan tidak hanya dalam R, tetapi juga dalam sejumlah besar bahasa lain (Jawa, Perl, PHP, dll., Dll.). Dan tidak hanya bahasa: bahkan baris perintah Windows terdiri dari 80 karakter.

Untuk pertama kalinya dalam pemrograman, angka ini muncul pada tahun 1928 alih-alih dengan kartu punched IBM standar, di mana ada tepat 80 kolom untuk data. Pertanyaan yang jauh lebih menarik adalah mengapa standar seperti itu dipilih? Bagaimanapun, kartu punch dengan panjang yang berbeda (untuk 24 atau 45 kolom) sebelumnya digunakan.



Jawaban paling populer menghubungkan panjang kartu punch dengan panjang mesin tik. Mesin pertama dirancang untuk kertas standar Amerika 8Β½ x 11 inci, dan diizinkan untuk mencetak dari 72 hingga 90 karakter, tergantung pada ukuran margin. Oleh karena itu, versi 80 karakter per baris terlihat cukup masuk akal, meskipun tidak benar di jalan terakhir. Ada kemungkinan bahwa 80 karakter hanyalah jalan tengah dalam hal ergonomi.

6. Baris indentasi: spasi vs tab


Gaya yang direkomendasikan oleh panduan ini adalah dua spasi, bukan tab. Penolakan tabulasi cukup dapat dimengerti: panjang TAB bervariasi dalam editor teks yang berbeda (bisa berkisar antara 2 hingga 8 spasi). Menolak mereka, kami mendapatkan dua keuntungan sekaligus: pertama, kode akan terlihat sama persis seperti yang kami ketikkan; kedua, tidak akan ada pelanggaran yang tidak disengaja dari panjang tali yang disarankan. Dalam hal ini, tentu saja, kami menambah ukuran file (siapa yang mau berurusan dengan optimasi mikro seperti itu di 2k19?)

Tab sengketa vs tab memiliki sejarah panjang, dan dapat disamakan dengan tab religius (seperti Win vs Linux, Android vs iOS, dan sejenisnya). Namun, kita sudah tahu siapa yang memenangkannya: menurut studi Stack Overflow, pengembang yang menggunakan spasi menghasilkan lebih banyak daripada mereka yang menggunakan tab. Argumen yang lebih kuat daripada aturan panduan gaya, kan?

Alih-alih kesimpulan: aturan panduan gaya mungkin tampak aneh dan tidak logis. Memang, mengapa panah <- jika ada operator standar = ? Tetapi jika Anda menggali lebih dalam, maka di balik setiap aturan ada beberapa logika, sering sudah dilupakan.

Source: https://habr.com/ru/post/id454432/


All Articles