Should all team members use the same IDE? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

开发者_StackOverflow社区 Improve this question

Should all team members be forced to use the same IDE (e.g. eclipse, netbeans, intellij) for programming, even though the build process is independent of IDE? (Assume no IDE specific plugins etc are being used on the project.)

If everyone is using the same IDE, they can share the same configuration and work in a more consistent environment. However, if you have been working with a certain IDE for many years, being forced to use another will be frustrating and reduce productivity because you will be trying to learn the IDE instead of focussing on the problem domain.

I am interested to hear which one of these two types of teams you have worked in and which one you think works best.

Thanks

If no specific plugins are being used then why not let people use what they want? We use a mixture of Eclipse, vim and other editors to edit a mix of Java, PL/SQL and Pro*C. We all have different vim setups, and it has never been a problem. Having said that we all use Eclipse for Java, but that is mainly because it is the best IDE for Java (for our purposes). We are all on different versions of it though so there is not really any enforced consistency there either.

I am a fan of letting each developer choose their IDE. I've worked in standardized environments and mixed, and I haven't seen much of a difference in productivity - its more of a morale issue (people forced to use tools they don't like are less happy).

You mention Java-centric IDEs (Eclipse, NetBeans, IntelliJ). In a Java-centric environment, one can use Maven to generate project files for those IDEs, which reduces a good portion of the argument for standardizing on a single IDE - because you standardize at a lower level - the Maven project file.

The only caveat to my opinion is that I find developers that choose to use simple text-editors rather than IDEs almost always create code that is riddled with warnings when viewed in an IDE, so I frown on that practice. Of course, if someone is a wiz with emacs or textmate, etc., and doesn't generate warnings, I have no problem with them continuing with their chosen platform.

I can not say much about Java. But as for C++, if you don't agree about indentation (is it spaces, tabs, tabs of what size) the code in runtime becomes a mess and less readable.

Additional point that can be against using several IDE in the same team if peer reviews/coding is done on regular basis (i.e. part of XP or coe review).

If these are not issues I don't see why team members can not pick up their favoirite IDE.

If you get too draconian about it you'll stifle innovation and in two years you will be on an ancient version of an IDE that is wholly inadequate for your task. On the other hand if you give free reign, each developer will do his own thing and you'll have a hit in productivity.

Have a "rule of 3". Let the team pick which IDE they want to use. If some members prefer a different IDE, allow for a second alternative. By the time that some members want to move to a third alternative it is only ok if the team agrees to get rid of one of the first two.

That way you have some consistency in your dev team (with the productivity gains that go with that) but you allow for moving to alternatives without a committee deciding it.

Forcing everyone to use the same IDE only works if you employ clones. Since every person is different, they have different approaches to solve tasks. If the gap becomes a too big, allowing individuals to use their preferred tool can boost performance and morale (morale because people feel better when they believe that they have an impact).

But that must not lead to a support issue. If someone is asking for some obscure IDE (for whatever reason), they better be able to solve their issues themselves. Choice doesn't mean you get an excuse to skip work because your tool breaks all the time.