Programming Tools You've Used?

crazy_speeder asks: "I'm looking for programming tools for the whole development cycle, including documentation. The project I'm working on will use C++ and Java. What has been your experience using tools like C++ Builder, Netbeans, Eclipse, JBuilder, Doxygen, ClearQuest, Rational Rose, g++, and any compiler, debugger, or IDE that you may have used. I need tools that will handle auto documentation, unit testing, design, file editing, and the like. As far as platform goes, Linux is the target OS while Linux or Solaris will be the host OS."

Comments

Nothing is perfect, but...

[Undertaker43017]

Avoid NetBeans, I had nothing but trouble with it. JBuilder is good if you can afford the commerical versions, since the free versions are pretty much useless. Eclipse is probably the best free IDE, and with C++ plugin I find it more than capable for what I need.

IMO Together is much better than RR, they both cost about the same, which is the serious downside to both. If you are only doing forward engineering I would consider ArgoUML. Argo does decent forward engineering, but it's reverse engineering leaves a lot to be desired. If you have to do any reverse engineering, none of the free UML tools I looked do a decent job of it. In fact Rose isn't even very good at reverse engineering.

Doxygen works well for documenting C++, I wish the output was MORE Javadoc like.

If you are doing a lot of C++ coding get a code memory/bounds checker. Commerically Purify is stll the best, IMO. There are also some good free options, sorry I can't remember the ones I looked at though.

Uniting testing I use junit for Java. There is cppunit for C++, I haven't tried it though so I can't say how good it is.

Maven is very useful for project management duties.

Re:Learn to write your own documentation.

[Samrobb]

...learning to write your own, comprehensive, thought-out documentation is a very valuable skill that most don't have.

It sounds like you've never used one of these tools. There are multiple types of documentation: design, end user, man pages, etc. Doxygen and other auto documentation tools help developers deal with a single, specific documentation problem - how to keep developer documentation in sync with the code. These tools make it easy to develop documentation on API usage, show the actual (not designed) interrelations between internal components, and do all the other documentation work that generally makes it much easier for a new developer to come up to speed in a particular area on a project.

That's it, really. The purpose is to automate an otherwise tedious task, and consolidate documentation in one location with the idea that having a single source for code and code documentaion will help prevent errors from creeping in. There's nothing character-building about hand-editing these sorts of docs, any more than it would be character building to execute all your build commands one by one on the command line instead of using a makefile.

Somewhere along the line, you will find yourself having to hack out code in a text editor, or use a less-than-top-of-the-line development environment, at which point you will have to fall back on your own skills and not those of an auto-documentation program.

Most of these auto-documentation tools work quite well on the command line, apart from any sort of IDE. A good number of them can produce decent documentation even if the source code wasn't written with the documentation tool in mind. These tools aren't complex, fancy whiz-bang sorts of things; they do a pretty straightforward job, do it well, and often are no more difficult to use than any other single-purpose tool. Whats more, most of them (Doxygen in particular) allow you to create links into your "real" (higher-level) documentation, so you can do interesting things like include pointers in the source code back to the features and requirements that it was written to support (and vice-versa).

Re:vim

[BinLadenMyHero]

May sound funny, but he is right.
With syntax highlighting for all languages know to man, text folding for structured overview of your large files, directory browsing, great integration with unix tools and great extensability, Vim is the only tool besided gcc and ocasionally gdb I've used for a long time. Even when I was programming in Java in a Windows machine two years ago.
Oh, and it's an excelent text editor too. =)

VI VI VI, the editor of the beast!

Keep it relatively simple

[treerex]

For all non-Java development, unless mandated by a contract, I use GNU Emacs as my primary environment, with the GCC tool chain and GNU Make. This works amazingly well on all stages of development, but as others have said, keep things simple: try to avoid mazes of recursive makefiles, for example (read Peter Miller's Recursive Make Considered Harmful, then read it again.)

Your choice of tools will depend a bit on how cross-platform you need things to be. If you are developing now, or think you will be developing in the future, for multiple platforms and compilers, take that into account from the start and save yourself a lot of headache. Don't bother with AutoGen and friends unless you are distributing this to third parties: it's a PITA. It's great if you have absolutely no control over future systems, but otherwise there are better ways.

For Java development Eclipse is going to be your very good friend. I'm not a big fan of IDEs, but Eclipse is really nice insofar as it integrates with the Java language very well and can help you a lot. It's refactoring capabilities are worth the learning curve. Unfortunately I have not had a lot of luck getting ANT integration working, so I maintain a separate ant build file that I use for release builds in my projects.

For documentation purposes Doxygen is the thing to use. It has Emacs integration as well (written by yours truly). We use this to generate reference documentation, and then have Python scripts to massage the HTML output as we need. With its XML output you can use XSLT instead, though I haven't tried that. We need to produce multilingual documentation, and after many different attempts with tools have settled on LaTeX with a customized version of the Python macros. It works really well, if you can find doc writers who are comfortable writing with it. We are experimenting with Lyx to see how it integrates with our hand-coded documents. We use JavaDoc for Java reference documentation, though we could (should) migrate to Doxygen.

Other tools that are essential: Valgrind is a must use. I prefer it to Purify. Use Bugzilla for bug tracking: easy to set up and maintain. I recommend Perforce for your SCM. I'd avoid CVS. Give Subversion a look, but we've been happy with Perforce. Depends on how much you want to spend. We use AutoGen a lot to generate sources: very useful. And pick a scripting language you are all comfortable with and use it: Python is what we use, Perl works. It doesn't matter which one you use, as long as you're all comfortable with it. We have Python scripts that produce hourly summaries of Perforce activity, for example. We've tied our Bugzilla into Perforce... lots of things can be done.

Re:vim

[WinterSolstice]

I agree. I use Vim to author/maintain code in Perl, Java, JavaScript, C, and C++, as well as documentation in XML, XHTML, and txt... all from the same free tool. I do it on 4 platforms, too. I use it at work on Solaris and Windows and at home on OSX and VMS.

Oh, and it makes things like NetBeans look extremely slow; though I guess n00bs can use the autocomplete stuff. I only find autocomplete helps for about the first 3 weeks of learning a language. After that it is a friggin pain in the butt.

In fact, when I switched jobs recently I had a crew of people look and go "Ooooh, I want that!".

Of course, the true best ever is the lse on VMS :)

-WS