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.

JavaScript

  • 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.

CSS (SCSS)

  • 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