subject:"too many lines too long"

Re: too many lines too long

2015-11-17 Thread Richard Eisenberg

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

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

Re: too many lines too long

2015-11-17 Thread Alexander Berntsen

-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]  
- -- 
Alexander
alexan...@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-
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: too many lines too long

2015-11-13 Thread Richard Eisenberg

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
> 

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

Re: too many lines too long

2015-11-11 Thread Alexander Berntsen

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

Re: too many lines too long

2015-11-11 Thread 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  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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: too many lines too long

2015-11-10 Thread 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  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/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: too many lines too long

2015-11-10 Thread Edward Kmett

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 <simo...@microsoft.com>
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-boun...@haskell.org] On Behalf Of Richard
> Eisenberg
> Sent: 09 November 2015 21:03
> To: ghc-devs Devs <ghc-devs@haskell.org>
> 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=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d
> ___
> 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

RE: too many lines too long

2015-11-10 Thread Ben Gamari

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

signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: too many lines too long

2015-11-10 Thread Tuncer Ayaz

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

Re: too many lines too long

2015-11-09 Thread Edward Z. Yang

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

Re: too many lines too long

2015-11-09 Thread 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

Re: too many lines too long

2015-11-09 Thread Austin Seipp

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

Re: too many lines too long

2015-11-09 Thread Ömer Sinan Ağacan

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

Re: too many lines too long

2015-11-09 Thread Joachim Breitner

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
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

too many lines too long

2015-11-09 Thread Richard Eisenberg

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

RE: too many lines too long

2015-11-09 Thread Simon Peyton Jones

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-boun...@haskell.org] On Behalf Of Richard 
Eisenberg
Sent: 09 November 2015 21:03
To: ghc-devs Devs <ghc-devs@haskell.org>
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=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: too many lines too long

2015-11-09 Thread Richard Eisenberg

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 <simo...@microsoft.com> 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-boun...@haskell.org] On Behalf Of Richard 
> Eisenberg
> Sent: 09 November 2015 21:03
> To: ghc-devs Devs <ghc-devs@haskell.org>
> 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=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cebcdeaa0675a490898dc08d2e94927cc%7c72f988bf86f141af91ab2d7cd011db47%7c1=6IXQEBFIJnDRWCSKmNxdVsWQm2bqPVPn133kblshukU%3d
> 

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

Re: too many lines too long

Re: too many lines too long

Re: too many lines too long

Re: too many lines too long

Re: too many lines too long

Re: too many lines too long

Re: too many lines too long

RE: too many lines too long

Re: too many lines too long

Re: too many lines too long

Re: too many lines too long

Re: too many lines too long

Re: too many lines too long

Re: too many lines too long

too many lines too long

RE: too many lines too long

Re: too many lines too long

17 matches

Site Navigation

Mail list logo

Footer information