Keeping it Clean: Haskell Code Formatters

A long time ago, we had an article that featured some tips on how to organize your import statements. As far as I remember, that’s the only piece we’ve ever done on code formatting. But as you work on projects with more people, formatting is one thing you need to consider to keep everyone sane. You’d like to have a consistent style across the code base. That way, there’s less controversy in code reviews, and people don’t need to think as much to update code. They shouldn’t have to wonder about following the style guide or what exists in a fragment of code.

This week, we’re going to go over three different Haskell code formatting tools. We’ll examine Stylish Haskell, Hindent, and Brittany. These all have their pluses and minuses, as we’ll see.

For some ideas of what Haskell projects you can do, download our Production Checklist. You can also take our free Stack mini-course and learn how to use Stack to organize your code!

Stylish Haskell

The first tool we’ll look at is Stylish Haskell. This is a straightforward tool to use, as it does some cool things with no configuration required. Let’s take a look at a poorly formatted version of code from our Beam article.

{-# LANGUAGE DeriveGeneric #-}{-# LANGUAGE FlexibleContexts #-}{-# LANGUAGE FlexibleInstances #-}{-# LANGUAGE GADTs #-}{-# LANGUAGE MultiParamTypeClasses #-}{-# LANGUAGE OverloadedStrings #-}{-# LANGUAGE StandaloneDeriving #-}{-# LANGUAGE TypeApplications #-}{-# LANGUAGE TypeFamilies #-}{-# LANGUAGE TypeSynonymInstances #-}{-# LANGUAGE ImpredicativeTypes #-}

module Schema where

import Database.Beamimport Database.Beam.Backendimport Database.Beam.Migrateimport Database.Beam.Sqliteimport Database.SQLite.Simple (open, Connection)

import Data.Int (Int64)import Data.Text (Text)import Data.Time (UTCTime)import qualified Data.UUID as U

data UserT f = User  { _userId :: Columnar f Int64  , _userName :: Columnar f Text  , _userEmail :: Columnar f Text  , _userAge :: Columnar f Int  , _userOccupation :: Columnar f Text  } deriving (Generic)

There are many undesirable things here. Our language pragmas don’t line up their end braces. They also aren’t in any discernible order. Our imports are also not lined up, and neither are the fields in our data types.

Stylish Haskell can fix all this. First, we’ll install it globally with:

stack install stylish-haskell

(You can also use cabal instead of stack). Then we can call the stylish-haskell command on a file. By default, it will output the results to the terminal. But if we pass the -i flag, it will update the file in place. This will make all the changes we want to line up the various statements in our file!

>> stylish-haskell -i Schema.hs

--- Result:

{-# LANGUAGE DeriveGeneric         #-}{-# LANGUAGE FlexibleContexts      #-}{-# LANGUAGE FlexibleInstances     #-}{-# LANGUAGE GADTs                 #-}{-# LANGUAGE ImpredicativeTypes    #-}{-# LANGUAGE MultiParamTypeClasses #-}{-# LANGUAGE OverloadedStrings     #-}{-# LANGUAGE StandaloneDeriving    #-}{-# LANGUAGE TypeApplications      #-}{-# LANGUAGE TypeFamilies          #-}{-# LANGUAGE TypeSynonymInstances  #-}

module Schema where

import           Database.Beamimport           Database.Beam.Backendimport           Database.Beam.Migrateimport           Database.Beam.Sqliteimport           Database.SQLite.Simple (Connection, open)

import           Data.Int               (Int64)import           Data.Text              (Text)import           Data.Time              (UTCTime)import qualified Data.UUID              as U

data UserT f = User  { _userId         :: Columnar f Int64  , _userName       :: Columnar f Text  , _userEmail      :: Columnar f Text  , _userAge        :: Columnar f Int  , _userOccupation :: Columnar f Text  } deriving (Generic)

Stylish Haskell integrates well with most common editors. For instance, if you use Vim, you can also run the command from within the editor with the command:

:%!stylish-haskell

We get all these features without any configuration. If we want to change things though, we can create a configuration file. We’ll make a default file with the following command:

stylish-haskell --defaults > .stylish-haskell.yaml

Then if we want, we can modify it a bit. For one example, we’ve aligned our imports above globally. This means they all leave space for qualified. But we can decide we don’t want a group of imports to have that space if there are no qualified imports. There’s a setting for this in the config. By default, it looks like this:

imports:  align: global

We can change it to group to ensure our imports are only aligned within their grouping.

imports:  align: group

And now when we run the command, we’ll get a different result:

module Schema where

import Database.Beamimport Database.Beam.Backendimport Database.Beam.Migrateimport Database.Beam.Sqliteimport Database.SQLite.Simple (Connection, open)

import           Data.Int  (Int64)import           Data.Text (Text)import           Data.Time (UTCTime)import qualified Data.UUID as U

So in short, Stylish Haskell is a great tool for a limited scope. It has uncontroversial suggestions for several areas like imports and pragmas. It also removes trailing whitespace, and adjusts case statements sensibly. That said, it doesn’t affect your main Haskell code. Let’s look at a couple tools that can do that.

Hindent

Another program we can use is [hindent](https://github.com/commercialhaskell/hindent). As its name implies, it deals with updating whitespace and indentation levels. Let’s look at a very simple example. Consider this code, adapted from our Beam article:

user1' = User default_  (val_ "James")  (val_ "[email protected]")  (val_ 25)  (val_ "programmer")

findUsers :: Connection -> IO ()findUsers conn = runBeamSqlite conn $ do    users <- runSelectReturningList $ select $ do        user <- (all_ (_blogUsers blogDb))        article <- (all_ (_blogArticles blogDb))        guard_ (user ^. userName ==. (val_ "James"))        guard_ (article ^. articleUserId ==. user ^. userId)         return (user, article)    mapM_ (liftIO . putStrLn . show) users

There are a few things we could change. First, we might want to update the indentation level so that it is 2 instead of 4. Second, let’s restrict the line size to only being 80. When we run hindent on this file, it’ll make the changes.

user1' =  User    default_    (val_ "James")    (val_ "[email protected]")    (val_ 25)    (val_ "programmer")

findUsers :: Connection -> IO ()findUsers conn =  runBeamSqlite conn $ do    users <-      runSelectReturningList $      select $ do        user <- (all_ (_blogUsers blogDb))        article <- (all_ (_blogArticles blogDb))        guard_ (user ^. userName ==. (val_ "James"))        guard_ (article ^. articleUserId ==. user ^. userId)        return (user, article)    mapM_ (liftIO . putStrLn . show) users

Hindent is also configurable. We can create a file .hindent.yaml. By default, we would have the following configuration:

indent-size: 2line-length: 80force-trailing-newline: true

But then we can change it if we want so that the indentation level is 3:

indent-size: 3

And now when we run it, we’ll actually see that it’s changed to reflect that:

findUsers :: Connection -> IO ()findUsers conn =   runBeamSqlite conn $ do      users <-         runSelectReturningList $         select $ do            user <- (all_ (_blogUsers blogDb))            article <- (all_ (_blogArticles blogDb))            guard_ (user ^. userName ==. (val_ "James"))            guard_ (article ^. articleUserId ==. user ^. userId)            return (user, article)      mapM_ (liftIO . putStrLn . show) users

Hindent also has some other effects that, as far as I can tell, are not configurable. You can see that the separation of lines was not preserved above. In another example, it spaced out instance definitions that I had grouped in another file:

-- BEFOREderiving instance Show Userderiving instance Eq Userderiving instance Show UserIdderiving instance Eq UserId

-- AFTERderiving instance Show User

deriving instance Eq User

deriving instance Show UserId

deriving instance Eq UserId

So make sure you’re aware of everything it does before committing to using it. Like stylish-haskell, hindent integrates well with text editors.

Brittany

Brittany is an alternative to Hindent for modifying your expression definitions. It mainly focuses on the use of horizontal space throughout your code. As far as I see, it doesn’t line up language pragmas or change import statements in the way stylish-haskell does. It also doesn’t touch data type declarations. Instead, it seeks to reformat your code to make maximal use of space while avoiding lines that are too long. As an example, we could look at this line from our Beam example:

insertArticles :: Connection -> IO ()insertArticles conn = runBeamSqlite conn $ runInsert $   insert (_blogArticles blogDb) $ insertValues articles

Our decision on where to separate the line is a little bit arbitrary. But at the very least we don’t try to cram it all on one line. But if we have either the approach above or the one-line version, Brittany will change it to this:

brittany --write-mode=inplace MyModule.hs

--

insertArticles :: Connection -> IO ()insertArticles conn =  runBeamSqlite conn $ runInsert $ insert (_blogArticles blogDb) $ insertValues    articles

This makes “better” use of horizontal space in the sense that we get as much on the first line. That said, one could argue that the first approach we have actually looks nicer. Brittany can also change type signatures that overflow the line limit. Suppose we have this arbitrary type signature that’s too long for a single line:

myReallyLongFunction :: State ComplexType Double -> Maybe Double -> Either Double ComplexType -> IO a -> StateT ComplexType IO a

Brittany will fix it up so that each argument type is on a single line:

myReallyLongFunction  :: State ComplexType Double  -> Maybe Double  -> Either Double ComplexType  -> IO a  -> StateT ComplexType IO a

This can be useful in projects with very complicated types. The structure makes it easier for you to add Haddock comments to the various arguments.

Dangers

There is of course, a (small) danger to using tools like these. If you’re going to use them, you want to ensure everyone on the project is using them. Suppose person A isn’t using the program, and commits code that isn’t formatted by the program. Person B might then look through that code, and their editor will correct the file. This will leave them with local changes to the file that aren’t relevant to whatever work they’re doing. This can cause a lot of confusion when they submit code for review. Whoever reviews their code has to sift through the format changes, which slows the review.

People can also have (unreasonably) strong opinions about code formatting. So it’s generally something you want to nail down early on a project and avoid changing afterward. With the examples in this article, I would say it would be an easy sell to use Stylish Haskell on a project. However, the specific choices made in H-Indent and Brittany can be more controversial. So it might cause more problems than it would solve to institute those project-wide.

Conclusion

It’s possible to lose a surprising amount of productivity to code formatting. So it can be important to nail down standards early and often. Code formatting programs can make it easy to enforce particular standards. They’re also very simple to incorporate into your projects with stack and your editor of choice!

Now that you know how to format your code, need some suggestions for what to work on next? Take a look at our Production Checklist! It’ll give you some cool ideas of libraries you can use for building Haskell web apps and much more!