Best Coding Practices

RaukR 2025 • R Beyond the Basics

Sebastian DiLorenzo

08-Jun-2025

Learning Outcomes

After this module:

• You will be aware of different coding styles.

• You will know what styles are good and bad and why.

• You will think a bit about what is a good name.

• You will learn about code formatting.

• You will sample some different notations.

What is Coding Style?

• Naming conventions — assigning names to variables

• Code formatting — placement of braces, use of white space characters etc.

From: Behind The Lines 2010-09-23. By Oliver Widder, Webcomics Geek And Poke.

Naming Conventions

A syntactically valid name:

• Consists of:

  • letters: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
  • digits: 0123456789
  • period: .
  • underscore: _

• Begins with a letter or the period (.), if . should not followed by a number

• Cannot be one of the reserved words: if, else, repeat, while, function, for, in, next, break, TRUE, FALSE, NULL, Inf, NaN, NA, NA_integer_, NA_real_, NA_complex_, NA_character_

• Also cannot be: c, q, t, C, D, I as they are reserved function names.

Naming Style

Variable names that are legal are not necessarily a good style and they may be dangerous ☠️:

F
T

[1] FALSE
[1] TRUE

F + T

[1] 1

F <- 3
F + T

[1] 4

do not do this!

unless you are a politician 🕴…

Avoid T and F as variable names.

Customary Variable Names

Also, there is a number of variable names that are traditionally used to name particular variables:

• usr — user
• pwd — password
• x, y, z — vectors
• w — weights
• f, g — functions
• n — number of rows
• p — number of columns
• i, j, k — indexes
• df — data frame
• cnt — counter
• M, N, W — matrices
• tmp — temporary variables

Sometimes these are domain-specific:

• p, q — allele frequencies in genetics,
• N, k — number of trials and number of successes in stats

Try to avoid using these for other variables to avoid possible confusion.

Code formatting

Goal: Improve readability

1. Consistent indentation/whitespace

a <- 15
  b <- 20
  
  c <- function(a,b){             #Bad
return(a + b)}

      d <- 1+2:3*(4/5)

a <- 15
b <- 20
c <- function(a, b) {             #Good
  return(a + b)
}
d <- 1 + 2:3 * (4 / 5)

https://posit-dev.github.io/air/

Code formatting

Goal: Improve readability

2. Consistent braces and linewidth

# Bad
fn <- function(a_really_long_variable_name, another_really_long_name) a_really_long_variable_name + another_really_long_name

# Good
fn <- function(
  a_really_long_variable_name,
  another_really_long_name
) {
  a_really_long_variable_name + another_really_long_name
}

https://posit-dev.github.io/air/

Different Notations

People use different notation styles throughout their code:

• snake_notation_looks_like_this

• camelNotationLooksLikeThis

• period.notation.looks.like.this

But many also use…

• LousyNotation_looks.likeThis

Try to be consistent and stick to one of them. Bear in mind period.notation is used by S3 classes to create generic functions, e.g. plot.my.object. A good-enough reason to avoid it?

It is also important to maintain code readability by having your variable names:

• informative, e.g. genotypes vs. fsjht45jkhsdf4

• Not too long, e.g. weight vs. phenotype.weight.measured

Special Variable Names

• There are built-in variable names:

  • LETTERS: the 26 upper-case letters of the Roman alphabet
  • letters: the 26 lower-case letters of the Roman alphabet
  • month.abb: the three-letter abbreviations for the English month names
  • month.name: the English names for the months of the year
  • pi: the ratio of the circumference of a circle to its diameter

• Variable names beginning with period are hidden: .my_secret_variable 👻 will not be shown but can be accessed

.the_hidden_answer <- 42
ls()

[1] "F" "T"

but with a bit of effort you can see them:

ls(all.names = TRUE)

[1] ".main"               ".QuartoInlineRender" ".Random.seed"       
[4] ".the_hidden_answer"  "F"                   "T"                  

Thank you!

Questions?

2025 • SciLifeLab • NBIS • RaukR