4

In projects with many developers it is useful if all their IDEs are configured with identical code style settings, such that you won't get pseudo-differences due to changed formatting checked into version control whenever someone else changes your code. You can try to convince everybody to import project standard formatting settings, but they might forget to do that on creating a new workspace and forget to adapt them whenever a change is necessary, so this will get lost over time.

So, is there a simple way to automate things such that everybody has the same settings and gets his settings changed automatically if they need to be updated - without them taking any action on their own?

Many of these settings are stored in .settings/org.eclipse.jdt.ui.prefs if they are configured project local , so it would be feasible to checkin this file into version control but leave out the other files in .settings. Unfortunately the formatter settings are contained in the big bucket .settings/org.eclipse.jdt.core.prefs, so you would have to do more complicated things to update these. So I am wondering if there are simpler / other options.

Clarification: In my experience many developers ignore requests to adapt the various code style settings in eclipse since they consider them unimportant. So I want to make it at least extremely easy for them to use the project standard settings, at best the codes style adaption should work completely without their cooperation - especially on updates of the coding style. I am looking for tools to do that.

Dr. Hans-Peter Störr
  • 25,298
  • 30
  • 102
  • 139
  • I've created a pretty generic answer. Note that there should be a few team related plugins that could do this for you as well. – Maarten Bodewes Dec 06 '12 at 15:09
  • Note that most development machines have rather lenient settings, I'm local admin at work. This means that developers can always "cheat" and use an other instance of Eclipse (or just another workspace). So the only thing you can really be assured of is what is being checked into the versioning system. So you can use hooks or an automated build process to check that. You cannot enforce anything locally. – Maarten Bodewes Dec 06 '12 at 19:12
  • @owlstead I don't want to enforce anything - that would not be appropriate for grownups. I just want to take away the excuses :-) and make it easier to do the right thing than to do the wrong thing. – Dr. Hans-Peter Störr Dec 06 '12 at 19:36

2 Answers2

1

Warning: it's not a good idea to be too strict when it comes to code style. Many programmers have a strong own style. So be careful what you wish for.

The easiest method in Eclipse is to create an empty workspace and use that initially by simply copying it to the developer's machines. You could even copy Eclipse with all the plugins. This has the drawback of having to manually create changes. It is also the most restrictive option.

Another method is to export/import all the settings. This is a bit more work, but it is less restrictive. You would need to distribute the following settings: Formatter, Clean Up, Templates. Furthermore you still would have to set the max. line size in the general settings.

The best way to let people adhere to code practices is to create a document about the minimum requirements. Make sure you document your decissions and let people participate. Then check if people adhere to it; if you let let it slip programmers will go their own way. Management (unfortunately) has a role to play here.

The best way of enforcing the code style is to create a CheckStyle configuration and keep it as a read only file on disk. You can then use this as an external style sheet from the CheckStyle plugin. Make sure that the Eclipse formatter and clean up settings match though.

The same CheckStyle configuration may be used on an automated build environment to generate warnings and errors. These warnings and errors should be discussed during review. Make sure you have loopholes, rules should ne broken if the need arises.

Managing developers is "not unlike herding cats"

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • 1
    I completely agree with what you say. However, what I am looking for are methods that work without much cooperation of the individual team members. In my experience many developers ignore requests to change their style settings. Checkstyle is good, but it only verifies that people are using the correct settings - I want to make it extremely easy for them, or maybe even unnoticeable. – Dr. Hans-Peter Störr Dec 06 '12 at 16:52
  • 1
    As for people having their "strong own style", I worked on one team where several people would run their personal style format when they started working on a file, and then run the official format before they checked anything in. That way people can do their own thing, but it doesn't mess up the `diff`. I think OP's real problem is that this is a management/team lead problem like you mentioned - someone has to enforce the rules. – Windle Dec 06 '12 at 17:10
1

In my old company, we would create a "default" or "template" workspace where everything is configured according to personal taste (like key settings, view positions etc.) and according to the companies rules (formatter, compiler warnings, checkstyle, mandatory plugins etc.).

Every time I needed a new workspace, I just duplicated this template workspace.

Since starting from scratch with a new workplace is such a pain, people automatically got used to using the template, rather than creating a complete new workspace. So there was never a problem with people forgetting it.

Bernhard
  • 665
  • 1
  • 6
  • 22