RFC: style cleanup & guidelines for GHC, and related bikeshedding
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Thu Jul 17 08:24:54 UTC 2014
Johan Tibell <johan.tibell at gmail.com>:
> On Thu, Jul 17, 2014 at 8:40 AM, Simon Peyton Jones
> <simonpj at microsoft.com> wrote:
>> | I used to be a 80 column guy, but moved away from that the last years.
>> | But you are right, there must be an upper limit and, if >80 is a
>> | problem for code reviews, then it's a reasonable choice.
>> As laptop screens have successively more horizontal pixels and fewer vertical pixels, longer lines use screen real estate better. 80 columns now seems a bit narrow to me. 100 would be better.
>> But I'm not going to die for this
> Here we go!
> * Wider screens let you have several Emacs buffers next to each
> other. At 80 chars you can have about 2 buffers next to each other on
> a 13" screen.
I think that was SimonM's premise for code reviews, that you want lines short enough to have two versions besides each other.
> * The average line length is about 30-35 characters in Python. If
> it's anything similar in Haskell shorter line length are more
> efficient, looking how much of the lines times columns space is filled
> with characters.
The problem is that indentation and long identifiers push you towards longer lines.
> * The eye has trouble traveling back to the next line if lines get
> too long (at least when reading prose). Research says around 60-70
> characters is optimal, if I recall correctly.
I think we read code differently to prose (and prose is not much indented), so I don't think these numbers transfer.
More information about the ghc-devs