Strict code formatting rules are useful when several developers work on the same code using a version control system. Merging can be a pain if different developers have different formatting rules as the same code would look different for the merging tool.

Eclipse (or any good IDE for that matter) has code formatting rules that can be customized in the preferences section (Java > Code Style > Formatter). Choose what you like best, but have also a look at the Java standard code conventions. Many open source projects also have their own code conventions that can be enforced with the Eclipse formatter.

In addition there are standard tools like CodeStyle, PMD and Findbugs that enforce additional rules and help avoid common (low-level) anti-patterns and mistakes.

I’ve found the autoformatter very useful. Instead of constantly taking microdecisions on how the code should be formatted — something which is error-prone and causes “cognitive friction” — you can set up formatting rules and let Eclipse format the code for you (ideally automatically using “Save actions”). Of course, this requires that you have a code base with consistent formatting, or that you have the mandate to reformat the code according to the rules you setup.

Having “autoformat-on-save” enabled is a little like having incremental compilation, it allows your brain to stay focused on the code itself, instead of being concerned with trivial issues such as code formatting or syntax.

But yes, sometimes the autoformatter will mess up some nicely formatted table you have. In such cases I use “on/off tags”. These are configured under the “on/off tags” tab in the code formatting profile. Using them, you can exclude regions in your code from being automatically formatted:

// @formatter:off

... my nicely formatted table here ...

// @formatter:on

Whether or not it’s recommended will depend on who you ask.

I can imagine that you would prefer to format code yourself, after all, you know what’s best and easiest to read for yourself.
On the plus side, if you’re a considerate person you can make it more readable for other human beings too.

Machines don’t have that kind of foresight, and can (just like you said) make your code look like a bit of a mess, even if they format it by strict rules.

A good IDE or tool can often do a semi-decent job at formatting the code for you, but won’t always make it as readable as you could.

So, my advice : don’t use it unless you receive code from somebody else, and it’s such a mess that you cannot read it otherwise.

You should use it all the time to ensure that you use a consistent styling in all your source files. This will also save you a lot of time which you would usually spent trying to adjust the formatting manually.

The Java formatter in Eclipse does a pretty good job and is completely customizable. If you don’t agree with the default settings (which I can completely understand), then you should adjust the formatter to your own personal style preference or whatever is the standard you use. You can do that in the preferences under Java/Code Style/Formatter.

Formatters are even more useful when you are not working alone. It’s very likely that you and your team members will disagree on what you think is the perfect code style™. In that case you should agree to a common base and once and for all define formatter rules for this particular code styling. Then everybody can just hit the format-shortcut and everything fits the agreed styling. That way your personal preference (when writing) won’t get in the way. And note that the formatter styling can be stored in Eclipse’s project files, so different formatters for each project are possible too.

Although I do like having the code formatted automatically on save (in fact I enabled it on my personal projects). I found that I couldn’t fully recommend this practice in project teams using Eclipse based products as the Eclipse formatter has some critical bugs that prevent me from recommending it.

Specifically if you have “code cleanup” + “formatter” enabled the indents get fixed/unfixed on every save.

Each new version of Eclipse may change the formatter (for the better) but would introduce significant changes such as JavaDocs finally removing that extra space after the * but that got introduced sometime after Helios and a lot of enterprises are using the older Rational Software version of eclipse that uses Helios as the base.

The code formatter that is provided by Eclipse is not extensible per their API in fact it explicitly states CodeFormatter javadoc

This class is not intended to be subclassed by clients.

Granted, I haven’t found any viable non-commercial alternative as of yet. Jalopy hasn’t been updated for years now and the forks in github are not organized as of yet to make me recommend any of them. Nor does it have any update site for Eclipse to have it integrated. I was actually planning to make the code formatting as part of the build much like I did cleanpom-maven-plugin using Jalopy but that idea fell by the wayside due to the lack up updates for Jalopy.