Good Haskell coding standards

Question

Could someone provide a link to a good coding standard for Haskell? I've found this and this, but they are far from comprehensive. Not to mention that the HaskellWiki one includes such "gems" as "use classes with care" and "defining symbolic infix identifiers should be left to library writers only."

Answer 1

I'd suggest taking a look at this style checker.

Answer 2

• I like to try to organize functions as point-free style compositions as much as possible by doing things like:

  func = boo . boppity . bippity . snd
      where boo = ...
            boppity = ...
            bippity = ...
  

• I like using ($) only to avoid nested parens or long parenthesized expressions

• ... I thought I had a few more in me, oh well

Answer 3

Some good rules of thumbs imho:

• Consult with HLint to make sure you don't have redundant braces and that your code isn't pointlessly point-full.
• Avoid recreating existing library functions. Hoogle can help you find them.
  • Often times existing library functions are more general than what one was going to make. For example if you want Maybe (Maybe a) -> Maybe a, then join does that among other things.
• Argument naming and documentation is important sometimes.
  • For a function like replicate :: Int -> a -> [a], it's pretty obvious what each of the arguments does, from their types alone.
  • For a function that takes several arguments of the same type, like isPrefixOf :: (Eq a) => [a] -> [a] -> Bool, naming/documentation of arguments is more important.
• If one function exists only to serve another function, and isn't otherwise useful, and/or it's hard to think of a good name for it, then it probably should exist in it's caller's where clause instead of in the module's scope.
• DRY
  • Use Template-Haskell when appropriate.
  • Bundles of functions like zip3, zipWith3, zip4, zipWith4, etc are very meh. Use Applicative style with ZipLists instead. You probably never really need functions like those.
  • Derive instances automatically. The derive package can help you derive instances for type-classes such as Functor (there is only one correct way to make a type an instance of Functor).
• Code that is more general has several benefits:
  • It's more useful and reusable.
  • It is less prone to bugs because there are more constraints.
    • For example if you want to program concat :: [[a]] -> [a], and notice how it can be more general as join :: Monad m => m (m a) -> m a. There is less room for error when programming join because when programming concat you can reverse the lists by mistake and in join there are very few things you can do.
• When using the same stack of monad transformers in many places in your code, make a type synonym for it. This will make the types shorter, more consice, and easier to modify in bulk.
• Beware of "lazy IO". For example readFile doesn't really read the file's contents at the moment the file is read.
• Avoid indenting so much that I can't find the code.
• If your type is logically an instance of a type-class, make it an instance.
  • The instance can replace other interface functions you may have considered with familiar ones.
  • Note: If there is more than one logical instance, create newtype-wrappers for the instances.
  • Make the different instances consistent. It would have been very confusing/bad if the list Applicative behaved like ZipList.