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

Reply via email to