<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>Brendon J. Colby wrote:</DIV>
<DIV><BR>| One thing I saw mentioned was "unit testing." As a (relatively
new)<BR>| python programmer, I've begun writing my code with unit testing
in<BR>| mind i.e. writing the unit tests before I write the function,<BR>|
testing returns for every possible input and output scenario I can<BR>| think
of. I think this is a very wise thing to do (testing input<BR>| output scenarios
at least, whether before or after writing<BR>| functions). This way any time I
change something my unit test will<BR>| (hopefully) tell me if I messed
something up. </DIV>
<DIV> </DIV>
<DIV><FONT size=2>C's preprocessor makes it easy to incorporate unit test code
right into the application or system using something like:</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>#define UNIT_TEST</FONT></DIV>
<DIV><FONT size=2>...</FONT></DIV>
<DIV><FONT size=2>#ifdef UNIT_TEST</FONT></DIV>
<DIV><FONT size=2> /* Unit test code here */</FONT></DIV>
<DIV><FONT size=2>#endif</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>For individual library functions, I typically include a
minimal main program with "cooked" test data in the same source file, like
this:</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>int function_name(int param)</FONT></DIV>
<DIV><FONT size=2>{ /* function code */</FONT></DIV>
<DIV><FONT size=2> return value;</FONT></DIV>
<DIV><FONT size=2>}</FONT></DIV>
<DIV><FONT size=2>#ifdef FUNCTION_NAME_TEST</FONT></DIV>
<DIV><FONT size=2>#include <stdio.h></FONT></DIV>
<DIV><FONT size=2>#include <stdlib.h></FONT></DIV>
<DIV><FONT size=2>int main(void)</FONT></DIV>
<DIV><FONT size=2>{ int cooked_data[] = /* values for testing
*/;</FONT></DIV>
<DIV><FONT size=2> /* Test program code */</FONT></DIV>
<DIV><FONT size=2> return EXIT_SUCCESS;</FONT></DIV>
<DIV><FONT size=2>}</FONT></DIV>
<DIV><FONT size=2>#endif</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>This approach ensures that the regression test doesn't "get
lost" when files are backed up, etc.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><BR>| Also I'd like emphasize 'Learn how the obfuscated and/or
"efficient"<BR>| and/or "mind blowing" code works, don't be tempted to use it
in<BR>| production code.' I really despise "cute" code and/or comments. I<BR>|
think straight forward, easily readable and self-documenting<BR>| approaches are
far more beneficial in the long run. I tend to be<BR>| quite methodical and
machine like when I code, even in the <BR>| comments, and stay away from the
"mind blowing" and the "cute."<BR>| Although I do like making perl do as much as
possible in one line...</DIV>
<DIV> </DIV>
<DIV><FONT size=2>In general, yes. Note that legitimate exceptions abound. I
worked with a gentleman on comp.lang.c whose S/390 application was running *way*
too slow. We put together a super-efficient (but messy) piece of code to replace
*one* printf() call. That change caused his program to run in half the
original time - and produced considerable satisfaction for all
involved.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>It's worth mentioning, though, that this tuning
exercise took place _after_ the entire application system had been written,
debugged, and made fully functional. Sometimes it's necessary to roll up your
sleeves and make some mud - but it should always be after a best attempt to do a
straightforeward implementation - and it should always be fully explained in the
documentation.</FONT></DIV>
<DIV><BR>Morris Dovey<BR>C links at <A
href="http://www.iedu.com/c">http://www.iedu.com/c</A></DIV></BODY></HTML>