My feeling though is the problem is they have a line limit. Maybe they should rethink their style. I'm serious.
Before I worked at Google, in 30 years of programming I never worked at a company that had a line limit. Adding a line limit at Google did not make me more productive. At first I thought "hey, I guess 80 chars makes side by side comparison easier" but then I thought back, hmm. I never had problems comparing code before when I didn't have a line limit.
Instead what I found was that 80 character limit was a giant waste of time. The article just pointed out a year of wasted time. I can point to searching and replacing an identifier and then having to go manually reformat hundreds of lines of code all because of some arbitrary style guide. I also had code generators at google that had to generate code that followed the line limit. I too wasted days futsing with the generator to break the lines at the correct places all because of some arbitrary line limit.
That should be the real takeaway here. Make sure each rule of your style guide actually serves a purpose or that its supposed benefits outway its costs.
> My feeling though is the problem is they have a line limit.
There are a few reasons why we do 80 columns:
1. Human eyes have an effective line limit. The longer a line gets, the harder it is to scan back to the beginning of the next line. This is why paperbacks are taller than they are wide and why newspapers use several short columns instead of one wide one.
2. Being too narrow hurts readability, sure, but being too wide does as well. Also, even though many developers have giant monitors now, we also spend a lot of time on laptops, doing side-by-side code reviews, looking at code on blogs, etc. 80 columns is pretty friendly towards all of the various and sundry places where a user may be looking at some code.
3. We found it encourages better code. Dart is syntactically kind of a superset of Java, which means you can write Dart code that looks like Java. In particular, you can revisit some of the egregiously verbose naming practices that infected that community in the 90s. I see a lot of code like:
LoggedInUserPreferenceManager preferences = new LoggedInUserPreferenceManager();
A shorter column limit has worked as an effective nudge to get people to do:
var preferences = new Preferences();
> The article just pointed out a year of wasted time.
We'll get the time back. It's amortized over the amount of time saved by running it x the number of engineers using it.
> I can point to searching and replacing an identifier and then having to go manually reformat hundreds of lines of code all because of some arbitrary style guide.
The problem here is that you had to manually reformat it! Refactoring is a key goal of automated formatting. You can make a sweeping change to the length of an identifier and automatically fix the formatting every where it appears.
> I also had code generators at google that had to generate code that followed the line limit.
Code generators are another explicit use case. We have a lot of code generators now that produce completely unformatted code and the run dartfmt on it.
> I too wasted days futsing with the generator to break the lines at the correct places all because of some arbitrary line limit.
Did you know that Go doesn't have a line limit and gofmt doesn't wrap lines? It only fixes whitespace within a line. It's up to programmers to split lines manually. It seems to work for them, so clearly there's more than one way to do this.
> Did you know that Go doesn't have a line limit and gofmt doesn't wrap lines?
Yup.
My feeling is that this keeps gofmt much simpler, but it kind of punts the problem onto users. I wanted a more complete solution, even though the result is a lot more complex.
The idea of an auto-formatter has come up many times on the Chrome team. It is always shot down because formatting often imparts meaning. Meaning that is unclear to an auto-formatter. Of course you're free to run an auto-formatter over your own code.
Often I want to format things that are more readable for me. Example (yea, not Google style guide example. Too lazy to dig one up)
If I break that line I'm not going to break it between xPositon and yPosition, nor and I'm going to break it between startAngle and endAngle. An auto-formatter will never know that semantically those things are more readable when they are on the same line.
Similarly you claim the short length encourages shorting names but you still run into plenty of situations where the code is far far less readable because of the line limit.
Example, assume 40 char limit
int w = desired_width *
scale_factor + padding;
int h = desired_height *
scale_factor + padding;
glBindTexture(
GL_TEXTURE_2D, someTexture);
glTexImage2D(
GL_TEXTURE_2D, level, format,
w, h, border, format, type, data);
glTexParameter(
GL_TEXTURE_2D, GL_TEXTURE_WRAP_S,
GL_REPEAT);
vs
int w = desired_width * scale_factor + padding;
int h = desired_height * scale_factor + padding;
glBindTexture(GL_TEXTURE_2D, someTexture);
glTexImage2D(GL_TEXTURE_2D, level, format, w, h, border, format, type, data);
glTexParameter(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
Chrome in particular is full of code line wrapped into what is effectively obfuscated code. So no, I don't agree what a line limit has any point.
You claim human eyes have a line limit. I don't disagree per say, but in my years before Google I never found anyone seriously abusing line length. Then again I never had to use Java but that's a separate issue. I hope Dart is not targeting Java's verboseness. I could make the same claim that unbroken lines, up to a point, are more readable, understandable and I will go on to claim that the 80 char limit at Google breaks that rule and ends up cause 20% of Google's code or more to effectively be obfusticated.
My eyes (much) prefer the 40-char version to that last code at the end, though I might do it like so:
int w, h;
w = desired_width;
w *= scale_factor;
w += padding;
h = desired_height;
h *= scale_factor;
h += padding;
glBindTexture(
GL_TEXTURE_2D, someTexture
);
glTexImage2D(
GL_TEXTURE_2D, level, format,
w, h, border, format, type, data
);
glTexParameter(
GL_TEXTURE_2D, GL_TEXTURE_WRAP_S,
GL_REPEAT
);
That's assuming C, for C++ I might start it off like so:
int w = desired_width;
w *= scale_factor;
w += padding;
int h = desired_height;
h *= scale_factor;
h += padding;
I might be tempted to use a macro but likely pass and just use shorter names all around.
Nowerdays on the web we've seen the benefits of separating content and presentation. Apart from inertia and weak existing tools, I don't see why we programmers mix presentation (indenting, newlines and line breaks) with our content.
If it was up to me, programs on disk and in version control would basically be an abstract syntax tree, and any time a user viewed them they would be formatted using whatever style rules and screen size the user liked.
The way we do things at the moment seems like the equivalent of those marketing e-mails where all the text is made into a big image to "make it look right".
That doesn't solve anything because you still have to write a parser and formatter. Once you have one it's easier to run the formatter when writing to disk and the parser when loading. A sufficiently smart editor could reformat the code in an alternate style for editing and format back again to the standard style on save.
It looks like this formatter isn't just for internal use, at a company that can buy each of their developers multiple 25-inch monitors. Not everyone has screen space to burn making their editors and terminals arbitrarily wide. If the majority of Dart code was formatted with a line length limit above 80, that would significantly deter me from exploring Dart.
I don't contribute to many open-source projects. But I'd imagine Python would have a good track record, PEP8 specifies something like a 72-character limit.
That said, long lines in an existing project aren't a dealbreaker, if I have other reasons for contributing. (The one I'm working on now has them.) But if there's no reasonable way for me to write code in a language without breaking 80 chars, I'm not likely to choose that language for my own projects.
The specific number of columns may be arbitrary, but you have to specify some number or your codebase will turn into a mess.
I've seen it happen - you'll get that one guy who likes to zoom a single editor to the full size of his monitor and then just type, type, type all the way to the far edge, making it impossible for anyone else to figure out what the hell he's doing without switching to his idiosyncratic editor setup. He'll see nothing wrong with nesting control structures fifteen or twenty levels deep, because it will all look completely reasonable on his screen, and he'll happily glom up absurdly complicated 30-40 character long identifiers because he has no taste and autocompletes all his identifiers anyway. An organization like Google can't tolerate that kind of crap and a strict code formatting guideline provides a simple first line of defense toward keeping it under control.
Limiting line length makes it easier for developers to work on each other's code, because they won't have to go resize all their terminals or change the length marker on a per-file basis. It's also a mechanical way to push developers toward shorter parameter lists and shorter, less deeply nested functions, which are good practice anyway.
(For what it's worth, I too have been programming for around 30 years, and Google is also the only place I've worked that had an official style guide with line limits. My reaction is the opposite of yours: I loved it, and I've tried to lobby for the practice everywhere I've worked since. I don't care what the details of the style guide are so long as they are enforced consistently - it's a really great feeling to drop into some far-distant file written by people you'll never meet and still find that the code is clear and consistent with the code you work on every day. I like 80 columns because it lets me fit three full size editors on each monitor, but I would be just as happy with 96 or 110 or 132 or whatever as long as there is some consistent limit I can count on.)
I can get behind most code style guidelines, but people who harp on 80 character line limits drive me nuts. It's such a funny anachronism. Is there really someone out there using an editor that can't soft-wrap?
The width of a developer's editor window is so fundamentally a presentation issue - I have trouble imagining anything more so. Having line length limits is like mandating editor color schemes. How about I set my soft-wrap preferences the way I like and you can do the same?
> I can get behind most code style guidelines, but people who harp on 80 character line limits drive me nuts. It's such a funny anachronism. Is there really someone out there using an editor that can't soft-wrap?
Personally, I'd never know. I assume my editors can soft-wrap, but, IME, in terms of being able to easily work on code, lines that fit the window are better than long lines that aren't soft-wrapped, and long lines that aren't soft-wrapped are better than long-lines that are soft-wrapped, so I don't ever use soft-wrapping features.
I'm personally not that tied to 80 characters as a perfect line limit, but its a not unreasonable general guideline for most code in most languages. Like most guidelines, there's times when its inconvenient as a hard limit.
I never use soft wrap. Code layout communicates meaning, and ought to be created on purpose. Having line length limits is like expecting developers to write comments. The compiler doesn't care, but other human beings do.
80 chars is too narrower. But it isn't about the editor, or word wrapping. It is about the plethora of other tools. Duffs, commit histories, compiler errors and so on
I'm not a huge fan if strict line limits. But in general you are better off keeping your lines shorter. There are many reasons, shorter lines are easier to read. Some programming lines are naturally short. Switching between long and short lines can be difficult.
But the biggest reason, many tools work better with shorter lines. Diffs, commit histories and so on. I don't know how many times the delta was in code that was off the screen and the tool didn't have a slider (or maybe it did, but sliding back and forth was painful)
Generally shorter lines are better than longer ones.
I also had code generators at google that had to generate code that followed the line limit.
That's an unusual requirement for a code generator. What is the purpose?
Generated code generally is not read by humans or checked into source control. I suppose in the rare event where you want to read the code you could rely on your editor's line wrapping feature.
Just to choose an open source example: JET generated code from the Eclipse Modeling Framework is generally expected to be checked in, read, and edited by humans.
My feeling though is the problem is they have a line limit. Maybe they should rethink their style. I'm serious.
Before I worked at Google, in 30 years of programming I never worked at a company that had a line limit. Adding a line limit at Google did not make me more productive. At first I thought "hey, I guess 80 chars makes side by side comparison easier" but then I thought back, hmm. I never had problems comparing code before when I didn't have a line limit.
Instead what I found was that 80 character limit was a giant waste of time. The article just pointed out a year of wasted time. I can point to searching and replacing an identifier and then having to go manually reformat hundreds of lines of code all because of some arbitrary style guide. I also had code generators at google that had to generate code that followed the line limit. I too wasted days futsing with the generator to break the lines at the correct places all because of some arbitrary line limit.
That should be the real takeaway here. Make sure each rule of your style guide actually serves a purpose or that its supposed benefits outway its costs.