3

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.

Improve this question
6
  • 5
    Don't get me wrong, but you can edit all almost all platforms to have the same style. You just have to agree on one (which is pretty hard, but can be done by the lead developer). Furthermore you can combine git hooks with clang format and produce an output which fits your coding conventions.
    – mistapink
    Aug 25, 2016 at 12:46
  • 2
    I think, mistapink is 100% right: If you have visible style changing just because you are using a different editor to look at your source code, you likely have code created by an editor that converts runs of spaces into tabs, assuming a certain tab length. If the viewing editor uses a different tab length, your view screws up. If this is your problem, then there is exactly one thing you have to do: set a convention on the use of tabs for indentation. Either you go all-tab with exactly one tab per indentation level, or you go all-space with a convention on the indentation width. No third way.
    – cmaster - reinstate monica
    Aug 25, 2016 at 14:19
  • @cmaster I agree with the points of space/tab and agreement on a uniform style but this is not just a space/tab difference problem. The style of Xcode not really modifiable. For example, the indentation of multi-line function calls is not modifiable.
    – Halil Sen
    Aug 25, 2016 at 14:46
  • @mistapink I am not sure if it is directly a style problem per se. Because the code looks normal in emacs but gets jammed up in Xcode. It is not space/tab problem. I think emacs displays the code by matching the parenthesis or something... so the user does not know that the actual code is not aligned at all... I don't know exactly whats going on. Thanks for the suggestion. I have found this githook-clang-format; however, it suggests to "[not] use this. Instead, look into integrating clang-format into your editor.".
    – Halil Sen
    Aug 25, 2016 at 14:56
  • Is there any chance to establish a single IDE as the one to be used? If you are able to set a code style convention in your team, you should also be able to set what IDE to use. At least we do this here. Everyone use the same IDE and set the same code style settings. Both policies are for the good of the team.
    – Laiv
    Sep 13, 2016 at 8:49

5 Answers 5

Reset to default
3

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.

Improve this answer
7
  • The language is C++ and I am exactly asking for those auto-formatters to use it with git or with IDE directly :) I don't know which is better and why.
    – Halil Sen
    Aug 25, 2016 at 15:06
  • 1
    @HalilŞEN Tool recommendations are off-topic here, but we can talk about methods and practices.
    – Thomas Owens ♦
    Aug 25, 2016 at 16:22
  • Oh, I didn't know that. Can you forward me to the correct stackexchange subsite for this type of request. Because the method and practices does not help you without the tool in this case. I know I can use pre-commit hooks but I don't know the tool or I don't know if I should select this or another method (which may or may not be tool dependent).
    – Halil Sen
    Aug 26, 2016 at 7:45
  • @HalilŞEN Software Recommendations, but they have very strict quality guidelines for questions asked there. I would also browse their Help Center and Meta before asking, as well.
    – Thomas Owens ♦
    Aug 26, 2016 at 10:44
  • I think this type of general rules are counter productive. Unless a question leads to an unnecessary discussion like "Tabs versus spaces" or an answer obviously advertising a product, it should be okay to mention a tool within an answer which describes a method or practice. Like cmaster comment to Jack Aidley's answer or GraniteRobert's answer.
    – Halil Sen
    Aug 26, 2016 at 13:00
2

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

Improve this answer
2

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:

  1. Only use tabs, or only use spaces, for indentation. Have all IDEs set to enforce this.
  2. 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).
Improve this answer
11
  • The problem is that not all IDE's have the same level of customization (the space/tab difference is not the only problem, the starting column of a broken line is missing in Xcode). Moreover, this leaves the responsibility to the developers. But a central style file and a way to enforce it is more fool-proof and easy to use and maintain (in case the style needs to be changed).
    – Halil Sen
    Aug 25, 2016 at 15:03
  • I disagree a bit about the hanging indents: It works fine as long as you do the indentation up to the nesting level in tabs, and proceed with spaces to align the continuation line with something in the line above. That way you get correct display no matter what tab-width is used for display, the continuation line will always be correctly aligned. But this takes care to do right, so it's not for the people who cannot distinguish a tab from a space. And, of course, you absolutely have to stop your editor from changing tabs into spaces or vice versa when adding another continuation line.
    – cmaster - reinstate monica
    Aug 26, 2016 at 6:16
  • @cmaster What about re-indentation feature of the IDE; the problem is (for example) the way Xcode deals with multiple lines while re-indenting the code. Since it does not conform with the style of the team. You cannot re-indent the code within Xcode, even if it does not look good on your screen. If you do that then the actual changes you have made will be buried under a lot of pseudo indentation changes. This means you have to work with a code that looks absurdly indented.
    – Halil Sen
    Aug 26, 2016 at 7:57
  • @HalilŞEN Yes, reindentation by IDE's must be avoided if you want to go with tabs. They all screw it, as far as I know. Personally, I forget about the auto-/reindenting "abilities" of the IDE's and do my indentation myself, it's not that hard if your editor is any good. I understand that other people want to use the auto-indentation features of IDE's, but when you do, you need to live with what you get. Indenting with tabs is unfortunately out of the question in that case.
    – cmaster - reinstate monica
    Aug 26, 2016 at 9:57
  • @cmaster Well, I didn't try but Xcode has an option to use tabs for indentation. But the team currently uses spaces. The problem is that this is an old and not-so-small project and filled with several styles (even in the same file). Developers come and go, so I don't want to leave the styling to people and resolve it with precommit-hooks; however, the githook-clang-format does not suggest this method :/
    – Halil Sen
    Aug 26, 2016 at 10:08
0

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.

Improve this answer
0

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?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.