Comment by cletus | Hacker News Reader

Comment by cletus | Hacker News Reader

Parent Full thread

At Google, our Python style guide dictates 80 characters with 2 character indenting [1]. Java is the only exception at 100.

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...

Lines of > 80 characters are really the last jabs at the dying corpses of typography and taste in the digital world. Typographically proper paragraphs are not wide across, because that forces the eye to move more while reading. This is a basic fact that has been known for literally longer than we've had printing presses.

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.

> Wide lines are barbaric

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!

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.

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.

> At Google, our Python style guide dictates 80 characters with 2 character indenting

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]

So we're all staring at a wrapped lines so you can do a 3-way merge? How often do you need to merge anyways? More often than you write code? Often enough for it to be the limiting factor?

How did they do interactive merges when they were limited to 80 characters?

i concur

I've renamed variables to avoid splitting a line on several occasions

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.

I am unmoved by this argument. Forcing E.E. Cummings to use proper spelling and punctuation would certainly have had a detrimental effect on his poetry. The other couple billion English speakers benefit from consistency the other 99.9999% of the time. If you can't find non-syntactic ways to express your programming brilliance, creativity, initiative and responsibility, then I doubt you have all that much in the first place.

For what it's worth, E. E. Cummings most often wrote his name with proper capitalization.

http://www.gvsu.edu/english/cummings/caps.htm

Thanks, fixed.

Reply on news.ycombinator.com