4D Pie Charts

Precedence of rules

1. When extending existing code, follow the style of that code.
2. Where there are no existing style rules, use this guide.
3. If this guide doesn’t cover it, try another guide (R internal coding standards, Bioconductor coding standards, Google’s, Hadley Wickham’s standard and Stat 405, Colin Gillespie’s, Henrik Bengtsson’s basic and Aroma, Paul E Johnson’s).

Variable and function names

4. Variables, in general, should be given meaningful and pronounceable names in the problem domain.
5. If the variable has a unit, that unit should be included as a suffix in the name.

#Good:
height_cm <- rnorm(1000, 170, 5)  #includes unit
is_tall <- height_cm > 200        #in problem domain

#Bad:
foo <- 1:10                       #not meaningful
height <- rnorm(1000, 170, 5)     #no unit
tall_flag <- height_cm > 200      #'flag' refers to var type not problem domain

6. Index variables with short scope may be given short names, e.g., i, j, k. Likewise, mathematical variables with short scope may be given an appropriate short name such as x, y, z.
7. Variables that are summary statistics of of variables should take the form stat_of_original_variable, except
8. The prefix n may be used instead of count_of for variables representing the number of objects (e.g., n_items).

#Good:
for(i in seq_along(x))               #short names are OK for indexers, math vars
{
  #loop content here
}
mean_of_height_cm <- mean(height_cm) #takes form stat_of_var; includes unit

#Bad:
height_cm_mean <- mean(height_cm)    #wrong form

9. Variable names, including function names, should be lower_under_cased, except
10. Variables representing constants should be UPPER_UNDER_CASED, and
11. Functions using S3 method dispatch must take the form generic_name.class, and
12. Column and row names for data frames, matrices, etc., should be lower.dotted.cased.

#Good:
body_data <- data.frame(
  weight.kg = c(65, 83, 99),           #lower dotted case; unit included
  height.m  = c(156, 179, 186)
)
PI_SQUARED <- pi^2
mean.my_class <- function(x) {}        #some implementation

#Bad:
firstdayofweek <- 'Monday'   # wrong case

13. Negated boolean names should be avoided.

#Good:
if(is_found) #...

#Bad:
if(!is_not_found) #...

14. Functions of opposite concepts should have matching opposite prefixes.

#Good:
read_my_data()
write_my_data()
#or
load_my_data()
save_my_data()

#Bad:
readRDS()
saveRDS()          #read and save don't match!

Code quality

15. All functions intended to be called directly by a user should include input validation and, where appropriate, default values for inputs.
16. All functions intended to be called directly by a user should have help documentation explaining usage.

#Good:
calculate_area_of_rectangle <- function(width, height) 
{
  if(any(width < 0) || any(height < 0)) 
  {
    stop("all inputs must be non-negative")
  }
  width * height
}

Code Reuse

17. Functions should be used instead of scripts, where appropriate.
18. Lots of small functions should be used rather than a few big functions.
19. Packages should be used instead of individual functions, where appropriate.

Syntax
Assignment

20. <- should be used for assignment (not =).

#Good:
mean_height <- mean(height)

#Bad:
mean_height = mean(height)

White space

21. There should be a space before and after all binary operators (<-, ==, +, *, &&, etc.), except
22. The colon operator, :, and the exponentiation operator, ^.
23. There should be a space after a comma, but not before.
24. There should be no white space immediately inside brackets, (), {}, {}.
25. Extra spacing is permissible if it improves alignment.
26. In particular, equals signs for named arguments in the same function call should be aligned.
27. Nested items should be given on their own line and indented, where this improves clarity.
28. Tabs should be made of space characters, not a tab character.
29. Tabs should be 32 spaces wide. (I’ve changed my mind about this. Since you can break lines whenever you like, highly indented code is possible and useful; this in turn requires a smaller tab size.)
30. Where function calls have been split over multiple lines, the closing bracket appears on its own line, aligned with the start of the function name.

#Good:
y <- x + 1;
z <- m[1:2, ];
list(
  x       = 1:10,        # extra spaces align equals signs
  data    = my_data,
  sublist = list(
    a = 123,
    b = list(
      zzz = "structure is easier to determine when you indent nested items"
    )                    #closing bracket gets its own line
  )                      #and again
)                        #and again

#Bad:
y<-x+1;                  # no spaces
z <- y[ 1:2,];           # spaces inside brackets, none after comma

Braces

31. Braces are not compulsory, but are recommended.
32. Braces for code blocks should appear aligned, on their own lines.

#Good:
if(runif(1) > 0.5)
{
  cat("more than a half")
}

#Bad:
if(runif(1) > 0.5) {         #misaligned brace
  cat("more than a half")
}

33. Code should be vectorised, where possible, in preference to loops.
34. Short loops for code that cannot be vectorised should use an apply-like function.
35. Outputs from loops should be initialised before the loop.
36. switch statements for character values should include an “otherwise” statement where possible.

#Good:
mean(height)                  #mean is vectorised
tapply(height, gender, mean)  #apply-like functions are the next best thing

#Bad:
total <- 0
count <- 0
for(i in 1:length(height))
{
  total <- total + height[i]
  count <- count + 1
}
mean_height <- total / count
#Slower and vastly more effort than it should be

37. Line lengths should be less than 80 characters. Longer lines should be split at a graceful point (e.g., after a comma or operator).
38. There should only be one command on any line, except for assignment/display combinations.
39. Even for assignment/display combinations, brackets are preferred to multiple statements.

x <- 1:10; x          #assignment and display is okay on one line...
(x <- 1:0)            #but using brackets is preferred for this task

Floating point numbers

40. Floating point values should always include a digit before the decimal point.

#Good:
0.5

#Bad:
.5    #less readable

Boolean values

41. TRUE and FALSE should be used for boolean values (not T and F).

#Good:
c(TRUE, FALSE)

#Bad:
c(T, F)    #less readable

Share this:

• Share

• Reddit
• Facebook
• Twitter
• Email
• Print

Like this:

Like Loading...