You may be tempted to recommend Dev-C++ to a beginner, or you may be a beginner tempted to use it.

Stop.

It’s 2011. Dev-C++ is not in development since 2005. Its latest version is a beta, and as you code, its beta status will be felt. Here is a short list of why a beginner should not use Dev-C++, and why he will not miss it after no longer being a beginner. Of course, this is also a list of reasons why competent and advanced coders should not use it. (Update March 28 2012: Here’s an additional opinion from way back in 2008.)

(in subjective order of importance)

1. Horrible auto-indentation
A beginner is still learning. A beginner will not know how to format code properly. Minimum of proper code formatting will have to be explained up to 10 times before the beginner will start properly formatting the code.

Having poor auto-indenation means someone will have to constantly review beginner’s code and correct its formatting. Having poor auto-indentation will slow down an advanced developer since he will have to fight the poor built in capabilities constantly.

Disabled indentation would be better than what Dev-C++ has.

2. Bad auto-completion
Dev-C++ can’t recognize many language constructs. Sometimes it will show senseless tooltips. It especially becomes noticeable once you try another IDE.

3. “Unhandled exception”
Dev-C++ is developed in Delphi, and what would crash other programs, sometimes allows Dev-C++ to live. But, it still throws warnings at weirdest times.

4. Debugger UI is a joke
Sometimes it works, sometimes it doesn’t. Half the time you need to open debugger console and manually talk with GDB to get anything done (even things like backtrace).

5. Horrible dependency tracking in the build system
While only important if you are a large project developer, note that by default, Dev-C++ will be horrible at tracking which headers are important for a particular implementation file (by which I mean .c and .cpp files); it won’t track it at all. If you change a header that you use in many places, a full rebuild is in order. If you turn on full dependency tracking, you’ll face somewhat reliable, but abysmally slow dependency tracking.

What’s wrong with this? You could be changing a class declaration in a header, but most implementation files that depend on this header will not be rebuilt, causing the program to crash at weirdest places, or work incorrectly, until full rebuild is performed.

6. Files used not by path, but by filename
Again important for projects. This means you cannot have two files of same name in the same project, placed in different directories.

7. Single-platform
When you can have such excellent IDEs such as Code::Blocks, or to a lesser extent CodeLite, and use same project files on multiple platforms, why restrict yourself to an IDE that appreciates only Windows?

/////////////////////////
All of the above mean that an experienced developer will needlessly suffer, and a beginner will learn incorrectly, or be wondering what went wrong. While Dev-C++ could have become an excellent IDE over the years (which is why back in 2005 and 2006 I extensively used it), its development has stopped.

You should not be using deprecated beta software. You should not be recommending software that might teach incorrect practices to a beginner. You should not lose your precious time on wrestling with the IDE just to retain some semblance of order in code.

Recommended C++ IDEs:
– Xcode – for Mac OS X developers; you don’t need to switch to Windows to learn or to develop quality software
– Code::Blocks – perfect for developing Windows and cross platform code
– CodeLite – while my personal impressions of CL are not as good as of C::B, still a nice IDE
– Visual C++ Express – 2005, 2008 and 2010 are quite nice free offerings from Microsoft; I don’t personally like them, but they’re reasonably good if you are into MS software

–
via blog.vucica.net