IDE可能是一个“优越”的选择，这取决于开发人员试图实现的目标。

文本编辑器可能更“优越”，因为ide通常面向一种(或一小部分)语言。

如果一个开发人员大部分时间都在单一语言或相关语言的“集群”(如c#和T-SQL)上，在一个操作系统中，那么一个好的IDE所提供的GUI设计、调试、智能感知、重构等工具就会非常引人注目。例如，如果你大部分时间都在VB上工作。NET，在Windows环境中可能偶尔会用到一点T-SQL，那么如果你不考虑Visual Studio或类似的IDE，那就太愚蠢了。

我对那些喜欢ide或文本编辑器的人没有偏见，如果学得好，两者都可以非常有效和有用!

这取决于你使用的语言，但在c#和Java中，我发现ide对以下方面有好处:

Quickly navigating to a type without needing to worry about namespace, project etc Navigating to members by treating them as hyperlinks Autocompletion when you can't remember the names of all members by heart Automatic code generation Refactoring (massive one) Organise imports (automatically adding appropriate imports in Java, using directives in C#) Warning-as-you-type (i.e. some errors don't even require a compile cycle) Hovering over something to see the docs Keeping a view of files, errors/warnings/console/unit tests etc and source code all on the screen at the same time in a useful way Ease of running unit tests from the same window Integrated debugging Integrated source control Navigating to where a compile-time error or run-time exception occurred directly from the error details. Etc!

所有这些都节省时间。这些事情我可以手动完成，但会更痛苦:我宁愿编写代码。

简单地说，IDE提供了比简单编辑器更省时的特性。

我从相反的方向来回答这个问题。我从小就在Makefile+Emacs的环境中编程。从我最早的DOS编译器，微软的Quick C，我有一个IDE自动化的事情。我在Visual c++ 6.0上工作了很多年，当我毕业到Enterprise Java时，我使用Borland JBuilder，然后决定使用Eclipse，这对我来说已经变得非常高效。

Throughout my initial self-teaching, college, and now professional career, I have come to learn that any major software development done solely within the IDE becomes counterproductive. I say this because most IDE's wants you to work in their peculiar I-control-how-the-world-works style. You have to slice and dice your projects along their lines. You have manage your project builds using their odd dialog boxes. Most IDE's manage complex build dependencies between projects poorly, and dependencies can be difficult to get working 100%. I have been in situations where IDE's would not produce a working build of my code unless I did a Clean/Rebuild All. Finally, there's rarely a clean way to move your software out of development and into other environments like QA or Production from an IDE. It's usually a clicky fest to get all your deployment units built, or you've got some awkward tool that the IDE vendor gives you to bundle stuff up. But again, that tool usually demands that your project and build structure absolutely conforms to their rules - and sometimes that just won't work for your projects' requirements.

我了解到，要与团队一起进行大规模开发，如果我们使用IDE开发代码，并使用手动编写的命令行脚本进行所有构建，那么我们可以获得最高的效率。(我们喜欢用Apache Ant进行Java开发。)我们发现在IDE中运行我们的脚本对于复杂的构建来说只是一个点击或者自动化的噩梦，用alt+tab到一个shell并在那里运行脚本要容易得多(而且破坏性更小)。

Manual builds requires us to miss out on some of the niceties in the modern IDE like background compilation, but what we gain is much more critical: clean and easy builds that can live in multiple environments. The "one click build" all those agile guys talk about? We have it. Our build scripts can be directly invoked by continuous integration systems as well. Having builds managed through continuous integration allows us to more formally stage and migrate your code deployments to different environments, and lets us know almost immediately when someone checks in bad code that breaks the build or unit tests.

In truth, my taking the role of build away from the IDE hasn't hurt us too badly. The intellisense and refactoring tools in Eclipse are still completely useful and valid - the background compilation simply serves to support those tools. And, Eclipse's peculiar slicing of projects has served as a very nice way to mentally break down our problem sets in a way everyone can understand (still a tad bit verbose for my tastes though). I think one of the most important things about Eclipse is the excellent SCM integrations, that's what makes team development so enjoyable. We use Subversion+Eclipse, and that has been very productive and very easy to train our people to become experts at.

ide基本上是:

编辑器/代码完成，重构和文档 调试器 文件系统资源管理器 scm的客户 构建工具

都在一个包里。

您可以使用单独的工具或出色的可编程编辑器和额外的工具，如Emacs(也可以使用Vim，但IDEbility IMO稍微少一些)来实现所有这些功能(以及更多功能)。

如果您发现自己经常在一个实用程序和下一个可以集成到环境中的实用程序之间切换，或者如果您缺少这里列出的一些功能(其他文章中有更完整的功能)，那么可能是时候转移到IDE了(或者通过添加宏之类的方法来提高环境的ideability)。如果你已经用一个以上的程序构建了一个“IDE”(在我上面提到的意义上)，那么就没有必要转移到一个真正的IDE。

Eclipse:

代码高亮显示，在后台编译，在执行过程中指出错误。

与javadoc集成，使用ctrl-Space提示变量名。

当我编译时，就会得到错误。我可以双击一个错误，它会显示相应的行。

很好地与JUnit集成，ctrl-F11运行测试，告诉我测试失败了。如果在输出窗口中出现异常，我可以双击某行，并将我带到失败的行。不仅如此，ctrl-F11还可以确保在运行测试之前编译所有内容(这意味着我永远不会忘记这样做)。

与ant集成。一个命令用于构建和部署应用程序。

集成调试器，包括web服务器的远程调试。

神奇的重构工具，搜索一段代码的引用。帮助我了解改变的影响。

总而言之，这让我更有效率。