Code style - BU-ISCIII/BU-ISCIII GitHub Wiki

General guidelines

File names

File names should be meaningful, written in lowercase characters only and end in .R. Both minus (-) and underscore (_) are good options to separate words within a file name, choosing whatever makes more sense. Never use dot (.), and never ever use whitespace ( ) for that purpose.

# Good
fit-models.R
utility_functions.R

# Bad
foo.r
StuFF.r
T3rr1bl3 N4m1ng.r

If files need to be run in sequence, prefix them with numbers and underscore (_):

0_download.R
1_parse.R
2_explore.R

General Code Style

While you should follow the code style that's already there for files that you're modifying, the following are required for any new code.

Indentation

Indent 4 spaces. No tabs. If you use the vim configuration in the dotfiles repository it will change tabs for spaces automatically.

Use blank lines between blocks to improve readability. For existing files, stay faithful to the existing indentation.

Line Length and Long Strings

Maximum line length is 80 characters.

If you have to write strings that are longer than 80 characters, this should be done with an embedded newline if possible. Literal strings that have to be longer than 80 chars and can't sensibly be split are okay, but it's strongly preferred to find a way to make it shorter.

Bad:

long_string_1="I am an exceptionalllllllllllly looooooooooooooooooooooooooooooooooooooooong string."

Good:

cat <<END;
I am an exceptionalllllllllllly 
looooooooooooooooooooooooooooooooooooooooong string.
END

Good:

long_string_2="I am an exceptionalllllllllllly 
 looooooooooooooooooooooooooooooooooooooooong string."

Variables

Naming Conventions

Meaningful self-documenting names should be used. If the variable name does not make it reasonably obvious as to the meaning of the variable, appropriate comments should be added.

Variable names must be words in lowcase separated with underscore, no camelCase.

Bad:

local TitleCase=""
local camelCase=""

Good:

local snake_case=""

Uppercase strings are reserved for global variables.

Bad:

local UPPERCASE=""

Good:

UPPERCASE=""

Variable names should not clobber command names, such as dir or pwd.

Bad:

local pwd=""

Good:

local pwd_read_in=""

Variable names for loop indexes should be named similarly to any variable you're looping through.

Good:

for zone in ${zones}; do
  something_with "${zone}"
done

Constants and Environment Variable Names

All caps, separated with underscores, declared at the top of the file. Constants and anything exported to the environment should be capitalized.

Constant:

PATH_TO_FILES='/some/path'

Functions

Naming Conventions

Lower-case, with underscores to separate words. Parentheses are required after the function name. The opening brace should appear on the same line as the function name.

Bad:

function my_bad_func {
  ...
}

Good:

function my_good_func() {
  ...
}

Error catching

You MUST always use error catching. This varies a lot between programming languages so this issue will be further address in each programming languages code styles.