Skip to content

Latest commit

 

History

History
33 lines (25 loc) · 1.48 KB

general-practices.md

File metadata and controls

33 lines (25 loc) · 1.48 KB

General Practices

Table of Contents

  1. Code Commenting

Code Commenting

Linter disabling reasons

Our linter rules, with ESLint and Stylelint, can be disabled for a file, for a code block, or for a specific line when needed. See documentation for Stylelint and for ESLint regarding their methods.

If our linter rules are well thought-out (and open to suggestions from the team), this should be done very rarely. When disabling a linter rule, we should include an additional comment line briefly noting why it was done. This helps code reviewers in their job and helps devs later maintain the code by indicating why the irregular decision was made.

For example:

body {
  // stylelint-disable-next-line property-no-vendor-prefix
  -webkit-text-size-adjust: 100%;
  // Prefix property needed for iOS font sizing.
}

Occasionally, the linter will throw multiple violations that can't be suppressed with inline comments. You may be tempted to use a generic disable inline comment: // stylelint-disable. Instead, use a block comment for each rule:

/* stylelint-disable font-weight-notation */
/* stylelint-disable color-named */
  strong { font-weight: map-get($weights, black); }

Remember to re-enable the linter:

/* stylelint-enable */