节省开发时间 通过提供集成调试、智能感知等功能，使生活更轻松。

有很多，但我会建议使用一个，他们比明显。

代码自动完成。它对探索代码有很大帮助。

拥有IDE有以下优势:

编译通常是“动态的”，这意味着不再切换到命令行进行编译 调试是集成的，在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!

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

不同的人可能有不同的原因。对我来说，这些都是优势。

为项目提供了一种完整的感觉。例如，我将有所有相关的项目文件在单一视图。 提供了更高的代码生产力，如 语法高亮显示 程序集引用 智能感知 数据库和相关UI文件的集中视图。 调试特性

最后，它帮助我更快地编写代码，而不是在记事本或写字板上。这是我更喜欢IDE的一个很好的理由。

至于我为什么使用IDE，简单的回答是懒惰。

我是一个懒惰的人，当有简单的方法时，我不喜欢用困难的方法来做事情。IDE使生活变得简单，因此吸引了我们懒人。

当我输入代码时，IDE会自动检查代码的有效性，我可以突出显示一个方法并点击F1以获得帮助，右键单击并选择“转到定义”以直接跳转到定义的位置。我按下一个按钮和应用程序，与调试器自动附加启动为我。这样的例子不胜枚举。开发人员每天所做的所有事情都集中在一个屋檐下。

不需要使用IDE。只是不这么做要难得多。

我喜欢IDE，因为它能在我的指尖提供很多功能。编辑/编译/项目中文件的可见性是我在IDE中所看重的一切。我现在使用Visual Studio，但在以前我使用slikedit，并发现它使我的开发过程比我不使用它时更流畅。

ide基本上是:

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

都在一个包里。

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

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

当“文本编辑器”实际上是emacs时，我认为做经典的“文本编辑器和控制台窗口vs IDE”是不公平的。IDE:s的大多数典型特性也在emacs中。或者它们甚至起源于那里，现代IDE主要是界面的改进/简化。

这意味着对于最初的问题，答案并不是那么明确。这取决于所讨论站点的用户如何使用emacs，是主要将其用作文本编辑器，还是完全使用自定义脚本，学习相关模式的命令，了解代码标记等等。

使用ide的一个很好的理由是，它们是生产现代软件的公认方式。如果您不使用，那么您可能会使用“老式”的东西，如vi和emacs。这可能会导致人们得出结论——可能是错误的——你被困在自己的方式中，无法适应新的工作方式。在软件开发这样的行业——创意可能在短短几个月内就会过时——这是一种危险的状态。这可能会严重损害你未来的工作前景。

Eclipse:

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

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

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

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

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

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

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

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

在决定是否使用IDE时，只需要考虑一件事，那就是它是否能提高您的工作效率。

简单的问题，简单的回答:)

我可以想到使用IDE的几个原因:

综合帮助是最受欢迎的。 内置的重构与Visual Studio预览 智能感知，语法高亮显示，大型项目的导航方便，集成调试等等(尽管我知道通过插件你可能可以在Emacs和Vim中得到很多)。 另外，我认为现在的ide有更广泛的用户基础，可能有更多的人为它们开发插件，但我可能错了。

坦白说，我喜欢我的鼠标。当我使用纯文本编辑器时，它变得很孤独。

对我来说，这肯定会提高我的工作效率。我甚至在Vista上的Visual Studio中编写Linux应用程序，然后使用Linux虚拟机来构建它们。

你不需要记住函数或方法调用的所有参数，一旦你开始输入它，IDE就会告诉你需要什么参数。您可以使用向导来设置项目属性、编译器选项等。您可以在整个项目中搜索内容，而不仅仅是当前文档或文件夹中的文件。如果你得到一个编译器错误，双击它，它会直接把你带到有问题的行。

集成了模型编辑器、连接和浏览外部数据库、管理代码“片段”集合、GUI建模工具等工具。所有这些东西都可以单独使用，但是将它们都放在同一个开发环境中可以节省大量时间，并使开发过程更有效地进行。

I'm not sure there's a clear dividing line between a text editor and an IDE. You have the likes of Notepad at one end of the scale, and the best modern IDEs at the other, but there are a lot of thing in between. Most text editors have syntax highlighting; editors aimed at programmers often have various other features such as easy code navigation and auto complete. Emacs even lets you integrate a debugger. The IDEs of even ten years ago had far less features to help programmers than you'd expect of a serious text editor these days.

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

这在很大程度上取决于你在做什么，以及你用什么语言来做。就我个人而言,我倾向于不使用IDE(或“我的IDE包含3 xterm vim运行,运行数据库客户端,和一个bash提示或尾矿日志”,这取决于你广泛的定义IDE)的大部分时间里我的工作,但是,如果我发现自己开发一个platform-native GUI,然后我会找一个瞬间看清IDE——国际海事组织、IDE和图形形式编辑显然是天生的一对。

IDE处理繁重的工作，节省了您的时间。

它将所有相关的项目文件保存在一起，使协作变得容易。

您通常可以将源代码控制集成到IDE中，从而节省更多的繁重工作，并进一步增强协作。

如果它有自动完成功能，它可以帮助你探索你所选择的语言，还可以节省一些输入。

基本上，IDE减少了程序员的非编程工作。

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

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

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

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

作为你在你的问题中强调的回答的作者，并且承认这一点有点晚了，我不得不说，在列出的许多原因中，专业开发人员的生产力是最受重视的技能之一。

我所说的生产力是指高效地完成工作并取得最佳结果的能力。ide在许多级别上都支持这一点。我不是Emacs专家，但我怀疑它缺乏主要ide的任何特性。

设计、文档编制、跟踪、开发、构建、分析、部署和维护，这些企业应用程序中的关键步骤都可以在IDE中完成。

如果你有选择，为什么不用这么强大的东西呢?

作为实验，让自己使用一个IDE 30天，然后看看感觉如何。我很想听听你对这次经历的看法。

我认为这主要与开发者的认知范围有关。IDE提供了开发人员工作环境的宏观视图。您可以同时看到类层次结构、引用的资源、数据库模式、SDK帮助引用等。而且，由于您的击键会影响和影响如此多的事情，以及体系结构和体系结构交叉点的数量不断扩大，一次只使用一个代码岛工作变得越来越困难。

OTOH，“只有我和vim和手册页”让我对我的工作有了一个更精简的微观——但强烈而精确的——视图。如果我有一个用一种语言和一组静态库构建的设计良好、分区良好、稀疏耦合且高度内聚的代码库，那么这是可以的——这不是典型的情况，特别是当开发团队规模随着时间、距离和个人偏好而增长并重新构建代码结构时。

I'm currently working on projects in Flex and .NET. One of the nicer things about Flex is how few different ways there are to accomplish a standard thing - pull data from a database, open/close/read/write a file, etc. (Yet I'm using the Flex Builder/Eclipse IDE - a typical heavy-weight example like VS, because I'm still learning the basics and I need the training wheels. I expect to evolve back to vim once I'm confident of my patterns.) In this view, I can do what I need to do professionally by knowing a few things really really well.

OTOH, I can't imagine getting to that point with .NET because the view I'm expected to maintain keeps expanding and shifting. There much less conceptual integrity, and over several developers on a project over several months, much less consistency - but the IDE supports that, maybe encourages it. So the developer really needs to (and can more easily) know many more things adequately. Which also has the benefit of helping them answer (or even understand) a lot higher percentage of the questions on StackOverflow. I.e. we can have a deeper knowledge stack. And we can respond to a wider variety of help-wanted ads.

事情可能会朝着两个方向发展。也许对于“仅编辑器”作用域，这就像“如果你只有一把锤子，那么所有东西看起来都像钉子”。使用IDE方法，对于任何您想要固定在一起的东西，您都有广泛的紧固件和相关的工具范围可供选择- nals/锤子，螺钉/螺丝刀，螺栓/扳手，粘合剂/胶枪/夹子，磁铁等等-所有这些都在您的指尖(有向导帮助您开始)。

我使用Emacs作为开发和邮件/新闻的主要环境已经有大约10年了(1994-2004)。当我在2004年强迫自己学习Java时，我发现了IDE的力量，令我惊讶的是，我实际上喜欢IDE (IntelliJ IDEA)。

我不会详细说明原因，因为很多原因已经在这里提到过了——只要记住，不同的人喜欢不同的功能。我和一个同事使用同一个IDE，我们都只使用了可用功能的一小部分，我们都不喜欢彼此使用IDE的方式(但我们都喜欢IDE本身)。

但是我想强调的是ide相对于Emacs/Vim相关环境有一个优势:您可以花费更少的时间安装/配置所需的特性。

使用Wing IDE(适用于Python)，我可以在安装后15-20分钟开始开发。不知道我需要多少小时才能让我使用的特性在Emacs/Vim中运行。：）

我不明白你在问什么。你问“我应该使用IDE而不是……”，但我不明白替代方案是什么——Vim和Emacs实现了任何IDE都能提供的许多功能。它们唯一不能处理的方面是，一个更大的IDE可能是像UI设计器。然后，您的问题可以归结为“我应该使用哪种IDE”，并为更简单的Vim和Emacs领域提供了论据。

我更喜欢IDE，因为它允许我集成编辑/编译/调试，只需单击一下从错误跳转到生成错误的行。此外，它允许使用操作系统标准接口显示多个信息窗格。简而言之，它为用户提供了一个基于鼠标的输入界面和一个现代的输出界面，而不是依靠上世纪70年代的技术和界面来帮助我。

IDE还有更复杂的用户和用途，我并没有说我使用过他们或了解他们所有人。当我需要的时候，我会学习它们。

不要认为这是排他性的。使用IDE来获得它所提供的好处，当需要集中精力时切换到vim/首选的文本编辑器。

我发现IDE更适合重构、浏览、调试以及找出要做的事情。然后在IDE中完成小的事情，大的事情我切换到vim来完成。

除了其他答案之外，我喜欢使用类似于Eclipse的ViPlugin之类的东西，将IDE的开发能力与Vim的编辑能力结合起来。

我并不完全相信ide的使用。然而，我认为像Eclipse这样的优秀IDE最有价值的方面是良好集成的cscope风格的功能，能够快速理解大型代码库。

例如，在Eclipse中，您看到一个方法接受类型为FooBar的参数，但您不知道它的含义。与其浪费一分钟艰难地寻找定义(并冒着一路上各种分心的风险)，只需选择FooBar，按F3，它就会打开相关的源文件，直到FooBar被定义的那一行。

在我看来，ide的缺点是它们给了您一个更大的学习曲线，除非您想使用绝对默认的配置。(Emacs也是如此。)

我使用它的主要原因是当代码超过100个文件时。

虽然ctags可以完成这项工作，但一些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.

智能感知、集成调试器和即时窗口使我的工作效率大大提高(Visual Studio 2008)。有了一切触手可及的东西，我可以在写代码的时候把一个庞大项目的绝大部分都记在脑子里。微软可能一直在他们的操作系统上犯错，但是Visual Studio是有史以来最好的产品之一。

IDE可以让人更快更容易地工作……我注意到我花了很多时间在一个简单的文本编辑器中浏览代码……

在一个好的IDE中，如果IDE支持跳转到函数，跳转到之前的编辑位置，跳转到变量……此外，一个好的IDE可以减少试验不同语言特性和项目的时间，因为启动时间可以很短。

For me, an IDE is better because it allows faster navigation in code which is important if you have something in your mind to implement. Supposed you do not use an IDE, it takes longer to get to the destination. Your thoughts may be interupted more often. It means more clicks/more keys have to be pressed. One has to concentrate more on the thought how to implement things. Of course, you can write down things too but then one must jump between the design and implementation. Also, a GUI designer makes a big difference. If you do that by hand, it may take longer.

基于gui的ide(如Visual Studio和Eclipse)比基于文本的ide(如Emacs或vim)有几个优势，因为它们具有显示功能:

所见即所得预览和实时编辑的GUI设计 高效的属性编辑器(例如;使用GUI调色板选择颜色，包括定位渐变停止等) 代码概要、文件相互关系等的图形化描述 更有效地使用屏幕空间来显示断点、书签、错误等 更好的拖放支持操作系统和其他应用程序 集成编辑图纸、图像、3D模型等 显示和编辑数据库模型

基本上，使用基于gui的IDE，你可以在屏幕上获得更多有用的信息，你可以像查看文本部分一样轻松地查看/编辑应用程序的图形部分。

作为开发人员，最酷的事情之一是编辑一个计算一些数据的方法，并看到代码的实时输出以图形方式显示在另一个窗口中，就像你的用户在运行应用程序时看到的那样。现在，这就是所见即所得编辑!

基于文本的ide(如Emacs和vim)可以随着时间的推移添加代码补全和重构等特性，因此从长远来看，它们的主要限制是基于文本的显示模型。

It's really VERY simple. But this answer is a bit of a paradox in that I am discussing something only EMBEDDED level developers ever encounter. The reason this is an odd view is that frankly when I was doing embedded work (the brief time I was making any real money) an IDE would be down right STRANGE and most of your coworkers would wonder why you can't remember enough about SNMP/ASN.1 or whatever protocol you were dealing with to just /do your job/. BUT you can NOT, as far as I know, do a graphical simulation of what your microcontroller is doing in something like /real time/ without an "IDE".

对我来说，这只是我们在终端时代所做的一切的GUI版本。我一直认为IDE不是很优秀，因为它们隐藏了很多东西，特别是关于链接的东西，但在某些情况下，它们有一个显著的优势，例如与某些开发平台，如Qt。

有些IDE甚至可以在你输入代码时解析代码，并在你编译之前检测错误:从逻辑上看，似乎只有IDE可以与编译器紧密合作，立即检测类型化源代码中的问题。

我疯狂地回答IDE/命令行之争的存在只是因为C/ c++可执行的构建不是很好地处理从标准化的角度来看，不像D语言;每个平台都以自己的方式处理编译/链接等，所以为了不那么混乱，他们制作了一个IDE。

从你的角度来看，使用命令行可能会更简单，如果只有一个带有标准选项的编译器，那就很容易了，但事实是C/ c++是灵活的，所以最后，所有平台都用自己的方式来做，因此IDE不会浪费时间解释如何做。

如果您了解可执行文件如何与内核对话，或者如果您了解编译器设计，那么也许有一种方法可以使用合适的命令行，但我怀疑您没有。

微软或苹果，他们都是邪恶的，必须提出一种直接的方法来构建应用程序，而不需要进入细节，因为构建应用程序直接依赖于操作系统的架构，它很难像命令行那样是“标准的”。

把它放在简单、大而复杂的应用程序中，你不想深入研究它的功能——> IDE，小块软件或简单的系统软件设计——>命令行。当然，除了那些嵌入Makefile的漂亮的库，但那是另一个故事。

另外，我认为IDE是在应用程序与GUI或有接口或直接绑定到操作系统的东西有关时使用的，所以，它也适用于那些使用UI/GUI但不知道它如何工作的人，而那些编写系统程序的人不需要它。

IDE只是现代的垃圾，但我认为在100年内命令行还会存在。

我也几乎只使用Vim(几乎是因为我现在正在尝试学习emacs)来完成我的所有开发工作。我认为纯粹的直观性(当然来自GUI)是人们喜欢使用ide的主要原因。通过直观，几乎不需要学习工具的开销。学习开销越少，他们完成的工作就越多。