Good Haskell coding standards

Really hard question. I hope your answers turn up something good. Meanwhile, here is a catalog of mistakes or other annoying things that I have found in beginners’ code. There is some overlap with the Cal Tech style page that Kornel Kisielewicz points to. Some of my advice is every bit as vague and useless as the HaskellWiki “gems”, but I hope at least it is better advice 🙂

• Format your code so it fits in 80 columns. (Advanced users may prefer 87 or 88; beyond that is pushing it.)

• Don’t forget that let bindings and where clauses create a mutually recursive nest of definitions, not a sequence of definitions.

• Take advantage of where clauses, especially their ability to see function parameters that are already in scope (nice vague advice). If you are really grokking Haskell, your code should have a lot more where-bindings than let-bindings. Too many let-bindings is a sign of an unreconstructed ML programmer or Lisp programmer.

• Avoid redundant parentheses. Some places where redundant parentheses are particularly offensive are

  • Around the condition in an if expression (brands you as an unreconstructed C programmer)

  • Around a function application which is itself the argument of an infix operator (Function application binds tighter than any infix operator. This fact should be burned into every Haskeller’s brain, in much the same way that us dinosaurs had APL’s right-to-left scan rule burned in.)

• Put spaces around infix operators. Put a space following each comma in a tuple literal.

• Prefer a space between a function and its argument, even if the argument is parenthesized.

• Use the $ operator judiciously to cut down on parentheses. Be aware of the close relationship between $ and infix .:

  f $ g $ h x == (f . g . h) x == f . g . h $ x
  

• Don’t overlook the built-in Maybe and Either types.

• Never write if <expression> then True else False; the correct phrase is simply <expression>.

• Don’t use head or tail when you could use pattern matching.

• Don’t overlook function composition with the infix dot operator.

• Use line breaks carefully. Line breaks can increase readability, but there is a tradeoff: Your editor may display only 40–50 lines at once. If you need to read and understand a large function all at once, you mustn’t overuse line breaks.

• Almost always prefer the -- comments which run to end of line over the {- ... -} comments. The braced comments may be appropriate for large headers—that’s it.

• Give each top-level function an explicit type signature.

• When possible, align -- lines, = signs, and even parentheses and commas that occur in adjacent lines.

• Influenced as I am by GHC central, I have a very mild preference to use camelCase for exported identifiers and short_name with underscores for local where-bound or let-bound variables.