为什么我应该使用IDE?

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

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

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

拥有IDE有以下优势:

• 编译通常是“动态的”，这意味着不再切换到命令行进行编译
• 调试是集成的，在IDE中拥有调试意味着步进调试器实际上使用就地编辑器来直观地显示执行了哪些代码
• IDE通常对您正在使用的语言具有更多的语义知识，并且可以在输入时向您显示可能出现的问题。重构比“搜索替换”强大得多。

还有很多，也许你应该试试。

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

• 快速导航到类型，而不需要担心名称空间，项目等
• 通过将成员视为超链接来导航到成员
• 当你不能记住所有成员的名字时自动补全
• 自动代码生成
• 重构(大规模重构)
• 组织导入(在Java中自动添加适当的导入，使用c#中的指令)
• 输入时警告(例如，有些错误甚至不需要编译周期)
• 一直在看医生
• 以一种有用的方式同时在屏幕上查看文件、错误/警告/控制台/单元测试等以及源代码
• 易于从同一窗口运行单元测试
• 集成调试
• 集成源控制
• 直接从错误详细信息导航到发生编译时错误或运行时异常的位置。
• 等等!

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

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

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

   最后，它帮助我更快地编写代码，而不是在记事本或写字板上。这是我更喜欢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，如果他们主要使用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建模工具等工具。所有这些东西都可以单独使用，但是将它们都放在同一个开发环境中可以节省大量时间，并使开发过程更有效地进行。

我不确定文本编辑器和IDE之间是否有明确的分界线。你在天平的一端有像记事本这样的东西，在另一端有最好的现代ide，但在两者之间还有很多东西。大多数文本编辑器都有语法高亮显示功能;针对程序员的编辑器通常具有各种其他功能，例如易于代码导航和自动完成。Emacs甚至允许集成调试器。即使是十年前的ide所提供的帮助程序员的功能，也远不及如今的文本编辑器所具备的功能。

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

我目前正在用Flex和。net开发项目。Flex的一个优点是，完成一件标准的事情只有很少的不同方法——从数据库中提取数据，打开/关闭/读取/写入文件，等等(然而我正在使用Flex Builder/Eclipse IDE——一个典型的重量级示例，像VS，因为我还在学习基础知识，我需要辅助轮。一旦我对我的模式有了信心，我希望能进化回vim。)从这个角度来看，我可以通过非常非常了解一些事情来做我需要做的专业工作。

哦，我无法想象用。net就能达到这一点，因为我希望保持的视图一直在扩展和变化。概念上的完整性要低得多，而且几个开发人员在一个项目上花费几个月的时间，一致性也要低得多——但是IDE支持这一点，也许鼓励它。因此，开发人员确实需要(而且可以更容易地)充分了解更多的东西。这也有帮助他们回答(甚至理解)StackOverflow上更高比例的问题的好处。也就是说，我们可以有更深层次的知识。我们可以对各种各样的招聘广告做出反应。

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

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

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

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

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

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

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

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

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

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

除了其他答案，我喜欢将IDE的发展中功能与Vim的编辑功能结合起来，使用类似ViPlugin的Eclipse。

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

例如，在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，这对我来说已经变得非常高效。

在我最初的自学、大学和现在的职业生涯中，我逐渐认识到，任何仅在IDE中进行的主要软件开发都会适得其反。我这么说是因为大多数IDE都希望你在他们的特有的我控制世界如何工作的风格下工作。你必须按照他们的思路来划分你的项目。您已经使用它们奇怪的对话框管理您的项目构建。大多数IDE对项目间复杂的构建依赖关系的管理很差，依赖关系很难100%工作。我曾经遇到过这样的情况，IDE不会生成我的代码的工作构建，除非我做了一个清洁/重建所有。最后，很少有一种干净的方法可以将软件从开发转移到其他环境中，比如从IDE转移到QA或生产环境中。构建所有的部署单元通常是一场点击盛宴，或者您有IDE供应商提供的一些笨拙的工具来捆绑东西。但是同样，该工具通常要求您的项目和构建结构完全符合它们的规则——有时这并不适合您的项目需求。

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

手动构建需要我们错过现代IDE中的一些细节，如后台编译，但我们获得的是更关键的:可以在多个环境中生存的干净和简单的构建。那些敏捷人士谈论的“一键构建”?我们有。我们的构建脚本也可以被持续集成系统直接调用。通过持续集成管理构建可以让我们更正式地部署并将代码部署迁移到不同的环境，并且当有人检入破坏构建或单元测试的坏代码时，可以让我们几乎立即知道。

事实上，我从IDE中夺走构建的角色并没有对我们造成太大的伤害。Eclipse中的智能感知和重构工具仍然非常有用和有效——后台编译只是支持这些工具。而且，Eclipse特有的项目切片是一种很好的方法，可以在精神上以一种每个人都能理解的方式分解我们的问题集(尽管对我来说还是有点啰唆)。我认为关于Eclipse最重要的事情之一是出色的SCM集成，这就是使团队开发如此愉快的原因。我们使用Subversion+Eclipse，这非常高效，而且很容易培训我们的员工成为这方面的专家。

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

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

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

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

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

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

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

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

对我来说，这只是我们在终端时代所做的一切的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的主要原因。通过直观，几乎不需要学习工具的开销。学习开销越少，他们完成的工作就越多。