For me, a huge reason why the line length errors are annoying is because there will often be some existing line which is 80+, and I just need to change one word in it. Well, now that's a line length error.
Now, I *could* refactor the line so that it's less than 80. But this (1) fluffs up the diffs with non-semantic noise, and (2) makes merge conflicts a lot more likely. I think the counts thing could help for this case. But now suppose there's an existing line which is just barely under 80, and you need to do a mechanical substitution which pushes it over. Yes, I /could/ reindent it, but it's a huge timesink for no very good reason. Usually the best way to eliminate a long line is to refactor the entire region of code, e.g. splitting out helper functions or whatnot. Edward Excerpts from Richard Eisenberg's message of 2015-11-09 13:02:48 -0800: > 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
