@studyportals/stylelint-config

Install & basic usage

Install the package

npm install --save-dev @studyportals/stylelint-config

Add beneath code to your package.json

"stylelint": {
  "extends": "@studyportals/stylelint-config"
}

Guidelines

Syntax

• Use tabs for indentation.
• Try to limit your character length per line to 80 characters, we have a absolute limit of 120 characters.
• Do not include a space before the opening brace of declaration blocks (e.g. .Foo{ .. }).
• Place closing braces of declaration blocks on a new line.
• Include one space after : for each declaration.
• Each declaration should appear on its own line for more accurate error reporting.
• End all declarations with a semi-colon. The last declaration's is optional, but your code is more error prone without it.
• Prefix property values or color parameters with a leading zero (e.g., 0.5 instead of .5 and -0.5px instead of -.5px).
• Uppercase all hex values, e.g., #FFFFFF.
• Use long hex values, e.g., #FFFFFF instead of #FFF.
• Quote attribute values in selectors, e.g., input[type="text"]. They’re only optional in some cases, and it’s a good practice for consistency.
• Avoid specifying units for zero values, e.g., margin: 0; instead of margin: 0px;.

/* Bad example */
.Selector, .SelectorSecondary, .Selector[type=text] {
  padding:15px;
  margin:0px 0px 15px;
  box-shadow:.5px 1px 2px #cccccc,inset 0 1px 0 #FFF
}

/* Good example */
.Selector, .SelectorSecondary, .Selector[type=text] {
  padding: 15px;
  margin-bottom: 15px;
  box-shadow: 0.5px 1px 2px #CCCCCC, inset 0 1px 0 #FFFFFF;
}

Nesting

Avoid unnecessary nesting. Consider nesting only when you must scope.

• We allow a nesting depth of 4 deep, to prevent a too deeply nested elements.
• Keep a empty line between after each nested selectors, for better readability.
• Keep a empty line between each declaration and the nested selector.

/* Bad example */
.Selector {
  padding:15px;
  .Nested{
    ...
  }
  .AnotherNested{
    .To{
      .Deep{
        .NestedChild{
          ...
        }
      }
    }
  }
}

/* Good example */
.Selector {
  padding:15px;

  .Nested{
    ...
  }

  .NestedChild{
    ...
  }
}

Class names

• Write classes in PascalCase, don't use lowercase, dashes or underscores. (e.g. .SomeExample).
• Do not use shorthand notation, so use .Button instead of .Btn.
• Keep classes as short and succinct as possible.
• Use meaningful names, use structural or purposeful names over presentational.
• Use .js-* classes to denote behavior (as opposed to style), but keep these classes out of your CSS.
• Use .is-* classes to describe a certain style within an current state.

/* Bad example */
.T{ ... }
.Red{ ... }
.Header{ ... }
.js-Header{ ... }

/* Good example */
.Tweet{ ... }
.Important{ ... }
.TweetHeader{ ... }
.is-Collapsed{ ... }

$Variable names

• Write classes in PascalCase, don't use lowercase, dashes or underscores. (e.g. .SomeExample).
• Do not use shorthand notation, so use .Button instead of .Btn.

Apply these rules also to @function and @import names.

/* Bad example */
$colorGrey: lightgrey;
$color-grey: lightgrey;
$_SomeOtherColor: firebrick;

/* Good example */
$GreyL: lightgrey;

@import

• Do not import .css files!
• Do not forget the underscore if the file has one.
• Add the extension to the filename.

/* Bad example */
@import "../path/to/some/stylesheet.css"; // Don't import css files
@import "../path/to/file"; // Define the file extension

/* Good example */
@import "../path/to/_file.scss";

Comments

Code is written and maintained by people. Ensure your code is descriptive, well commented, and approachable by others. Great code comments convey context or purpose. Do not simply reiterate a component or class name.

Be sure to write in complete sentences for larger comments and succinct phrases for general notes.

• Preferable use block comments above single-line comments.
• If you add reminder add a TODO before you start the comment (e.g. /* TODO: Add styling for invalid state. */).