[lug] C code quality tools

[Chris Riddoch]

Evelyn Mitchell <efm at tummy.com> writes:
> In general, having a clear understanding of what you're trying to do before
> you start coding is the single most important factor in software quality.
> All these resources address that. The first item is the best book on
> software construction written in several years.
> 
> _The Pragmatic Programmer_ by Andrew Hunt and David Thomas
>   Addison-Wesley October 1999
>   http://www.pragmaticprogrammer.com/
>   http://www.pragmaticprogrammer.com/ppbook/extracts/rule_list.html

Well, that'll teach me to borrow a book and not start reading it until
after my next project's due - one of my friends gave me a copy of this
about a month ago. I'm now 30 pages into it, and finding it's saying
all the things that seem naturally and intuitively the right way to go
about handling programming projects.

> If you know what you need to do, you can make your software tell you
> when you've done it, and tell you when it doesn't do it any more. Unit
> tests are a good thing.
> Test first programming:
>   http://www.c2.com/cgi/wiki?CodeUnitTestFirst
>   http://www.pragmaticprogrammer.com/articles/stqe-01-2002.pdf

Good thought. This last project seemed to work just fine under one set
of circumstances, where the program state was stored in external files
- it would read state, perform some function, and re-save it.  I was
doing this to aid debugging, because hexdump -C is simpler than using
GDB for what I was doing... the system worked, and it felt like solid
code.

Then I tried to link the functions to a library that was designed to
test the system with a sequence of function calls, and naturally, my
program promptly segfaulted after the first.  Even adding calls to my
save-state and restore-state functions at the entrance and exit of the
others didn't manage to fix it.

More comprehensive unit-testing would have shown me these problems
before the system got too big. And lclint would have shown me several
dozen errors scattered across my source. checkergcc would have helped
me find the source of those segfaults.

This feels frighteningly similar to the previous way I got burned -
not testing my program in the exact same environment it would be used
in until it's too late.  Of course, it would have been better had I
known the nature of the testing environment when I started the design
phase, because it would have changed the priorities I had when I
began.

> Planning doesn't have to be complicated or difficult.
> Extreme Planning
>   http://www.c2.comj/cgi/wiki?ExtremePlanning
>   http://xplanner.sourceforge.net

I downloaded the xplanner source. I'm not sure I want to bother trying
to install MySQL right now, and I don't have Tomcat set up, either.

Planning is something I've managed to do okay on, though. I did a
high-level design fairly early on, and had it worked out on paper. I
knew what each major function would need to take, return, and do, and
how it would fit together.

> If you're writing code for reuse, design by contract can make your
> libraries more robust.
> Design by Contract:
>   http://www.c2.com/cgi/wiki?DesignByContract

This *does* makes things easier, yes. I've tried using that before,
but unfortunately it was long enough ago and isn't a well-formed
habit now.

In any case, thanks for the resources!

-- 
Chris Riddoch       | epistemological
socket at peakpeak.com | humility