JavaScript Rules

https://github.com/airbnb/javascript

Rules Lint? Notes
Types ⬛ Skip: #1.1, #1.2
References ✅ Skip: #2.3
Objects ✅ Other Rules:
  1. Use computed property names when creating objects with dynamic property names. (#3.2)
  2. Group your shorthand properties at the beginning of your object declaration. (#3.5)

Prettier: #3.6 | | Arrays | ✅ | Other Rules:

  1. Use Array#push instead of direct assignment to add items to an array. (#4.2)
  2. Use array spreads ... to copy arrays. (#4.3)
  3. To convert an iterable object to an array, use spreads ... instead of Array.from (#4.4)
  4. Use Array.from for converting an array-like object to an array. (#4.5)
  5. Use Array.from instead of spread ... for mapping over iterables, because it avoids creating an intermediate array. (#4.6)

Prettier: #4.8 | | Destructuring | ✅ | **Other Rules:

  1. Use object destructuring for multiple return values, not array destructuring. (#5.3)** | | Strings | ✅ | Other Rules:
  2. Strings that cause the line to go over 100 characters should not be written across multiple lines using string concatenation. (#6.2)

Prettier: #6.1 | | Functions | ✅ | Other Rules:

  1. Avoid side effects with default parameters. (#7.8)

Prettier: #7.11, #7.15 | | Arrow Functions | ✅ | Prettier: #8.3, #8.4, #8.5, #8.6 | | Classes & Constructors | ✅ | Other Rules:

  1. Always use class. Avoid manipulating prototype directly. (#9.1)
  2. Use extends for inheritance. (#9.2)
  3. Methods can return this to help with method chaining. (#9.3)
  4. It’s okay to write a custom toString() method, just make sure it works successfully and causes no side effects. (#9.4) | | Modules | ✅ | Other Rules:
  5. Always use modules (import/export) over a non-standard module system. You can always transpile to your preferred module system. (#10.1)
  6. Do not use wildcard imports. (#10.2)
  7. And do not export directly from an import. (#10.3)

Prettier: #10.4, #10.8 | | Iterators and Generators | ✅ | Prettier: #11.3 | | Properties | ✅ | Prettier: #12.1 | | Variables | ✅ | Other Rules:

  1. Assign variables where you need them, but place them in a reasonable place. (#13.4)

Prettier: #13.2, #13.3 Skip: #13.7, #13.8 (handled by eslint-plugin-unused-imports) | | Hoisting | ✅ | Skip: #14.1, #14.2, #14.3, #14.4 | | Comparison Operators & Equality | ✅ | Other Rules:

  1. Use shortcuts for booleans, but explicit comparisons for strings and numbers. (#15.3)

Prettier: #15.7, #15.8 Skip: #15.2, #15.4, #15.9 | | Blocks | ⬛ | Prettier: #16.1, #16.2, #16.3 | | Control Statements | ⬛ | Other Rules:

  1. Don't use selection operators in place of control statements. (#17.2)

Prettier: #17.1 | | Comments | ✅ | Other Rules:

  1. Use /** ... */ for multiline comments. (#18.1)
  2. Use // for single line comments. Place single line comments on a newline above the subject of the comment. Put an empty line before the comment unless it’s on the first line of a block. (#18.2)
  3. Prefixing your comments with FIXME or TODO helps other developers quickly understand if you’re pointing out a problem that needs to be revisited, or if you’re suggesting a solution to the problem that needs to be implemented. These are different than regular comments because they are actionable. The actions are FIXME: -- need to figure this out or TODO: -- need to implement(#18.4)
  4. Use // FIXME: to annotate problems. (#18.5)
  5. Use // TODO: to annotate solutions to problems. (#18.6)

Prettier: #18.3 | | Whitespace | ✅ | **Other Rules:

  1. Leave a blank line after blocks and before the next statement. (#19.7)

Prettier:** #19.1, #19.2, #19.3, #19.4, #19.5, #19.6, #19.8, #19.9, #19.10, #19,11, #19.12, #19.13, #19.14, #19.16, #19.17, #19.18, #19.19, #19.20 | | Commas | ⬛ | Prettier: #20.1, #20.2 | | Semicolons | ⬛ | Prettier: #21.1 | | Type Casting & Coercion | ✅ | Other Rules: 1. If for whatever reason you are doing something wild and parseInt is your bottleneck and need to use Bitshift for performance reasons, leave a comment explaining why and what you’re doing. (#22.4)

Skip: #22.1, #22.5 | | Naming Conventions | ✅ | Other Rules:

  1. Don’t save references to this. Use arrow functions or Function#bind. (#23.5)
  2. A base filename should exactly match the name of its default export. (#23.6)
  3. Use camelCase when you export-default a function. Your filename should be identical to your function’s name. (#23.7)
  4. Use PascalCase when you export a constructor / class / singleton / function library / bare object. (#23.8)
  5. Acronyms and initialisms should always be all uppercased, or all lowercased. (#23.9)
  6. You may optionally uppercase a constant only if it (1) is exported, (2) is a const (it can not be reassigned), and (3) the programmer can trust it (and its nested properties) to never change. (#23.10)

Skip: #23.1 (airbnb 設置是 off) | | Accessors | ⬛ | Other Rules:

  1. Do not use JavaScript getters/setters as they cause unexpected side effects and are harder to test, maintain, and reason about. Instead, if you do make accessor functions, use getVal() and setVal('hello'). (#24.2)
  2. If the property/method is a boolean, use isVal() or hasVal(). (#24.3)
  3. It’s okay to create get() and set() functions, but be consistent. (#24.4)

Skip: #24.1 | | Events | ⬛ | Other Rules:

  1. When attaching data payloads to events (whether DOM events or something more proprietary like Backbone events), pass an object literal (also known as a "hash") instead of a raw value. This allows a subsequent contributor to add more data to the event payload without finding and updating every handler for the event. (#25.1) | | jQuery | ⬛ | Other Rules:
  2. Prefix jQuery object variables with a $. (#26.1)
  3. Cache jQuery lookups. (#26.2)
  4. For DOM queries use Cascading $('.sidebar ul') or parent > child $('.sidebar > ul'). jsPerf (#26.3)
  5. Use find with scoped jQuery object queries. (#26.4) | | ECMAScript 5 Compatibility | ⬛ | Skip: #27.1 | | ECMAScript 6+ (ES 2015+) Styles | ⬛ | Other Rules:
  6. Do not use TC39 proposals that have not reached stage 3. (#28.2)

Skip: #28.1 | | Standard Library | ✅ | | | Testing | ⬛ | Other Rules: 1. Whichever testing framework you use, you should be writing tests! 2. Strive to write many small pure functions, and minimize where mutations occur. 3. Be cautious about stubs and mocks - they can make your tests more brittle. 4. We primarily use mocha and jest at Airbnb. tape is also used occasionally for small, separate modules. 5. 100% test coverage is a good goal to strive for, even if it’s not always practical to reach it. 6. Whenever you fix a bug, write a regression test. A bug fixed without a regression test is almost certainly going to break again in the future.

Skip: #30.1 |

React Rules

https://airbnb.io/javascript/react

Rules Lint? Notes
Basic Rules ✅
Class vs React.createClass vs stateless ✅
Mixins ⬛ Skip
Naming ✅ Other Rules:
  1. Use .jsx, .tsx extension for React components.
  2. Use PascalCase for filenames. E.g., ReservationCard.jsx
  3. Use the filename as the component name. E.g., ReservationCard.jsx should have a reference name of ReservationCard. | | Declaration | ✅ | | | Alignment | ⬛ | Prettier | | Quotes | ✅ | | | Spacing | ⬛ | Prettier | | Props | ✅ | Other Rules:
  4. Always use camelCase for prop names. | | Refs | ✅ | | | Parentheses | ⬛ | Prettier | | Tags | ⬛ | Prettier | | Methods | ✅ | | | Ordering | ✅ | |