Free choice of an IDE in your team
Introduction
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. It’s not because I don’t want to reveal it, but because it’s about something more fundamental: I think it’s good if every developer can make their own decision and choose their IDE. The goal is to increase the individual and the team’s productivity.
It shouldn’t be problematic to use multiple IDEs in a team. The process of compiling, packaging, testing, and delivering the software shouldn’t depend on a particular IDE anyway.
In this post, I’m going to give you some pieces of advice from my own experience:
Don’t push the IDE-specific files
Developers should not push the IDE-specific files 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 the structure of your project is and 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 the structure and configuration of your project in an IDE specific language. 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 to express dependencies and packaging. 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 you package the application.
Provide a way of generating these IDE-project files
You should provide an easy way for 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 by 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 has published their: https://github.com/google/styleguide. They provide the XML files for multiple IDEs.
Use conversion tools
Look if the IDE can import style schemes from other IDEs or if there is a plugin for it. For instance, in IntelliJ IDEA, there is a way of importing it from Eclipse:
Git’s command diff diff makes 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.