"If the argument for expanding to 100 or more is that screen is getting wider, then the benefit of wide screen is the ability to fit multiple terminals in one window. For normal workflow, I'd split my windows into two or terminals, depending on what I am doing, so I don't see any benefit in increasing the limit."
1. Like you said, splitting windows. I now use a tiled window manager and also I use vim splits a LOT. If I can fit two windows side by side, good - if I can fit three, great!
2. I find that when my lines go over 80/100ish characters they are very hard to read anyway (too much eye travel between lines) and its usually (though admittedly not always) a sign that my code is too nested or otherwise could be simplified.
So now I happily use 80 character lines (When using Python I strictly follow the vim PEP8 checker, for example). I actually kinda prefer 80 to 100 now because I use slightly above average font sizes (I don't have the best eyesight) and this way I can still comfortably fit two editors side by side.
If the lines come out too long too often, it may be a symptom of other problems.
if ((browser.OS == 'win') && (browser.userAgent == 'IE')) {
isIE = (browser.userAgent == 'IE');
isWindows = (browser.OS == 'win');
if (isIE && isWindows) {
I decided some time ago that it was worthwhile forcing myself to adjust until it wasn't noticeably painful; there are too many people out there I want to communicate with who do it.
> Readability - You don't have to scroll over horizontally when you want to see the end of some lines.
It's not having to scroll horizontally that bothers me with long lines. My monitor is wide enough that it can probably hold 250 characters with ease. It's having to read long lines. Something is very bloody, terribly wrong in your code if you consistently find you need to write 150-character lines.
Besides, yes, monitors have gotten that wide that it's not an issue. Is there any serious reason to assume that code is the only thing I want displayed on my monitor at a given time? In a single window? That's as big as the monitor? The only moment when people had a good reason to be enthusiastic about that was the late 70s, when serial terminals appeared and teletypes began going the way of the dodo.
Also, who says the IDE is the only place where I want my code to be output? Maybe I want to grep on it or whatever. On an 80x25 terminal window because the least useful thing on earth is a huge monitor where I constantly alt-tab between a full-screen editor and a full-screen terminal.
Not necessarily.
Most lines are below 80 characters, but there are good reasons (for readability!) to use longer lines from time to time: vertical space is more precious than horizontal on modern screens, and the more content I can fit into each vertical page, the faster I'll understand what I'm looking at.
The main reason I like the ability to occasionally have a 150 or 180 character line is akin to code folding, which some editors have as a feature. The feature allows you to hide a function or class by collapsing it into one line, because you want an overview of the code around it or calling it, and for the moment the implementation details aren't relevant. Now, I don't actually use the code folding feature in practice, mainly because I find that the times I would want to use it are times when I nearly always want to fold the code, and in a case like that, it's nice to be able to "pre-fold" it by putting it all on one line.
For example, if not using an ORM, I might want to use SQL to grab some results from a db (in a model, say), and I almost never want to think about my SQL and my surrounding code in the same context. Now, you might say, "Just put that SQL in its own method with a reasonably short name, and call it where you would otherwise have a long SQL string, and in the function that returns it, you can break each line at 70-80 characters," but that seems like a "solution" which improves nothing in my typical reading of the code, and requires me to jump around to find the SQL in the rare case I need to pay attention to it. It breaks up something which is naturally local and specific to this place in the code.
Another example which happens somewhat more frequently for me is when I want to use a literal object in JS. If I want to keep the definition local -- because, perhaps, nothing outside of this function ever needs it -- my choices are to put each key/value pair on its own line (easy to find a given key, but consumes lots of vertical space), to put multiple key/value pairs on each line to fit ~80 characters (both moderately difficult to find a given key, and still eats moderate amounts of vertical space), or to "fold" it all to one line (consumes the minimum vertical space, with the trade-off that it's difficult to find a given key). The most common case of this is where I have the choice between using 4-6 lines, or one line, and it's an easy choice for me to pick one line, though I've never encountered a coding standard that agreed with me.
IMO that's just compensating for the inadequacy of tools by making code harder to follow. Usefulness of code folding (and what it says about the code it's folding) aside, this is a really poor solution. If you just need that done temporarily, why not temporarily replace all the returns in the region you select, and then add them back when you're done? Any editor with search-and-replace can do that.
> For example, if not using an ORM, I might want to use SQL to grab some results from a db (in a model, say), and I almost never want to think about my SQL and my surrounding code in the same context. Now, you might say, "Just put that SQL in its own method with a reasonably short name, and call it where you would otherwise have a long SQL string, and in the function that returns it, you can break each line at 70-80 characters,"
No, what I might say is "just stop thinking about the SQL query and the surrounding code in the same context".
Alternatively, put the SQL query in a separate function that conveys some meaning related to its purpose, so that people who read your code later don't have to decipher a 300-character query line in order to understand what that code is doing. They may not even be debugging that part of it, maybe something several layers of abstraction above borks and they end up in that part of the code debugging it.
> (easy to find a given key, but consumes lots of vertical space)
which can be easily averted with code folding? Or by simply scrolling down to the body of your code. Skipping entire lines is very easy, it's following a hundred-character snake that sucks.
It's not massively too few, and most lines never get close to the limit anyway, but the odd line of 100-120 thrown in really isn't a problem on a modern display.
...just Googled it: http://programmers.stackexchange.com/questions/148677/why-is...
It's like the railway gauge size being standardized by the ancient romans. The best part of all of this though is the other comments on this page - many of them seem to imply that 80 width was chosen because of how well it fits onto your computer screen and that 100 must be too wide. If the dollar bill in 1890 had been a bit wider, they'd likely be arguing now how 80 is too small!
It proves the point that it's important to actually understand why certain things are chosen and not just assume they're always the best. Going with the standard method is not always the most beneficial path.
I think 80-100 is fine. More than 100 and you probably need to refactor the line some, because you probably have too much logic on a single line (or you need to choose names that aren't hugely long).
Err, yeah they do, I have been given exactly that reason on a few occasions, generally by older engineers who had experience with old-school machines that had precisely those screen dimensions. I don't disagree with your main point, but it's really not a straw man.
I usually work with a file list/project navigator/something to the left and a build window at the bottom of the screen. I usually have two screens so that docs/browsers/whatever can live on the second screen. Seems to work for me.
In my current project I'm using eclipse which has a right-hand panel for build targets. Even with both left and right hand panels there's still enough space in the source window for 130 character lines.
Don't get me wrong, I think most lines should be short and that you should endeavour to keep them a reasonable, readable length. I just disagree with 80 as a hard limit.
This is especially true if you're using something verbose (Java, Objective-C) or whitespace-sensitive (Python).
class Engineer(Person):
__tablename__ = 'engineers'
__mapper_args__ = {'polymorphic_identity': 'engineer'}
engineer_id = Column('id', Integer, ForeignKey('people.id'), primary_key=True)
primary_language = Column(String(50))
12345678901234567890123456789012345678901234567890123456789012345678901234567890
^^ Line length marker
Guess perhaps I should rename my columns with more obscure names like engnr_id instead.
Seriously; you see this in python all the time; people not wanting to break the line because its only a character or two off, and then stupidly renaming a variable to some obscure abbreviation instead.
We won't go into the 2-character indents argument, or the push for the 100 character limit that the BDFL veto'd for the PEP8 revision; but... safe to say, I think a fair number of people hit this as an issue.
I don't think 'you can just refactor that to be shorter' is really a solution in all circumstances.
They're not a substitute for common sense, and sometimes breaking the rules is for the greater good. I find the similar situations in shops that enforce strict naming conventions.
edit: The other tip is that the 80 character limit is closely aligned to the optimal line length for regular reading: http://ux.stackexchange.com/questions/3618/ideal-column-widt... A bit more than normal is allowable for programming because of indentation and the more structured nature of the text.
I currently maintain a large Python codebase where the original authors /needed/ big long lines. Anytime I see one of these big wads of bubble gum, I know I can rewrite it to be simpler, clearer and shorter (I've done it enough now). Fortunately, there are increasingly fewer of them...
It's important to remember that you're not just writing for the computer -- while it can take almost anything syntactically correct that you throw at it -- some human, somewhere will still have to read and understand that code.
It may be you, six months later.
There's two modern reasons for smaller liner lengths (80-100) besides cognitive capacity:
Viewing/editing two files side by side on the same screen.
Side by side diffs.
Now, that's not to say that you should contort the code to make lines short. If it makes the code significantly more difficult to read, don't do it... but still try to keep it reasonable. This is also a good reason to keep your variable names relatively short - so you don't hit this situation all the time.
===
If anyone's interested, I wrote a simple command to scan files for configurable line length violations and the presence of a file-terminating line ending.
https://github.com/frou/pagecop
(yes, I'm aware it could probably be duplicated with some sed/awk wrangling!)
For me, 80 chars is an arbitrary but acceptable limit (I could even argue it should be even shorter).
Personally, I view verbose languages that needs longer line as bugs. If you look at Scheme for example, it lets you wonderfully indent and nest, so that you rarely need long lines. Everyone benefits from it. Shorter lines are better for the brain, the problem is when coding languages make line too long by design, forgetting the 1000 years of experience in typography we've accumulated.
When I have trouble keeping the lines short I consider: 1) Is there a better way to write this? 2) Is this function too big?
There are cases where lines have to be longer, but not in Lisp. Inability to write short lines is a symptom of bad syntax designs like e.g. C et al.
EDIT: I have been writing JS the last months and keeping lines short is especially hard in JS, because of its abomination of a syntax. UNIX style backslash escaped line breaks don't help either.
I would be happy to read code more than 80 characters, if it doesn't have to be artificially cut into multiple lines (the screenshot in the post is a pretty good example). In fact, I find 80 characters too less and often set Emacs to use 100 characters as the limit.
[1]: http://stackoverflow.com/questions/903754/do-you-still-limit...
return some_loaded_module.fairly_descriptive_but_necessarily_long_name(not_very_long_argument)
fdbnln = some_loaded_module.fairly_descriptive_but_necessarily_long_name
return fdbnln(not_very_long_argument)
return $some_loaded_thing->fairly_descriptive_but_necessarily_long_name(
$not_very_long_argument
);
var thingy = FactoryFactoryObjectThingymybobProducer
List<T> l = new ArrayList<T>();
ArrayList<T> l = new ArrayList<T>();
Simply put: the world is different than it was in the 70s and 80s and 90s (all decades I have programmed in).
1) screen width is generally wider 2) screen widths are generally exandable 3) identifiers are generally longer
In today's world I see little reason to hold to the 80 character limit causing line breaks in what would other-wise be odd places.
That all being said, we still have yet to realize an editor that displays source code in a programmers preferred spacing while saving the program in the repository's preferred spacing. THAT is the real issue, here -- that editors are not helping with this issue, wrapping and indenting code as the screen width allows.
Your primary concern, with line-length, should be readability -- if your group decides 72 characters is the limit, well, so be-it, but I would press anyone who believes that is acceptable for JAVA.
And I no longer see a reason why one line length limit should hold for all source files. Why not let the source code decide the best line length -- we no longer have fixed sized screens, these are windows that expand with click and drag.
A similar thing would happen if technical writing and scientific reports kept the average sentence to 12-15 word sentence averages and tried not to go over 25. Reading comprehension goes up:
http://www.onlinegrammar.com.au/how-many-words-are-too-many-...
It's very similar. Breaking one long sentence into two is the same as breaking nested if and loop statement into several lines, the first just assigning a boolean based on the test. Then the if test just tests the boolean. Reading comprehension goes WAY up.
Look at the top response on this question: https://news.ycombinator.com/item?id=7289087 (the one with several short lines.)
100% comprehension.
It's literally logic that will be followed extremely, anally literally. No scientific language gets close to being that literal - normally, you are always going to keep the author's view/point in mind as you read. If you were to accidentally remove a random "not" from scientific writing (as happens), we can usually realize what the author meant. (With rare exceptions, if we are particularly unfamiliar with the topic.)
With code, on the other hand, code doesn't have a "point of view". It will just do whatever you wrote, completely literally. The shorter the expressions, lines, etc, the better.
Not only do I find the code easier to look at, but I find I write better code and I'm less likely to violate the Liskov substitution principle.
I presume it is on the front page because it has got several up votes in its first half hour.
set textwidth=80 colorcolumn=+1
For some things I use colorcolumn=+1,+21 for highlighting 81 and 101, for situations where I allow myself 100 in an extremity.
match Error /\%81v.\+/