too many lines too long

[Austin Seipp]

Lots of good replies in this thread. I just wanted to follow up on my
suggestion from earlier and give some insight as to why I suggested
this:

The _only_ reason I really suggested a hard enforcement is because,
roughly speaking, maintaining code is roughly ~infinitely more
expensive than actually writing it.

Abiding by a column limit, if enforced, seems really really trivial to
many people and very stupid to reject a patch over. But it is far more
useful to the tons of people who may read it later, because the labor
balance is asymmetrical. The author of a patch must spend some amount
of effort N writing it, where N is roughly linear in the size of the
change. But the 'maintenance effort' for that patch is, instead, at
least linear in the _lifetime of the project_. Basically: code is very
cheap, but maintenance is extremely costly.

All that said, I'm not going to lose sleep over this, and it's not a
stylistic hill that's worth dying on. And again, if GHC only had a few
occurrences of this, it would be easier to fix, but that's not the
case, and hampers contributors a bit. If anything, a more pressing
stylistic concern is our odd naming scheme that has very little
consistency, and that does make it harder to find and read things I
think. :)


On Mon, Nov 9, 2015 at 3:15 PM, Austin Seipp <austin at well-typed.com> wrote:
> Something like this might be possible. It'd just require implementing
> a new arcanist linter, I think, and enabling it in .arclint
>
> In general I really sympathize with this. The problem 90% of people
> hit is that they touch a line that was *already* over 80 columns, so
> 'arc lint' warns them and gets annoyed, but they don't want to fix or
> split up a bunch of stuff to avoid it. It's an issue of having to do
> 'boring work' which nobody likes, and seems very tedious, regardless
> of the mechanism of how they do the change.
>
> Really, I'm more inclined to begin a policy of rejecting reviews that
> do not pass the linter. Exceptions can be made, but in general we need
> to start *enforcing it* with the red button I think. And it would
> require us to be more diligent about merging patches quickly to reduce
> the scope of merge conflicts (because fixing an 80col violation
> normally, almost always, adds more LOC).
>
> However, there are people who in general think the contribution
> barrier is already too high, and I fear that enforcing this with a
> hard rule may make people 'give up' because it seems like a pointless
> thing to mandate to block their changes. I'm not sure how people feel
> about that, but it is worth keeping in mind the developer economics.
>
> I hope suggesting the possibility of being more forceful against 80col
> violations doesn't derail this too much. :)
>
> On Mon, Nov 9, 2015 at 3:02 PM, Richard Eisenberg <eir at cis.upenn.edu> 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
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/