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
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