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.

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.

Sutff I use

[pauljlucas]

C++: vim, GNU make, g++, doxygen. AFAIK, there's no good, freely available C++ IDE for Linux/BSD/Solaris. (On Mac OS X, there's Xcode.) You can pretty much auto-do anything with GNU make. It's far more powerful than vanilla make.

Java: vim, GNU make, javamake, javac, javadoc, IntelliJ IDEA.

Re:Sutff I use

[Otter]

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

KDevelop

Re:Sutff I use

[Tr0mBoNe-]

Eclipse is great. I use it for my Java, and just started with C++ and C in that. There are plugins for all major languages which you can get on the eclipse site. Doxygen is great for creating cool UML diagrams or documentation for the code. The GNU compilier tools are great and make is where it's at.

For java, once you have your desired runtime lib installed its all gravy...

vi, vim, nano, emacs, whatever you want to use, it should be up to the programmmer. I would also ask your staff what tools they want to use and what they feel would make them be the most productive.

cheers

Re:Sutff I use

[Noksagt]

Anjuta is also nice.

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: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)

vim

[Anonymous Coward]

vim

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!

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

Re:vim

[fvbommel]

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

Click here to find out: GCJ ;)

Eclipse

[Profane MuthaFucka]

Eclipse will work for your overall environment. For documentation, use Doxygen. Stick with gcc for the compiler.

Use SIMPLE makefiles; don't make multi-nested monstrosities if you can help it. Seriously, simple makefiles and absolutely NAILING the build procedures up front will save you a hunk of time. The user should be able to type 'make' and build the whole system, if at all possible. Don't make them jump through hoops. Don't let people change makefiles without review.

Don't rely on Rational Rose too much, or you will have a pretty demo, but nothing running on anything else other than a slide projector.

Use cvs for your version control. Get a bug tracking system that you can use to smoothly promote code along from devel to test to system test to staging to release to retired.

Beyond that, don't spend too much for tools. If you find something you need, cool. But don't add tools just because you can.

Re:Eclipse

[Profane MuthaFucka]

I think Ant sucks complete ass, but I must reluctantly admit that the tool does work, it works well, will support both Java and C++, integrates with Eclipse, and most likely fulfill all of the requirements of the original query.

The truth sometimes hurts.

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.

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.

Re:Stuff I use

[pauljlucas]

KDevelop

OMG! Thanks for the pointer. :-)

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!

[Unordained]

As I happen to have been reading up on them recently ... (we -did- code in C++ without Boost, and have done just fine so far, but felt it might be handy for a few odd situations)

auto_ptr is pretty much equivalent to Boost's scoped_ptr: it just makes sure that when the -1- pointer to your object goes out of scope, the object is deleted. this is good for securing objects around try/catch blocks or early returns, where you would have to manually plan for each possible exit and code your deletes appropriately. these are not safe in STL containers, which copy values around. you'll wind up having a pointer go out of scope and delete your object.

shared_ptr is reference-counted, though it doesn't handle circular refs for you. weak_ptr is used for this, though the examples I found weren't terribly clear on the topic. unlike java's garbage collection, you have a pretty clear idea of when an object will be destroyed (when the last shared_ptr to it is destroyed). these are safe in STL containers.

intrusive_ptr lets you do reference-counting yourself in the objects the pointers will reference. that has the additional benefit of letting your objects know how many references to them there are, which they wouldn't know if you were using shared_ptr. but you have to code a little more yourself.

regardless, you have to be careful. these aren't language-enforced, so unlike java and other GC'ed languages, you can easily screw over your garbage collection by using raw pointers instead of smart pointers. you'll have to enforce a level of discipline. typedefs recommended? maybe even a separate class that hides the smart pointer entirely and is passed around by copy?

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

[Anonymous Coward]

C++ auto_ptr does not have normal copying semantics, for one. When you copy an auto_ptr, it transfers ownership of the pointed-to object, so when the copy is deleted, the object is as well. Your original auto_ptr is pointing to garbage that used to be an object. If you pass-by-reference all is well and good, but if you pass-by-value, you're SOL.

Boost's shared_ptr allows several "copies" of a pointer to co-exist, only when the last one is destroyed is the pointed-to object deleted.

auto_ptr also doesn't have array support, it doesn't call delete[] on the pointer when destroyed. Boost has a smart pointer that does that, as well as lots of other features (if you need them).

SH

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

[slamb]

What is the difference between boosts smart pointers and standard C++ auto pointers?

std::auto_ptr<> has this limited and confusing concept of "ownership". Multiple auto_ptrs can point to the same object, but at most one should own it. (Of course, if none do, you have to delete it manually, defeating the point.) Assignment transfers ownership, so it changes the right-hand side of the assignment also.

boost has a couple variants:

• The simple boost::scoped_ptr<> always owns what it points to and isn't assignable from another scoped pointer. So it just avoids the ownership thing altogether; it's limited but not at all confusing.
• boost::shared_ptr<> is a non-intrusive reference-counting pointer. (The object is destructed when all of the pointers go out of scope or are reassigned to something else.) It's both more powerful and simpler to understand than std::auto_ptr<>. It even supports weak references through boost::weak_ptr<>.

The boost pointers also have variants for arrays; using std::auto_ptr<> with an array would incorrectly use "delete ptr;" instead of "delete [] ptr;" on destruction.

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.

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.

Re:Nothing is perfect, but...

[ogonek]

For Java development.

Uniting testing I use junit for Java.

I prefer TestNG for unit testing Java things. It's much better than jUnit, it really is. You can define test dependencies and lots of other nifty things that jUnit doesn't allow you to do. If you are using jUnit, switch now.

Also IntelliJ's IDEA is a nice IDE, but not free.

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)

Re:on the Java side

[redhookgroup]

Try looking at maven for your build. It has been described as ant on steroids: http://maven.apache.org/

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:KISS applies here.

[stefanlasiewski]

For new projects, you should seriously consider Subversion.

SVN is simple to use like CVS, but fixes many of CVS's fundamental shortcomings-- directories can be under version control, which means that re-organizing the directory structure isn't the anathema that it is in CVS. So many simple fixes which really affect the KISS process...

You can easily make the SVN repository available over Apache. This seems much more robust then CVS + RSH/SSH, and you can use the huge range of Apache modules for your SVN repository.

The version numbering scheme is a little hard to get used to-- the 'Version Number' is actually the version of the repository, not the version of the file itself. Not sure if I like that ...

Tools I use

[MarkLewis]

I use vim and make for small C++ projects, but for larger projects I've found it useful to have a real IDE. Either Anjuta or KDevelop are good.

Most of my professional programming recently has been in Java. Eclipse is far and away the best free IDE, although I've heard unconfirmed rumors that recently NetBeans has started becoming usable. We use IntelliJ IDEA, which I highly recommend. We switched away from Eclipse because it supported the same sort of refactoring that Eclipse did, but it was faster, easier to control from the keyboard, and seemed more intuitive. And at $500/license it's pretty cheap compared to the (commercial) competition.

I agree with the comments others have posted about getting a well-designed build system set up first thing; it really will save you time. If you're using Java, then Ant is basically the de facto standard, and is well worth using. If you're running both Java and C++, it probably makes sense to use Ant for both, so you can have a single build system.

As far as version control goes, you really want something more flexible than CVS. I've used CVS in a professional setting, and while it has its advantages, its lack of changesets makes managing a large project difficult. It isn't so bad with C/C++ code, where it is common to have a few large source files, but with Java forcing you to make lots of small source files it makes version management a real hassle.

We're switching over to Subversion for version control. While you're looking at version control, take a look at Trac, which is an immensely useful issue management system that integrates directly with SVN.

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.

Re:EMACS!

[Anonymous Coward]

Umm, not hoping to get any free publicity... honest, but there is a Latex plugin for Eclipse called Ecletex http://sourceforge.net/projects/etex The current version (0.0.4) is a bit shakey, but the cvs is upto date and much more stable. Okay advert over.

Oh and its more "Lazy Coward" than "Anonymous Coward"

Re:EMACS!

[goofyheadedpunk]

Nope, just a Saint.

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.

Unit / regression testing

[devphil]

QMTest is an open-source testing framework that you should try. Fairly simple, adaptable, extensible. (Full disclosure: It's made by my company, but not by me. From reading the mailing lists, we get lots of kudos, so presumably it's working. *grin*)

As for other tools:

• avoid Rational Rose like the plague of death. I used it for a year at a previous job, and had nothing but painful user-interface experiences and craptacular code to show for it.
• CVS makes for a decent revision control system, but its limitations are a pain to work around. Subversion is considered mature, and Monotone is supposed to be quite nice, but I have no first-hand experience with them. Arch is suitable for small projects but does not scale (also, its author is an asshole, so you have no support there).
• Unless you need to support some exotic environments, the autotools (autoconf/automake/libtool) have become more trouble than they're worth. Any of the mainstream make(1) implementations -- GNU Make, BSD Make, Solaris Make, etc -- will have enough extensions to let you do just about everything a build system needs to do. GNU Make is particularly rich, but use its features sparingly or your makefiles become undebuggable.
• If you do need to support exotic environments, or think you might someday, then autoconf is your friend. Automake used to be friendly before they went overboard with it, now it's just bloated and broken; use Make extensions instead. Libtool has never been anybody's friend; more time has been put into making and debugging and debugging and debugging libtool than has ever been recouped by its wrappers -- use ELF binary format and be done with it.
• Doxygen and Synopsis are both highly capable documentation tools.

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.

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.

Re:Use open tools only!

[kraut]

... and use Jython to script you Java stuff

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:Stuff I use

[mibus]

Thanks... for the *pointer*?

Surely, "Thanks for the object reference"? ;-)

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.

Eclipse + myEclipse

[StarWynd]

If you're doing any J2EE work, I highly recommend Eclipse with the myEclipse plugin. It carries a price tag of about $30 per year, but this is much cheaper than many of the other equivalent IDEs. Included are a JSP developer, XML editor, SQL Editor, database explorer, EJB modeler and JSTL support among many other features. It is a great tool.

If J2EE isn't of any concern, I still first recommend Eclipse because of its nice integration with CVS, JUnit and other Java tools. There are also plugins for C and C++. And best of all, it's free. Even if Eclipse weren't free, I'd still pay for it. It's the best IDE I know.

The only other IDE I'd recommend is SlickEdit. I used it for a number of years for C/C++ and Java before switching to Eclipse. It's a good editor, but I found that I could do my job better with Eclipse. Many of my co-workers use SlickEdit instead and rave about it. It all depends on what you need to do and how you work. There's now a plugin so you can use the SlickEdit code editor in Eclipse. However, Visual SlickEdit comes with a price tag in the $200 - $300 range and the plugin is a about $150 or so.

UltraEdit

[mpeisenbr]

UltraEdit is hands-down my favorite editor. It carries a $40 price tag, but It is well worth it IMO. I also use Beyond Compare for visual diffs; its a great tool with lots of filtering options.

My Favs

[NaNO2x]

For C/++ I use Dev-Cpp. It has built in CVS, and almost any feature you could need. Plus it is open source. (find it here: http://www.bloodshed.net/devcpp.html , but as the site goes up and down you can get it here: http://prdownloads.sourceforge.net/dev-cpp/devcpp- 4.9.9.2_setup.exe) For Java I am just starting to work with it but from what I have done so far I have done in command and Eclipse. It seems to have most things that are needed. (find it here: http://www.eclipse.org/)

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.