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

Latex / Kile

[Eternally optimistic]

Write whitepapers and similar documentation with LaTeX, it looks more believable. It looks better, and makes indexing easier.

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.

[bjb]

A program that does "automatic documentation" is worthless if it just generates headers that say "TODO: Insert comment here. You've got parameters X and Y which are integers" and nothing else.

I've seen too many projects where someone claims that they have javadocs, but in fact its just the crap that was generated by JBuilder or Eclipse or something like that. The documentation those things generate is USELESS. You need to write in your own words.

Re:Learn to write your own documentation.

[bladesjester]

I dislike when people go making changes without making any changes in the documentation (CVS logs don't count. I don't tend to look at the log files when I'm working on code. Just to see who's done what).

The documentation is important not only for existing people working on the code months down the line, but also for the new people who get brought in. It allows you to get a general overview of what the code really does and where it does it without having to sit down with a ton of source and reading every line.

There is one very important thing that the Self Documenting Code fans often don't get - the code is no longer "self documenting" when someone goes in and makes significant changes to it, and if the program stays around long enough, someone will. That is assuming that the code was really "self documenting" to begin with (and most of it isn't) instead of being an excuse to not write documentation. (and if I see the comment of "does stuff", I beat people)

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.

Re:Don't write C++ without boost!

[Pseudonym]

ML exists (and is faster than C++).

No it's not.

It is impossible for one language to be faster than another language. At best, you can talk about specific programs running with specific language implementations. The assertion is even more silly when talking about ML vs C++, because ideomatic ML has very little in common with ideomatic C++ and vice versa, so talking about implementing "the same program" under two different implementations of two different languages is a difficult task which almost nobody has done under proper research conditions, and when they have, it's almost always on toy problems.

ML is a nice language. Well, O'Caml is, anyway. But C++ is also a nice language when you get to know it. I should know. I also used to call it a horrible kludge until I actually wrote something nontrivial in it using modern C++ development techniques. I still dissent from C++, but I don't disrespect it any more.

Re:Eclipse

[Procyon101]

In my experience, screw the makefiles and use GNU automake/autoconf. These force you into a best practice and get rid of the complexity of maintaining makefiles in the first place.

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

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.

sparse tools

[XO]

Only tool I've used since leaving DOS was 'vi'.

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.

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.

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?

Don't make ME use YOUR editor

[bluGill]

Editors and IDEs are personal choices. Make vim, emacs, and kdevelop available to everyone (Those are selected because they are the most popular free ones, have the admins install any other free ones on request). Then have each department budget for other editors that any one person may find works best for them. You might want to see if there are demo versions of commercial software you can make available to those who care to try it.

Everything else you need to make choices. There can be only one source code system so choose one. There can be only one make, so choose one. (my current project had two incompatible makes for a short time while we converted to the new system, it was a pain not worth living with any longer than you must!)

Make sure you code is cross platform. Don't use any gcc only tricks if you can avoid them, and where you must use them be careful to make them easily wrapable so you can use other compilers latter. For C++ gcc isn't very good, if speed becomes a concern you can buy a different compiler latter (perhaps just for one platform, using gcc for the other). In fact you can developers work with gcc (which is free and normally good enough), and have a good compiler for the build system.

Re:A TAB is not 8 spaces!

[Heretik]

no no no.

Anything that needs to "line up" at all should be done with spaces. Period. No argument.

Indentation levels are done with tab, and indentation levels only. Lining things up is done with space. If you ever, ever, ever, smash tab a bunch of times then start hitting space to "line something up", you're doing it wrong. A tab is not a substitute for "a few" spaces. Ever.

It's really not that hard to ask yourself "will a changing tab size screw this up?" - I don't understand how it's such an issue.

In short, no the tab display size does not matter in any case. If it matters, you are doing something wrong.