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

[Profane MuthaFucka]

Use Eclipse as an IDE. I used to be a vi/makefile snob (for 18 years!) but I picked up Eclipse and now I love it.

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

[Anonymous Coward]

You can pretty much auto-do anything with GNU make. It's far more powerful than vanilla make.

I agree. However, I recently moved over to scons and am very impressed.

Re:Sutff I use

[redhookgroup]

For large Java projects I would highly recommend maven http://maven.apache.org/ for your project builds, testing reports etc.

Re:Sutff I use

[ameoba]

re: the fork bomb in your sig -

It's not going to work very well on Linux (or other modern Unix systems). Something more like:

while(1){malloc(sizeof(int))=fork();}

will be much more effective.

Re:Sutff I use

[Anonymous Coward]

Allow me to simply repeat:

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

Re:Sutff I use

[Noksagt]

Anjuta is also nice.

Re:Sutff I use

[MrResistor]

Agreed. I just started using it, and it's great. The one thing I wish it had is a split-screen capability, such as in Kate. I like having my .h and .cpp side by side.

Re:Sutff I use

[rjshields]

Eclipse is great with the CDT plugin. Ant as a build tool is great - XML build files are nice. Not to mention, Ant integrates with JUnit which I use for Java unit testing. Oh, and Javadoc and Doxygen for source code documentation.

Re:Sutff I use

[rjshields]

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

No Java project is complete without using the Ant build tool and JUnit for unit tests :) There must be a reason why you choose these other build tools, but I'm not sure what.

Re:Sutff I use

[barrkel]

Eclipse is crap with the CDT plugin. Debugging just plain doesn't work well in a project of any significant complexity, with any C++ data types of anything approaching something realistic.

Re:Sutff I use

[rjshields]

What do you use then? Make a suggestion instead of slagging off Eclipse and CDT.

Re:Sutff I use

[lachlan76]

I like KDevelop a lot, but could anyone possibly point me to a way to make it work without running KDE?

Re:Sutff I use

[Otter]

What do you mean by "without running KDE". I run it in WindowMaker all the time, without doing anything special. If you mean using it without having the KDE libraries installed -- that isn't going to happen.

Re:Sutff I use

[Digital_Quartz]

Well, aside from the fact that whenever I try to search or search and replace, it crashes. Anjuta looks very promising, but it doesn't seem very stable. I'm eagerly awaiting the 2.0 release.

Re:Sutff I use

[Profane MuthaFucka]

So just set up ddd as an external tool. No problem.

Re:Sutff I use

[moonbender]

Ant is integrated into IntelliJ IDEA, and IIRC there are JUnit plugins. Let me just state here that IntelliJ IDEA is by far the best IDE I have ever seen. Their motto is "develop with pleasure", and as cheesy as it may sound, some of the convenience the IDE brings really is quite pleasing. I'm using Eclipse now because the J2ME integration is way better, and so far Eclipse could do everything IDEA could, but it's just all much more streamlined in IDEA. At least that's my experience - I don't want to start a religious war here. I really hope JetBrains continues working on IDEA; their latest tool was a C# development tool, I hope they're not jumping ship.

Re:Sutff I use

[Anonymous Coward]

And getting the KDE libraries installed isn't going to happen as long as QT refuses to even compile.

Re:Sutff I use

[barrkel]

Visual Studio

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.

[Ghetto_D]

I definitely agree. With all the "auto-documentation" tools that have gained popularity, code is actually becoming documented more poorly. I remember a professor introducing our class to javadoc a few years back. I don't know how many people thought it was the answer to all their problems because it created html documents with all the classes and functions hyperlinked. A page that says "this class contains these functions" is not adequate documentation.

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.

[EvlG]

Too bad those comments won't be maintained by someone who fixes the code later. And too bad most of that information can be had from the source repository - there really is no need to clutter up the code with flowerboxes like this:

// Function GetSize()
// Return: int
// Gets the size of the field
int GetSize()
{
return size;
}

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.

[phats garage]

When I see a function with a nice doc header including revisions and have to add my own, the existing revision history tends to nudge me toward adding a line and otherwise leaving some notes on what and why.

Re:Learn to write your own documentation.

[rjshields]

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

Nop, it's not happened to me yet. I must just be lucky. In the mean time, I'll count my blessings and keep using Doxygen and Javadoc.

at which point you will have to fall back on your own skills and not those of an auto-documentation program.

When it happens, I will concede that point. Until then, I think your reasoning flawed because it's not going to happen. It's like saying you might as well code in assembler intead of C because one day you might not have access to a C compiler and you'll be damn glad you learned assembler. Crazy :)

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)

Re:Learn to write your own documentation.

[gstoddart]

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.

Well, yes, if you don't populate the fields used for javadoc and the like, it makes for pretty crappy documentation.

However, the amount of extra work required to actually have some pretty decent developer documentation generated by this type thing is very low.

In Javadocs, my habit of writing a comment for the function before I wrote the function makes for some pretty up-to-date documentation to refer back to and find things.

Nothing works if you don't put a little effort into it. But it doesn't take much more than a little effort to be able to do it consistently.

Re:Learn to write your own documentation.

[Anonymous Coward]

Personally, I assume that I'll be the guy maintaining the code. It only takes a few experiences coming back to your own code after months or years to recognize the value of good comments. I also assume that my boss won't be sympathetic to any complaints I have about the lack of documentation.

Re:Learn to write your own documentation.

[Anonymous Coward]

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

No, clearly it's you who doesn't get what Self Documenting Code is about. The point is that it's always self-documenting, no matter how much it is changed.

Seperate code and documentation can easily get out of step with each other. If the code is the documentation, then there is only a single source and it is guaranteed to describe excatly what the code does at that moement in time.

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

[Anonymous Coward]

elvis. vim hurts too much.

Re:vim

[lachlan76]

As much as I agree with you, I do not have knowledge of how to compile Java using gcc ;)

Re:vim

[fvbommel]

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

Click here to find out: GCJ ;)

Re:vim

[Anonymous Coward]

nvi. vim is the emacs of vi's.

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

[UberChuckie]

I would use Ant instead of Make. It is well documented, easy to understand, supports both Java and C++ and Eclipse can run Ant build scripts directly.

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

[superpulpsicle]

I have always hated Makefiles. It was so much overhead above the regular programming itself.

Am I the only person in this entire forum that give M$ some credit to their visual studio suite? Editor, compiler, setup.exe maker, handle many languages all in one app. I would kill for a single complete suite like this for linux.

Re:Eclipse

[GuyWithLag]

No, use maven. Much more powerful, with a smaller learning curve.

Re:Eclipse

[Anonymous Coward]

Er. Okay. Then go get Eclipse (it's written in Java, it's not just for java...). There's also KDE KDevelop with a heavy, but not exclusively, C++ slant, and (ahem) Emacs (no, seriously, for several languages, while emacs isn't as pretty-pretty as other IDEs, it has all their functionality and more. Emacs was the orignal IDE).

Re:Eclipse

[Anonymous Coward]

Use cvs for your version control.

No. Use Subversion.

Re:Eclipse

[hey!]

Well, ant is imperfect. For one thing, I find that people don't grasp it as quickly as make.

To me this is a bit odd, because the underlying model seems pretty similar It shouldn't be a big issue. Except it is an issue. People seem to want to copy and paste hunks of ant files, then tweak them to do what they want, rather than just sitting down and spitting them out the way you do make files. It suggests to me that people find the syntax painful. I've seen the same phenomenon with Tomcat configuration files which are also XML. They're none to handsome to start with, but after the same configuration file has been carried accross multiple applications and installation files, it gets downright ugly.

That said, ant has enough critical mass, it's undoubtedly the way to go if you're doing java. It supports the things you need to do if you are using java, like unit testing. You just have to bite the bullet.

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

[EvlG]

I was all excited for SVN until I saw the debate over which repository store to use, berkeleydb or ffs.

Looks like there is still quite a lot of maturing left before SVN is ready...

Re:Eclipse

[dozer]

URL please? As far as I can tell, there is no debate. bdb was just a hack used to bring up Subversion faster. Now that fsfs is stable, bdb is just legacy.

Re:Eclipse

[vadim_t]

I don't see the problem.

As long as it works, who cares how it stores the files internally? It does matter for the developers who want a clean and efficient way of doing things, which would be why they are having a discussion, but I don't think it's a sign of instability or anything.

If you're worried about backups and such, then you are doing things wrong. You should be using dumps for that. It's very easy to set up SVN to make incremental repository backups. I do that here.

I've been using SVN for years and it has never failed me yet.

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!

[Miffe]

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

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

[Procyon101]

Have you noticed the boost unit testing library sucking up ALL your ram if you put too many tests in one file? I had a 300 line C++ file using the test framework and it took my machine 4 hours to compile (dual P4 2.2Ghz 512M RAM)... insane. Breaking up the files into small tests and one test per file worked to speed it up as it wasn't tromping RAM all at once, but I was wondering what others experience was.

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!

[gokeln]

Don't take this as a troll, or anything, but I find Boost's overuse of templates impenetrable. And, God, I'd hate to have to debug any misuse of the Boost libraries. Are there any good debuggers that are template-savvy? If somebody could automatically parse even the STL structures into a nice graphical representation, that would be a good start.

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

[gokeln]

I find Boost's excessive use of templates impenetrable. And, God, I'd hate to have to debug any misuse of the Boost libraries. Are there any good debuggers that are template-savvy? If somebody could automatically parse even the STL structures into a nice graphical representation, that would be a good start.

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

[Anonymous Coward]

I was wondering what others experience was.

You'll have better luck getting answers on boost-users than here.

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

[Pseudonym]

I find Boost's excessive use of templates impenetrable.

One of the things about generic programming is that it's hard to design generic, reusable code, but it's not difficult to use. The STL is a good example. Many C++ programmers don't know what an iterator category is, but don't find it difficult to use std::vector.

The iostreams library is another good example. Many people don't truly understand it, but using it isn't so bad.

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:Don't write C++ without boost!

[gokeln]

Thanks for the reply. I agree with you in part. The C++ std library is easy to use, initially. Until you make a mistake using it and then have to trapse through the underlying mechanisms in the debugger. I currently use VC++6 on the windows side, and it's god-awful with respect to the std libraries. You have to follow umpteen references to begin to get a feel for things. And they're shown in that horrible tree structure.

My problem really is that to get the nice features you want using templates, you often have to create a horrible mess underneath. Once it's debugged, it's nice, but until then, you may be spending some late nights pulling out what little hair remains.

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

[drxenos]

Saying that one language is "faster" than another shows your utter lack of logical thought.

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

[Anonymous Coward]

dude thats like working with gcc 1 and complaining its not implementing C99

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

[Anonymous Coward]

Multiple auto_ptrs can point to the same object, but at most one should own it.

No, that's not right.

To see why, first consider what happens when you copy an auto_ptr: An auto_ptr owns the object that it holds a pointer to, and only one auto_ptr may own an object at a time. When you copy an auto_ptr, you automatically transfer ownership from the source auto_ptr to the target auto_ptr; if the target auto_ptr already owns an object, that object is first freed. After the copy, only the target auto_ptr owns the pointer and will delete it in due time, while the source is set back to a null state and can no longer be used to refer to the owned object.

Another Eclipse endorsement

[Samrobb]

I'm working in Eclipse right now, trying to debug a userland NFS server, and it's a pretty nice product. I may be biased, though, because my company sells an IDE based on Eclipse + CDT, so try it for yourself.

You'll need to install the CDT plugins for C/C++ work, but that's not a liability. In fact, it's really Eclipse's strength - there are literally hundreds of plugins (commercial and OSS) that can be integrated into the environment to give you exactly what you want.

the most impotant tools are...

[warpSpeed]

a white board and a yo-yo.

Re:the most impotant tools are...

[dauthur]

I thought I was being generic when I instinctually thought "Wordpad".

Programming tools?

[Anonymous Coward]

Changes are, you most already have everything you need on your system.

My Favorite JAVA IDE,

[MoOsEb0y]

would happen to be BlueJ. It's written in Java, so it'll work on a lot of platforms, it's got a very simple interface, and just lets you code. None of the clutter of Eclipse.

Re:My Favorite JAVA IDE,

[Pacifix]

please for the love of god tell me you're joking. I believe BlueJ to be a convoluted plot to turn people off from programming, thus shrinking the supply of programmers and raising the demand and hence salaries. I didn't say it was a good plot or that it was working, but I believe it's a plot nonetheless.

Re:My Favorite JAVA IDE,

[Fitzghon]

I cannot agree more! BlueJ is only even remotely good for testing methods! Just use Eclipse to code, please! You can maximize your text editing window in Eclipse by double-clicking on it, just do that!

Fitzghon

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.

Re:Nothing is perfect, but...

[lphuberdeau]

Quite unrelated, but I wonder why you prefer the JavaDoc style documentation. I personally think doxygen looks a whole lot better and is more intuitive and visual with the graphics showing relations. Also, there are less purple pixels in the interface.

Re:Nothing is perfect, but...

[circumlocution]

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

I have used CPPUnit with VS .NET and found it to be difficult to get working. I found it easier just write my own basic testing framework and have it write the results to a text file or the console rather than bother with trying to get CPPUnit to work. The only thing I lost by doing it this way was the fancy GUI interface that displays the results.

You might want to check out http://easyunit.sourceforge.net/index.php?page=exa mple&lang=en. From the example it looks much easier to integrate into a current project.

Re:Nothing is perfect, but...

[Undertaker43017]

It's more about what I'm used to. The project I work on is 95% Java.

Plus blue is my favorite color, so purple isn't too bad. ;)

Re:Nothing is perfect, but...

[Anonymous Coward]

it's reverse engineering leaves a lot

"its".

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.

IntelliJ IDEA

[avalys]

The best Java IDE, by far, bar none, is IntelliJ IDEA. It blows everything else out of the water, although it has a price to match.

Eclipse is essentially an open-source clone of IDEA, but in reality it doesn't even come close to matching it. IDEA's tagline is "develop with pleasure", and that's not just marketing drivel.

Re:IntelliJ IDEA

[Anonymous Coward]

When I last looked at IDEA (albeit a few years ago) it wasn't very good. Most of the developers revolted at using it because of the number of brain-dead behaviours.

Re:IntelliJ IDEA

[fishdan]

Intellij is SO good. You're really missing out if you haven't tried it yet.

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 ...

Re:KISS applies here.

[Anonymous Coward]

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.

That should be a non-issue these days. Any editor worth its salt supports modelines.

Re:KISS applies here.

[swright]

just thought I'd jump in with my 2 cents worth...

I really like the repository-scoped version number; basically because it lets me say things like '..fixed in r5436' or 'developed in r5401 thru r5411' - and thats all the information anyone needs to know exactly what changed and when. no more info required.

Choosy men choose ....

[halber_mensch]

emacs-21

I was just wondering about this ...

[stuffduff]

Anyone have a grid with links? I'd like to see what's available by platform/OS vs language. Lately all I've been doing is LZMP, but some of these new devices have me wondering if there are any Open Source tools that can run on platforms like Windows Mobile. (Sigh) Maybe I should try and finish porting python to my smartphone first ...

Re:I was just wondering about this ...

[computational super]

LAMP = Linux Apache MySql PHP. LZMP = Linux ??? MySql PHP?

Re:I was just wondering about this ...

[stuffduff]

LZMP: Linux Zope MySQL Python

ddd

[Eternally optimistic]

for debugging, ddd works ok on top of gdb

For C++

[SunFan]

Consider Sun's DBX and the DTrace utility in Solaris 10. I haven't used DTrace much, yet, but I really got a lot of milage out of DBX' ability to track down memory leaks and array overruns, for example. I think Sun's compiler suite (incl. dbx) is still somewhat expensive, but DTrace is free with Solaris.

Re:For C++

[EduardoFonseca]

Try valgrind, its way better than dbx for memory leak detection.

Cheers!

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.

Traditional Tools

[linguae]

For my programming (I'm a student), I currently code in C and Java, and sometimes I play around in Python and Scheme. I pretty much use all traditional Unix tools for my programming. I use FreeBSD as my operating system and vim as my editor. I compile my C programs using gcc, check them for errors with lint, and debug them with gdb. For Java programs, I use the JDK, and I use the python interpreter and the guile interpreter for Scheme, as well. I've heard great things about Eclipse; I'll try that.

sparse tools

[XO]

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

Chained CVS?

[Anonymous Coward]

Use a version control system like cvs or svn to manage your project; it will save you a lot of time.

One thing I'd like to do for various reasons is to use "chained" cvs so that I could checkout (or cvs-update) from a master cvs repository, say cvs.sourceforge.net, to an intermediate repository, say sharedhost.com ( to which other developers might have shared shell access) and then checkout (or cvs-update) from there to my private local repository at privatehost.com, for example:


privatehost $ ssh sharedhost.com

sharedhost $ cvs -d `pwd` init
sharedhost $ export CVS_RSH=ssh
sharedhost $ cvs -z3 \ -d:ext:USERNAME@cvs.sf.net:/cvsroot/PROJECTNAME update MODULE
cvs update: Updating MODULE
cvs update: Updating MODULE/... ...

sharedhost $ pwd /home/me
sharedhost $ logout

privatehost $ cvs -d `pwd` init
privatehost $ export CVS_RSH=ssh
privatehost $ cvs -z3 \ -d:ext:USERNAME@sharedhost.com:/home/me/PROJECTNAM E update MODULE
cvs update: Updating MODULE
cvs update: Updating MODULE/... ...

Unfortunately the second stage despite numerous variations of cvs inits, export CVSROOT=..., etc never actually checks out anything from sharedhost.com except an empty directory tree. All the sub-directories are there, but the files are not actually checked out.

Re:Chained CVS?

[Anonymous Coward]

Huh? That's not going to work. What on earth makes you think that will work? That's like downloading http://google.com/index.html and wondering why your laptop doesn't have a full index of the web all of a sudden.

You need to copy the RCS files (*,v) and then you will have a mirror of the repository. The non-,v files are just noise to CVS, which is why you get an empty tree!

I do something like this to "distribute" my projects to co-workers at other locations. Instead of sending them copies of each branch, I just rsync my private CVS repository and tell them which tags to use.

You need shell access to the repository directory to do this. You must also note that 1) you can't do this while anybody else is using either repository, or you must lock the repository, mirror it, and then unlock both the local version and the remote version. and 2) the mirror is READ-ONLY. Also 3) be careful with CVSROOT files and permissions.

Unfortunately, the sad state of open-source version systems leaves a lot to be desired. What we need is distributed version control that allows mixing CVS/Subversion/etc backends and/or frontends.

I'm keeping my eye on DARCS, SVK, and Arch, but so far everything has been disappointing, especially subversion, which makes branching and changeset management even HARDER than CVS. I.e. instead of automatically tracking merges, or at least letting you have a floating tag, you have to deal with revision numbers and track which changes you've merged, etc. Huge pain in the butt, and assumes a very simple use case. Uhm, sorry didn't mean to gripe....

Re:Chained CVS?

[Anonymous Coward]

> That's not going to work.
> What on earth makes you think that will work?

It's because I don't know enough about CVS! I wish I had time to study the docs in detail. Anyway, thanks for your helpful tips. I do have shell access to the sourceforge cvs repository but I was hoping I could somehow create a fully functioning cvs repository on sharedhost.com, or at least initialise it on sharedhost.com from a plain cvs checkout without having to scp across the ,v files - not sure if that's ever going to be possible. I'd just prefer not to have to rely on having shell access as the method of re-creating those ,v files on sharedhost.com.

I'd agree open-source version management s/w is limited. DARCS looks the most promising to me at the moment; it seems to have a strongly academic pedigree.

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!

[docbombay]

I agree with that -- and it holds true for XEmacs as well (the branch Zawinskian version). Plus, I have yet to find a text-editor in an IDE that's as full-featured or customizable as Emacs. However, I have yet to find a decent JSP mode for it, so I use a combination of XEmacs and NetBeans.

Re:EMACS!

[Dr. Photo]

*grin*

I was a hairy-chested VIM man until I started coding in Lisp.... now I'm a hairy-bearded Emacs man! :-)>>>

Re:EMACS!

[crmartin]

Have a look at MMM and nXML mode.

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!

[Anonymous Coward]

I have yet to find a text-editor in an IDE that's as full-featured or customizable as Emacs.

One thing you might try is Vim. It's much more configurable than emacs, and much lighter, too.

Re:EMACS!

[ksheff]

is it a requirement for an emacs user to have a beard? Or does using emacs make you not want to shave? As another hairy bearded Emacs man, I need to get the correct story for future converts to the Church of Emacs.

Re:EMACS!

[dfj225]

"the cool thing about Emacs is that it has modes for all languages known to man, and then some."

So, I guess that means Emacs was coded by God then? :)

Re:EMACS!

[rose_bud4201]

I'm a die-hard emacs fan, but you do realize that you can get Vi to do all of that too? Emacs just uses Lisp instead of vi-scripting to do its customization.

Cheers to the good luck with Eclipse...biggest PoS software I've ever seen. There should be a law against writing desktop applications in Java, seriously.

Re:EMACS!

[RisingSon]

I can get vi in visual slick edit and kdevelop because it is small and efficient like my happy hacker keyboard. Mostly, I use vim and make because its harmony between depth and simplicity satisfy me. I write my latex in with vim as well as my email. I don't understand how overcustomizing your bloat makes you more flexible for what life will send your way tomorrow. Educate me, please.

Re:EMACS!

[goofyheadedpunk]

Nope, just a Saint.

Re:EMACS!

[Dr. Photo]

I think it just makes your VIM-acquired chest hair migrate upward. :)

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

[Richard_at_work]

You might want to mention that Valgrind is Linux only, if you are on anything else, including *BSD or OSX then Valgrind is useless.

valgrind

[AT]

One tool I've been using a lot of lately is valgrind. Valgrind is a debugging tool that runs an unmodified binary in a special environment to detect memory related problems.

It's great at detecting memory leaks and odd memory management related crashes. In particular, it's invaluable for threading related memory errors. It can be a bit overwhelming though, especially if you use a lot of libraries that are sloppy with their memory.

One limitation: it's pretty platform specific. Originally, it was pretty tightly coupled to the x86 architecture, though I think there's a PPC port in the works.

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.

Re:Unit / regression testing

[snorklewacker]

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.

I think that's the best description of autotools I've yet heard. My advice for makefiles: don't be afraid of using "include". It's portable, really it is. Automake avoids doing any includes, which is one reason it inserts so much godawful boilerplate, to say nothing of its excreble dependency generation scheme -- can you even see what's compiling in all that garbage that automake-generated makefiles spit onto stdout? Just use gcc -MM if you need to regenerate deps -- it won't require gcc for the user, it's purely for the convenience of the makefile maintainer.

Even better, use SCons. Calculates dependencies automatically. Obviously, SCons is not for everyone and every purpose, and god knows some of its darker corners have never seen documentation, but when it is useful, it's a freakin godsend, given that it will portably compile and link exes and libraries, static and shared, on unix and windows, with the same simple file. And it can even output MSVC project files now.

Slickedit

[ncmusic]

Slickedit is still my favorite all around multi-platform, multi-language IDE. The only thing it's really missing is a visual design tool for developing GUIs. But you could always get the plugin and run it with Eclipse.

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.

scons

[Anonymous Coward]

Cool new python-based build tool: scons. More intuitive than make, imo.

Re:scons

[Anonymous Coward]

What could more intuitive than a Makefile containing:

target1: dependency1 dependency2
action1
action2

target2: etc


I don't think "scons" is better than "make"; it comes with all the inelegance and messy syntax you'd expect of a script language.

Re:scons

[ebbe11]

What could more intuitive than a Makefile containing:

target1: dependency1 dependency2
action1
action2

target2: etc

Yep, that's intuitive. It is also extremely rare to see such a simple makefile in a real-life project. Your example does not cater for:

• Debug versus release builds.
• Mixed environments. Very common when doing embedded stuff.
• Multi-platform builds with same source code.

I don't think "scons" is better than "make"; it comes with all the inelegance and messy syntax you'd expect of a script language.

I agree with you here. I've never got my head around scons either.

IMO a good build tool must address the following problem areas in a such a way that each can be addressed more or less separately:

• What? Which files go into the build and which files should come out of it? (BTW, that is what your example does)
• Where?. The location of source and target files should be configurable. Essential if you do debug and release builds with incompatible comiler options.
• How? The methods used to perfom the build.

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.

Re:Choose the right tool for the methodology

[Profane MuthaFucka]

You hit the nail right on the head. I have run into many people who tell me that cvs doesn't work because of the endless conflicts. When I explain to them how the tool is meant to be used, as opposed to pvcs or rcs which lets you lock a file for weeks, the light goes on and they get it. I also explain at that time that sending changes back to a cvs repository is NOT a release. That's why there is a tagging feature in cvs.

Education about the proper way to use cvs right up front has solved all the bitching about cvs in my experience. The people who still didn't use the tool properly were punished for their evil ways, and when they came to me with 100 conflicts on their commits I'd frown at them and explain yet again how to use the tool. Their ignorance and stubbornness doesn't last long, because the only one who suffers is them.

I know, I'm your typical evil team leader. Well, not completely, since I really don't mind explaining how to use a tool multiple times if that's what's required.

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!

[His name cannot be s]

Here's the big thing: only use open tools ...
What happens when IntelliJ stops supporting your version of IDEA and you have to upgrade with money you don't have? Etc.


Ouch.

I'd prefer you not use that as the argument for OpenSource tools. If 3-5 years away a vendor "stops supporting" a tool, that's ok! Panicing because a tool isn't supported anymore isn't any reason to throw it away or stop using it. Right now, I'm on an $850,000 project to replace a peice of software inside a company, that the users are perfectly happy with and want no feature upgrades. The end users get absolutely no benefit to rewriting the app at all. The *only* justification for re-writing it, is that the tool/language that it was written is not supported by the manufacturer any longer. Never mind that the application source code hasn't had to be modified in over 4 years, or that nobody complains about it...*sigh*.

Frankly, I'm appalled at people's (phb's) insistance on using supported tools. How many times have you actually used the support? 99% of the time, Google and the community give me better support and with faster results.

I'd hope that the best reasons for using OpenSource, were: 1- PRICE, 2-QUALITY, and 3-It's Open.

I love OpenSource tools, but I use them where they meet the needs best. I won't use a peice of crap over a commercial product, just because it's opensource.

Other than that, I figure your list is right on. With the exception of jedit.(it's a pig on Aix -> Exceed)

feh;

Re:Use open tools only!

[rjh]

Feel free to substitute "stops the cheap licensing of your current software and gives you a choice between abandoning your software or upgrading" for "stops supporting", as you like.

It's exactly the sort of technique abusive monopolies in the software industry have been known to do.

Re:Use open tools only!

[kraut]

... and use Jython to script you Java stuff

Re:Use open tools only!

[mordemur]

I haven't found a good C++ unit testing framework yet. If you find one, please let me know.

Well, since you recommend jUnit, why not use CppUnit ?

Re:Use open tools only!

[YourMomsCock]

If you are using Java, I would like to recommend Cruise Control for automated, continuous builds. We use it at work and decided on it after looking at Mozilla's Tinderbox and some other similar tools.

Re:Use open tools only!

[eric2hill]

What happens when IntelliJ stops supporting your version of IDEA and you have to upgrade with money you don't have? Etc.

I've only been using IDEA for the last few months, but it seems to me that a folder with some Java source code and an Ant build file (supported NATIVELY with the default IDEA install) would be a piece of cake to build without the IDE entirely. Turn off your FUD machine. IDEA is the best IDE that I've ever used, hands down.

Re:Use open tools only!

[dubl-u]

What happens when IntelliJ stops supporting your version of IDEA and you have to upgrade with money you don't have? Etc.

I generally prefer open tools as well, but I think you take this too far.

My time is worth something, both to me and to my clients. If using commercial tools let me get sufficiently more done, then they pay for themselves. For personal projects, of course, there's no requirement to be efficient (although it's probably a good idea). But for client work, I feel like there's obligation to trade money for time if it results in a net money savings for them.

And IntelliJ's IDEA in particular is a good deal. Their base license prices are very reasonable, and every year they have a sale on personal licenses where you can get it for a couple hundred bucks. For me, I've probably paid 15 cents per hour that I've used IDEA. I'm glad to help support guys that do such good work.

Re:IntelliJ IDEA - agreed!

[Wabbit Wabbit]

I agree with avalys - Intellij is by the far the best IDE for Java. Despite being large and visually cluttered (which most all IDEs are), it doesn't get in your way, and actually helps you be productive.

I've tried using Eclipse many, many times (oh LORD, I've tried!) but something never quite works right, or it acts just a little odd, and it ends up distracting more than helping. I really want Eclipse to succeed, and I will keep trying it, but for now it's Intellij all the way (hee hee, new marketing jingle).

BTW, I've used IDEA on Windoze, Linux and OS X, and it works great on all of them.

A TAB is not 8 spaces!

[stefanlasiewski]

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.

This is a pet-peeve of mine. A 'tab' should never be 2/4/8 space characters, it should be the Tab character.

If people use spaces instead of Tab characters, then this means that *everyone* must use the same number of spaces and indent in the same style or the code is unreadable. BAD! It violates the KISS principal!

If you want Tabs which are 2 characters wide, then set the tab-width DISPLAY in the IDE or editor and use the tab key. That way, every developer can adjust the tabs to their liking. Simple, no silly CVS whitespace-merging issues and it works in most situations.

Any decent IDE or text editor should let you adjust how tabs are displayed.

Personally, I'm a 'set tabstop=4' kind of guy myself. You want a tab to be 1 or 18 characters wide? FINE! Go for it! But just use tabs ... *sigh*

[/end rant]

Re:A TAB is not 8 spaces!

[curunir]

It's not quite that simple.

When working in a team, it's really helpful to agree on a certain line length so that long lines do not wrap. It used to be 80 cols was standard, but with larger displays, this is somtimes increased. If different members of the team have different TAB display settings, it effects when they break the line and put the rest of the statement on the next line. So, if I use a tab display of 2, it's likely that some of the lines of code that I write would wrap on your display.

Also, some languages (notably the C variants) are most easily read when certain elements are aligned properly. Take for instance: (slashdot lameness filter breaks the line, but you can get the idea)

public void someReallyLongMethodNameWhereYouToRunOutOfSpace( SomeReallyLongTypeName type,
SomeOtherLongTypeName otherType) ...


If you use tabs, you can only accomplish this if the desired indenting level is an exact multiple of your tab stop setting. It will also end up being formatted badly for anyone with different tab settings from the code's author.

Also, using tabs removes some of the flexibility you have when using indenting. Even though it's pretty rare, sometimes you come across a situation where using a different indentation allows you to put an entire statement on one line and increase the readability of the code. If you use tabs, this is harder to do.

BTW...our dev team had a 4-space standard (which was frequently broken by someone I'm sure you can guess ;)

Re:A TAB is not 8 spaces!

[swright]

hmm, I agree but I disagree.

yes- tabs should remain as the tab character, no converting to spaces or anything like that.

but it IS important how many characters that is *displayed* as and it is important that developers are consistent about it; because lining up blocks of code, or '//' style comments on the ends of lines (e.g. on the lists of member variables at the start of the class) does depend on the tab width; what lines up ok at tab=4 does not line up ok at tab=2

Re:A TAB is not 8 spaces!

[snorklewacker]

> If you use tabs, you can only accomplish this if the desired indenting level is an exact multiple of your tab stop setting.

Only if your editor eagerly replaces space with tabs. That indent on the second line should be comprised of exactly as many tabs as the first line, followed by spaces underneath all the text to force it to line up. That way when you change your tab width, it remains lined up.

I just stopped caring about the tab religion some coding-standards nazis kept flogging and just set emacs to tabify on load and untabify on save for all files under a certain directory. Made everyone happy.

Re:A TAB is not 8 spaces!

[stefanlasiewski]

Right, it's never simple. I'm just being persnickety because I'm reading "someone's" undocumented, poorly-indented code.

In one-liners and class signatures, I think it's fine to use spaces instead of tabs. In signatures, you're really just lining up characters with characters.

But once you get to the body, you better use a Tab :)

But really, if a team just settles on one standard and modifies the tab key appropriately, I'm happy.

Re:A TAB is not 8 spaces!

[torpor]

oh my god, you use an editor that lets you set the tab display? wow!!

seriously though, ''indent -ts4 -kr hw.c", think of /usr/bin as a toolbox, not a repository.

Re:A TAB is not 8 spaces!

[dtfinch]

I hate people crapping up nicely tabbed code with their space indents. Especially they have their indents set to 3 or 5 spaces. Stick to tabs and everyone can make them as narrow or wide as they like.

Always use tabs.
Use only tabs.
When breaking a line, it doesn't have to line up. But sometimes you can find a more appropriate place to break it.
Identifier names should be as long as needed for their purpose to be clear, and no longer.

public void someMethod(
SomeType type,
SomeOtherType other
) { ...

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.

c++ test framework

[Anonymous Coward]

dont know jack about unit testing, so cant tell you how good it is, but this just got taken up by a project i use:

http://cxxtest.sourceforge.net/

Re: Rational Rose

[Myen]

I agree that Rose is a pain. (Caveat: student here, so maybe we just suck)

We tried to draw some class diagrams, sequence diagrams, etc. After struggling with Rational Rose, we found it easier to just do things semi-manually in Visio, rather than use the built-in capabilities of Rational Rose. Havn't tried using the code generation / reverse engineering capabilities of Rose though. In generally, I just find its UI to be annoying, even if its output isn't necessarily so. Not to mention that there was no obvious way of printing out the diagrams (I ended up taking screenshots and printing that).

If you use MS Visual Studio: If you can, try to use the older versions of Rose if you must. The new one (XDE) integrates with VS, and it completely drags VS down.

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"? ;-)

Tools book from O'Reilly coming this summer

[Matt_Doar]

There is an upcoming book from O'Reilly named Practical Development Environments about development environments for software - the tools you use and how you use them. It's mainly for Unix and Windows. The draft for review is nearly complete. I'm the author.

I've no idea what animal it will have on the cover. Any suitable suggestions?

Re:Tools book from O'Reilly coming this summer

[Anonymous Coward]

How about a chimpanzee holding one of those sticks they use to dig ants out of an anthill?

Re:Tools book from O'Reilly coming this summer

[Anonymous Coward]

A beaver building a dam! Although O'Reilly may have used a beaver previously and you probably can't fit a beaver dam on the cover with the animal.

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.

Re:Stuff I use

[Anonymous Coward]

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

References are not polymorphic, and therefore are not suitable for the public interface of most any C++ code. Nor can they be used in C interfaces. The number of strikes against references grows larger the longer you look at it, to the point where you shouldn't ever use a reference unless you're absolutely certain that you need one. Basically they're necessary for operators, and that's about it.

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.

Re:UltraEdit

[Anonymous Coward]

This editor is the best I ever saw (dymanic syndax higlighting, word completion,..., backup system, direct working on ftps, customizable limiters :D It has them all), and I'm using it on all my windows environments.
Gnome devs should look into it some time to improve their gedit (which I like too, but it lacks almost all features) :D

Re:UltraEdit

[Albigg]

UltraEdit is nice and tight. I love how it feels, however SlickEdit has some features that I really enjoy like finding all the references to a symbol really quickly. "Pushing" to the definition of something and "Poping" back to your current location is priceless in today's world of reading code more than writing it. If UltraEdit had that ability I'd be all over it. Ultraedit does have ctag support, but they are hard to work with, they aren't as integrated as SlickEdit's. Because SlickEdit just doesn't have the feel that UltraEdit has.

Doxygen

[Anonymous Brave Guy]

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.

Just as an aside, Doxygen is actually quite a good tool for writing general documentation as well; constructing project documentation intranets is pretty straightforward. The fact that it integrates well with existing code, picks up clever comment markers, etc. makes it easier to write design documentation that links directly to the implementation survey stuff, but it's good for a lot more than just that.

pico

[Anonymous Coward]

pico. or nano.
everything else sux.

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:My Favs

[spagetti_code]

Yeah, Dev-Cpp sounds very cool, until you try to debug. You cant set breakpoints once the app runs.

Re:Netbeans and Where is Emacs

[geoaxis]

Agreed . Netbeans 4.0 has improved. I am my slef getting used to complete opensource tools for development. I only have an x86 machine and use WinXP and Gentoo (some times) for Dev (though I have a project total linux in progress) for C++ gcc can be used in both caes (CygWin and MinGW for windows) But so far i ahve only stuck with JDK from Sun. I would like to try out Jikes some day. Coming back to Netbeans . its an awsome IDE but those of you who want to spend some time and configure their IDE for themselves ..it is not the complete solution. In the end i can only think of either eclipse or Emacs (surprsingly no one mentioned it) I plan to spend some time making my own IDE out of Default Emacs. Atleast it would help me master language features Also ant+subversion for java and cvs+gnu make for cpp were my conclusions. Its not about having exposure to maximum tools ..or the best tools. But its about using the RIGHT tool (i think) :) Also ..KDEVELOP is good and is available for Windows too with KDE Cygwin project (buggy though) I still think that sticking to a single documenation style ie doxygen would be better.

Re:IntelliJ IDEA - agreed! - me too!

[Pyr05x]

Just lending support for IDEA... best java IDE i've found

on the Java side-Grasping for code.

[Anonymous Coward]

Jgrasp

Source-navigator

Jedit

Wet Ware

[HalWasRight]

I need tools that will handle auto documentation, unit testing, design, file editing, and the like.

How about hiring PEOPLE to do this?

Kylix (C++ Builder)

[haydies]

I would personaly use Kylix, because it compiles better then any thing else.

I'm fairly sure I remember that Borland got the linux kernel to build with Kylix and it was faster and smaller.

Borland make the best compilers.

I'd also go for J Builder, because its cool, and its writen in Java. It also makes life easy for you.

Of course, I'd never write C, but what the hell, there is no accounting for taste :-)

Re:UltraEdit - Seconded

[Anonymous Coward]

I completely agree. I've been using UltraEdit-32 for almost eight years. I've grown so accustomed to its flexibility and general usefulness (converting unix to dos or mac linefeeds automagically?) that I feel crippled in things like JBuilder.

The down side is, I feel productive enough in UE32 that I have not spent time learning Eclipse . . .

Re:Stuff I use

[E_elven]

Er, references are not polymorphic? Surely you're on crack?

Use JAM

[gothmog666]

Jam is by far the best make tool I ever used. Its so much simpler then all other makes. Yes its out of the standart, but it works flawlessly, althought kinda unmaintained.

Slickedit DOES do GUI building!

[Elrac]

UPDATE: Version 8.0 of SlickEdit (the latest greatest) includes a Java GUI designer. It allows drag-and-drop GUI editing like you know from other products, and produces reasonably decent Java code.

It's a wee bit quirky, perhaps pending some small bug fixes, but it works and will even use the much-dreaded GridBagLayout.

Impressive, I think, for a tool that's supposed to be an editor. I strongly second the recommendation of Visual SlickEdit as an editor and, a little more reservedly, as a Java GUI builder.