Style Guidelines

To stay consistent with the style of this project, please abide by the following guidelines. If your code does not follow style guidelines, you should leave a comment explaining why. For all languages, the following rules apply:

• Use (2) spaces instead of tabs
• Use Pokemon references liberally when writing tests. Only the first 151 Pokemon are recognized.

Annotations

This section is taken from the CoffeeScript style guide, but it's important enough to copy here.

Use annotations when necessary to describe a specific action that must be taken against the indicated block of code. Write the annotation on the line immediately above the code that the annotation is describing. The annotation keyword should be followed by a colon and a space, and a descriptive note.

  // FIXME: The client's current state should *not* affect payload processing.
  resetClientState()
  processPayload()

Annotation types:

• TODO: describe missing functionality that should be added at a later date
• FIXME: describe broken code that must be fixed
• OPTIMIZE: describe code that is inefficient and may become a bottleneck
• HAX: describe the use of a questionable (or ingenious) coding practice
• REVIEW: describe code that should be reviewed to confirm implementation

JavaScript

Generally abide by these style guidelines, except for the section about function declarations. If eslint doesn't complain when you run npm run lint then you should be fine. (tip: npm run linc will run the linter only on changes that git sees, while npm run lint will lint the entire codebase)