I use eclipse for coding, and the language which we use is Java. Once it was suggested by someone that to properly format the code, using the auto formatter(CTRL+SHIFT+F) While this command does format the code, but sometimes I feel that overall look becomes weird, and it is not actually very readable.

So is this a recommended thing to do? If not what is the better of formatting our code in eclipse ?

  • I use the auto-formatting capacity of emacs all the time - there are potentials for collisions (eg with SC merging) .. but overall, standardizing your format is extremely helpful
    – warren
    Commented May 13, 2013 at 17:44

5 Answers 5


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.

  • 4
    Once you've setup your formatter the way you'd like it. There's an "Export" button that will allow you save it to an .xml file. We put this into our SVN Repository, so everyone has access to it when they check out the project.
    – CLo
    Commented May 7, 2013 at 14:04
  • I agree with this, and use PMD and FindBugs and all. But this only is a good idea if everyone on the team follows and uses the code formatting rules. Otherwise you end up with commits that are changes + formatting by some devs and not others, and it's difficult to see the "real" changes. In other words, if the old code is not already formatted with the auto-formatter, don't format it with additional changes in one commit.
    – Mufasa
    Commented May 8, 2013 at 19:19
  • 2
    If you customize the code formatting settings, either push those settings into the source control so all developers get them, or publish them in some kind of wiki or developer documentation so everyone can agree on the style.
    – Mufasa
    Commented May 8, 2013 at 19:21

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
  • 5
    +1: I never knew about (or to be more accurate, I never bothered to find out about) the on/off tags.
    – Paul Cager
    Commented May 7, 2013 at 14:47
  • 2
    Autoformat-on-save is good if everyone on the project uses it. If only some developers use it, then it is too easy to commit changes with code formatting changes at the same time, which makes it difficult to find the "real" changes in a commit.
    – Mufasa
    Commented May 8, 2013 at 19:22
  • @Mufasa Yes, you're right.
    – JesperE
    Commented May 8, 2013 at 19:50
  • 1
    When you don't want format comment you can write /*- my super format */ Eclipse don't format such comment :)
    – Gelldur
    Commented May 11, 2013 at 21:44

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.