The DRY principle

Don’t Repeat Yourself.

\[ \textrm{RMS}(x_1, \ldots, x_n) = \sqrt{\frac{1}{n} \sum_{i = 1}^n x_i^2} \]

rms1 = np.sqrt(np.mean(
  np.square(error1)
))
rms2 = np.sqrt(np.mean(
  np.square(error2)
))

def rms(x):
    '''Return the root mean square of
    the vector x'''
    return np.sqrt(np.mean(
      np.square(x)
    ))


rms1 = rms(error1)
rms2 = rms(error2)

Follow a style guide

Style guides list rules to follow when laying out your code.

You should start from a publicly available guide.

For R, you can follow the Tidyverse style guide [1].

For Python, the standard is called PEP 8 [2].

You can tweak the guidelines to suit you, but not following some style guide is like writing a paper with inconsistent grammar, or using two different citation styles in the same document (Bertolacci, 2020).

R style example

y <- x*2
if(y > 2) {
  z <- y + 2
}
sqrt_z <- sqrt (z)

y <- x * 2
if (y > 2) {
  z <- y + 2
}
sqrt_z <- sqrt(z)

The R package lintr [3] can check your code automatically:

example.R:1:7: style: Put spaces around all infix operators.
y <- x*2
     ~^~
example.R:2:3: style: Place a space before left parenthesis, except in a function call.
if(y > 2) {
  ^
example.R:5:11: style: Remove spaces before the left parenthesis in a function call.
sqrt_z <- sqrt (z)

Python style example

y = x*2
if y> 2:
   z = y + 2
sqrt_z = sqrt (z)

y = x * 2
if y > 2:
    z = y + 2
sqrt_z = sqrt(z)

The program pycodestyle [4] checks if you are following the rules:

example.py:2:5: E225 missing whitespace around operator
example.py:3:4: E111 indentation is not a multiple of four
example.py:4:14: E211 whitespace before '('

Sometimes you knew what the code does when you wrote it, but a few months later…

loc<-c(137.5, -4.7)
loc2<-c(77.5, 18.1)
dat<-read.csv('locations.csv')
d=2*3389.5*asin(sqrt(
sin((dat$lat*pi/180-loc[2]*pi/180)/2)^2
+cos(dat$lat*pi/180)*cos(loc[2]*pi/180)
*sin((dat$lon*pi/180-loc[1]*pi/180)/2)^2))
d2=2*3389.5*asin(sqrt(
sin((dat$lat*pi/180-loc2[2]*pi/180)/2)^2
+cos(dat$lat*pi/180)*cos(loc2[2]*pi/180)
*sin((dat$lon*pi/180-loc2[1]*pi/180)/2)^2))
#dat$nrst=-1
dat$nrst=0
for(i in 1:nrow(dat)){
if(d[i]<d2[i])
dat$nrst[i]<-1
else
dat$nrst[i]<-2
}

More clean code tips

• Code for correctness and readability first.
• Comments are great, but it’s better if the code is obvious enough not to need comments.
• Shorter isn’t necessarily better—short programs don’t run any faster!
• Tab completion in your editor means you don’t have to type longer function and variable names every time.
• Picking good names for things is hard, but it’s worth the effort.

A tale of two errors…

n <- length(y)
sigma <- 1
log_likelihood <- (
  - n * log(2 * pi) / 2
  - n * log(sigma)
  - sum(y ^ 2 / sigma ^ 2) / 2
)
bic <- log(n) - 2 * log_likelihood
print(bic)

## [1] NA

dat <- data.frame(x = 1 : 10)
dat$y <- sin(df$x)
fit <- lm(y ~ x, data = dat)
print(coef(fit))
plot(dat$x, fitted(dat$y))

## Error in df$x: object of type
##   'closure' is not subsettable

Dead programs tell no lies

Defensive programming can be used when you’re aware you’re making an assumption. The idea is to intentionally throw an error when an assumption found to be false.

Most languages have functions to help you do this.

This way, you don’t have to search for the offending line.

Example: the exponential covariance function,

\[ C(\mathbf{x}, \mathbf{x}') \equiv \exp\left( -\frac{||\mathbf{x} - \mathbf{x}'||}{l} \right) \]

where \(l > 0\).

In R, you can use the stopifnot function:

# Given a vector or matrix x, return the covariance matrix based on the
# exponential covariance function
cov_exponential <- function(x, length_scale) {
  stopifnot(length_scale > 0)
  exp(-fields::rdist(x) / length_scale)
}

cov_exponential(y, -1)

## Error in cov_exponential(y, -1): length_scale > 0 is not TRUE

In Python, you can use the assert keyword:

import numpy as np

def cov_exponential(x, length_scale):
    '''Given a vector or matrix x, return the covariance matrix based on the
    exponential covariance function'''
    assert length_scale > 0, 'length_scale must be positive'
    return np.exp(-np.linalg.norm(x) / length_scale)

cov_exponential(y, -1)

Traceback (most recent call last):
  File "example.py", line 7, in <module>
    cov_exponential(y, -1)
  File "example.py", line 4, in cov_exponential
    assert length_scale > 0, 'length_scale must be positive'
AssertionError: length_scale must be positive

Back to the tale of two errors

stopifnot(all(!is.na(y)))
n <- length(y)
sigma <- 1
log_likelihood <- (
  - n * log(2 * pi) / 2
  - n * log(sigma)
  - sum(y ^ 2 / sigma ^ 2) / 2
)
bic <- log(n) - 2 * log_likelihood
print(bic)

## Error: all(!is.na(y)) is not TRUE

More defensive programming tips

• You won’t always know what assumptions you’re making implicitly immediately.
• But! when your code breaks, add a stopifnot or assert to catch it next time.
• Don’t feel the need to check everything, just the most important parts.
• In R, the assertthat package [6] can help.