在另一个问题中,Mark高度评价了ide,说“有些人仍然不知道”为什么“他们应该使用一个……”。作为一个使用vim进行编程的人,并且在大多数/所有同事都使用vim或emacs进行所有工作的环境中工作的人,ide的优势是什么?我为什么要用它?

我相信这对一些人来说是一个棘手的问题,我对开始一场论战不感兴趣,所以请只回复你认为基于ide的方法更好的原因。我对听到为什么我不应该使用IDE不感兴趣;我已经不用了。可以这么说,我感兴趣的是听取“栅栏的另一边”的意见。

如果您认为ide可能适合某些类型的工作,但不适合其他类型的工作,我也很想知道为什么。


当前回答

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

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

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

其他回答

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

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

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

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

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

我从相反的方向来回答这个问题。我从小就在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提供了比简单编辑器更省时的特性。

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

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

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