Programming Tools You've Used? 179
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."
Latex / Kile (Score:2, Insightful)
Re:Latex / Kile (Score:5, Funny)
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 (Score:3, Informative)
Java: vim, GNU make, javamake, javac, javadoc, IntelliJ IDEA.
Re:Sutff I use (Score:5, Informative)
KDevelop
Re:Stuff I use (Score:3, Informative)
Re:Stuff I use (Score:3, Funny)
Surely, "Thanks for the object reference"?
Re:Stuff I use (Score:2)
Re:Sutff I use (Score:3, Informative)
Re:Sutff I use (Score:2)
Re:Sutff I use (Score:2)
Re:Sutff I use (Score:2)
Re:Sutff I use (Score:3, Informative)
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 t
Another Eclipse endorsement (Score:2)
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.
Re:Sutff I use (Score:2)
Learn to write your own documentation. (Score:4, Insightful)
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. (Score:5, Interesting)
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.
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).
Doxygen (Score:2)
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 imp
Re:Learn to write your own documentation. (Score:3, Insightful)
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. (Score:2)
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
Re:Learn to write your own documentation. (Score:5, Funny)
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. (Score:2)
Re:Learn to write your own documentation. (Score:3, Insightful)
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 ever
vim (Score:2, Funny)
Re:vim (Score:5, Interesting)
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 (Score:3, Interesting)
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
Re:vim (Score:2)
Re:vim (Score:4, Informative)
Click here to find out: GCJ [gnu.org]
Eclipse (Score:2, Informative)
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 muc
Re:Eclipse (Score:1)
Re:Eclipse (Score:2, Funny)
The truth sometimes hurts.
Re:Eclipse (Score:2)
Re:Eclipse (Score:2)
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
Re:Eclipse (Score:3, Insightful)
Re:Eclipse (Score:2)
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.
Choose the right tool for the methodology (Score:4, Insightful)
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:Eclipse (Score:4, Informative)
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 (Score:2)
Looks like there is still quite a lot of maturing left before SVN is ready...
Re:Eclipse (Score:2)
Re:Eclipse (Score:2)
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 a
Don't write C++ without boost! (Score:5, Insightful)
boost also has a nice unit testing library [boost.org]. I use it for all my C++ code.
Re:Don't write C++ without boost! (Score:2)
Re:Don't write C++ without boost! (Score:3, Informative)
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.
Re:Don't write C++ without boost! (Score:2, Informative)
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
Re:Don't write C++ without boost! (Score:3, Informative)
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:
Re:Don't write C++ without boost! (Score:2)
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! (Score:3, Insightful)
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 nobod
Re:Don't write C++ without boost! (Score:2)
Jikes (Score:3, Informative)
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 [gnu.org].
Nothing is perfect, but... (Score:4, Interesting)
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 [apache.org] is very useful for project management duties.
Re:Nothing is perfect, but... (Score:2, Informative)
I prefer TestNG [beust.com] 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... (Score:2)
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... (Score:2)
Plus blue is my favorite color, so purple isn't too bad.
Netbeans (Score:4, Insightful)
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 [developer.com]
Re:Netbeans (Score:5, Funny)
IntelliJ IDEA (Score:2)
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 (Score:2)
on the Java side (Score:4, Insightful)
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 (Score:2, Informative)
KISS applies here. (Score:5, Insightful)
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. (Score:3, Informative)
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 re
Re:KISS applies here. (Score:2)
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.
A TAB is not 8 spaces! (Score:2)
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
Re:A TAB is not 8 spaces! (Score:2)
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,
Re:A TAB is not 8 spaces! (Score:2)
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 emac
Re:A TAB is not 8 spaces! (Score:2)
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! (Score:2)
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! (Score:2)
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! (Score:2, Insightful)
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
I was just wondering about this ... (Score:2)
Re:I was just wondering about this ... (Score:2)
For C++ (Score:2)
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.
Tools I use (Score:2, Informative)
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, ea
Traditional Tools (Score:2)
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 (Score:3, Insightful)
EMACS! (Score:5, Insightful)
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! (Score:2)
I was a hairy-chested VIM man until I started coding in Lisp.... now I'm a hairy-bearded Emacs man!
Yeah, that too... ;-) (Score:4, Insightful)
"A guy on Slashdot" even made it to Paul Graham's collection of Lisp quotes: [paulgraham.com]
"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:EMACS! (Score:2)
Re:EMACS! (Score:2, Informative)
Oh and its more "Lazy Coward" than "Anonymous Coward"
Re:EMACS! (Score:2)
So, I guess that means Emacs was coded by God then?
Re:EMACS! (Score:2, Funny)
Re:EMACS! (Score:2)
Valgrind (Score:4, Informative)
Valgrind [kde.org] 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 (Score:2)
valgrind (Score:2)
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
Unit / regression testing (Score:3, Informative)
QMTest [codesourcery.com] 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:
Re:Unit / regression testing (Score:2)
I think that's the best description of autotools I've yet hear
Keep it relatively simple (Score:3, Interesting)
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 [pcug.org.au], 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 [doxygen.org] 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.
Use open tools only! (Score:5, Informative)
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 [jedit.org] 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 [gnu.org], but it's considerably more friendly to use.
- Boost [boost.org]. If you're writing C++ and you're not using Boost, you're committing a crime against yourself.
- Python [python.org]. 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 [swig.org] is another tool that's excellent for creating scriptable C++ applications.
- Subversion [tigris.org] for your version-control needs. Nothing else will do.
- Doxygen [doxygen.org] 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 [redhat.com] 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 [gnu.org] 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 [eclipse.org] is an excellent Java IDE. jEdit [jedit.org] also fits the bill nicely, if all you want is an editor. I use both frequently, and am quite pleased with both.
- Subversion [tigris.org] again for your version-control needs.
- jUnit [junit.org] for unit tests. Your code's incomplete unless you've written unit tests for it.
- Javadoc for documentation. I would recommend Doxygen [doxygen.org], but it's quite possible you'll be deploying your applications on machines that don't have it installed.
- Ant [apache.org] for all your build needs.
Hope all this helps.Re:Use open tools only! (Score:2)
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
Re:Use open tools only! (Score:2)
It's exactly the sort of technique abusive monopolies in the software industry have been known to do.
Re:Use open tools only! (Score:3, Informative)
Re:Use open tools only! (Score:2)
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.
Don't make ME use YOUR editor (Score:3, Insightful)
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 (Score:3, Informative)
If you're doing any J2EE work, I highly recommend Eclipse with the myEclipse plugin [myeclipseide.com]. 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 [slickedit.com]. 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 (Score:2)
My Favs (Score:2, Informative)
Re:My Favs (Score:2)
Re:My Favorite JAVA IDE, (Score:2)
Re:scons (Score:2)
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:
I don't think "scons" is better than "make"; it comes with all the inelegance and messy syntax you'd exp