Style guide

Viz collaborations are smoother when we adopt a consistent code style. Here is the style we have chosen:

Naming conventions

1. Viz.yaml element ids: my-element-mobile
2. R functions that build viz.yaml elements: process.my_element()
3. R function names: my_function_name
4. R variable names: my.variable.name
5. File names: scripts/process/process.my_element.R, example_data_file.tsv
6. CSS classes and IDs: fig-text
7. JavaScript functions and variables: myVariableName, myFunctionName

Organization

1. In JavaScript, use namespacing to put related things together and to keep variables localized
2. Fetch/process/visualize functions should each produce a single file (at the viz 'location') for the sake of clean dependency management.

Handoffs between stages

Within the constraints of efficiency and practicality, and allowing for exceptions:

1. Fetch functions should preserve a raw or near-raw data format. If you do any processing, limit it to actions you're sure no one will need to revise during the viz sprint, so that we have a fighting chance of only having to do the download once per computer.
2. Process functions should bring the data all the way from just-fetched to visualization-ready. As much as possible, say 'yes' to tabular and spatial data manipulation, 'no' to SVG, CSS, and JavaScript. It's fine for there to be 2+ process phases for a single dataset.
3. Visualization functions should produce static (but interaction-ready) graphics.
4. The publish phase is the ideal place for layout, styling, and interactivity.