Do you think it makes sense to enforce that every member of a team must use the same IDE?

For instance all engineers that are already on the team use IDE X. Two new engineers come and want to use IDE Y instead because that's what they have been using for several years now.

Do you have any experience with "mixed IDE" teams? If so what is it?

  • 5
    The problem I've often had with mixed-editor environments is auto-formatting of code and treatment of things like tabs. As long as you get all that straight, it won't matter much. Commented Oct 23, 2013 at 12:31

13 Answers 13


Provided the 'official' build system (as used by the Continuous Build servers) is the same for all, I don't see any reason why each member of the team could not choose the tools he wants...

  • 5
    This is the right answer.
    – user1249
    Commented Dec 24, 2010 at 14:00
  • 32
    I'd add that if the official build system depend on an IDE, there is a problem. Commented Dec 24, 2010 at 14:39
  • 4
    When you spend a lot of time at other team member's desks it can be annoying figuring out their setup before you can help them.
    – Doug T.
    Commented Dec 24, 2010 at 17:53
  • 4
    OMG!!! An internally developed IDE ??? That is a recipe for a disaster, like an internally developed bug tracking system.
    – Job
    Commented Dec 24, 2010 at 19:02
  • 9
    @Job, I work at Microsoft, so strictly speaking VS is also an internally developed IDE. We also use an internally developed bug tracking systems... TFS and Product Studio :). Commented Dec 24, 2010 at 19:11

If your team relies on certain plugins available only to certain IDEs, then it only makes sense to unify everyone under the same development platform. I also find it easier to help someone with a development issue if they have the same IDE as me, whereas if I'm to read someones screen with an unfamiliar interface it'll take a bit longer.

  • 7
    If your team relies on an IDE plugin for anything non-trivial, you already have bigger issues.
    – HedgeMage
    Commented Dec 24, 2010 at 23:00
  • @HedgeMage Only a sith deals in absolutes. E.g. what if the project is based on Eclipse Platform? I don't know what is the current state, but a couple years ago IntelliJ was incapable to do sophisticated validation and such for Eclipse plugin metadata. We had a developer on team who insisted on IntelliJ - more then once checking in broken code.
    – Eugene
    Commented Oct 23, 2013 at 15:39

One downside is that when pairing you can't swap the keyboard between you as fluently. Between mainstream IDEs this is probably not a huge problem, but if one person is used to Eclipse while the other is used to vim, there is going to be a mismatch. The Eclipse user may well be entirely unable to use vim, while the vim user (that's me ;) spends a lot of time cursing under their breath at the horrible slowness of using vanilla Eclipse.

That said, I'd still much rather use vim myself. Provided your pair are happy with just one of you "driving" for extended periods it works OK.

And I know there are plugins to make Eclipse work like vi, but I'm talking about pairing where I go and sit with someone who has Eclipse working as they like it, so they won't be installing that plugin.


It would make no sense at all to force every developer of Linux kernel to use the same IDE (or use any IDE at all).


I don't have experience with mixed IDEs, unless you count a commercial IDE with occasional supplementing by a text editor "multiple IDEs," but I can think of a couple pros and cons.


  • Each developer can be most productive with what they know best
  • Some IDEs may provide an advantage over others (one might be better at refactoring, another might be better at providing coding aids, others might be better with data integration, whatever). Using a blend might allow your team to capitalize on that.
  • You'll have a bit of a hedge against the possibility that one of the IDEs goes defunct.


  • Licensing issues. If there are multiple commercial IDEs involved, maybe it's more expensive. At the least, it could be more to keep track of.
  • Licensing issues 2. If there are frameworks or plug-ins that are licensed by IDE or langauge, will this be a problem?
  • As Dszordan mentioned, certain plug ins may not be compatible with the different IDEs.
  • If the IDEs have code generation components or style formatting engines that do things differently, this might cause some confusion.

Today's developer wants to choose their own tools

This has changed over time though. 10 or 15 years ago there wasn't as many choices at places where I've worked. (yes there were lots of editors but they weren't a 'choice'). The shop that I worked at 15 years ago was very 'old school' (even then!) and vi was the editor. No choice. This was actually pretty useful, because after the first month of cussing and swearing I actually got to like it.

Today, there are many choices and each has many advantages.

In my personal experience I used an IDE - rubyMine - for a couple of years before switching 'back' to vi(m). I did this because Ruby is a very hard language to write an IDE for (duck typing and other dynamic features) and as a result IDE's tend to be slow and/or require the latest, fastest machine.


There is a reason for which this can be forced. Simply consider visual studio and emacs/vim. As on windows visual studio will add an extra \r at the end of the line. This mess up with the display in emacs/vim. Also the tabs create problem. The problem with us is that we developers work in Linux but our software architect is comfortable in visual studio. He once cursed us saying that we do not format the file properly. But then when he found that this is because of the default setting issue, we all agreed to the same format.
If anyone force me to use particular IDE, I will not feel bad. Whatever is good for the team I will respect that and will compromise accordingly.

  • 2
    You are confusing code formatting standard with IDE usage. If you decide to use 3 spaces for your indentation level, you can set that in Visual Studio or Emacs (I know, I use them both). Other issues such as the different line endings in Windows, Macs, and Unix could be solved by custom check-in/check-out scripts, ala if OS == Windoze ... Commented Dec 27, 2010 at 4:16
  • Switching IDE because you don't know how to set spaces/tab in the one you are using is unfortunate. Also a boss cursing you without knowledge is not a good thing. Commented Oct 24, 2021 at 11:04
  • This feels more like an anecdote than an answer though. The opening sentence doesn't make sense to me other than essentially saying that ignorance of settings might be a reason. Commented Oct 24, 2021 at 11:05
  • Note also that this is from 2010 Things have changed in 11 years. Commented Oct 24, 2021 at 11:07

Well yes I have some experiecne in that regards being a part of mixed windows/unix & c++/java team. I think this is not an issue provided either everyone is comfortable working with the other IDE or there is never going to be a situation when anyone who is not familiar with IDE Y needs to work on the other guy's (that is the guy with IDE Y) system.


If everyone wants to, that's fine, but different people might want to use different editors/IDEs. I wouldn't really want people to force me to use an editor other than my preferred one if I were working on something big with a team, and I doubt I'm alone. People may be most happy with the situation if you don't force them to use a particular editor.

BTW, Emacs!


I don't think everyone needs to have the "same" IDE, but it would be nice that everyone had a "supported" IDE.

For example, if your IDE is integrated into the code review process as far as commenting and updating code goes, then it would make sense for everyone to be on a supported platform.

If your company is using a collaborative environment such as Rational Team Concert and one or two guys want to use an unsupported IDE (or a different version) while everyone else uses compatible ones, then life may be difficult for the people who have chosen to be outside of the support loop.


At our place we build our projects using Visual Studio. When it comes to editing text I switch to Emacs. Your company shouldn't care as long as the work is done.


Sounds a bit like "we used this at my old job". Well, they aren't at their old job.

If it doesn't affect your tool chain or source control plug.ins, then maybe yes. Then again, can the two new folk demonstrate a clear benefit? Have they used your IDE?

Otherwise, I have no patience with this nonsense unless there is a good case for it. They aren't at their old job: it couldn't have been that good for them to want to leave. Was using the other IDE the only highlight in ther old job: if so, they should STFU and be grateful..

  • Shouldn't peoples preferences matter to a workplace? Is preference nonsense? Isn't a programmers satisfaction a benefit to the company? I am sorry but this doesn't "compile" for me.
    – daramarak
    Commented Feb 14, 2012 at 9:06
  • @daramarak: Where does this cross into arrogance or being a prima donna, especially for larger shops with a corporate standard? Remember: new guys walking into a new company saying "we want this" is arrogance.
    – gbn
    Commented Feb 14, 2012 at 9:12

YES! Enforce singleton IDE.

It makes problems when the project dependency change. if one introduce a new dependency to the project, then every one will waste time to introduce that new dependency, and some might fail and waste time on that process. HUGE WASTE OF TIME.

there should be a REALLY good justification to add a different IDE to the team, meaning the saved time should surpass the time dedicated to migrate the system to different IDEs

  • An IDE is really an editor. In no way does an editor constitute a project dependency. (I'm aware that this answer may have been sarcastic, however, this is not the place for sarcasm)
    – Arafangion
    Commented Jul 21, 2012 at 18:39
  • IDE is not really an editor, because you don't use "Notepad.exe". you need extra work done by IDE, and ide does not have standards, which makes things difficult to use the external ability. and if you ment that hex edit is just "text editor" then code is not just text. Commented Jul 22, 2012 at 11:00
  • The IDE really is just an editor, with a bunch of other tools, the vast majority of which can be called on the command line anyway.
    – Arafangion
    Commented Jul 22, 2012 at 14:35
  • i don't get people here. they say an internal ide is bad, and uniform ide is bad. so ide should be uniform to all programmers, but not to all programmer that work on the same project. HUH?! I DON'T GET IT! Commented Aug 12, 2012 at 11:56
  • 2
    It's just a tool. Any competent programmer should be able to utilise their tools appropriately, and if they feel that a different IDE is more suitable for how they do development, then they should do so.
    – Arafangion
    Commented Aug 12, 2012 at 13:38

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