Coding Standard

• use newtype instead of type where possible
  • type is a type synonym, which is a weak form of newtype
  • newtype is a strong form of type that allows for more type safety
• prefer using newtype over data for single-variant types
  • data is designed for multi-variant types
  • data introduces a runtime overhead of boxing and unboxing
• prefer using records over anonymous tuples
• use do only in monadic context, use where or let otherwise
  • using do in non-monadic context is misleading and confusing
• use record-destructuring pattern matching over case-expression pattern matching where possible
  • record-destructuring pattern matching is more concise and readable, use it when possible
  • case-expression pattern matching is more flexible and powerful, use it when necessary
• prefer using full nouns for identifiers instead of abbreviations
  • examples
    • correct: state
    • wrong: st
    • exception: extremely long identifiers may be abbreviated and/or use abbreviation iff it helps readability
• prefer using built-in features instead of hand-crafting lambdas
  • examples
    • correct: const x
    • wrong: \_ -> x
• prefer using short-hand form for lambdas
  • examples
    • correct: (_ + 1)
    • wrong: \x -> x + 1
• avoid needless layering of lambdas and function calls
  • examples
    • correct: f g
    • wrong: f (\value -> g value)
• use fully qualified names
  • fully qualified names lower cognitive overhead by making it clear where a symbol comes from
  • fully qualified names lead to much shorter and more manageable lists of imports
  • fully qualified names do not pollute the namespace and prevent name clashes
  • examples
    • import syntax
      • correct: import Foo.Bar as Foo.Bar
      • wrong: import Foo.Bar, because it pollutes the namespace with all symbols exported by Foo.Bar
        • exception: Prelude is implicitly imported, so it is not necessary to qualify its symbols
      • wrong: import Foo.Bar (baz), because it pollutes the namespace with baz, which still may not be universally unique
      • wrong: import Foo.Bar as FB, because it introduces cognitive overhead on the reader
        • exception: Universally well known abbreviations (specifically listed in the coding standard) are acceptable
    • usage syntax
      • correct: Foo.Bar.baz
      • wrong: baz
      • wrong: Bar.baz
      • wrong: FB.baz