I find your approach much more reasonable than the one outlined in the article, which to me feels like complexity for complexity's sake. There might be some minor win to breaking lines by analyzing billions of possibilities, but it just seems like overkill, and it's certainly not predictable for the programmer.
f(a, b)
f(
a, b)
f(a,
b,
)
f(a,
b)
f(
a,
b,
)
f(a, b)
f(
a,
b,
)(In particular, automatic refactoring tools don't need to wrap lines when they get longer.)
And everything seems to have worked out fine.
It's not the only way to do it, but I think it's interesting how getting everyone to agree that a problem doesn't need solving sometimes simplifies things a lot.
If we want to do it automatically, we need to figure out an algorithm to do that. It turns out that if you use 80 columns as a heuristic, the vast majority of the code will look fine. A lot of people (myself included) tried to use different algorithms but couldn't beat that heuristic.
If you know of a better way, please let me know :)
I'm not sure what corpus was used to determine that heuristic (nor what tab size). But it would trash a lot the projects I work on.
The upside is that as a developer you don’t need to worry about formatting yourself as you can just write code in a bad way, save the file and it’s formatted. And as a team, you will no longer spend any time in code review arguing about formatting and doing roundtrips to change small nits.
If the result is good enough that you are willing to let go of your manual formatting, the upsides are nontrivial.
Optimal text width for readability is 4-6 inches or (typically) 50-75 characters. Code, with its indented nature, tends to fit nicely within this if you keep to the 80 column rule.