Advice requested: Respect existing line breaks

[robfig]

I'm trying to get google-java-format to respect existing line breaks, as gofmt does. I want to make it not insert or remove newlines in the middle of a statement, even if it adjusts indentation or other things about it.

I've spent some time going over the code, but I'm having trouble figuring out how to make such a change. Can you provide any pointers on how to accomplish this?

Thank you!
-Rob

[kevinb9n]

Bad news for you: this is actually a fairly deep and stable design choice that we made early on in the project. Here's a snippet from our internal FAQ:

Why didn't it leave my perfectly valid code alone?

There are at least two kinds of source code formatter one could build. One kind finds violations and fixes them (an auto-correcting linter). The other kind ignores the existing formatting choices in the file, seeing only a stream of tokens, and chooses a formatting for those tokens following a consistent set of rules.

google-java-format (like clang-format before it) is of the second kind (with various exceptions). Its goal is not just to correct mistakes; it is to free developers from having to make formatting decisions in the first place, bringing greater consistency to your codebase. Every time the formatter decides to preserve an existing formatting choice, it works directly against that goal.

Users have also found it to be very liberating to not have to care what initial formatting they choose. Said one early adopter joyfully, "I just write code like a four-year-old doing finger paints!"

We have no plans to build the other kind of formatter.

But in this case, shouldn't it preserve my existing choice?

There are exceptions. For example, the formatter preserves your choices of interior blank lines inside a method implementation. Before opting to preserve an existing formatting choice, we check whether all three of these criteria are met:

• The formatting choice has an important effect on readability.
• The choice depends on the nature of the code in question, not just on varying personal preferences.
• We consider it infeasible for the formatter to figure out an acceptable choice on its own.

Notice, for example, that these criteria are clearly met in the case of interior blank lines, and that's why the formatter preserves them.

Why did the formatter change X to Y?

The important thing to understand is that nearly every aspect of how the existing code was formatted is intentionally ignored. So, trying to understand its behavior in terms of why it chose certain changes will lead to confusion and difficulty communicating. For the most part, it sees only tokens, and it makes formatting decisions in total unawareness of the previous state.

[robfig]

Sorry, I didn't mean to propose to change this tool itself -- I wanted to make a fork of it that was more palatable to those used to gofmt. I believe without this change, I can't get the necessary buy-in to bring some relief to our Java developers that our Go developers have been enjoying. Gofmt has a similar approach and similar raves about it, so I don't think that my tweak is incompatible with what you pasted.

I had been hoping since it maintains interior blank lines within a function, that it might be feasible to accomplish if only I could be pointed in the right direction, but maybe that's not the case.

Thanks for responding!

[kevinb9n]

Oh, I see. @cushon might have insights to help you, maybe. But it could also be that it's just too deeply baked in.