too many lines too long

newer
Re: [ANNOUNCE] GHC 7.10.3 release...

older
Further custom type error questions

Richard Eisenberg

9 Nov 2015 9 Nov '15

4:02 p.m.

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

Show replies by date

Edward Z. Yang

9 Nov 9 Nov

4:10 p.m.

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

Austin Seipp

4:15 p.m.

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

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

Richard Eisenberg

4:21 p.m.

I agree that being forceful about the 80-col limit would solve my problem. But I really dislike the idea. There will always be long-running patches. Volunteers can't be relied on to have time available to continue their work right away. And so I think this decision would increase barriers to contributing and increase merge conflicts for a cause that, frankly, isn't terribly important. (To repeat: I *do* want 80-col lines. I just want an amazing compiler more.) Richard On Nov 9, 2015, at 4:15 PM, Austin Seipp 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 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

-- Regards,

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

Ömer Sinan Ağacan

5:17 p.m.

I also dislike the idea of automatically rejecting such code. I agree with Austin's argument that the contribution barrier is already too high and Richard's arguments, but in addition to those, I think it wouldn't be fair because some patches of people with push access won't be subject to the automatic lint checks. 100-col lines will make it to the code base even if only by mistake. It'll be annoying to new contributors and won't solve the problem. Personally I'm trying to be very careful, and in my patches I usually do a lint pass at the end to fix all long lines. But I'm OK if some patches with 100-col lines occasionally make it to the master. 2015-11-09 16:21 GMT-05:00 Richard Eisenberg :

...

I agree that being forceful about the 80-col limit would solve my problem.

But I really dislike the idea. There will always be long-running patches. Volunteers can't be relied on to have time available to continue their work right away. And so I think this decision would increase barriers to contributing and increase merge conflicts for a cause that, frankly, isn't terribly important. (To repeat: I *do* want 80-col lines. I just want an amazing compiler more.)

Richard

On Nov 9, 2015, at 4:15 PM, Austin Seipp 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 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

-- Regards,

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

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Austin Seipp

10 Nov 10 Nov

12:22 p.m.

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

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

Simon Peyton Jones

9 Nov 9 Nov

5:45 p.m.

In my view 80 chars is too short. It was justified in the days of 80-column CRTs, but that just isn't a restriction any more. I routinely edit in a much wider window. Clearly there's a judgement call here. But I'd prefer 120 cols say. Simon -----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Richard Eisenberg Sent: 09 November 2015 21:03 To: ghc-devs Devs Subject: too many lines too long 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 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d

Richard Eisenberg

5:51 p.m.

At both school and at home I can fit 3 80-character buffers side by side, at a comfortable font size. Going up (even to 85 cols) would mean losing a buffer. (Or straining my eyes.) Of course I can deal with wrapped lines. But I still vote for 80 characters as a target, while allowing people wiggle room to miss this target. The number 80 is with us for historical reasons, but I know I'm not the only one who still routinely uses 80-column buffers. Richard On Nov 9, 2015, at 5:45 PM, Simon Peyton Jones wrote:

...

In my view 80 chars is too short. It was justified in the days of 80-column CRTs, but that just isn't a restriction any more. I routinely edit in a much wider window.

Clearly there's a judgement call here. But I'd prefer 120 cols say.

Simon

-----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Richard Eisenberg Sent: 09 November 2015 21:03 To: ghc-devs Devs Subject: too many lines too long

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 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d

Nikita Karetnikov

5:59 p.m.

...

At both school and at home I can fit 3 80-character buffers side by side, at a comfortable font size. Going up (even to 85 cols) would mean losing a buffer. (Or straining my eyes.) Of course I can deal with wrapped lines. But I still vote for 80 characters as a target, while allowing people wiggle room to miss this target.

...

The number 80 is with us for historical reasons, but I know I'm not the only one who still routinely uses 80-column buffers.

Tuncer Ayaz

10 Nov 10 Nov

6:31 a.m.

On Mon, Nov 9, 2015 at 11:51 PM, Richard Eisenberg wrote:

...

At both school and at home I can fit 3 80-character buffers side by side, at a comfortable font size. Going up (even to 85 cols) would mean losing a buffer. (Or straining my eyes.) Of course I can deal with wrapped lines. But I still vote for 80 characters as a target, while allowing people wiggle room to miss this target.

The number 80 is with us for historical reasons, but I know I'm not the only one who still routinely uses 80-column buffers.

It's not just for historical reasons, it's one of those things that turned out to be a reasonable convention: Regardless of the width of windows, it's easier to read limited-width columns. I may be part of a sub-group, but just like a newspaper, I find it easier to "eye-scroll" up and down than left and right. This is the major reason why limiting column width still makes sense. Unless, of course, it's just a few lines, or things that cannot be limited due to technical reasons. I don't know if 120 is too wide, but 100 might be okay. Also, changing the length while touching a line is the most natural way to do it, as white-space reformatting patches, unless done once-only-for-everything-and-never-again, will be noise and make things like git-bisect harder to use. A width limit also is a nice way to alarm you if you start nesting too much :).

Alan & Kim Zimmerman

6:33 a.m.

80 cols does work well with the side by side diff in Phabricator. Alan On Tue, Nov 10, 2015 at 1:31 PM, Tuncer Ayaz wrote:

...

On Mon, Nov 9, 2015 at 11:51 PM, Richard Eisenberg wrote:

...
At both school and at home I can fit 3 80-character buffers side by side, at a comfortable font size. Going up (even to 85 cols) would mean losing a buffer. (Or straining my eyes.) Of course I can deal with wrapped lines. But I still vote for 80 characters as a target, while allowing people wiggle room to miss this target.

The number 80 is with us for historical reasons, but I know I'm not the only one who still routinely uses 80-column buffers.

It's not just for historical reasons, it's one of those things that turned out to be a reasonable convention:

Regardless of the width of windows, it's easier to read limited-width columns. I may be part of a sub-group, but just like a newspaper, I find it easier to "eye-scroll" up and down than left and right. This is the major reason why limiting column width still makes sense. Unless, of course, it's just a few lines, or things that cannot be limited due to technical reasons. I don't know if 120 is too wide, but 100 might be okay.

Also, changing the length while touching a line is the most natural way to do it, as white-space reformatting patches, unless done once-only-for-everything-and-never-again, will be noise and make things like git-bisect harder to use.

A width limit also is a nice way to alarm you if you start nesting too much :). _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

David Fox

9:28 a.m.

I am concerned that 80 character lines discourages the use of longerSymbolNamesLikeThis. Which I really like. On Mon, Nov 9, 2015 at 2:51 PM, Richard Eisenberg wrote:

...

At both school and at home I can fit 3 80-character buffers side by side, at a comfortable font size. Going up (even to 85 cols) would mean losing a buffer. (Or straining my eyes.) Of course I can deal with wrapped lines. But I still vote for 80 characters as a target, while allowing people wiggle room to miss this target.

The number 80 is with us for historical reasons, but I know I'm not the only one who still routinely uses 80-column buffers.

Richard

On Nov 9, 2015, at 5:45 PM, Simon Peyton Jones wrote:

...
In my view 80 chars is too short. It was justified in the days of 80-column CRTs, but that just isn't a restriction any more. I routinely edit in a much wider window.

Clearly there's a judgement call here. But I'd prefer 120 cols say.

Simon

-----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Richard Eisenberg Sent: 09 November 2015 21:03 To: ghc-devs Devs Subject: too many lines too long

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

https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d

...
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Simon Marlow

11:23 a.m.

I also use multiple 80-column windows side-by-side, and long lines are quite unreadable. I have a local emacs key binding to make the window 120 wide temporarily for when I'm working on Simon's code :-) There's also the issue of having side-by-side diffs in Phabricator being readable on a laptop screen, for which I think 80 is a reasonable limit. I think the current level of nagging in Phabricator isn't terrible, though if we want to make it less annoying I believe it's also possible to make it an "advice"-level warning, which wouldn't force you to explain yourself, but it would still appear in the diff. Cheers Simon On 09/11/2015 22:51, Richard Eisenberg wrote:

...

At both school and at home I can fit 3 80-character buffers side by side, at a comfortable font size. Going up (even to 85 cols) would mean losing a buffer. (Or straining my eyes.) Of course I can deal with wrapped lines. But I still vote for 80 characters as a target, while allowing people wiggle room to miss this target.

The number 80 is with us for historical reasons, but I know I'm not the only one who still routinely uses 80-column buffers.

Richard

On Nov 9, 2015, at 5:45 PM, Simon Peyton Jones wrote:

...
In my view 80 chars is too short. It was justified in the days of 80-column CRTs, but that just isn't a restriction any more. I routinely edit in a much wider window.

Clearly there's a judgement call here. But I'd prefer 120 cols say.

Simon

-----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Richard Eisenberg Sent: 09 November 2015 21:03 To: ghc-devs Devs Subject: too many lines too long

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 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Alexander Berntsen

11 Nov 11 Nov

4:50 a.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FWIW, I agree with Austin on this. On 09/11/15 23:51, Richard Eisenberg wrote:

...

I know I'm not the only one who still routinely uses 80-column buffers. My preferences are 78 > 74 > 80 > less than 80 > *. I don't feel strongly about any =<80 number in particular, but I feel rather strongly about =<80.

However, the most important thing is choosing a limit and sticking to it. If you're not going to do anything about it, why have Phabricator warn about it at all. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWQw9wAAoJENQqWdRUGk8BJBEP/Ao7zyCh0zmR1aDpa0oy2d76 6X+2gBsx3aA6kEJmkaM6I23eAQLBowkHAwS5y2lizouulvPVkL7ZRIA25U5adutq swGmsoQXS+n/dJtkVpugnW116ILEnORC7Y/NHH+cHhUMuCdWTWsANssF6h3gHciN SH1nS1O4oPI63kpb7PhZA5r4CpVWGwD9aq8bruKrLPmZkYuvdYgF4Vly69UX6n1z P5wVEfws04E/sdM/BRf4v1JY0TpgP0CBOnjDIcX63Rhir9xAp3jAUyMHOVHdHnKh +TaHGmwkavINhpOjQgNh6akNoC/Nh4ocWq7J9Hqo9JgdIW2LfUozf52Ha7jFUaeu 6gXXr4stMnfv6fje3MNFpIQ1tCTarDsvCTJ549rqmH++RVtZLFmDpnXQAYMq8wNd sqDCtmdM8bOgru3kkdsJjGRFumZ5k+r9riKf/STXdf4rXfZt20aq0hg+snZDWSIQ 0zyTl6jYD+0Xu8naP3/F+THvLzEpefOROAFdYpii2R42Y5jBA56XSbJ4atkLdA/1 fUaewmYomGHeCileolJ56A0qgnoh67siEYQ8aKMfK68B9anvjvkN/0trixNEF94B CMWJrBGoK4NOyQX7TuJKNq9cCELLpvsjr8oU1J4UyZfYm10Zcjm0JN+JGqwtM64A pfLNN+0yi7kYtUiGPaUy =bt6t -----END PGP SIGNATURE-----

Ben Gamari

10 Nov 10 Nov

6:30 a.m.

Simon Peyton Jones writes:

...

In my view 80 chars is too short. It was justified in the days of 80-column CRTs, but that just isn't a restriction any more. I routinely edit in a much wider window.

As far as a hard length limit is concerned I am with Simon here. 80 characters is quite short and some of the more "tabular" source files of GHC would be on the whole less readable if such a limit were strictly enforced. On the other hand, I agree that in many cases 80-characters is quite a convenient length; having several buffers side-by-side can make reading much easier. Many of the files with long-lines could and should be fixed. However, I am not convinced that this is true for *all* source files and in my opinion a bit of discretion doesn't hurt. Cheers, - Ben

Edward Kmett

4:47 p.m.

Heck, I've been able to use 132 columns since my VT-220 days. ;) -Edward On Mon, Nov 9, 2015 at 5:45 PM, Simon Peyton Jones wrote:

...

In my view 80 chars is too short. It was justified in the days of 80-column CRTs, but that just isn't a restriction any more. I routinely edit in a much wider window.

Clearly there's a judgement call here. But I'd prefer 120 cols say.

Simon

-----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Richard Eisenberg Sent: 09 November 2015 21:03 To: ghc-devs Devs Subject: too many lines too long

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

https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Joachim Breitner

9 Nov 9 Nov

5:47 p.m.

Hi, I’d like to state a differing opinion: I don’t think highly of such a hard rule. A line should have the length that is most natural to it. Patches should be easy to review. Developers time is spent better than re-shuffling code to be short and still nicely formatted and aligned. I might be in the minority here, and of course I’ll be adhering to any hard requirements agreed on by broad consensus, but note that the support for an 80-line regime is not unanimous. Oh, and obviously dropping this requirement would also solve Richard’s problems with the linter :-) Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

C Maeder

11 Nov 11 Nov

7:03 a.m.

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

Dan Doel

12:32 p.m.

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

Jan Stolarek

13 Nov 13 Nov

10:01 a.m.

My view on this is: Firstly, I hate explaining myself to Arcanist. When prompted to explain the reason for too long lines I typically enter "wontfix" without thinking too much. Secondly, I really don't like how warnings clutter code reviews. I have my Emacs highlight text beyond 80th column with a really ugly colour, so I strive real hard to maintain 80-column limit whenever possible. But sometimes fitting in that limit is nearly impossible: imagine being in a let nested in a do-notation nested in a guard nested in a where clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I would support introducing a hard limit on having no more than 80 columns. Janek PS. It makes me really sad that we don't have any coding convention for GHC: we mix camelCase with underscore_case, indentation is inconsistent (good thing we at least got rid of tabs!), whitespace usage is inconsistent, etc. I could make this list very long. --- Politechnika ÅÃ³dzka Lodz University of Technology TreÅÄ tej wiadomoÅci zawiera informacje przeznaczone tylko dla adresata. JeÅ¼eli nie jesteÅcie PaÅstwo jej adresatem, bÄdÅº otrzymaliÅcie jÄ przez pomyÅkÄ prosimy o powiadomienie o tym nadawcy oraz trwaÅe jej usuniÄcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

Richard Eisenberg

10:20 a.m.

Could you add your comment to the ticket I've created? https://ghc.haskell.org/trac/ghc/ticket/11082 As for case conventions: The parts of GHC I play in have a fairly reliable convention: underscores for local things (both local variables and non-exported helper functions) and camel case for exported things. It's a nice convention that I've used elsewhere. This is not rigorously applied, but it's pretty good. Richard On Nov 13, 2015, at 10:01 AM, Jan Stolarek wrote:

...

My view on this is:

Firstly, I hate explaining myself to Arcanist. When prompted to explain the reason for too long lines I typically enter "wontfix" without thinking too much.

Secondly, I really don't like how warnings clutter code reviews.

I have my Emacs highlight text beyond 80th column with a really ugly colour, so I strive real hard to maintain 80-column limit whenever possible. But sometimes fitting in that limit is nearly impossible: imagine being in a let nested in a do-notation nested in a guard nested in a where clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I would support introducing a hard limit on having no more than 80 columns.

Janek

PS. It makes me really sad that we don't have any coding convention for GHC: we mix camelCase with underscore_case, indentation is inconsistent (good thing we at least got rid of tabs!), whitespace usage is inconsistent, etc. I could make this list very long.

--- Politechnika ÅÃ³dzka Lodz University of Technology

TreÅÄ tej wiadomoÅci zawiera informacje przeznaczone tylko dla adresata. JeÅ¼eli nie jesteÅcie PaÅstwo jej adresatem, bÄ dÅº otrzymaliÅcie jÄ przez pomyÅkÄ prosimy o powiadomienie o tym nadawcy oraz trwaÅe jej usuniÄcie.

This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Simon Marlow

17 Nov 17 Nov

5:19 a.m.

On 13/11/2015 15:01, Jan Stolarek wrote:

...

My view on this is:

Firstly, I hate explaining myself to Arcanist. When prompted to explain the reason for too long lines I typically enter "wontfix" without thinking too much.

Secondly, I really don't like how warnings clutter code reviews.

I have my Emacs highlight text beyond 80th column with a really ugly colour, so I strive real hard to maintain 80-column limit whenever possible. But sometimes fitting in that limit is nearly impossible: imagine being in a let nested in a do-notation nested in a guard nested in a where clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I would support introducing a hard limit on having no more than 80 columns.

Janek

PS. It makes me really sad that we don't have any coding convention for GHC: we mix camelCase with underscore_case, indentation is inconsistent (good thing we at least got rid of tabs!), whitespace usage is inconsistent, etc. I could make this list very long.

Why not write down a set of style guidelines and get everyone to agree to them? I'd happily compromise my personal stylistic preferences if there was a standard style that we all agreed on and tried to adhere to. Personally I think a good starting point is http://chrisdone.github.io/hindent/HIndent-Styles-JohanTibell.html Incidentally the mixed camelCase and underscore style is deliberate: underscores for local identifiers, camelCase for exported functions. It's a cute idea I've been using for a long time, but we don't have to do it that way. At work we use camelCase exclusively and it's fine. Cheers, Simon

...

--- Politechnika Łódzka Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Richard Eisenberg

9:15 a.m.

We have such a thing: https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle I don't think its widely consulted or respected, though. Richard On Nov 17, 2015, at 5:19 AM, Simon Marlow wrote:

...

On 13/11/2015 15:01, Jan Stolarek wrote:

...
My view on this is:

Firstly, I hate explaining myself to Arcanist. When prompted to explain the reason for too long lines I typically enter "wontfix" without thinking too much.

Secondly, I really don't like how warnings clutter code reviews.

I have my Emacs highlight text beyond 80th column with a really ugly colour, so I strive real hard to maintain 80-column limit whenever possible. But sometimes fitting in that limit is nearly impossible: imagine being in a let nested in a do-notation nested in a guard nested in a where clause. Approx. 15-20 columns are lost for the indentation. Nevertheless I would support introducing a hard limit on having no more than 80 columns.

Janek

PS. It makes me really sad that we don't have any coding convention for GHC: we mix camelCase with underscore_case, indentation is inconsistent (good thing we at least got rid of tabs!), whitespace usage is inconsistent, etc. I could make this list very long.

Why not write down a set of style guidelines and get everyone to agree to them? I'd happily compromise my personal stylistic preferences if there was a standard style that we all agreed on and tried to adhere to.

Personally I think a good starting point is http://chrisdone.github.io/hindent/HIndent-Styles-JohanTibell.html

Incidentally the mixed camelCase and underscore style is deliberate: underscores for local identifiers, camelCase for exported functions. It's a cute idea I've been using for a long time, but we don't have to do it that way. At work we use camelCase exclusively and it's fine.

Cheers, Simon

...
--- Politechnika ÅÃ³dzka Lodz University of Technology

TreÅ›Ä‡ tej wiadomoÅ›ci zawiera informacje przeznaczone tylko dla adresata. JeÅ¼eli nie jesteÅ›cie PaÅ„stwo jej adresatem, bÄ…dÅº otrzymaliÅ›cie jÄ… przez pomyÅ‚kÄ™ prosimy o powiadomienie o tym nadawcy oraz trwaÅ‚e jej usuniÄ™cie.

This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Alexander Berntsen

9:31 a.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 17/11/15 15:15, Richard Eisenberg wrote:

...

We have such a thing: https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle

I don't think its widely consulted or respected, though. There are several issues here. (Get rid of tabs v. spaces for instance.) In general it's just too complicated. Successful coding guidelines are in my experience a line or two to explain each point, and then an example or two.

Anyway, I read these, but quickly enough found out that the best strategy was to just try to fit in with the existing code. We should simplify them and make a more pretty site for them. Something like [0], although that's a bit wordy for my taste. Then we need to decide on how to "get there". E.g. do we enforce all new files to follow it rigorously, but adhere to the dominating style of the file you are changing? Do we change the function we are modifying in a patch to adhere to the style? Do we just go through everything all at once and fix it once and for all, like with tabs? I'm not voting for any of them right now, but we need to consider them. [0] http://docs.ganeti.org/ganeti/2.13/html/dev-codestyle.html#haskell - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWSzo8AAoJENQqWdRUGk8BuYkQAMVLUfgdYaaduhTCeDBSACjC 9iP8AcmmTsMPbEcSvIA3u2c5wDSxJe1v4kJcglftylcCwLNZQgcVy9k05HlbRbDP CCUS/Glv1TM+s79xueH3ByispjrhZt7yJgdJ5SJbe43i9KyjAG+TaqfgyJRL5oiw 4VKRAfoT2RYm6cjG1WlnzGzDh4QF3y8F9MCZWVgAMbAIDU0gKyR1Mxpf3xSXb02y ObbCKiA3qqITqfjs1ZHXwaJqbg/F21uELS+veGZN149ylimm0zpVzolx9mRgYASv t/b20+qBtDBr/K0BQ/ZPzgx0d9TaYiGF2Jd1AE+m9P9cqPD7qPqljI2/G4Vn0g61 pEburlt4OdSdMlUCmsf3lXBDUMQrXDjBRkh8zMirlt/BzC9a6+9JOfjLixgFlDSV ohy3XmQVokeDWrcFmxz0FPWinU4P+5uQos0Jp/sO+fukRkormM089UYB7vRZVOn9 GtaBCA5FQSvgqfLbDpPDRHfYka5qLPXo9dKtyjjhqEXggwlVCys5rrF+y1B4qs9A XgENKexKtsg7aGc99KZh3t2rF7/jwKsdcVnAbEbyEUvZ9fqvtwZO6DN32YLjNLoV McVeGkLWhtw+ihD/E6VueUxk0ImCr8CpGGMxW7WvyPlQW3v/seU3l7Qezh1PkRZ/ jvj8PUJfGZA/GEZALpIv =tY36 -----END PGP SIGNATURE-----

3473

Age (days ago)

3481

Last active (days ago)

List overview

Download

23 comments

17 participants

participants (17)

Alan & Kim Zimmerman
Alexander Berntsen
Austin Seipp
Ben Gamari
C Maeder
Dan Doel
David Fox
Edward Kmett
Edward Z. Yang
Jan Stolarek
Joachim Breitner
Nikita Karetnikov
Richard Eisenberg
Simon Marlow
Simon Peyton Jones
Tuncer Ayaz
Ömer Sinan Ağacan