Bruno said: >> I'm currently learning C. In many languages, you hear lots of stuff likes 'unit testing', 'refactoring', 'agile programming' and others... It seems that these techniques are not very present in C programming (whereas check framework is in packages, it seems too complex) Looking quickly at the OpenBSD's CVS, I found no unit test. I won't debate on the merit or cost of this approach, and I'm not really fond of it (add not-so-usefull complexity) but I'm just curious to know why OpenBSD developpers choose to not use this technique for userland tools (for kernel, it's obvious :). <<
First, I'm not (perhaps yet) an OpenBSD developer, so I can't speak for them. I write a lot of C (and assembler), but my speciality is embedded work (e.g. instrumentation, controllers, the design of which uses embedded micros). In that field, the methodologies you cite are indeed used, albeit not necessarily fully and individually, and perhaps not as widely as they should be. With embedded devices, bugs are less forgiving. I've now spent nearly three decades acquiring techniques and methodologies that allow me to provide bug-free software (actually, usually firmware) by design, rather than by debugging (something I actively try to avoid) [1]. The methodologies you cite each contain valuable lessons and techniques, but I rarely come across full-blooded devotees of any one or more or them. Regression testing has its uses, and in some cases is absolutely necessary, but in others impractical. There are many other appropriate techniques; it's a large area which pretty much amounts to the entire craft of software engineering. There are many good books (perhaps starting with The Mythical Man-Month). Mostly, IMO, it's an attitude: developing an approach (to both design and coding) which results in clear, maintainable, and above all robust code. Back at OpenBSD, the developers are proactive on these things, and are actively encouraging the use of certain idioms and alternatives to classic library functions to avoid common bugs (e.g. buffer overflows). I've yet to read much source, but I'm confident you'd find it enlightening. [1] A typical response to this claim is "get real!" or "must be really trivial software, then". I can understand that; the software industry at large is fixated on the myth that complex software must be buggy. I don't buy that; it's a question of managing complexity. Reducing the complex to a collection of inter-communicating trivial things is one of the most important skills there is. Steve http://www.fivetrees.com
