A long time ago, we had an article that featured some tips on . 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. how to organize your import statements This week, we’re going to go over three different Haskell code formatting tools. We’ll examine , , and . These all have their pluses and minuses, as we’ll see. Stylish Haskell Hindent Brittany For some ideas of what Haskell projects you can do, download our . You can also take our free and learn how to use Stack to organize your code! Production Checklist Stack mini-course Stylish Haskell The first tool we’ll look at is . 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 . Stylish Haskell 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 instead of ). Then we can call the command on a file. By default, it will output the results to the terminal. But if we pass the 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! cabal stack stylish-haskell -i >> 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 . 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: qualified imports: align: global We can change it to to ensure our imports are only aligned within their grouping. group 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 . 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: [hindent](https://github.com/commercialhaskell/hindent) user1' = User default_ (val_ "James") (val_ "james@example.com") (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 on this file, it’ll make the changes. hindent user1' = User default_ (val_ "James") (val_ "james@example.com") (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 . By default, we would have the following configuration: .hindent.yaml 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 , integrates well with text editors. stylish-haskell hindent 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 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 example: stylish-haskell Beam 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 and your editor of choice! stack Now that you know how to format your code, need some suggestions for what to work on next? Take a look at our ! It’ll give you some cool ideas of libraries you can use for building Haskell web apps and much more! Production Checklist
