aphorisms_and_principles.md

Aphorisms & Principles

April's Aphorisms & Principles:

* [Rethink best practices](https://www.youtube.com/watch?v=x7cQ3mrcKaY).

* [A dogma is born when the solutions are presented without enough original context,
  and newcomers feel pressured to delegate crucial decisions to an authority](https://medium.com/@dan_abramov/the-case-for-flux-379b7d1982c6)

* We like nice things:
    * Pure functions when practical, side effects when necessary.
    * Self contained, testable modules that do not leak implementation
      details. It should not be neccessary to use karma to spin up a
      web browser with a live DOM to test utility functions.
    * Strive to write self-documenting APIs. When you have more
      than one parameter, using key-value options hashes to name parameters
      can be a powerful tool.
    * Do not abuse dynamic types without a really good reason. Use implicit
      static typeing, even when your language doesn't have a good typechecker.
      Inspect argument types and fail loudly when you are passed something
      unexpected. Wrap these preflight tests in if (!production) {} blocks
      to strip them from builds.

* Avoid globals. [This means you, CSS](http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html).
    * When using React, use inline styles whenever possible to reap the
      benefits of scope, namespaces, and compentization.
    * When React is unavailable, qualify CSS selectors with parent component
      class names in LESS to emulate these traits as best as possible.

* [Objects are a poor man’s closures. Closures are a poor man’s objects.](http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent)
    * When all you have is a hammer, every problem looks like your thumb.

* [Shared mutable state is the root of all evil.](http://henrikeichenhardt.blogspot.com/2013/06/why-shared-mutable-state-is-root-of-all.html)
    * Centralize mutable state in stores.
    * Object state should be immutable.
    * Immutable.js isRecords are a performant tool to avoid shooting yourself
      in the foot with improper use of mutable state.

* [Abstraction is naming things.](https://mitpress.mit.edu/sicp/chapter1/node4.html)
    * Choose explicit, clear identifier names. Do not be afraid of verbosity.
    * Use JS's built-in meaningfully named FPisms when iterating:
      `forEach` (for side effects), `map`, `filter`, `every`, `some`.
    * `reduce` is usually hard to read. If you need a special, pure
      iterator, implement it on top of `reduce` with a meaningful name,
      and use that name at the call site.

* Code is easy to write and hard to read; make the extra effort to write
  code that is easy to read.
    * You are writing for yourself in six months when you have forgotten
      everything you know about the problem domain.
    * You are writing for a new team member.
    * Comment obsessively. Comment beautifully. [Anything from 45 to 75 characters
      is widely regarded as a satisfactory length of line for a single-column page
      set in a serifed text face in a text size.](http://webtypography.net/2.1.2)
    * Polish it until it shines.