Consider exposing option for longer line lengths

[carl-mastrangelo]

While not Google's style, several other companies and projects prefer longer line length than 100 chars. My current team evaluated google-java-format, and the most contention issue was the line length being too short. I feel like the majority of the value of the formatter has been lost over this one point.

For programmers with wider monitors (more and more common these days), the 100 char line limit results in a lot of wasted space. The main benefits of the shorter line length seem to be for people looking at two pages of code side by side. However, this is not a frequent activity, and code is normally viewed one page width at a time.

I don't think the line length that google-java-format uses needs to be general purpose. I propose 120 as a straw-man. Popular projects, such as Spring and Netty use 120 chars. GitHub adds a horizontal scrollbar after 120 too. I think such projects would be much more amenable to using this formatter if there was a --long-lines option, similar to the --aosp option.

[talios]

You may want to vote for #57 - this functionality used to exist, and still exists internally but unfortunately is no longer exposed - however my maven formatter plugin works around this.

Whilst I do appreciate the shorter lines, esp. for cases where you may be including code snippets in bug reports, email diffs, slide shows/presentations it can still be annoying when you have generics and longer class names, and as you say - bigger monitors.

[cushon]

See also this FAQ entry.

[carl-mastrangelo]

@cushon I have read this entry. I think most people agree on the decisions google-java-format makes (where to break lines, how to put curly braces, etc.) . It seems these decisions are not parameterized; there isn't any input into the decision. That's okay. For decisions that are a matter of picking a number, like the 4 / 8 character spacing for AOSP, I think it is more reasonable to let it be changed.

There is another question here: Is this project a "Look but don't touch" open source project? I get that this is for Google, but if Google wants the wider OSS community to adopt it, it will need to find some common ground. If you are not interested in OSS contribution and feedback, can you at least say as much on the readme?

[cushon]

The documentation mentions that the goal of the tool is to reformat Java source code to comply with Google Java Style (and AOSP style). The decision about the column limit is part of those style guides.

As @kevinb9n mentioned in #57 (comment), we understand that not everyone wants to follow one of those style guides, and so not everyone will want to use this formatter. We'd prefer to focus our efforts on making this formatter do the best job it can of implementing Google and AOSP style, and expanding the scope to include other style guides or configurations somewhat works against that goal.

[cushon]

6b86849 adds a --max-line-length flag to google-java-format and will be available in the next release.

Unlike configuration that would change decisions about code layout, the max line length is orthogonal to how the formatting layout algorithm works and doesn't add significant maintenance overhead. Other opinionated formatters support similar flags.

The overall approach to configuration in google-java-format hasn't changed, it will continue to be an opinionated formatter with minimal configuration. We're not planning to add other configuration to alter formatting decisions.

[mkurz]

Wow, finally, thanks!