일관성 있는 R 코드 작성하기: 해들리 위컴의 R 코딩 스타일 가이드

다양한 R 스타일 가이드

좋은 코딩 스타일은 정확한 구두점을 찍는 것과 비슷합니다. 구두점이 없더라도 의미를 알 수는 있지만 구두점은 의미 전달을 더욱 쉽게 하고 글을 읽기 쉽게 만듭니다. R 에는 아래와 같이 유명한 스타일이 존재합니다.

- Bioconductor’s coding standards (https://bioconductor.org/developers/how-to/coding-style/)

- Hadley Wickham’s style guide (http://stat405.had.co.nz/r-style.html )

- Google’s R style guide (http://google-styleguide.googlecode.com/ svn/trunk/google-r-style.html )

- Colin Gillespie’s R style guide (http://csgillespie.wordpress.com/2010/ 11/23/r-style-guide/)

The State of Naming Conventions in R (by Rasmus Bååth)

일관적으로 코딩하는 것은 1) 사람들과 소통하기 쉽도록하고, 2) 스스로도 읽기 쉬운 코드를 작성할 수 있습니다. 코드를 작성한지 오랜 시간이 지나고, 다시 그 코드를 보았을 때, 의미를 알기 힘든 경우가 많습니다. 하지만 최대한 비슷한 스타일로 코딩을 한다면, 코드 이해에 드는 부담을 줄일 수 있습니다. 또한 많은 사람들이 비슷한 코딩 규약을 사용한다면 코딩을 통한 소통이 편리할 것입니다.

해들리 위컴의 R 코딩 스타일 가이드

본 포스팅에서는 tidyverse (tidyr, dplyr, ggplot2 등) 패키지로 유명한 해들리 위컴의 R 스타일 가이드를 정리해보도록 하겠습니다. 해들리 위컴의 R 스타일은 Google 의 R 스타일 가이드 를 약간 변형한 스타일입니다.  

이름짓기

- 파일 이름

1. 파일 이름은 의미가 있어야합니다.

# Good
fit-models.R
utility-functions.R

# Bad
foo.r
stuff.r

2. 만약 파일이 순서대로 실행되어야 한다면, 이와 같이 숫자로 prefix 를 붙이는 것도 좋습니다. 

0-download.R
1-parse.R
2-explore.R

- 객체 이름 

“There are only two hard things in Computer Science: cache invalidation and naming things.”

— Phil Karlton

변수명과 함수이름은 소문자를 사용하며, 단어를 분리할 때는 underscore(_) 를 사용합니다. 일반적으로 변수는 명사, 함수는 동사를 사용하는 것이 좋습니다. 이름은 최대한 간결하며 의미를 잘 전달할 수 있습니다. (이것은 때론 쉽지 않습니다.)

# Good
day_one
day_1

# Bad
first_day_of_the_month
DayOne
dayone
djm1

c, mean 과 같은 이미 사용되고 있는 객체에는 새로운 변수나 함수를 할당하는 것이 좋지 않습니다. 

# Bad
T <- FALSE
c <- 10
mean <- function(x) sum(x)

문법

Spacing

infix operators (=, +, -, <-, etc.) 에는 space 를 양옆으로 위치시킵니다. = 에서도 마찬가지입니다. comma 뒤는 한 칸 띄우며, comma 전에는 띄우지 않습니다. (이는 영어, 한글에서도 마찬가지입니다.)

# Good
average <- mean(feet / 12 + inches, na.rm = TRUE)

# Bad
average<-mean(feet/12+inches,na.rm=TRUE)

하지만 : 나 ::는 spacing을 하지 않습니다. 

# Good
x <- 1:10
base::get

# Bad
x <- 1 : 10
base :: get

if, for 문 등에서 ( 전에 한 칸을 띄웁니다. 하지만 함수를 호출할 때는 띄우지 않습니다. 

# Good
if (debug) do(x)
plot(x, y)

# Bad
if(debug)do(x)
plot (x, y)

아래처럼 정렬을 위해 space 를 두 번 이상하는것을 허용합니다. 

list(
  total   = a + b + c, 
  mean  = (a + b + c) / n
)

중괄호나 대괄호에는 comma 가 있는 경우가 아니라면 space 를 넣지 않습니다. 

# Good
if (debug) do(x)
diamonds[5, ]

# Bad
if ( debug ) do(x)  # No spaces around debug
x[1,]   # Needs a space after the comma
x[1 ,]  # Space goes after comma not before

중괄호

중괄호의 시작 ( { ) 이 있는 경우, 항상 개행을 해야합니다. 중괄호의 끝( } ) 이 있는 경우, if 문의 else 가 뒤따라오지 않는다면 그 줄에는 } 만 오도록 합니다. 물론 중괄호 안에서의 indentation 은 기본입니다. 

# Good

if (y < 0 && debug) {
  message("Y is negative")
}

if (y == 0) {
  log(x)
} else {
  y ^ x
}

# Bad

if (y < 0 && debug)
message("Y is negative")

if (y == 0) {
  log(x)
} 
else {
  y ^ x
}

매우 짧은 if 문의 경우 한 줄에 작성하는 것을 허용합니다. 

if (y < 0 && debug) message("Y is negative")

한 줄의 길이

한 줄의 길이를 80 자가 넘지 않도록 하는 것이 좋습니다. 이는 일반적인 크기의 글꼴로 프린트를 했을 때 용지에 잘 맞도록 하기 위함입니다. 

Indentation

Indentation 을 할 때, space 만 사용하는 것이 좋습니다. 다만 function 을 정의할 때, parameter 의 수가 많아 줄이 길어진다면 함수의 정의가 시작되는 부분에 맞게 indentation 을 합니다. 

long_function_name <- function(a = "a long argument", 
                               b = "another argument",
                               c = "another long argument") {
  # As usual code is indented by two spaces.
}

할당

변수 할당에는 = 를 사용하지 않고 <- 를 사용합니다. 

# Good
x <- 5
# Bad
x = 5

주석 달기

코드에 주석을 다는 것이 좋습니다. 주석은 무엇을 (what) 이 아닌 왜(why) 에 대한 내용을 설명해야 합니다. what 에 대한 내용은 코드 자체로 충분히 이해할 수 있도록 하는것이 좋습니다. 아래처럼 주석을 입력한 줄에 - 또는 = 을 사용해 읽기 쉽도록 분리하는 것도 좋습니다. 

# Load data ---------------------------

# Plot data ---------------------------

출처 - http://adv-r.had.co.nz/Style.html