Deliver better frontend code!

Acceptance criteria

• The code meets the rules. See the Coding standards section.
• The resulting visual is identical to the graphic template. Pixel perfect is not required, but we are very close to it.

Coding standards

General declarations

• Write code that is reasonable, maintainable and scalable.
• Code documentation is not needed in most cases. Write unambiguous and understandable code.

Example of comments in CSS:

/* Header of the web
   =============

   Header prototype, not finished component.
   Used on all sites except the purchase process.
*/     

// Main block
// --------------

// [1] It is a relatively positioned container, which we will 
//     use in components from the `header/` directory.
// [2] We need Flexbox due to the layout of internal components
//     and also the change of order for `.header__top` 
//     to `@query-lg` breakpoint.

.header {
  padding-bottom: (@lineHeight / 2);
  position: relative; // [1]
  display: flex; // [2]
  flex-wrap: wrap;
  align-items: center;
}

Templates

1. Valid HTML according to doctype (e.g. HTML 5).
2. HTML character entities in numeric form (–).
3. Accessibility rules according to WCGA 2 in priority 1 and WAI-ARIA at least at the level defined by the Bootstrap framework.
4. Beware of the dangerous arsenal — atomic classes. Use it wisely.

Style sheets

We follow the principles of the used framework (Bootstrap). Extend styles with BEM methodology is handy. In complex projects namespaces can help.

Code tidiness

1. We write clean code without vendor prefixes, which adds Autoprefixer according to the project specifications.
2. No !important declarations.
3. Respect selector specificity in the cascade.
4. No IDs if the functionality doesn’t require it.

Code performance

1. Use CSS properties wisely. Too many CSS variables cause high demands on the browser and slow rendering. Local CSS properties are handy.
2. CSS must be quickly processed. Pay attention to generic selectors (*, >, etc.).
3. We do not forget the computational demands, so we work carefully with multiple shadows, animations or transformation s (GPU isolation with translateZ or translate3D).

Code structure

1. We try to have a flat structure, minimal immersion of selectors.
2. We immerse media queries in selectors due to modularization and debugging.
3. We prefer a mobile-first approach — media queries from the smallest breakpoint to the largest.
4. Sorting CSS properties according to the specification prevent overlooked duplicities and redeclarations.
5. Sorting inside the cascade according to the rule: @extend, @include, pseudo-classes, pseudo-elements, BEM modifications, BEM elements and descendants.

The order of declarations:

.my-class {
  @extend %module;

  @include transition(all 0.3s ease);

  background: blue;

  &:hover {
    background: navy;
  }

  &::before {
    content: '';
    display: block;
  }

  &.my-class--red {
    background: red;

    &:hover {
      background: maroon;
    }
  }

  > h3 {
    @include transform(rotate(90deg));

    border-bottom: 1px solid white;
  }
}

SCSS

1. We pay attention to the correct use of the variable within the context e.g. $theme-colors vs $colors or $spacers vs component speciffic variables $btn-padding-y, $btn-padding-y-sm etc.
2. We use SCSS tools with caution, especially @extend.
3. Use frameworks mixins and functions.
4. Write your custom mixins and functions for better code readability.
5. We use the same file encoding (UTF-8) as templates because content: attr(), emojis etc.
6. Code formatting by project defaults. Primarily defined in .editorconfig, .prettierrc.yml and .stylelintrc.yml.

JavaScript

We prefer vanilla JS processed by Babel.

File structure and organization

There is no universal way to structure source files in a project.

• Reactive frameworks as VueJS on projects with visually similar blocks calls for single file components.
• Small projects or prototyping can help use utility-first CSS frameworks as TailwindCSS but keep in mind that the rewrite to the components will be so painful and time-consuming.
• The component-based approach with BEM methodology asks for each component in a single file named by the component. Each file should contain all behaviour include modifies, element, responsivity and parent or siblings dependencies.
• Small projects can be organized as my Frontend Gulp DevStack.

Wrap up

Appropriate choice of frontend framework simplifies and speeds up development. I this case, standardization equals predictivity and testability. I prefer Bootstrap — it is widespread, the most stable and widely tested. Good documentation greatly accelerates onboarding. When compiling, you can easily modularize within CSS and JS. For a smooth delivery, I recommend using the tools for static code analysis with pre-commit and pre-merge hooks. Live usage of these tools is in my Frontend Gulp DevStack.