By 마르신 뒤벨, 앱실론

깨끗한 R 코드가 중요합니다

 
 
성공적인 프로젝트를 제공하는 수년간의 경험을 통해 저는 각 구현에서 하나의 공통 요소를 발견했습니다. 깨끗하고 읽기 쉽고 간결한 코드베이스는 효과적인 협업의 핵심이며 클라이언트에게 최고 품질의 가치를 제공합니다.

코드 검토는 고품질 코드 프로세스를 유지하는 데 중요한 부분입니다. 또한 팀 구성원 간에 모범 사례를 공유하고 지식을 배포할 수 있는 좋은 방법입니다. Appsilon에서는 코드 검토를 모든 프로젝트의 필수 항목으로 취급합니다. 우리가 작업을 구성하는 방법에 대해 자세히 알아보십시오. 올가의 블로그 게시물 모든 데이터 과학 팀에 권장되는 모범 사례.

잘 정립된 코드 검토 프로세스가 있다고 해서 개발자가 훌륭하고 깨끗한 코드를 작성해야 한다는 사실이 바뀌지는 않습니다! 코드의 기본적인 실수를 모두 지적하는 것은 고통스럽고 시간이 많이 걸리며 검토자가 코드 논리를 깊이 파고들거나 코드의 효율성을 개선하는 데 방해가 됩니다.

잘못 작성된 코드는 팀 사기에도 해를 끼칠 수 있습니다. 코드 검토자는 좌절감을 느끼고 코드 작성자는 엄청난 수의 댓글에 기분이 상할 수 있습니다. 그렇기 때문에 검토할 코드를 보내기 전에 개발자는 코드가 가능한 한 깨끗한지 확인해야 합니다. 또한 도움을 줄 수 있는 코드 검토자가 항상 있는 것은 아닙니다. 때때로 당신은 프로젝트에서 혼자입니다. 지금은 코드가 괜찮다고 생각하더라도 몇 달 후에 다시 읽어보십시오. 나중에 시간을 낭비하지 않으려면 명확해야 합니다.

이 기사에서는 피해야 할 가장 일반적인 실수를 요약하고 일반적인 프로그래밍에서 따라야 할 모범 사례를 간략하게 설명합니다. 다음 팁을 따라 코드 검토 반복 프로세스의 속도를 높이고 검토자의 눈에 록스타 개발자가 되십시오!

주석이 있는 주석을 피하십시오

 
 
코드에 주석을 추가하는 것은 중요한 개발자 기술입니다. 그러나 더 중요하고 숙달하기 어려운 기술은 언제 지원 의견을 추가합니다. 좋은 댓글을 쓰는 것은 과학이라기보다는 예술에 가깝습니다. 그것은 많은 경험을 필요로 하고 그것에 관한 전체 책 장을 쓸 수 있습니다(예: 여기에서 지금 확인해 보세요.). 

댓글에 대한 댓글을 피하기 위해 따라야 할 몇 가지 간단한 규칙이 있습니다.

• 주석은 독자에게 외부 지식을 추가해야 합니다. 코드 자체에서 일어나는 일을 설명하는 경우 코드가 깨끗하지 않고 리팩터링해야 한다는 위험 신호입니다. 일부 해킹이 사용된 경우 진행 상황을 설명하는 데 주석이 사용될 수 있습니다. 일부러 추가한 필수 비즈니스 논리 또는 예외를 주석 처리합니다. 미래의 독자가 놀랄 수 있는 것을 생각하고 혼란을 선점하십시오.
• 중요한 댓글만 쓰세요! 귀하의 의견은 쉽게 검색할 수 있는 정보의 사전이 되어서는 안됩니다. 일반적으로 주석은 주의를 산만하게 하며 코드만큼 논리를 설명하지 않습니다. 예를 들어 최근에 코드에서 다음과 같은 주석을 보았습니다. trimws(.) # this function trims leading/trailing white spaces – 중복됩니다. 독자가 어떤 기능을 모르는 경우 trimws 하고 있는지 쉽게 확인할 수 있습니다. 여기에 더 강력한 주석이 도움이 될 수 있습니다. 예를 들면 다음과 같습니다. trimws(.) # TODO(Marcin Dubel): Trimming white spaces is crucial here due to database entries inconsistency; data needs to be cleaned.
• R로 함수를 작성할 때 추천합니다. {roxygen2} 댓글 사용 패키지를 작성하지 않더라도. 함수 목표, 매개 변수 및 출력에 대한 지식을 구성하는 데 탁월한 도구입니다.
• 주석(및 코드의 모든 부분)은 영어로만 작성하십시오. 모든 독자가 이해할 수 있도록 하면 모국어의 특수 문자를 사용할 때 나타날 수 있는 인코딩 문제를 줄일 수 있습니다.
• 향후 일부 코드를 리팩터링/수정해야 하는 경우 # TODO 논평. 또한 귀하를 이 주석의 작성자로 식별할 수 있는 몇 가지 정보(세부 정보가 필요한 경우 연락)와 다음 코드가 TODO로 표시되고 바로 수정되지 않는 이유에 대한 간략한 설명을 추가하십시오.
• 주석 처리된 코드를 주석 처리되지 않은 상태로 두지 마십시오! 미래를 위해 일부 부품을 보관하거나 잠시 꺼두는 것은 괜찮지만 항상 이 작업의 이유를 표시하십시오.

주석은 코드에 남아 있음을 기억하십시오. 검토자에게 한 번만 말하고 싶은 것이 있다면 코드 자체가 아닌 Pull(Merge) Request에 주석을 추가하십시오.

예: 최근에 "로직이 변경되면서 제거되었습니다."와 같은 주석이 있는 코드의 일부를 제거하는 것을 보았습니다. 좋아요, 알아두면 좋겠지만 나중에 코드의 주석이 이상하게 보이고 중복됩니다. 판독기가 제거된 코드를 더 이상 볼 수 없기 때문입니다.

문자열

 
 
텍스트와 관련된 일반적인 문제는 문자열 연결의 가독성입니다. 내가 많이 접하는 것은 paste 기능. 오해하지 마세요. 예를 들어 문자열이 단순할 때 훌륭한 기능입니다. paste("My name is", my_name), 그러나 더 복잡한 형식의 경우 읽기 어렵습니다. 

paste("My name is", my_name, "and I live in", my_city, "developing in", language, "for over", years_of_coding)

더 나은 해결책은 다음을 사용하는 것입니다. sprintf 기능 또는 glue, 예. 

glue(“My name is {my_name} and I live in {my_city} developing in {language} for over {years_of_coding}”)

쉼표와 따옴표가 없으면 더 명확하지 않나요?

많은 코드 블록을 처리할 때 별도의 위치(예: .yml 파일. 코드와 텍스트 블록을 더 쉽게 읽고 유지 관리할 수 있습니다.

텍스트와 관련된 마지막 팁: Shiny 애플리케이션에서 자주 사용되는 디버깅 기술 중 하나는 추가하는 것입니다. print() 진술. 지문이 코드에 남아 있지 않은지 다시 확인하십시오. 코드 검토 중에 상당히 난처할 수 있습니다!

루프

 
 
루프는 프로그래밍 빌딩 블록 중 하나이며 매우 강력한 도구입니다. 그럼에도 불구하고 계산적으로 무거울 수 있으므로 주의해서 사용해야 합니다. 따라야 할 경험 법칙은 다음과 같습니다. 루핑이 좋은 옵션인지 항상 다시 확인하십시오. 행을 반복해야 하는 경우는 거의 없습니다. data.frame: ~이 있어야 한다 {dplyr} 기능을 통해 문제를 보다 효율적으로 처리합니다. 

문제의 또 다른 일반적인 원인은 개체의 길이를 사용하여 요소를 반복하는 것입니다. for(i in 1:length(x)) .... 그러나 x의 길이가 1이면 어떻게 될까요! 예, 루프는 반복자 값 0, XNUMX에 대해 다른 방식으로 진행됩니다. 아마도 귀하의 계획이 아닐 것입니다. 사용 seq_along or seq_len 기능이 훨씬 안전합니다.

또한 다음에 대해 기억하십시오. apply 루핑을 위한 함수군. 그들은 훌륭합니다(말할 것도 없이 {purrr} 솔루션)! 참고 sapply 이 함수는 출력 자체의 유형을 선택하기 때문에 리뷰어가 불안정하다고 언급할 수 있습니다! 따라서 때로는 목록일 수도 있고 벡터일 수도 있습니다. 사용 vapply 프로그래머가 예상되는 출력 클래스를 정의하므로 더 안전합니다.

코드 공유

 
 
혼자 작업하는 경우에도 프로그램이 다른 컴퓨터에서 올바르게 실행되기를 원할 것입니다. 그리고 팀과 코드를 공유할 때 얼마나 중요한지! 이렇게 하려면 코드에 절대 경로(예: "/home/marcin/my_files/old_projects/september/project_name/file.txt")를 사용하지 마십시오. 다른 사람이 액세스할 수 없습니다. 폴더 구조를 위반하면 코드가 충돌합니다. 

모든 코딩 작업에 대한 프로젝트가 이미 있어야 하므로 특정 프로젝트와 관련된 경로를 사용해야 합니다. "./file.txt"가 됩니다. 또한 모든 경로를 한 곳에 변수로 보관할 것을 제안합니다. 따라서 파일 이름을 바꾸려면 예를 들어 XNUMX개의 서로 다른 파일에서 XNUMX개가 아니라 코드를 한 번 변경해야 합니다.

때때로 귀하의 소프트웨어는 예를 들어 데이터베이스 또는 개인 리포지토리에 대한 일부 자격 증명 또는 토큰을 사용해야 합니다. 이러한 비밀을 리포지토리에 커밋해서는 안 됩니다! 항목이 팀 간에 동일하더라도. 일반적으로 이러한 값을 .Renviron 파일은 시작할 때 로드되는 환경 변수로 파일 자체는 리포지토리에서 무시됩니다. 당신은 그것에 대해 더 읽을 수 있습니다 여기에서 지금 확인해 보세요..

좋은 프로그래밍 방법

 
 
마지막으로 코드를 개선할 수 있는 방법에 초점을 맞추겠습니다. 우선, 코드는 이해하기 쉽고 깨끗해야 합니다. 혼자 작업하더라도 잠시 후 코드로 돌아오면 삶이 더 쉬워질 것입니다! 

길어 보이더라도 특정 변수 이름을 사용하십시오. 일반적으로 이름만 읽어도 그 안에 무엇이 있는지 추측할 수 있어야 합니다. table_cases_per_country 괜찮아, 하지만 tbl1 아니다. 약어를 사용하지 마십시오. 모호한 것보다 긴 것이 좋습니다. 팀원들 간에 합의된 개체 이름(예: camelCase 또는 snake_case)에 대해 일관된 스타일을 유지합니다. 

논리 값을 축약하지 마십시오. T for  TRUE 및 F for  FALSE – 코드는 작동하지만 T 및 F 동안 덮어쓸 수 있는 일반 객체입니다. TRUE 및 FALSE 특별한 값입니다. 

다음과 같은 방정식을 사용하여 논리값을 비교하지 마십시오. if(my_logical == TRUE). 비교할 수 있다면 TRUE, 그것은 당신의 가치가 이미 논리적이라는 것을 의미하므로 if(my_logical) 충분하다! 값이 다음과 같은지 다시 확인하려면 TRUE 실제로(아니오, 예를 들어, NA), 다음을 사용할 수 있습니다. isTRUE() 기능.

논리 진술이 올바른지 확인하십시오. R의 차이점을 이해했는지 확인하십시오. 단일 및 이중 논리 연산자!

좋은 간격은 가독성에 중요합니다. 규칙이 동일하고 팀에서 동의했는지 확인하십시오. 서로의 코드를 더 쉽게 따라갈 수 있습니다. 가장 간단한 해결책은 거인의 어깨 위에 올라서서 다음을 따르는 것입니다. 티디버스 스타일 가이드. 

단, 리뷰시 모든 라인의 스타일을 확인하는 것은 상당히 비효율적이므로 꼭 소개해주세요. linter 및 스타일러 에 제시된 대로 개발 워크플로우에서 올가의 블로그 게시물. 이것은 생명을 구할 수 있습니다! 최근 우리는 linter에 의해 자동으로 인식되었을 일부 레거시 코드에서 오류를 발견했습니다.

sum_of_values <- first_element + second_element

작성자가 예상한 대로 요소의 합계를 반환하지 않습니다.

변수 이름에 대해 말하자면, 이것은 프로그래밍에서 가장 어려운 일 중 하나로 알려져 있습니다. 따라서 불필요할 때는 피하십시오. R 함수는 기본적으로 마지막으로 생성된 요소를 반환하므로 쉽게 바꿀 수 있습니다.

sum_elements <- function(first, second) { my_redundant_variable_name <- sum(first, second) return(my_redundant_variable_name)
}

더 짧고 더 간단하면 이름에 대해 생각할 필요가 없습니다.

sum_elements <- function(first, second) { sum(first, second)
}

반면에 함수 호출이나 계산을 반복할 때마다 추가 변수를 사용하십시오! 그것은 계산적으로 더 효과적이고 미래에 수정하기 쉽게 만들 것입니다. 코드를 유지하는 것을 잊지 마십시오 건조 – 반복하지 마십시오. 일부 코드를 복사하여 붙여넣는 경우 변수에 저장하지 말아야 하는지, 루프에서 수행해야 하는지 또는 함수로 이동해야 하는지 다시 한 번 생각하십시오. 

결론

 
 
깨끗한 R 코드를 작성하고 코드 리뷰어에게 주석을 남기지 않는 XNUMX가지 전략이 있습니다. 이 다섯 가지만으로도 몇 년이 지난 후에도 이해하기 쉬운 훌륭한 품질의 코드를 작성할 수 있습니다. 즐거운 코딩하세요!

 
바이오 : 마르신 뒤벨 Appsilon의 엔지니어입니다.

실물. 허가를 받아 다시 게시했습니다.

관련 :

• R에서 손으로 쓴 알파벳 인식을 위한 지원 벡터 머신
• 최고의 프로그래밍 언어와 그 용도
• 데이터 과학자가되는 방법에 대한 가이드 (단계별 접근 방식)