/home

Share IntelliJ Code Style and Inspection Configurations Between Team Members

Having a well-defined code style is key for having a clean change history in your repository. That alone, however, does not enforce everybody in your team to actually comply with them. IDEs like IntelliJ IDEA thus provide a rich feature set to format code and also allow highly-customized configurations. However, keeping these configurations in sync seems to be a problem for many developers. And solutions like EditorConfig are by far too limited. But if your whole project team uses the same IDE, it gets a little easier. For IntelliJ, it is even very simple as you will see below. Actually, I wonder why that approach is not more common.

IntelliJ stores its per-project code style and inspection configuration in .idea/codeStyleSettings.xml and .idea/inspectionProfiles/, respectively. The .idea directory (which is hidden by default on Mac OS and Unix), is in the root of your project path. That directory is usually ignored because it is in your .gitignore and/or .gitignore_global file (it hurts if it is not). So to add the configuration files to your git repository, you need to git add them manually. Note that you need to add the force flag -f or you will get the “The following paths are ignored by one of your .gitignore files” error message.

git add -f .idea/codeStyleSettings.xml
git add -f .idea/inspectionProfiles/

Assure your codeStyleSettings.xml contains the line <option name="USE_PER_PROJECT_SETTINGS" value="true" />. If it does not, your code style settings are not project-based but a default (or changed by you) configuration that cannot be shared is used instead. If this is the case, go to the IntelliJ settings and change Scheme to “Project” in Editor => Code Style.

Once you have changed your code style and inspection configuration accordingly, they will show up in your git status view. Add, commit, and push them to your repository. Now, your team members can just do a normal git pull and the IDE settings are synchronized. Keep in mind, however, that their local settings get overwritten without any warning when they do so. When somebody else changes the configurations, he can push that change to the repository and after git pull, everybody else will have the exact same code format and code inspections as well.

Another important aspect of this approach is using the same IntelliJ version. Older versions tend to remove settings from newer versions which causes unwanted local changes when your colleagues do not use the same software as you do. To avoid that problem, it is recommended to always use the most up-to-date IntelliJ version.