3 Developing: 3. Style Guide
athena edited this page 4 months ago

Style Guide

Code style, that is.

Here are some best practices to stay consistent with Jupiter.

This is only required when doing pull requests. Otherwise, just for consistency.


  • Only use function expressions unless you have a real good reason to use the alternative.
  • If your function expressions only take one parameter, exclude the parenthesis. (const func = value => {} instead of const func = (value) => {})
  • Use const unless you really need to use let; try to avoid var
  • Use classnames instead of ID's where possible; use .querySelector instead of getElementsByClassName or .getElementById where possible.
  • Use semi-colons.
  • 4 character tabs, not spaces.
  • use_snake_case
  • If your IDE supports it, you can use Prettier to format the code, as long as it is customized to the rules above.


  • Use SASS functions where possible to avoid clutter.
  • Try to keep most rules nested within an element, to avoid conflicts.
  • Don't add a billion rules. The src/css/layout/spacing rules are long enough.
  • The final source .css file (NOT g-zipped) needs to be less than 500 KB.
  • To add size-related cutomizations to components, use the ..., .xs, .sm, .md, .lg, .xl, .2xl, ... class convention
  • Add more colors only if they are distinctive from the default colors, and only add to the default colors. Make sure to add them to the dynamic_accents.js file if you want them to be included there.
  • Where the file might be considered ambiguous, add a header comment section which explains the purpose. Example: src/css/layout/spacing/_padding_percentage.scss
  • Mobilize your components where needed using the sizes specified in the docs/2-layout.md file.

Next: Developing: 4. Overrides