Syd's rules for sustainable Haskell

General Tips

  • Make the simplest thing you can get away with.
  • Don't make things more general than you need to.
  • Don't make a system distributed if that's not a hard requirement.
  • Solve the problem you have, not the problem you hope to have.

Haskell-specific

  • Write tests first. If you can't do that, you've probably made things too complex.
  • Choose an automated linter and enforce its use.
  • Ban dangerous functions. Think twice before introducing exceptions.
  • Know about WATs
  • Choose an automated formatter, don't argue about which one, and enforce its use.
  • Remove every instance that you don't use.
  • Before writing an instance, write a function. Then reconsider whether you still need an instance. (You probably don't.)
  • Don't write an instance if you can't use it to write generic code.
  • If your instance is not law-abiding, remove it.
  • Have roundtrip tests for any serialisation.
  • Have golden tests for any external output you produce. (That means "for every ToJSON instance" as well.)
  • Write JSON instances manually until you have both roundtrip tests and golden tests.
  • Don't use lenses. You don't need them.
  • Use prefix naming: data Thing = { thingField :: FieldType }
  • Use as few languages extensions as you can get away with.
  • Don't try to break the laws of physics.
  • Don't try to prove "false".
  • Don't use any effect systems. Use IO or a ReaderT with a fixed Env over IO. No parametric environment and no parametric monad.
  • Never implement a custom Show and/or Read instance. If you want an instance, derive it.
  • Use monomorphic functions instead of type-class constraints.
  • Use polymorphic functions if you do not need type-class constraints.

Choosing a database

  • Use sqlite if you can get away with using a single machine.
  • Use postgres if you cannot get away with having only one machine.
  • Stay the hell away from NoSQL databases like MongoDB and CouchDB