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

Learn to write your own documentation.

[jbarr]

I know this doesn't answer your question directly, but while I certainly understand that there are "auto documentation" tools, and such available, learning to write your own, comprehensive, thought-out documentation is a very valuable skill that most don't have. Don't rely completely on automated processes. 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.

Finding a complete and comprehensive development environment is definitely an ideal situation, but don't neglect your knowledge and skill by using it as a crutch.

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:Learn to write your own documentation.

[bladesjester]

People either love me because of my commenting and documentation or they look at me like I've sprouted a couple of extra heads. I have a set comment block at the top of each function and class (name, purpose, date created, creator, date modified, modifier, calls, uses, and notes) and then comments for meaningful portions of code.

I usually hang the following quote in any office that I occupy as a reminder - "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. (Martin Golding)"

Unfortunately, I tend to end up being the violent psychopath because I know too many people that go "the code should be self explainatory..."

Re:Sutff I use

[Otter]

AFAIK, there's no good, freely available C++ IDE for Linux/BSD/Solaris.

KDevelop

Don't write C++ without boost!

[slamb]

Don't even think about writing C++ code without using boost. In particular, everyone should be using their smart pointers. IIRC, they've been proposed for inclusion in the C++ standard and it's likely to happen.

boost also has a nice unit testing library. I use it for all my C++ code.

Jikes

[mechsoph]

Nobody's mentioned Jikes yet. It's an open source (CPL) java compiler from IBM. It's written in C and is significantly faster than javac which runs in the vm.

If you want your java code to run on the vm, jikes may be a good idea. If you want native java code, then there's also gcj .

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.

Netbeans

[Mr. Competence]

Use Netbeans. It has recently leapfrogged Eclipse in many areas (not to say that won't change) and the guys I work with say it is faster than Eclipse now in addition to the Refactoring, Swing Builder, etc. that it has.
The new 4.0 and 4.1 releases use ANT build files for all of their project information. They build and run JUnit tests as part of the project and the build process, and they come with a sweet profiler that even allows you to profile remotely. One of the neat things about the ANT based projects is anything that can use an ANT build script can build your project -- whether it be ANT itself, CruiseControl, Maven, Eclipse, etc.
The latest beta of 4.1 will even import Eclipse projects.
Also recently voted Developer.com Product of the Year 2005

Re:Netbeans

[SunFan]

The first sentences of the previous two comments are quite amusing.

on the Java side

[BigGerman]

Jboss and Tomcat
Axis
Jakarta commons, Spring, Hibernate
NetBeans (only if doing massive Java web app or Swing UI), Eclipse (good all around; web features castrated by IBM now trying to re-attach)
CVS and CVS client inside IDE. Other Linux clients IMHO have issues.
Junit
Ant, Ant and Ant everything via Ant
CruiseControl
Some form of Wiki
Poseidon / Argo UML
JIRA or equivalent

IMHO, deserve to stay away from:
JBuilder
Oracle Jdeveloper
IBM WSAD and other minions
Portal frameworks (maybe Liferay is ok)

KISS applies here.

[pi_rules]

Keep the project simple and bare bones. I wouldn't try and lock any of your developers into specific tools. CVS, Ant (because you're doing Java too), JavaDoc/Doxygen, any IDE should be able to integrate with these.

The project I'm on does not require any specific IDE at all. We've got guys running Emacs, I'm a vim user, another uses NetBeans, a few more Eclipse, and somebody has their personally licensed copy of JBuilder out here too.

The only issue have is when developers sometimes setup their IDEs to use different tabs sizes (we say they're 2 spaces, but people forget sometimes) and when some IDEs reformat a whole class on you, which makes the CVS diffs difficult to apply to different branches for fast-tracked bug fixes.

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!

EMACS!

[PaulBu]

Yeah, eat this, all you VI fans! ;-)

Seriously, while newer-generation IDEs might be better for Java/C/C++, the cool thing about Emacs is that it has modes for all languages known to man, and then some. So if you just code in Java/C/C++ -- pick up an IDE, but if you do not know what life will send your way tomorrow -- start customizng your Emacs.

And of course good luck editing LaTeX docs in Eclipse! ;-)

Paul B.

Valgrind

[cakoose]

Valgrind is great for debugging memory problems (wild pointers, memory leaks). It's not at all like the older memory debugging tools; you just run "valgrind your-program" and it'll rewrite your executable to perform the appropriate checks, then run it. Right now it only supports x86 executables; they're working on PowerPC support.

Re:Eclipse

[hey!]

I've looked at both subversion and cvs.

I think subversion is fundamentally better, but cvs is more mature and has better support in tools. There are subversion versions of everything you need, but when I've looked at them they've always been a bit more squirrely than their CVS counterparts.

It's enough that I'm holding off on converting my company's stuff from cvs to subversion. If I were starting from scratch, I'd go with subversion.

Choose the right tool for the methodology

[hey!]

and the right methodology for the job.

This is not to criticize your choice of tools. Personally, it's close to what I use, except I use ant for building. But I've found time and time again that people on my team struggle with one or other part of the tools chosen. When I've looked at the problem, it is usually that they are struggling against the presumed methodoloy presumed by those tools.

For example, cvs or subversion have a concurrent editing model that goes nicely with agile methodologies. Agile methodologies are the engineering equivalent of keeping your room picked up as you go along rather than letting the crap pile up waist deep and then dealing with the problem.

But agile might not be the kind of methodology you choose, for (occasionally) good or (usually) bad reasons. if it isn't, cvs will probably multiply your problems painfully.

With CVS, people work on what they think they need to work on, then deal with the fact that this might conflict with somebody else's idea of what needs to get done. The process is that you update from your repository, resolve any conflicts that arise, and then commit the resolved changes back. You do this every day, if not multiple times per day. It's the equivalent of keeping your room picked up. The problem is, this process doesn't seem like much fun at the outset. Actually, when you work this way, it is pretty enjoyable, but if you let things go, say not committing for a few days, you are punished. I've had people working for me who found this excessively time consuming and restrictive. The problem was they weren't doing it enough. You have to have real commitment to continual integration for cvs to work.

So, if you're not commited to continually integrating your work, and not stressing collective code ownership, then maybe cvs is not the tool for you. You may want a tool that supports locking on checkout.

Use open tools only!

[rjh]

Here's the big thing: only use open tools.

What happens three years down the road when Management decides not to renew the Rational Rose license? What happens when IntelliJ stops supporting your version of IDEA and you have to upgrade with money you don't have? Etc.

Use only open tools. Open-source is best, of course, but anything that uses completely documented file formats and has tools for exporting to other formats is acceptable.

Don't let yourself get nailed with vendor lock-in. That's a bad, bad place to be. Better to use slightly inferior tools which are open than to lock yourself to a vendor.

That said, here are the tools I find myself using again and again:

• C++
  • jEdit is a Java programmer's editor with excellent C++ support. I do development on Linux, Win32 and MacOS X, so it's very nice for me to have one editor I use on every platform. jEdit's not as featureful as, say, Emacs, but it's considerably more friendly to use.
  • Boost. If you're writing C++ and you're not using Boost, you're committing a crime against yourself.
  • Python. With Boost's Python library, it's easy to make your C++ applications scriptable. Write the heavy lifting parts in C++, then make those parts callable from Python. Do the rest of your development in a far safer, more sane language. You get almost all of the speed of C++, and far fewer headaches.
  • SWIG is another tool that's excellent for creating scriptable C++ applications.
  • Subversion for your version-control needs. Nothing else will do.
  • Doxygen for all your documentation needs. Learn it, love it. Your code's not done until every public part of the API has been doxygenated.
  • The GNU Autotools are really, really awful. They're also far better supported than Scons or pick-your-Autotools-replacement. Get ready to feel the pain of m4 macros. Sorry. :(
  • The GNU Compiler Collection started getting a good C++ compiler around version 3.0. I've been quite favorably impressed with 3.3, and I'm looking forward to 4.0. I don't recommend it for Windows, but for Solaris and x86 Linux it's beautiful.
  • I haven't found a good C++ unit testing framework yet. If you find one, please let me know.
• Java
  • Eclipse is an excellent Java IDE. jEdit also fits the bill nicely, if all you want is an editor. I use both frequently, and am quite pleased with both.
  • Subversion again for your version-control needs.
  • jUnit for unit tests. Your code's incomplete unless you've written unit tests for it.
  • Javadoc for documentation. I would recommend Doxygen, but it's quite possible you'll be deploying your applications on machines that don't have it installed.
  • Ant for all your build needs.

Hope all this helps.

Yeah, that too... ;-)

[PaulBu]

Of course we know that Lisp is the only language worth coding in! ;-)

"A guy on Slashdot" even made it to Paul Graham's collection of Lisp quotes:

"I have heard more than one LISP advocate state such subjective comments as, "LISP is the most powerful and elegant programming language in the world" and expect such comments to be taken as objective truth. I have never heard a Java, C++, C, Perl, or Python advocate make the same claim about their own language of choice."

- A guy on Slashdot. What theory fits this data?

Re:Latex / Kile

[ottothecow]

I like to do everything on TI calculators.

You've got TI-basic and tons of math functionality in addition to text editors for your documentation, drawing software for your uber cool splash screen, calendars for keeping on track with your coding and even the capability of an address book to keep track of contributors.

Some notable projects developed using this suite are "AP pHysix cheeT'r" "Drug Wars" and of course the numerous high quality ports of Windows.

Re:vim

[fvbommel]

I do not have knowledge of how to compile Java using gcc ;)

Click here to find out: GCJ ;)