Is there a convenient and sustainable way to handle code indentation and style in a team in which multiple IDE’s (Emacs, XCode, VS) are used by different programmers?
We are using git, so, should we use a precommit hook or should we integrate the auto-formater into the IDE of each developer directly? I think the first one is a better option since it gives the developers freedom to use a custom style but it complicates the process a bit and I feel like it is more prone to errors.
Nevertheless, a solution which uses a config file might make sense. That way we can put the config file in the root of the project and before every push (or every save) the code gets re-structured automatically.
This is a real problem because a code that looks great on one IDE looks like a mess on the other. This is not just a space/tab issue.
6
There are a few options.
Many version control systems offer the ability to run scripts on a commit. Git, since you mention that specifically, has pre-commit hooks. But it’s not unique to Git – Subversion has pre and post hooks, as does Mercurial, and even ClearCase has some level of scripting abilities. You can use these to automatically call a code formatter. Everyone can configure their IDE (and even choose to reformat code on checkout) to their liking, but the hook and tool will reformat before checking it in so that way the version in the repository matches your coding style.
If your language doesn’t have a good autoformatter, it may have a linter that supports style rules. In that case, the developers may need to forgo their custom style conventions and adopt the team’s guidelines on their own, before a commit. Using commit hooks or a CI server, you can block merges to a mainline branch that doesn’t meet quality guidelines. You can hook into linters, static analysis tools, and your unit tests and require everything be acceptable or risk a build marked as failure.
If your developers are using IDEs, formatting tools are often built in. If a developer makes a style, it can usually be exported and shared among other developers using the same IDE. If the developer is using a programming-centric text editor, there may be ways to do autoformatting or hook into autoformatting tools. If there are configuration files for your tools, you could export them and check them into version control (separate from your project) and that would also serve as a captured version of your style guide, allowing you to make sure that it is up-to-date.
7
We use a trigger which automatically runs Artistic Style before each check-in. If individual developers don’t keep the style consistent, the problem goes away before anyone else works on the code.
Artistic Style
Code that looks fine on one IDE should look fine on another IDE. If it isn’t then someone is mixing tabs and spaces or something equally misguided. Instead of trying to fix the problem in post, eliminate it in your code:
- Only use tabs, or only use spaces, for indentation. Have all IDEs set to enforce this.
- Don’t do hanging indents if you’re using tabs (in my view: don’t try and vertically align anything except to indicate scope but I realise others do it differently).
11
We used to have stored configuration files for different IDEs. Like “if you are using Eclipse, import this preference file to have it format the code as required by our code style”.
It also helps to have both vim and emacs modelines in the beginning of each file. Just in case.
Let’s look at the pros and cons of each approach:
Git hook script
- Pros:
- Automatic (easy to use)
- IDE-agnostic
- Cons:
- Harder to set up
- Has no judgement on whitespace (like hanging indent)
- Commited code is different from local copy – local gets overwritten
Verbal agreement on standard
- Pros:
- Lets the programmer apply judgement on whitespace (like hanging indent)
- Cons:
- Requires fiddling with each IDE
What do you and your team prefer?