question: remove 80 char line limit?

[ryanseys]

Can we increase the limit to something like 95-100 or remove the strict limit from linting? Seems archaic to have such a limit with higher resolution screens these days. Just my $0.02

[rakyll]

I don't have a strong opinion on this and would like to hear more opinions.

[ryanseys]

Because stuff like this and this just upsets me, especially when concatenation is happening at runtime possibly for every api call.

[stephenplusplus]

When I first started wrangling with the 80 limit, I felt the same way. I eventually figured out it can be annoying (for sure), but has also lead to some better clarity/maintainability decisions, I think.

The links you pasted used to bug the heck out of me, but I'm over it.

However... I would be totally willing to extend the limit, if we weren't already so far along with 80 characters. What would look worse to me is a bunch of 80 char limits mixed in with not as strict limits. And going through the code and sending a 100% line diff PR would be pretty nasty... For these reasons, my vote is to stick with 80.

(Side note: My 15" MBP retina barely fits 2 side-by-side 80char windows with only a little room left off to the side for the terminal to be visible).

[ryanseys]

if we weren't already so far along with 80 characters

I mean the library isn't that big.

100% line diff PR would be pretty nasty

Only lines that could really benefit would be affected, but yes there would be some mix.

barely fits 2 side-by-side 80char windows

Yeah, I don't look at multiple files simultaneously very often but if I do, I could always shrink the text to fit. Guess this is a "my use case vs. your use case" situation.

That being said, I don't hold this idea too close to my heart, just curious why the 80 char value was chosen in the first place for this project E.g. "it was a default value in the config" or "I've always done it this way... just seemed right" or "because 80 chars was the column limit for punch cards back in 1928"

[stephenplusplus]

I think regardless of the long history of "why 80", the less characters you can use to write a line of text, the easier it becomes to follow along. 80 is a standard that works well. Having multiple windows open is a pretty common use case in code, which is why narrower lines really help. Again, I'm not tied to 80, but I stand by it being more helpful than limiting. My only reason for not bumping up the limit is for the reasons I said before. I would personally find it really offputting to have hard 80 limits mixed with a wider one (in addition to the code, all the docs are at 80). However, if a pr covered all of it, I would +1 it :)

[jgeewax]

I'm going to add my vote for keeping the 80-char limit. I'm in the boat of people who do side-by-side file editing, and would rather not have to shrink text...

[ryanseys]

Yes, we will keep 80 char.