ESLint code conventions vs lint config

findings.md

Okay, I've gone through the Code Conventions document. Here is a list of each section of that document, as well as whether we are enforcing it via our own ESLint configuration.

• Indentation: 4 spaces: indent
• Primitive Literals:
  • Double quotes: quotes
  • Single-line strings: no-multi-str
  • Numbers:
    • No octal literals: no-octal
    • No leading/trailing decimal: no-floating-decimal
  • Null: Unsure how to enforce
  • No undefined: no-undefined
    • No comment about void 0. Should no-void be on if you prefer typeof?
• Operator Spacing:
  • Space around binary ops: space-infix-ops
  • No space inside parens: NOT COVERED, could use space-in-parens
• Object Literals:
  • Must begin on same line: UNENFORCEABLE
  • First property must be on next line: UNENFORCEABLE
  • One property per line: UNENFORCEABLE
  • Properties must be indented one level: indent
  • Property keys must be unquoted: NOT COVERED, could use quote-props
  • No space between key and colon: key-spacing
  • Function must wrap under property: UNENFORCEABLE
    • There's no way to warn on single-line functions at all, much less in object values
  • Function-valued KVPs must have blank line before/after: UNENFORCEABLE
  • Passing object literal to function as multi-line: UNENFORCEABLE
  • Question: Is value alignment tolerated? Not clear from document. Could be covered in key-spacing. Example below.

  var obj = {
      longerKey: 1,
      key:       2
  };

• Comments:
  • Single-Line Comments:
    • Same indentation as nearby code: UNENFORCEABLE
    • Must be preceded by blank line: NOT COVERED, could use lines-around-comment
    • Multiple line comments should be block comment: UNENFORCEABLE
      • ...Unless used to block out code: SUPER UNENFORCEABLE
  • Multi-Line Comments:
    • First line has same indentation as nearby code: UNENFORCEABLE
    • Newline after begin-comment token: UNENFORCEABLE
    • Subsequent lines must begin with *: UNENFORCEABLE
    • Leading * must align with * from first line: UNENFORCEABLE
    • Must have blank line before comment: NOT COVERED, could use lines-around-comment
  • Comment Annotations:
    • Only TODO/HACK/XXX/FIXME/REVIEW allowed: UNENFORCEABLE
      • Could maybe use no-warning-comments to call out things like NOTE?
• Variable Declarations:
  • Declared at top of containing scope: NOT COVERED, could use vars-on-top
  • Indentation of subsequent lines: indent
  • Equals should be aligned: UNENFORCEABLE
  • Declare one variable per line: NOT COVERED, could use one-var-declaration-per-line
  • One var statement per function: NOT COVERED, could use one-var
  • Initialized variables before uninitialized: UNENFORCEABLE
• Function Declarations:
  • Should be declared before use: no-use-before-define
  • Must not be function expression: func-style
  • No Function constructor: no-new-func
  • No space before function name and parentheses: space-before-function-paren
  • No space just inside parens: space-in-parens
  • Must have space between parens and blocks: space-before-blocks
  • Brace on same line as function keyword: brace-style
  • Parameters should have space after comma but not before: comma-spacing
  • Function decls should come after variable decls: UNENFORCEABLE
  • Anonymous funcs should have no space before parens: space-before-function-paren
  • IIFEs should surround call with parens: wrap-iife
• Naming:
  • Do not begin var name with uppercase letter: NOT COVERED, could use id-match
  • Do not begin var name with verb: UNENFORCEABLE
  • Do not use underscores in vars: camelcase
  • Begin function name with verb: UNENFORCEABLE
  • Do not begin function name with uppercase letter: new-cap
  • Do not use underscores in funcs: camelcase
  • Constructors must begin with uppercase: new-cap
  • Do not begin constructor name with verb: UNENFORCEABLE
  • Constants should be uppercase-underscore: UNENFORCEABLE
    • Uppercase-underscore is allowed by camelcase rule
• Strict Mode:
  • No global strict: NOT COVERED, could use strict (set to "safe" or "functions")
• Assignments:
  • Comparison must use parens if assigned to variable: UNENFORCEABLE
• Equality Operators:
  • Use ===/!==: eqeqeq
• Ternary Operator:
  • Must assign result: UNENFORCEABLE
• Statements:
  • One per line: UNENFORCEABLE
    • New rule coming up that could be consumed
  • Require semi: semi
  • Returns should avoid parens except for clarity: UNENFORCEABLE
  • Compound Statements:
    • Indentation of inner statements: indent
    • Opening/closing brace location: brace-style
    • Use braces even for one-line blocks: curly
    • Statement keyword should be followed by space: keyword-spacing
    • Space between parens and block: space-before-blocks
    • No single-line blocks: UNENFORCEABLE
    • No variable declarations in for init: NOT COVERED, could use vars-on-top
    • Consider guard in for-in: guard-for-in
    • Cases indented under switch: indent
    • Blank line between cases: UNENFORCEABLE
    • Cases must not implicitly fall through: no-fallthrough
    • Comment required if no default: UNENFORCEABLE
• White Space:
  • Two blank lines between file sections: UNENFORCEABLE
  • Two blank lines between class/interface definitions: UNENFORCEABLE
  • One blank line between methods: UNENFORCEABLE
  • One blank line between var declarations and first statement: NOT COVERED, could use newline-after-var
  • One blank line before comment: NOT COVERED, could use lines-around-comment
  • Space between keyword and parens: keyword-spacing
  • Space after commas in arg lists: comma-spacing
  • Space surrounding binary ops: space-infix-ops
  • No space between unary op and operand: space-unary-ops
• Things to Avoid:
  • No new String(): no-new-wrappers
  • No eval: no-eval, no-implied-eval, no-new-function
  • No with: no-with