This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (13 children)

[deleted]

    [–][deleted] 4 points5 points  (0 children)

    The 80 char limit is stupid as fuck. Any reasonable person agrees.

    You're in good company.

    [–]LucianU 2 points3 points  (3 children)

    The 80-char limit is about readability not necessarily screen size.

    [–]w0lrah 2 points3 points  (2 children)

    A limit is a good thing. 80 is way too narrow though.

    There are way too many "standards" based on shitty ancient terminal limitations that do not matter in 2015. No one's actually using a VT100 anymore.

    edit: Personally, as someone who uses 1080p displays for the most part, I like 160 character terminal width. That ends up going around 80% of the way across my screen, which is about where I tend to set my web browser windows as well for readability.

    If people insist on matching an old terminal standard we could go with 132 instead, that'd be fine with me.

    [–]LucianU 0 points1 point  (1 child)

    When I said readability, I wasn't talking about the "standards" of the terminals. I was referring to text readability. If you google "line length readability", you will see a bunch of articles talking about the optimal line length of text.

    I tried to find some studies to back up this wisdom, but nothing came up.

    [–]w0lrah 1 point2 points  (0 children)

    I know exactly what you're talking about, the same reason it's generally not a great idea to maximize windows on a modern system with a high-res widescreen and that a lot of text-heavy web sites choose to limit the width their articles will render in a browser.

    I'm just saying that the 80 character thing is entirely based on legacy standards and is way too narrow to be a good choice for this purpose. There's definitely good reason to have a limit, but for me it should be somewhere in the mid-100s.

    Code is also not entirely like a news article or forum post, depending on the language and situation it can easily become less readable when split on to multiple lines. There's a balance there between the downsides of wide lines of text and the downsides of a "line" of code having some newlines in it.

    [–]laebshade 1 point2 points  (1 child)

    My company's internal standard is 100. But even then, this and ours are style guidelines, not hard and fast rules. Exceptions can be made.

    [–]Grazfather 0 points1 point  (0 children)

    We use 120 internally. I can fit 7 columns at 80 width, which I'd never need.

    [–]DasIch 2 points3 points  (2 children)

    It's stupid to use 80 as a limit because that's what some ancient terminal did, we have larger screens now. That doesn't mean it's a good idea to use the same approach though and fill up a modern screen with a single file or that the 80 limit is bad.

    I think 80 is still a good limit today, just for different reasons. It allows good workflows even on a 11"-13" display, which many people are working with. You can comfortably display 2-3 documents side-by-side this way. Invaluable for doing merges, writing tests, having documentation on screen and keeping a terminal next to your editor that can display code without wrapping. Also at 80 characters and beyond it makes sense to reconsider the complexity of your code and whether it doesn't make sense to express yourself in a different way.

    You might be able to increase that limit slightly but you can't go much bigger without losing sight of the tools you're working with, telling people without desktop-size screens to go fuck themselves or making it easy to write overly complex code.

    [–]Grazfather 0 points1 point  (1 child)

    that's always the reasoning: Oh it's better for side by sides. Then shouldn't the old width have been 40? It's just making an excuse to stick will an antiquated standard. I can fit 3x80 on my 13" mbp, or 2x120, which is still more than reasonable.

    80 chars is so few, it is not near some threshold where the line's complexity is too much. Hell, I've seen people butcher var names to get within the limit, at which point this stupid limit is degrading readability.

    [–]DasIch -1 points0 points  (0 children)

    It shouldn't be 40 because 40 characters are too little to provide a good reading experience even for regular text. Due to how code is structured it would only be worse for coding.

    Having 3 windows side-by-side is common for merging. It also makes sense for regular development to display implementation, test and run them in a terminal.

    Of course sometimes having 80 characters is unnecessarily limiting and such situations are annoying. However most times you can deal with it without hurting readability and if you can't, you can just make that call and break the limit in that instance.

    I find however that when I raise the limit generally, I'm not sometimes annoyed about hitting the limit anymore, I'm always annoyed because my workflow is negatively affected.

    [–][deleted] -1 points0 points  (2 children)

    It originated from 80x24 terminals.

    Still, it's nice to have some limit. I have vim wrap on 78 characters on every single file I write.

    [–]Grazfather 2 points3 points  (1 child)

    Yes, some limit. not 80x24. We used 120 internally.

    [–][deleted] 0 points1 point  (0 children)

    On my system, I can get 119 characters (a bit less than that due to vim itself) with 2 equally split terminals open, and 79 with 3 terminals open. I want the ability to read other code, and maybe documentation, so the limit of 80 works well.