Multi-IDE software development teams

You start a new software project, for instance in Java, and you ask yourself what IDE you should choose for your team. Many people are used to Eclipse, but IntelliJ IDEA is getting popular. What to do?

This post is not an IDE comparison. I’m not even going to say what my personal preference is. Not because I don't want to reveal it, but because it's about something more fundamental: The team shouldn't impose a decision.

I think it should be up to every developer to choose the IDE they work best with. It shouldn’t be problematic that multiple IDEs are used. The process of compiling, packaging, testing, and delivering the software shouldn’t depend on a particular IDE anyway.

There are a few things, I think, you should be aware of:

Don’t push the IDE-specific files

The IDE-specific files should not be pushed to the version control system (e.g., git). You built the software through tools like maven or gradle (Java), distutils (Python) or npm (JavaScript). These tools have configuration files to tell how your project structure is, how it should be compiled and packaged. It’s ok, and necessary to push these files.

What are the IDE-specific files? They tell your IDE how project structure and configuration is. But I see them as a byproduct of the main configuration. If you have a maven project, the pom.xml files are the ultimate place where you express dependencies and packaging. Depending on whether you work on Eclipse or with IntelliJ IDEA, you will need additional .project and .classpath files (Eclipse) or a .idea folder (IntelliJ IDEA).

As you likely aren't going to modify these IDE-specific files directly, don't push them to the project’s repository. And if you do change them, it's likely a private configuration you don't want to push anyway.

If you are using git, you can add them to the .gitignore file.

To gitignore Eclipse-specific files add this to the .gitignore file:

**/.project
**/.classpath
**/.settings
**/.metadata

To do the same with IntelliJ IDEA:

.idea/
**/*.iml
**/*.ipr
**/*.iws

This way, you ensure that the IDE-specific byproducts are not pushed to git and don’t generate confusion when it comes to change something in the project structure or the way the application is packaged.

Provide a way of generating this IDE-project files

You should provide an easy way to your team of generating those IDE-specific files. E.g. In my last Java project, this was:

Eclipse

As it was a multi-module project, with multiple nested modules we realised that Eclipse’s way of importing the maven project didn't work well. We used maven's eclipse plugin: executing:

mvn eclipse:eclipse

Then you can directly import an existing Eclipse project.

IntelliJ IDEA

In this case, importing directly from the IDE worked the best.

Don't let every team member find out by themselves how to make it work.

Every time you change the project structure every team member generates these byproducts for their specific IDE again (one way).

Style configuration

If you provide guidelines about how the code must be formatted, you have to provide the configuration for every IDE. The best way of doing this is providing configuration schemes (xml files). The problem is that these configuration files are IDE-specific. You have several options:

Use existing format conventions

For example, Google: https://github.com/google/styleguide(https://github.com/google/styleguide). They provide the xml files for multiple IDEs.

Use conversion tools

Look if the IDE has an option to import style-schemes from other IDEs, or wether there is a plugin for it. For instance, in IntelliJ IDEA there is a way of importing it from Eclipse:

How to import an code style scheme from Eclipse into IntelliJ IDEA

Git’s command git diffmakes it easy to check if you got a correct conversion: Format with one IDE, then with the other and check if you get the same result.

And again: Don't let that everyone wastes their time with this. Make it once, check it works, and provide the result (the configuration for every IDE you need) to your team.

Manuel

Manuel