Coding Standards


  • Use spaces not tabs.
    • (If you're using Geany, this can be changed in Edit->Preferences->Editor->Indentation->Type->Spaces)
  • Indents are 4 spaces.
  • Don't use "amusing" variable and function names - it just makes it harder for the next person. Make variable names easy to understand and descriptive of their usage.
  • If possible, don't copy and paste code between files - code reuse is much quicker and more practical.
  • All filenames are to be lowercase, alphanumeric with hyphens or underscores (hyphens preferred, except for Python modules where underscores are necessary).
    • This means no filenames with spaces or brackets (lest the fury of a thousand suns, i.e. others who live in the terminal, rain down upon you).
    • Use hyphens or underscores to separate words.
  • Team members should not work off code that is not in the team's repository.
    • This means you should not be pulling from other team members' forks.


Read PEP 8, and follow it where it affords clarity and readability. Pretty much the only thing we don't agree on is the line length limit.

(David seems to like the 90-ish line length limit suggested in Raymond Hettinger's Beyond PEP 8 talk though.)

In particular, name things like so:

  • Class names use PascalCase.
  • Function names use snake_case, except for when implementing WPILib interfaces (which use camelCase).
    • (This is potentially up for discussion.)
  • Variable names use snake_case.
  • Global "constants" in ALL_UPPERCASE.
  • Global "constants" declared at the top of the file or top level of a relevant class.


We don't have our own style guide here. We do like Airbnb's JS style guide though.


2 space indents are probably a good idea here — HTML is very nesting-heavy…


  • Classes declared in header, functions defined in cpp file.
  • Classes use CamelCase.
  • Functions use lowerLeadingCamelCase.
  • Variables use lowercase_with_underscores.
  • Symbolic constants in ALLUPPERCASE.
  • Symbolic constants in the header file.