&quot;It turns out that style matters in programming for the same reason that it matters in writing. It makes for better reading.“ Douglas Crockford in JavaScript: The Good Parts Why do we need yet another style guide? &quot;The reason to care about a style guide is just one thing: We want that our source code is not only interpretable by a computer but also by a human.“ If you start to write not only for yourself but also for others, you do not want to lose your readers. You have to start to care about format, style and clarity. The format and partially the style can be addressed by sticking to a style guide. However, your code is not becoming prose just like that. If an author does not care if her code is readable, even a style guide won’t help. On the contrary, if you do care about readability, format and style are the easiest things to get started with and it will have an immediate impact. When you begin to care about readability, here is a short list of benefits: Your colleagues will like you and are happy to pick your work up where you left off. Well, not quite, but we can get there. Errors are easier to spot. When you review your own source code you will fewer and fewer ask yourself: Who wrote this? And what does it mean? When you decide to stick to any style guidelines, be aware that it is not that important which one you pick. What is important is that you and your team can agree on sticking to it. There are two popular style guides for R. One is the style guide from Google and the other one can be found in Advanced R by Hadley Wickham. We deviate only on some specific rules from these guides. Furthermore, we have decided to make them mandatory. Every time code is committed into a git repository, a CI tool will automatically check for any style violations. Another component is a template for a typical script which can be found below. We also implemented most of these rules and some more ideas in a dedicated package INWTUtils which can be found in its GitHub repository. Naming convention In contrast to the two style guides mentioned before, we decided to use lowerCamelCase for most identifiers. Underscores and dots are not allowed in usual object names. There is one case where you could deviate from this convention: By naming GLOBAL_VARIABLES – they are only used in scripts and only defined at the top – in upper case with underscores, they can be found at a glance. Automatic style checking If you want to go a step further, you can even check your R code for deviations from style rules with automated checks. The lintr package contains useful functions to run such checks. You can apply these checks to a package or a single file. While doing so, you can choose exactly which rules you want to test. Our own checks are: Use