• Use verb in the file name, section name, and function name

  • 8_entry_model to 8_estimate_entry_model
  • # travel frequency to adjecent mesh to # make travel frequency to adjecent mesh

• Do not use . in the file, object, and variable names. Use _ instead.

  • _ works in C/C++ but . does not. Write robust object names for translation into C/C++.

• Use Ctrl+Shift+R to make a section in RStudio.

  • By doing so, the table of contents are automatically generated in RStudio.

  • When making a subsection, add one # and remove one -.

    

• Don’t use the plural in the file name, section name, or function name

  • The plural may mean multiple elements, multiple vectors, multiple matrices, and so on.
  • Even if you meant something at the beginning, it gradually loses sense, leaving some cognitive cost.

• In each file, load relevant data at the beginning, transform data next, analyze the transformed data, and report the results. These steps should be Do not mix up these steps inside a file.

  • Take care of the indentation.

• Put a space after ,, ), } and so on. Put spaces before and after =.

• Break lines when there are more than one arguments in a function-like:

gpu_output <-
  foreach (
    i = 1:nrow(gpu),
    .combine = "rbind"
    ) %dopar% {
    model_i <- 
			gpu[i, ] %>% 
			dplyr::pull(model)
    release_i <- 
			gpu[i, ] %>% 
			dplyr::pull(release) 
    time_i <- paste(release_i, current_date)
    trend_i <- 
      gtrendsR::gtrends(
        keyword = model_i,
        time = time_i
      )
    trend_i <- trend_i$interest_over_time
    return(trend_i)
  }

• Call a function in a library in dplyr::mutate format.
  • To avoid name space conflictions.
  • To make the dependence on library explicit.
  • To make it compatible with a multi-node parallelization.
  • Exceptions are magrittr for %>% and foreach for %do% and %dopar%.
  • In reporting file, you can also load ggplot2, modelsummary, etc.
• Avoid using an upper case letter.
  • We do not want to remember whether it was an upper or lower case when we type it.
• If you find a minor mistake or typo in the cleaned data, make sure to go back to the data cleaning step, correct the mistake, and perform the data-cleaning code again. Do not fix it in the data transformation step while leaving the problem in the cleaned data.
  • If you are afraid that running the data cleaning code again can change the results of the following analysis, it is a sign that your code is not well organized.
  • Keep the data cleaning code clean and efficient so that you can re-run it whenever you want without any hesitation.
• Pipe %>% should be used only for a sequence of operations comprising a single meaningful task.
  • For example, if you drop rows including NA and/or outliers and then construct some new variables, you should separate these two tasks, and should not connect with %>%.
• When we join data frames, only use dplyr::left_join. Never use other joins such as dplyr::full_join and dplyr::inner_join.
  • You have a list of observations on the left data frame. We never change this list by a join operation.
  • If you need to join and drop rows with some NA, do this explicitly by dplyr::left_join followed by dplyr::filter.
  • No operation that mystifies changes the list of observations is allowed.
• Each file should have the structure of:
  • Set environment
  • Load data
  • Set constant
  • Transform data
  • Analyze data
  • Export results
  • In particular, never read data in the middle of the code. The dependence on reading data should be upfront.
• In RStudio, by Ctrl + Shift + R, you can insert a section and generate a table of contents. Use them to structure the code.
• When obtaining multiple results, standardize the format of the result and hold them as elements of a list. Write a function applicable to the standard and happy to each element of the list by purrr::map.
  • For example, when running multiple regressions, prepare a list of formulas and pass it to purrrr::map to run multiple regressions and obtain the results in another list.
• The file names of the same category should have the same format.
  • For example, if there is a figure for a long window and a short window, the file name should be figure_long.png and figure_short.png. They should not be like figure.png and figure_short.png. If you added figure_short.png later, make sure to rename figure.png to figure_long.png.
• Do not ignore any warnings.
  • If you ignore "ignorable" warnings, you will also ignore dangerous warnings.
  • Warnings are often signals of unexpected behavior or a bug.
• When saving a file in output and figuretable, make a subfolder of the code file’s name and save it in the subfolder.
  • For example, if the code file is main/estimate_parameters.R, then make a subfolder output/estimate_parameters/ and save files in it.
  • This is to make it easy to remove unnecessary files.
  • This also makes it easy to find a figure and table file and the code making them from the path in the draft.