R Style(R 程式碼規範)
最近看到有朋友說起R程式碼書寫規範的問題,突然讓我意識到,從學R語言開始,似乎沒怎麼在書上提起過R程式碼風格。之前在學習Perl的時候,Perl語言入門這本書從最開始就提到了Perl程式碼的書寫風格,但其實Perl的風格就是沒有風格,只要不太過分隨意就好(所以我現在除了看自己的Perl程式碼還流暢,看其他的人的Perl程式碼需要打起十二分的精神,似乎每個人都很隨意~)
後來整理了下R程式碼風格,只要有以下幾個資料可以看看:
- Advanced R development(book)中的第三章-R程式碼,中文版則是R包開發
- ofollow,noindex" target="_blank">Google’s R Style Guide
- R Style Guide
一些部落格作者也對Google’s R Style Guide進行了中文翻譯:
然後發現了一個問題,感覺大家對於R程式碼的Style也並不是一致認同的,當然大部分的程式碼風格都是一致的
1.對於R變數的命名規則這裡有明顯的差異,我最早接觸的是Perl,對於變數命名一般用下劃線(_)分割變數的名詞,但是在Google’s R Style Guide則說要用點(.),還好Hadley Wickham認為點(.)要為S3方法保留;我也看了不少R指令碼以及R包的原始碼,似乎很少有人會用點(.)來分割。。。一般命名如下:
# Good day_one day_1 # Bad first_day_of_the_month DayOne dayone djm1
2.還有對於R程式碼縮排的問題,還好我從開始學習R就開始用Rstudio來寫我的R指令碼,所以縮排方式都是Rstudio所預設的,即2個空格;因此也不如製表符(tab)的坑,雖然Perl/Shell都習慣用tab來縮排的
3.但是也有個問題,對於一些情況,比如呼叫某函式時有多個引數要輸入,這時需要對一些引數寫到第二行,這時縮排該怎麼處理,是依舊按照2個空格處理,還是上下兩行的引數對其,如下:
doThatThing(arg1 = "a_long_string_is_passed", arg2 = "a_long_string_is_passed_here_too", arg3 = "another_long_string")
還是:
doThatThing(arg1 = "a_long_string_is_passed", arg2 = "a_long_string_is_passed_here_too", arg3 = "another_long_string")
如果是在Rstudio上寫的話,一般是上述第一種,而在一些Notepad++寫的話,我會手動調成第二種。。個人感覺喜歡就好
4.對於變數賦值到底是用箭頭<-
還是等號=
這個問題,上述資料中無一都是用箭頭<-
的,一些R語言入門教材中也是如此。。但其實在網上一些R程式碼中,用等號=
的人也不少;而我每次如果想偷懶複製其程式碼後,都會強迫自己把等號=
再改為我自己習慣的箭頭<-
,雖然其實兩者都不會影響程式碼的執行,但是會影響整體程式碼的可讀性(個人覺得。。),當然函式引數賦值還是要用等號=
的
# Good x <- 5 # Bad x = 5
5.註釋在程式碼中是必須的,但是註釋其實也有其標準(大家認為的)的寫法:整行註釋的話,是井號#
後面跟一個空格再接註釋文字;如果註釋內容是在行內短註釋,則在程式碼後面跟兩個空格,加個#
,再一個空格後接註釋內容。注意:一個井號#
就夠了,而我總喜歡個性隨意地用1-2個井號不等(似乎得改了)。。。
6.至於還有對註釋更進一步的函式文件的書寫,我似乎看到很少有人會這麼寫。。
函式在定義行下方都應當緊接一個註釋區. 這些註釋應當由如下內容組成: 此函式的一句話描述; 此函式的引數列表, 用Args: 表示, 對每個引數的描述(包括資料型別); 以及對於返回值的描述, 以Returns: 表示. 這些註釋應當描述得足夠充分, 這樣呼叫者無須閱讀函式中的任何程式碼即可使用此函式.
7.對於R file名字的命名,一般採用一些有意義的名字來命名,不要有特殊字元和空格(一般人也不會這樣做吧),但是要注意大小寫(特別是windowws系統是不管大小寫的),所以最好就小寫就行了;R程式碼就放在.R
檔案中,而R資料檔案則放在.RData
檔案中,雖然有人不建議用.rdata
or.rda
,但是其實在網上還是有不少人用的,反正大家也看得懂
8.剩下的也就是一些小問題了,比如括號、中括號、大括號等等書寫間隔的問題,一般都還正常的
最後我還是比較認同下面這段話:
Use common sense and BE CONSISTENT. If you are editing code, take a few minutes to look at the code around you and determine its style. If others use spaces around their if clauses, you should, too. If their comments have little boxes of stars around them, make your comments have little boxes of stars around them, too. The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you are saying, rather than on how you are saying it. We present global style rules here so people know the vocabulary. But local style is also important. If code you add to a file looks drastically different from the existing code around it, the discontinuity will throw readers out of their rhythm when they go to read it. Try to avoid this.
儘量遵循R程式碼書寫風格,如果要更改現有程式碼,儘可能與原作者風格保持一致,這樣便於其他人閱讀
本文出自於http://www.bioinfo-scrounger.com 轉載請註明出處