If you put calling functions before called ones, then when you reload GHCI and it dumps a lot of errors at you, the last one is usually a good place to start, because it depends on nothing else flagged as an error in the same module.

Also I always flag mutually recursive functions or types with a hard-to-miss "PITFALL: mutually recursive with <set of functions>" comment, as those are easier to understand if you begin recognizing the mutual recursion.

On Thu, Aug 12, 2021 at 2:11 AM Sven Panne <svenpanne@gmail.com> wrote:
Am Do., 12. Aug. 2021 um 00:33 Uhr schrieb Christopher Conforti <christopher@conforti.xyz>:
Indeed, this is the direction I'm heading. However, I'm doing it by
hand first so I can refine my methods to a point I'm satisfied with,
and then build the automation afterwards, hopefully doing it right the
first time. [...]

IMHO this is exactly the wrong way round: Pick one of the existing formatters (hindent, brittany, ormolu, ...) and stick with it for a while. If you don't like what you see, you can try another one. But the main point is: These formatters embody good practice learned the hard way from lots of other people, and using them will make your code more readable not only by you, but by others, too. The "not invented here" syndrome is seldom a good idea, and consistency is far more important than small details you might not like.

Cheers,
   S.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


--
Jeff Brown | Jeffrey Benjamin Brown
LinkedIn   |   Github   |   Twitter  |  Facebook  |  very old Website