10 Answers
10

Emacs/Vim/Eclipse/... - Personally I am an Emacs user. If you find the control sequences tire your pinky, just Viper-Mode it up. Emacs is so well integrated into unix, making it very easy to control everything all from one place. Vim also does a good job here, but I find Elisp to be a much more powerful extension language than Vim Script. One could talk for hours about all of the ways to set up Emacs for C development. Flymake Mode has been mentioned, and is a super start to things. I am not familiar with Eclipse, I do not find it leaves enough room on my screen for code, nor do I like how bloated it is(Vim users will say the same thing about Emacs). I am also unfairly biased against anything written in Java, for purely aesthetic reasons.

Ctags - Tags your C(or many other language) functions so that Vim or Emacs or whatever can do a little bit of hyper-text linking in your files. Say you're wandering around and you see a function and you're scratching your head saying "What does that one do again? The naming is a bit vague." Plink-plank-plunk, you can zap straight to it's definition.

Cmake/Gnu-Autotools - Make is great, but at some point you need to abstract things a bit so that your project can build itself on all sorts of systems you have no way of testing for. If you only need people to build your code on a *nix, Autotools is great, but realy you should familiarize yourself with Cmake anyway. The Cmake team build code in every conceivable configuration possible and make sure that you don't have to go through the headache. If you want your project to be easily picked up buy others, one of these tools is crucial.

Git/Mercurial/Subversion/... - You could spend months researching version control software, but you should probably just go with Git. It's solid, it's distributed, the @$!#%& Linux Kernel is tracked with it. If it's good enough for Linus, it's got to be good enough for you. I also hear good things about Mercurial, apparently G**gle uses them, so it's probably not bad. Some people appear to like Subversion and CVS and whatnot. I don't like them because they are monolithic, which to me is very inconvenient and limiting.

Stumpwm/wmii/XMonad/... - At some point you're going to realize that anything you can do to keep your work flowing is going to greatly improve your output. One of the best ways to keep your brain from breaking it's context is to switch to tiling, KEYBOARD DRIVEN window managers. I am a personal fan of StumpWM, the Emacs of window managers. Fully implemented in an on-the-fly customizable Common Lisp process, anything you find yourself doing repetitiously can be banished away into functions and bound to commands. Great stuff. I don't know much about any of the others, but maybe further elaboration is better left to another thread. USE KEYBOARD AS MUCH AS POSSIBLE.

GDB - I'm not familiar with other debuggers, but this appears to be the de-facto standard.

Valgrind - I don't know of anything else that does what this does so well. Valgrind is crucial for all those pesky profiling/memory leak hunts you want to go on. You just can't write code with malloc/calloc without Valgrind.

I just made it a community wiki, so you can add those in there however you feel is appropriate. Performance Counter is looks to be Linux only? I'll look to confirm/deny this, but if so this should at least be noted in it's suggestion.
–
Eli FreyAug 13 '10 at 3:42

I persisted with Vim for a while, it's worth knowing the VIM basics as you will always find a UNIX box somewhere that only has that, but I tried Emacs and haven't looked back. Eclipse is a 'modern' alternative, I have all three on my system !

It's very much a personal preference, so I don't think I can do much more than tell you what I use. I have Emacs set up with Flymake mode, which periodically compiles the file you're working on and parses the compiler output to figure out what errors you've made. It hilights the errors/warnings in the buffer, and shows the associated compiler error message

If you're doing C development under Unix/Linux, you absolutely have to be using Cscope if the project is any significant size.

Cscope is a developer's tool for browsing source code -- jump to function foobar's definition, find all places where the variable foo is referenced, find all files including bar.h, change all occurrences of bar into baz, etc.

Also, you mentioned Vim in your post... here is a tutorial on using Vim & Cscope together.

I edit C with Vim in the console. I employ makefiles and have a number of compilers to test my code against, including gcc, clang (LLVM) and icc. Other things I consider part of my development environment: the use of grep, debuggers and valgrind. A scripting language for more complicated builds. Git for version control.

More important in my mind than what you use to edit the code is how you structure your code. How to lay that out is probably a question for Stack Overflow, but, as you asked, I often have a separate directory for object code not for distribution and another folder for the resultant binar(y|ies). I have a testing folder which contains more C files that use all the generic code I'm writing and these I valgrind, along with the final project file.

You can try Motor IDE. It's curses based so you should feel like at home (tm) .) It's also a bit sad because it's not being maintained for 5 years now so somethings might be broken. Although still - I believe it's worth a try.