#11082: Tweak workflow around overlong lines -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://mail.haskell.org/pipermail/ghc-devs/2015-November/010373.html This thread] discussed potential changes to the way the GHC dev workflow deals with overlong lines. This ticket summarizes the discussion. '''Initial complaint:''' arc/Phab is too heavy-handed about overlong lines. Almost all patchers have to write a vacuous "explanation" for them, and the overlong line warnings clutter code reviews. '''Initial suggestion:''' 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? }}} '''Reactions:''' * +1 * Even the delta in overlong lines is bad, because perhaps a small refactor added to the length of an identifier. * We might just want to reject code with overlong lines. Then the problem would really go away. It favors one-time work over many-time maintenance burden. (Austin's point, +1 by Alexander Berntsen) * This would cause more work and would increase the barrier to contribution. And sometimes it's appropriate/more readable to have overlong lines. * 80 is too small. 120 (SPJ)? 132 (Ed Kmett)? * And a small limit discourages informative identifiers. * Just drop the column limit entirely. * Why 80? Because two 80-column buffers fit nicely side-by-side on small laptop screens. Three such columns fit nicely on monitors. Several (4 emails) echoed this point. Bottom line: no one expressed liking the status quo (though Simon M called it "not terrible"). If we're to choose a limit, a choice of 80 seemed to appease the plurality of respondents. Two respondents advocate enforcing the limit. I count four respondents rejecting hard enforcement. In my (surely biased) view, this means that we should implement my original proposal. :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11082 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler