[ACCEPTED]-Why should I use an IDE?-ide

It really depends on what language you're 4 using, but in C# and Java I find IDEs beneficial 3 for:

• 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!

All of these save time. They're things 2 I could do manually, but with more pain: I'd 1 rather be coding.

Code completion. It helps a lot with exploring 1 code.

The short answer as to why I use an IDE 16 is laziness.

I'm a lazy soul who doesn't 15 like to do things a difficult way when there 14 is an easy way to do it instead. IDE's make 13 life easy and so appeal to us lazy folk.

As 12 I type code, the IDE automatically checks 11 the validity of the code, I can highlight 10 a method and hit F1 to get help, right click 9 and select "go to to definition" to jump 8 straight to where it is defined. I hit one 7 button and the application, with debugger 6 automatically attached is launched for me. And 5 so the list goes on. All the things that 4 a developer does on a day to day basis is 3 gathered under one roof.

There is no need 2 to use an IDE. It is just much harder work 1 not to.

I don't think it's fair to do the classic 12 "text editor and console window vs IDE" when 11 "text editor" is really emacs. Most features 10 that are typical for IDE:s are also in emacs. Or 9 perhaps they even originated there, and 8 modern IDE:s are mainly interface improvements/simplifications.

This 7 means that for the original question, the 6 answer is not so clear-cut. It depends on 5 how people at the site in question use emacs, if 4 they mainly use it as a text editor, or 3 if they go all out and use custom scripting, learn 2 the commands for the relevant modes, know 1 about code tagging and so on.

I come at this question from the opposite 75 direction. I was brought up in programming 74 with very few pitstops in Makefile+Emacs 73 land. From my very earliest compiler on 72 DOS, Microsoft Quick C, I had an IDE to 71 automate things. I spent many years working 70 in Visual C++ 6.0, and as I graduated into 69 Enterprise Java, I worked with Borland JBuilder 68 and then settled on Eclipse, which has become 67 very productive for me.

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

I have learned that, to 40 do large-scale development with a team, we 39 can be the most productive if we develop 38 our code using an IDE and do all of our 37 builds using manually written command line 36 scripts. (We like Apache Ant for Java development.) We've 35 found that running our scripts out of the 34 IDE is just a click fest or an automation 33 nightmare for complex builds, it's much 32 easier (and less disruptive) to alt+tab 31 out to a shell and run the scripts there.

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

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

Being the author of the response that you 18 highlight in your question, and admittedly 17 coming to this one a bit late, I'd have 16 to say that among the many reasons that 15 have been listed, the productivity of a 14 professional developer is one of the most 13 highly-regarded skills.

By productivity, I 12 mean the ability to do your job efficiently 11 with the best-possible results. IDEs enable 10 this on many levels. I'm not an Emacs expert, but 9 I doubt that it lacks any of the features 8 of the major IDEs.

Design, documentation, tracking, developing, building, analyzing, deploying, and 7 maintenance, key stepping stones in an enterprise 6 application, can all be done within an IDE.

Why 5 you wouldn't use something so powerful if 4 you have the choice?

As an experiment, commit 3 yourself to use an IDE for, say, 30 days, and 2 see how you feel. I would love to read your 1 thoughts on the experience.

Having an IDE has the following advantages:

• Compiling is usually "on the fly" which means no more switching to the command line to compile
• Debugging is integrated, and having that in an IDE means that the step debugger actually uses your in-place editor to visually show you which code is executed
• IDE's usually have more semantic knowledge of the language you're working in, and can show you possible problems while typing. Refactoring is much more powerfull than the "search replace".

There 2 are much more, maybe you should give it 1 a try.

IDEs are basically:

• Editor w/code completion, refactoring and documentation
• Debugger
• Filesystem explorer
• SCMS client
• Build tool

all in a single package.

You 15 can have all this (and some more) using 14 separate tools or just a great programmable 13 editor and extra tools, like Emacs (Vim 12 as well but has a little less IDEbility 11 IMO).

If you find yourself switching a lot 10 between one utility and the next that could 9 be integrated in the environment or if you 8 are missing some of the abilities listed 7 here (and more completely in other posts), maybe 6 it's time to move to an IDE (or to improve 5 the IDEbility of your environment by adding 4 macros or what not). If you have built yourself 3 an 'IDE' (in the sense I mention above) using 2 more than one program, then there's no need 1 to move to an actual IDE.

Eclipse:

Having code higlighting, compiling 20 in the background, pointing out my errors 19 as I go along.

Integration with javadoc, suggesting 18 variable names with ctrl-Space.

When I compile, I 17 get errors right there. I can double click 16 on an error, and it displays the appropriate 15 line.

Really well integrated with JUnit, ctrl-F11 14 runs the test, tells me the tests have failed. If 13 there is an exception in the output window, I 12 can double click on a line, and takes me 11 to the line that failed. Not only that, but 10 ctrl-F11 makes sure everything is compiled 9 before it runs the tests (which means I 8 never forget to do that).

Integration with 7 ant. One command to build and deploy the 6 application.

Integration with debuggers, including 5 remote debugging of web servers.

FANTASTIC 4 refactoring tools, searching for references 3 to a section of code. Helps me know the 2 impact of a change.

All in all, it makes 1 me more productive.

I have used Emacs as my primary environment 20 for both development and mail/news for about 19 10 year (1994-2004). I discovered the power 18 of IDEs when I forced myself to learn Java 17 in 2004, and to my surprise that I actually 16 liked the IDE (IntelliJ IDEA).

I will not go into specific 15 reasons since a lot of them have already 14 been mentioned here -- just remember that 13 the different people love different features. Me 12 and a colleague used the same IDE, both 11 of us used just a fraction of the features 10 available, and we disliked each others way 9 of using the IDE (but we both liked the 8 IDE itself).

But there is one advantage with 7 IDEs over Emacs/Vim related environments 6 I want to focus on: You spend less time 5 installing/configuring the features you 4 want.

With Wing IDE (for Python) I'm ready to start 3 developing 15-20 minutes after installation. No 2 idea how many hours I would need to get 1 the features I use up and running with Emacs/Vim. :)

It definitely leads to an improvement in 21 productivity for me. To the point where 20 I even code Linux applications in Visual 19 Studio on Vista and then use a Linux virtual 18 machine to build them.

You don't have to 17 memorize all of the arguments to a function 16 or method call, once you start typing it 15 the IDE will show you what arguments are 14 needed. You get wizards to set project properties, compiler 13 options, etc. You can search for things 12 throughout the entire project instead of 11 just the current document or files in a 10 folder. If you get a compiler error, double-click 9 it and it takes you right to the offending 8 line.

Integration of tools like model editors, connecting 7 to and browsing external databases, managing 6 collections of code "snippets", GUI modeling 5 tools, etc. All of these things could be 4 had separately, but having them all within 3 the same development environment saves a 2 lot of time and keeps the development process 1 flowing more efficiently.

There might be different reasons for different 5 people. For me these are the advantages.

1. Provides an integrated feel to the project. For instance i will have all the related projects files in single view.
2. Provides increased code productivity like
   1. Syntax Highlighting
   2. Referring of assemblies
   3. Intellisense
   4. Centralized view of database and related UI files.
   5. Debugging features

End 4 of the day, it helps me to code faster than 3 i can do in a notepad or wordpad. That is 2 a pretty good reason for me to prefer an 1 IDE.

An IDE can be a 'superior' choice based depending 17 upon what a developer is trying to accomplish.

A 16 text editor can be 'superior' because IDEs 15 are typically geared toward one (or a small 14 selection) of languages.

If a developer 13 spends most of his/her time in a single 12 languge or a 'cluster' of related languages 11 (like C# and T-SQL), in one OS, then the 10 GUI design, debug, intellisense, refactoring 9 etc. tools offered by a good IDE can be 8 very compelling. If, for instance, you 7 spend most of your time working in VB.NET, with 6 maybe a little T-SQL now and then, in a 5 Windows environment, then you'd be pretty 4 silly to not look at Visual Studio or a 3 comparable IDE.

I have no prejudice towards 2 those who prefer IDEs or text editors, both 1 can be very productive and useful if learned well!

I think it has mostly to do with scope of 56 awareness for the developer. The IDE provides 55 a macroscopic view of the developer's work 54 context. You can simultaneously see class 53 hierarchies, referenced resources, database 52 schemas, SDK help references, etc. And with 51 so many things affected by, and affecting, your 50 keystrokes, and the expanding volume of 49 architectures and architectural intersections, it 48 gets more and more difficult to work solely 47 from one island of code at a time.

OTOH, "just 46 me and vim and the man pages" gives me a 45 much leaner microscopic - but intense and 44 precise - view of my work. This is ok if 43 I have a well-designed, well-partitioned, sparsely 42 coupled highly cohesive codebase built in 41 one language with one set of static libraries 40 to work from - not your typical situation, especially 39 as dev team sizes grow and reshape the code 38 structure over time, distance, and personal 37 preference.

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

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

Things can go too far in both directions. Maybe 9 with the "editor-only" scope, it's like 8 "if you only have a hammer, everything looks 7 like a nail". With the IDE approach, for 6 whatever you want to fasten together, you 5 have a broad selection of fasteners and 4 associated ranges of tools to choose from 3 - nals/hammers, screws/screwdrivers, bolts/wrenches, adhesives/glue-guns/clamps, magnets, and 2 on and on - all at your fingertips (with 1 a wizard to help you get started).

Don't think of it as exclusive. Use the 7 IDE for the benefits it provides, and switch 6 to vim/preferred text editor when you need 5 some serious focus.

I find the IDE better 4 for refactoring and browsing and debugging 3 and for figuring out what to do. Small things 2 are then done right in the IDE, large things 1 I flip to vim to finish the job.

In addition to the other answers, I love 3 combining the developing power of an IDE with the 2 editing power of Vim using something like the ViPlugin for 1 Eclipse.

IntelliSense, the integrated debugger, and the immediate 7 window make me enormously more productive 6 (Visual Studio 2008). With everything at my fingertips, I 5 can keep the vast majority of an enormous 4 project inside of my head while writing 3 code. Microsoft may keep dropping the ball 2 on their OSs, but Visual Studio is one of 1 the finest products ever developed.

I do not understand what you are asking. You 9 ask "Should I use an IDE instead of...", but 8 I don't understand what the alternative 7 is - Vim and Emacs fulfil many functions any 6 IDE will give you. The only aspect they 5 do not handle that a larger IDE may are 4 things like UI designers. Then your question 3 boils down to simply "what IDE should 2 I use" with arguments to be made for 1 the simpler realm of Vim and Emacs.

A couple of reasons I can think of for using 2 an IDE:

• Integrated help is a favorite.
• The built-in Refactor with Preview of the Visual Studio
• IntelliSense, syntax hightlighting, ease of navigation for large projects, integrated debugging, etc. (although I know with addins you can probably get a lot of this with Emacs and Vim).
• Also, I think IDEs these days have a wider user-base, and probably more people developing add-ins for them, but I might be wrong.

And quite frankly, I like my mouse. When 1 I use pure text-based editors it gets lonely.

An IDE allows one to work faster and more easily... I 8 noticed I spent a lot of time navigating 7 in the code in a simple text editor...

In 6 a good IDE, that time goes down if the IDE 5 supports jumping to functions, to previous 4 editing position,to variables... Also, a 3 good IDE reduces the time to experiment 2 with different language features and projects, as 1 the start-up time can be small.

GUI-based IDEs like Visual Studio and Eclipse 17 have several advantages over text-based 16 IDEs like Emacs or vim because of their 15 display capabilities:

• WYSIWYG preview and live editing for GUI design
• Efficient property editors (eg. color selection using a GUI palette, including positioning gradient stops etc)
• Graphical depiction of code outlines, file interrelationships, etc
• More efficient use of screen real-estate to show breakpoints, bookmarks, errors, etc
• Better drag and drop support with OS and other applications
• Integrated editing of drawings, images, 3D models, etc
• Display and edit of database models

Basically with a GUI-based 14 IDE you can get more useful information 13 on screen at once and you can view/edit 12 graphical portions of of your application 11 as easily as text portions.

One of the coolest 10 things to experience as a developer is editing 9 a method that computes some data and seeing 8 the live output of your code displayed graphically 7 in another window, just as your user will 6 see it when you run the app. Now that's 5 WYSIWYG editing!

Text-based IDEs like Emacs 4 and vim can add features like code completion 3 and refactoring over time, so in the long 2 run their main limitation is their text-based 1 display model.

I also almost exclusively use Vim (almost 8 because I'm trying to learn emacs now) for 7 all my development stuff. I think sheer 6 intuitiveness (from the GUI of course) is 5 the primary reason why people like to use 4 IDEs. By being intuitive, little to no learning 3 overhead of the tool is required. The lesser 2 the learning overhead, the more they can 1 get work done.

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

My main reason to use one is when the code 5 goes beyond 100 files.

Although ctags can 4 do the work, some IDEs have a pretty good way to 3 navigate the files easily an super fast.

It 2 saves time when you have a lot of work to 1 do.

To me it's just the the GUI version of everything 51 we did in the good old days of the terminal. I 50 will always agree that IDE are not very 49 superior because they hide a lot of stuff, especially 48 concerning the linking stuff, but they have 47 a notable advantage in some cases, for example 46 with certain development platforms like 45 Qt.

Some IDE like visual of others even seem 44 to parse your code as you type it, and detect 43 errors before you even compile: it seems 42 logics that only an IDE can work closely 41 with a compiler to immediately detect problem 40 in the typed source.

My wild answer that 39 the IDE/Command-line flame war exists is 38 just because the C/C++ executable building 37 is not very well handled from a standardized 36 point of view, unlike with the D language; every 35 platform handles compiling/linking/etc its 34 own way, so to make it less messy they make 33 an IDE.

From your viewpoint it might be more 32 simple to use the command-line, if there 31 would have been only one compiler with standard 30 options, it would have been easy, but the 29 truth is C/C++ is flexible, so in the end, all 28 platform do it their own way, hence the 27 IDE to not waste explaining how to do it.

If 26 you can learn how an executable talks to 25 the kernel or if you know anything about 24 compiler design, maybe there is a way to 23 work with a proper command-line, but I doubt 22 you have.

Microsoft or Apple, all evil they 21 would be, have to propose a straight-forward 20 way to build application without entering 19 in the details, and since building an application 18 depends directly on the architecture of 17 the OS, it will hardly be "standard" as 16 the command-line is.

To put it simple, big 15 and complex applications where you don't 14 want to dig too deep into what it does -> IDE, little 13 pieces of software or simple system software-design 12 -> command-line. Except of course those 11 nifty libraries that embed a Makefile, but 10 that's another story.

Also I think IDE are 9 used when the application delivered has 8 something to do with, ironically, a GUI 7 or something that has an interface or is 6 directly bound to an OS, so again, it's 5 also for people who will use a UI/GUI without 4 knowing how it works, while people who will 3 program systems won't need it all.

IDE is 2 just modern shit, but I think in 100 years 1 the command-line will still exist.

Saves time to develop
Makes life easier 3 by providing features like Integrated debugging, intellisense.

There 2 are lot many, but will recommend to use 1 one, they are more than obvious.

I like an IDE because it puts a lot of functionality 7 at my fingertips. Editing/Compilation/visibility 6 of files in the project are all things I 5 value in an IDE. I use Visual Studio now 4 but in a former life I used SlickEdit and 3 found that it made my development process 2 more streamlined than when I wasn't using 1 it.

There's only one thing to consider when 3 deciding whether to use an IDE or not, and 2 that's whether it makes you more productive 1 or not.

Short question so short answer :)

It depends highly on what you're doing and 10 what language you're doing it in. Personally, I 9 tend to not use an IDE (or "my IDE consists 8 of 3 xterms running vim, one running a database 7 client, and one with a bash prompt or tailing 6 logs", depending on how broadly you define 5 "IDE") for most of my work, but, if I were 4 to find myself developing a platform-native 3 GUI, then I'd reach for a language-appropriate 2 IDE in an instant - IMO, IDEs and graphical 1 form editing are clearly made for each other.

An IDE handles grunt work that saves you 9 time.

It keeps all associated project files 8 together which makes it easy to collaborate.

You 7 can usually integrate your source control 6 into your IDE saving more grunt work and 5 further enhancing collaboration.

If it has 4 auto complete features, it can help you 3 explore your language of choice and also 2 save some typing.

Basically, an IDE reduces 1 non-programming work for the programmer.

I'm not entirely sold on the use of IDEs. However, I 16 think that the most valuable aspect of a 15 good IDE, like Eclipse, is the well-integrated 14 Cscope-style functionality rapid comprehension 13 of a large code base.

For example, in Eclipse, you 12 see a method takes an argument of type FooBar, yet 11 you have no idea what it means. Rather than 10 waste a minute finding the definition the 9 hard way (and risk all sorts of distractions 8 along the way), just select FooBar, hit 7 F3, and it opens the relevant source file 6 to the very line that FooBar is defined.

The 5 downside of IDEs, in my opinion, is that 4 they give you a bigger learning curve, except 3 in the case in which you want to use the 2 absolutely default configuration. (This 1 is true for Emacs as well.)

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

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

Simply put, an IDE offers additional time-saving 1 features over a simple editor.

I prefer an IDE because it permits me to 12 integrate editing/compiling/debugging, with 11 a 1-click jump from error to line generating 10 the error. Further, it permits multiple 9 panes of information with OS-standard interfaces 8 displaying the information. In short, it 7 gives the user a mouse-based input interface 6 with a modern output interface instead of 5 relying on 1970s technology and interfaces 4 for my help.

There are more sophisticated 3 users and uses for an IDE, I don't claim 2 to use them or to know them all. When I 1 have need, I will learn them.