For a precedent on doing inline unit testing (i.e. something to mine for implementation ideas) see Test::Inline, which I implemented for Perl.<br><br><a href="http://search.cpan.org/~adamk/Test-Inline-2.208/lib/Test/Inline.pm">http://search.cpan.org/~adamk/Test-Inline-2.208/lib/Test/Inline.pm</a><br>
<br>Adam K<br><br><div class="gmail_quote">2009/2/25 Tim Post <span dir="ltr">&lt;<a href="mailto:echo@echoreply.us">echo@echoreply.us</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
I am soon to upload iniparser as a converted module and am correcting<br>
some things in the original author&#39;s code.<br>
<br>
Excessive whitespace bugs me .. so do merge conflicts resulting from<br>
correcting those instances if I&#39;m going to maintain the module. I&#39;d<br>
rather just pull patches from the author (if they make sense) apply them<br>
cleanly and upload a new version. Yeah, I&#39;m going to hit conflicts<br>
anyway, but far less if I&#39;m correcting cstyle.<br>
<br>
If someone shares my nits, they can modify the module in place, merge<br>
conflicts become their problem.<br>
<br>
So, is a score of 4/5  (or after GSOC 6/10) acceptable, if the only<br>
thing that lint complains about is whitespace?<br>
<br>
Secondly, can we introduce a central doxyfile (I&#39;m happy to maintain it)<br>
so that documentation per module can be extracted? Modules that have<br>
such comments can be easily added to this file in a uniform way.<br>
<br>
Otherwise, each module would have its own, generated documentation would<br>
be inconsistent at best and we&#39;re riddling the grand makefile with shell<br>
hacks.<br>
<br>
Finally, we have unit tests. Could someone comment a function like this<br>
and have them generated automagically? (Rusty, please forgive the winged<br>
comment, I&#39;m making it compatible with doxygen)<br>
<br>
/**<br>
 * Check if foo can bar<br>
 * @param .. yadda yadda<br>
 * @tap++<br>
 * @test ok1(foo(foo[1], foo[2]));<br>
 */<br>
<br>
... that may surely tickle a GSOC student :) Its not likely that they&#39;d<br>
accomplish it in a summer, but a good project to design. The generated<br>
test suite would need human attention (how else could it get foo[] ?)<br>
but:<br>
<br>
1 - It breaks the tests totally at build time if someone forgets<br>
something<br>
<br>
2 - Its much easier to keep up on unit testing, (if done correctly) with<br>
very little time involved.<br>
<br>
<br>
Cheers,<br>
--Tim<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
ccan mailing list<br>
<a href="mailto:ccan@ozlabs.org">ccan@ozlabs.org</a><br>
<a href="https://ozlabs.org/mailman/listinfo/ccan" target="_blank">https://ozlabs.org/mailman/listinfo/ccan</a><br>
</blockquote></div><br>