Wide lines are barbaric, and I'd go so far as to say that languages that can't be rendered comfortably in 80 character lines are nothing more the primitive tools of barbarians.
I agree utterly, and enjoy the irony that I read your comment displayed as http://i.imgur.com/iJNs9SV.jpg ... a full 258 characters ... HN could do with some responsive css to max-width comments above certain viewport widths!
This is probably the most insightful comment to come out of this discussion. The exact numbers aren't all that important, but having a consistent style (including line length limits - which I'm fairly sure no one will argue that there should not be a limit) and not checking in stylistic changes (or at a minimum, disentangling them from actual changes of substance) is important.
The problem is, we as programmers obsess over details (especially the closer you get to the hardware). The key is to obsess over the correct details, or obsess once and move on.
The style guide you linked to says indents are 4 spaces. I sense the question of indent size hasn't been solved at Google yet :-) I find 2 to be too little, except for XML and HTML which are naturally indented many levels and there's no way to refactor into new functions or methods.
[Edit: added quote]
How did they do interactive merges when they were limited to 80 characters?
enforcing a common style
I've seen people here for 6+ months still fighting this
Or you could, you know, just treat each other as adult, responsible individuals.
Hint: rules for the sake of uniformity don't "defuse boneheadedness". They just suppress individuals, and eventually either drive them out or tame creativity, initiative, and responsibility out of them.
I mean, come on, you say that yourself! So just acknowledge that that's what you're doing. There are processes for making better software. These kinds of style guidelines are not among them.
Even 100 can be awkward to fit into. Lord knows I've renamed variables to avoid splitting a line on several occasions.
But what a lot of posters here seem to miss is that it isn't about the width of screens for editing, it's about the width of screens for reviewing so you need twice the real estate.
Add in doing interactive merges and you need three times the width.
This really comes down to the principle of enforcing a common style (for an organization or project). A lot of people rail against "arbitrary limits" and "arbitrary style guidelines" as it's something extra they need to learn and adds no value (according to them). I've seen people here for 6+ months again still fighting this.
Such things (IMHO) have value as it adds a reasonable level of consistency across teams, it avoids commits on files due to stylistic changes (which may or may not be automatic from IDEs, etc) and, most importantly, defuses a lot of the aesthetic-driven boneheadedness that we engineers are prone to.
The last point is really important. Otherwise you'd have engineers and groups fighting over where to put curly braces, 2 space indents vs 4, whether tabs are OK, etc--none of which actually matters.
So if you feel your creativity somehow stifled over 80 characters, I'd strongly suggest you just abosrb it, get over it and move on to things that actually matter.
[1]: http://google-styleguide.googlecode.com/svn/trunk/pyguide.ht...