???? R Coding Style Guide
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.
Language is a tool that allows human beings to interact and communicate with each other. The clearer we express ourselves, the better the idea is transferred from our mind to the other. The same applies to programming languages: concise, clear and consistent codes are easier to read and edit. It is especially important, if you have collaborators, which depend on your code. However, even if you don’t, keep in mind that at some point in time, you might come back to your code, for example, to fix an error. And if you did not follow consistently your coding style, reviewing your code can take much longer, than expected. In this context, taking care of your audience means to make your code as readable as possible.
Good coding style is like using correct punctuation. You can manage without it, but it sure makes things easier to read. Hadley Wickham
There is no such thing as a “correct” coding style, as there is no such thing as the best color. At the end of the day, coding style is a set of developers’ preferences. If you are coding alone, sticking to your coding style and being consistent is more than enough. The story is a bit different if you are working in a team: it is crucial to agree on a convention beforehand and make sure that everyone follows it.
Even though there is no official style guide, R is mature and steady enough to have an “unofficial” convention. In this post, you will learn these “unofficial” rules, their deviations, and most common styles.
Naming
Naming files
The convention actually depends on whether you develop a file for a package, or as a part of data analysis process. There are, however, common rules:
-
File names should use
.R
extension.# Good read.R # Bad read
File names should be meaningful.
# Good model.R # Bad Untitled1.R