I don't really have a strong opinion on what gets decided here. But, I might take the blog post with some salt.
I write some Scala for work, and despite not being a fan of long lines, I find myself writing them in Scala (and our code base has many), because it is often difficult to break a single line into multiple lines in a way that looks good in Scala (in my opinion at least, although I know at least one other person who shares my opinion). So for Scala, I'd probably look for justifications of longer lines, because they look better there. By contrast, I find it much easier to format Haskell code to 80 columns in a way that looks good. So my average Haskell line length is almost certainly shorter than my Scala line length, because I prefer something around 80 columns when possible. Just a thought, -- Dan P.S. I don't see why github would be relevant for a project that doesn't use it. It seems like a better idea to base line length on what the tools GHC actually uses can handle well. Maybe that was the point, though. On Wed, Nov 11, 2015 at 7:03 AM, C Maeder <c.mae...@jacobs-university.de> wrote: > Maybe increasing the limit is not such a bad idea (see scala blog) > http://hilton.org.uk/blog/source-code-line-length > > "GitHub is the de facto coding standard > > 125 characters per line is the real de facto coding standard for maximum > line length these days, because this is the maximum number of characters > that you can see in the GitHub diff view." > > Cheers Christian > > On 09.11.2015 22:02, Richard Eisenberg wrote: >> Hi devs, >> >> We seem to be uncommitted to the ideal of 80-character lines. Almost every >> patch on Phab I look through has a bunch of "line too long" lint errors. No >> one seems to do much about these. And Phab's very very loud indication of a >> lint error makes reviewing the code harder. >> >> I like the ideal of 80-character lines. I aim for this ideal in my patches, >> falling short sometimes, of course. But I think the current setting of >> requiring everyone to "explain" away their overlong lines during `arc diff` >> and then trying hard to ignore the lint errors during code review is wrong. >> And it makes us all inured to more serious lint errors. >> >> How about this: after `arc diff` is run, it will count the number of >> overlong lines before and after the patch. If there are more after, have the >> last thing `arc diff` outputs be a stern telling-off of the dev, along the >> lines of >> >>> Before your patch, 15 of the edited lines were over 80 characters. >>> Now, a whopping 28 of them are. Can't you do better? Please? >> >> Would this be ignored more or followed more? Who knows. But it would sure be >> less annoying. :) >> >> What do others think? >> >> Thanks, >> Richard >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
