To IDE or not to IDE?

[Stewbond]

I sometimes come across code that has never to my knowledge been loaded into an IDE. I'd usually rather bang my head against a wall for 8 hours than deal with a project like this in notepad++, so usually I just import it into visual studio.

It's come to my attention that many of you masochists like to work this way too:

Someone wrote:

I don't use an IDE. I write my C++ code ... in text files using a text editor.

I am now absolutely dependent on my mouseovers to check object types, and my Right-Click...Go To Definition. I'm even becoming partial to the little red squiggle that VS2010 puts under your errors before you compile.

What are the advantages to working outside of an IDE?

If you find that the advantages are worth it, how do you work on a 30+ file project where you can't easily trace where objects are going?

[moorecm]

For what it's worth, I use Vim. I wouldn't quite call it an IDE but I have a good number of IDE-like features turned on or otherwise integrated into it.

I work on very, very large projects. The one I'm working on currently has this many files:

$ find . | wc -l
612329
$

[Cubbi]

The last time I used an IDE was on a brief Win32/MFC project in early 2002 (it was hard to find programming jobs at the time). Normally, my code compiles and runs on a small variety of unix-style systems and is written "in text files using a text editor". Granted, modern vim has a lot of your typical IDE functions -- syntax highlighting, integrated building, jumping to errors, jumping to identifiers, folding, etc -- but there's almost never a need to use them.
(number of files in the current project that I personally wrote: 944. Not sure what "tracing where objects are going" means)

[Catfish]

If you find that the advantages are worth it, how do you work on a 30+ file project where you can't easily trace where objects are going?

OOP puts a high emphasis on design before even starting to code.
You can use the traditional paper and pen, and then store the design in your mind.
So I imagine that if you find it hard "tracing where the objects are going", you're maintaining code that's not yours, and is also poorly documented?

Anyway, I guess it's safe to say that those who don't use an IDE, simply don't need it.

[Stewbond]

You guys obviously work differently than I do.

Cubbi wrote:

Not sure what "tracing where objects are going" means

It means that if I am debugging and I find the offending variable, I need to find out where that variable is set. That means finding all of the references of that variable in my solution and checking which are assignments, starting from the declaration. This is easy in visual studio. If I were to do this with text editors, it'd take me forever as searching 612329 files in (at least in Windows) would take forever meanwhile everything is indexed in my IDE. Perhaps this is where Linux becomes strong for developers.

[chrisname]

For C, C++, asm, Python, HTML/CSS/JavaScript/PHP, etc. I use a text editor (usually gedit) + command-line most of the time. For C# I use MonoDevelop.

I don't like IDEs that much, though I really like MonoDevelop for C#. If I found something as good as or better than MonoDevelop for other languages then I'd probably use it for most of my projects.

Stewbond wrote:

how do you work on a 30+ file project where you can't easily trace where objects are going

If you can't tell what code is in which file just by the path, you're doing it wrong.

Let me give you an example. I have a smallish project (about 3.5 kLOC) which is (the start of) a basic OS kernel (I'm using information from the Internet to learn how to write one as I go). It has 43 source files. But because of the way I've split up the source tree, I can easily tell where any given function is.

It looks like this:

X:\Projects\OSDev\Myelin\src\
├───common
│   ├───mem
│   ├───boot
│   ├───kernel
│   └───libc
└───arch
    └───i386
        ├───mem
        ├───boot
        │   └───head
        ├───kernel
        └───libc

The include folder is almost identical, it just doesn't have the 'head' directory.

mem is the memory manager, boot is all code that runs during the boot procedure, libc is the C standard library (I have to implement everything I need because I can't use userspace code in my kernel) and kernel is everything else. There will be a separate directory for modules when I get that far.

[LB]

To IDE.

[1vRz3TCk]

Both.

It partly depends on what system I'm working on and the size of the solution (a projects of projects if you like) or individual project. For some reason I don't like working without an IDE on Windows.

[Stewbond]

@Catfish, You're right. Most of the code I go through isn't mine. I tend to do more debugging than writing, especially when a project is deployed and that particular programmer has left the organization or is working on different projects. I don't think I've ever seen documentation stored with source code ( I try and make my headers self-documenting).

When I come accross code written in an IDE, I can ussually find my way around very quickly and solve the issue within a reasonable amount of time. But if I have to use something written with a non-IDE methodology, it always takes me longer. Most of that time is just spent familiarizing myself with the layout of everything and what could possibly go where.

@chrisname, I like your explanation of using the folder structures to sort things in a clear way. I consistently find projects with 30+ files in a single folder and each having 40+ character names. Reading through the directory is like reading a book.

Enough whining for me. The conclusion is that source-code without an IDE needs to be well organized and documented. If that can be done, then it can be just as powerful. I might try making my next few projects in this fashion to see if I like it.

[chrisname]

I'm very well organised on a computer but in real life my organisation is terrible. It seems to be the other way around for most people.

[TheMassiveChipmunk]

IDEs are nice but not what I want. I used to use Visual Studio then to Code blocks but then I found Emacs. Emacs was exactly what I was looking for. Emacs text editing experience is what makes it so powerful. With Emacs you can cut your typing time in half. I like Vi's philosophy and way of doing things but Emacs had taken my heart so I could not bring myself to switch. The only thing I can complain about Emacs is that is not installed by default on most Linux distributions.

[rapidcoder]

My list of important IDE features:
1. interactive error underlining, including type error checking - saves lots of time for compilation
2. code completion working for methods, types, templates and just everything language supports
3. navigation support in code (go to definition)
4. documentation popup
5. refactoring
6. debugging would be nice, but I can easily get with printf debugging - most C++ debuggers can't grok templates, so they are pretty useless

The problem is, there exist no C++ IDE supporting all of these. I really wish there existed a C++ IDE capable of doing at least half the things that e.g. Visual Studio + Resharper can do for C#, or IntelliJ IDEA / Eclipse can do for Java.

[xander333]

Code::Blocks for me, I never understood how people could prefer a text editor over an IDE.
It must be a pain to compile each time!

[Athar]

Makefiles make compiling easy enough, but rather, it must be a pain to write the code. In the absence of code completion, do you actually type out identifiers with 20+ letters?
It turns out people actually don't, which results in them choosing identifiers that have 2-3 letters in average. In other words, you might just as well have put the code through an obfuscator. The next person to work on your code -this might be you again- will (not) thank you for it.

[1vRz3TCk]

...but rather, it must be a pain to write the code. In the absence of code completion, do you actually type out identifiers with 20+ letters?

A good text editor outside of an IDE does the same as a good text editor inside an IDE.

[rapidcoder]

A good text editor outside of an IDE does the same as a good text editor inside an IDE.

If it does the same as IDE, it *is* IDE.
For example to provide code completion and refactoring, the text editor has to understand the structure of the project. Not just operate on a single file. And if it lets you organize files in "projects", then it is already an IDE.

Makefiles make compiling easy enough

Makefiles are ok if they are generated by IDEs. Otherwise, editing Makefiles by hand is a pain (and they invented autoconf and automake to handle that pain, yet creating even more pain). Makefiles are artifact from ancient times, when compilers were dumb enough not to understand module dependencies. Probably no language except C and C++ needs them.

[1vRz3TCk]

rapidcoder wrote:

If it does the same as IDE, it *is* IDE.
For example to provide code completion and refactoring, the text editor has to understand the structure of the project. Not just operate on a single file. And if it lets you organize files in "projects", then it is already an IDE.

So, say BBedit is an IDE? I think not.

[rapidcoder]

So, say BBedit is an IDE? I think not.

Yes it is. IDE = Integrated Development Environment. Or, even if you don't think so, it is very close to what any IDE provides:
- code folding
- code completion
- scripting support
- syntax highlighting
- projects
- automatic deployment support (FTP, etc.)

To me it looks like a fully fledged IDE for HTML developers.

[1vRz3TCk]

rapidcoder,

Wow, you must have very low expectations of an IDE if you think that a text editor is one.

Your list above is good for a source code editor but is lacking as an IDE. Would you not want things like a compiler, build automation tools, a debugger, etc. in your IDE?

[rapidcoder]

Your list above is good for a source code editor but is lacking as an IDE. Would you not want things like a compiler, build automation tools, a debugger, etc. in your IDE?

BBEdit is an IDE for HTML. Of course it has to have a different toolset than an IDE for C++. Why anyone would need a debugger and compiler for HTML? Or why would you need a "preview in browser" for a C++ IDE? :D

Anyway, it has scripting support, so it is easy to fire up make / ant / maven / sbt whatever to build and run the project.

Code completion, error highlighting and refactoring tools are probably the most important features for me that affect productivity. They are also the hardest to get right, and none of the C++ IDEs got to the point where all three work seamlessly. Usually they break on heavily templated code or on macros.

All the rest (including a debugger) is a minor convenience. Oh, I can't remember when I debugged something for more than 5 minutes. Usually I catch most of the bugs just by looking at the code, and the rest by printf debugging, which is still more powerful debuggind technique than the most advanced debugger (because it records the whole sequence, why debuggers usually allow you to look at the single state of the program).