Skip to content

Coding Conventions

WesIngwersen edited this page Apr 25, 2018 · 1 revision

This page establishes conventions for coding that should be consistent across the project

Naming conventions

Functions should start with a verb in non-caps. Common operations should use common verbs..do not use synomyms without reason

The following keywords and succeeding nouns should use title capitalization

Prepositions should be in non-caps

Avoid underscore in variable and function names

Variable name should be non-caps

Nouns should be set up like state = "GA" (with quotation marks)

Numbers should be set up like referenceyear = 2013 (without quotation marks)

In addition, follow these rules

File and Data conventions

All data and metadata (e.g. files with field names or info on data files) file are stored in SI and under subfolders designated by the providers name

The SI/Crosswalk folder contains all crosswalks

All input files specific created specifically for USEEIO with USEEIO inputs are in the SI/USEEIO folder

Data are stored in the code repository under the conditions: They are from static files that are not frequently updated or readily available and they may be used more than once They are not exceeding 1MB

Data are stored in .csv files.

Output files from running the code are Model Builds with the subfolder having the model name and version number. Within a specific model build folder all model pieces have a standard name beginning with the modelname and version number, eg. 'USEEIOv1.0'

Program structure conventions

Global variables are declared and loaded in a single folder. These include paths to files and global functions for package setup.

If functions are used in more than one file, put them in a separate file, with functions in the name and group them by the type of data or type of operations they apply to.

File with just functions should not have inline code except to declare a variable or import data used by all functions

Source calls should appear inside functions if they are only used by one function

Functions should ideally do a perform a single abstract function well Reference: tidy tools manifesto

Avoid mixing side-effects with transformations. Ensure each function either returns an object, or has a side-effect. Don?t do both. Reference: tidy tools manifesto

When performing the same type of operation on data, use the same function from the same package, unless there is good reason not do

Clone this wiki locally