too many lines too long

[Dan Doel]

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.maeder at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs