Style guide - WoWAnalyzer/WoWAnalyzer GitHub Wiki

We have a couple of basic eslint checks running in Travis and the npm start window that checks for code issues that may indicate bugs, fixing these is required.

image

TLDR: Just fix the ESLint warnings and you're good.

If you want a really comprehensive style guide, see the Airbnb JavaScript Style Guide. Our version is a mild variance of that with the aim to reduce the learning curve and interruptions, but the Airbnb style guide is a bit more comprehensive and most rules lead to better code.

Code style

The TL;DR:

Guidelines

The following are a subset of common guidelines that may be looked at when reviewing code but usually won't block merging of your PR. We might still point them out so you might solve them in a follow up PR.

The guidelines are written in dos and don'ts to be concise and clear, but most guidelines have exceptions if you have a good reason for doing something else (this often warrants a comment though).

Functional guidelines

  • Please don't show multiple statistic boxes from 1 module (analyzer).
  • Please don't add tooltips that do not reveal any new information. This is to avoid having a tooltip on everything so that users do not stop reading them because they don't contain anything interesting most of the time.
  • Please do try to be consistent with other specs. If another spec solves the same problem you should seriously consider solving it the same way. If you think it should be solved differently, please discuss it.

Technical guidelines

  • Please don't copy-paste easily shareable code (e.g. functions). Move them to the common, core or shared directory.
  • Please don't use Hungarian notation or variants on this.
  • Please do give all your variables a proper name.
  • Please don't include the name of the class in a property name (no car.carSpeed, just speed would be enough).
  • Please don't leave any dead code such as empty methods or commented out code.
  • Please don't use for() if it can be done with array.forEach or array.map.
  • Please don't use relative paths ("../../") for things in the shared codebase, e.g. the common, Main, Parser/Core folders.
  • Please do use relative paths within your namespace, e.g. within your spec folder.
  • Please don't keep console.logs enabled in your code.
  • Please avoid nested if-statements. Instead do a single if-statement per check and return early.
  • Please do use curly brackets for all blocks such as if-statements.
  • Please don't use increment (++) or decrement (--). Instead use += 1 or -= 1.
  • Constant naming. See: https://github.com/airbnb/javascript#naming--uppercase
  • Import grouping (one newline between top level groups):
    1. Libraries
    2. Absolute imports (no newlines between subgroups)
      1. common
      2. Parser
      3. Main
    3. Relative imports
  • Folders should be lower-case unless the contain an index.js representing a module or component.