patch for readability of return codes

[Adrian Otto]

Nick,

I'll review this patch and put it into 0.7.4 unless Eric Raymond objects. We
should plan to use bogofilter-dev at aotto.com for discussing our development,
patches, and testing. You can subscribe using this address:

bogofilter-dev-subscribe at aotto.com

Thanks,

Adrian

PS: Version 0.7.3 is out on the bogofilter.aotto.com FTP site, and will be
announced later today as soon as I finish writing the FAQ. All your other
patches have already been rolled in.

> -----Original Message-----
> From: Nick Simicich [mailto:njs at scifi.squawk.com]
> Sent: Thursday, September 12, 2002 1:49 PM
> To: David Relson
> Cc: bogofilter at aotto.com
> Subject: Re: patch for readability of return codes
>
>
> In code review, one always has to go back to bogofilter to see what is
> produced as a return code.  Using the constant adds the extra step of
> verifying the content of the symbol and that it is used consistently.
>
> Really, take my word for it, I used to do this for a living. Whenever you
> use symbolics to represent constants, you add the extra step of insuring
> that the constants are defined only in one place, to only one value (I
> have read code where the same constant had different values in different
> places or under different cirumstances) to the work of reading the code,
> while requiring that you read and debug exactly the same amount of code
> outside of the constants. Yes I know that it is standard practice, but it
> is also bad practice.
>
> On Thu, 12 Sep 2002, David Relson wrote:
>
> > My patch also clarifies the following bit of code from main.c:
> >
> > 	int	status = bogofilter(0);
> >
> > 	... [snip] ...
> >
> > 	if (inheaders && strncmp(textend->block, "Subject:", 8)==0)
> > 	    printf("X-Spam-Status: %s, tests=bogofilter\n",
> > 		   status ? "No" : "Yes");
> >
> > To verify the correctness of this code, one must go back to
> bogofilter() to
>
> call this bit of work (a)
>
> > see how it determines its zero/non-zero status and must then check for
> > consistent usage to verify that "No" or "Yes" is printed correctly.
>
> call this bit of work (b)
>
> > With
> > my return codes, one can first read bogofilter()
>
> same work as (a), above
>
> > and see that it has a
> > sensible calculation for returning RC_SPAM or RC_NONSPAM
>
> exactly the same work as the first bit of (b), above
>
> > and then one can read
> >
> > 		(status == RC_NONSPAM) ? "No" : "Yes"
> >
> > and apply a similar check to see that status is used sensibly.
>
> Exactly the same as the second part of (b) above.
>
> > If both
> > chunks of code pass the "sensible" test, then the code is demonstrably
> > consistent and correct.
>
> (c) one has to verify that RC_SPAM and RC_NONSPAM have different values
> and that they are defined the same way in the different modules and that
> they are used the same way.
>
> In either case one has to do (a) and (b).  Given the obfuscating
> symbolics, one now ha to do the extra work of (c), which is the only real
> difference between using obfuscating symbolics and not using obfuscating
> symbolics.
>
> What you have just said was that if you do not treat a cold, it will take
> you fourteen long days to get better, but if you do treat it, you will be
> better in two short weeks.  You have ignored the fact that the treatment
> you recommend, sticking red hot needles up your nose, is painful and
> useless. :-)
>
> I fail to see how you have clarified anything.
>
> > David
> >
> > Note:  the consistency of the code could be improved by making
> bogofilter()
> > return rc_t, the return code type.
>
> Please, it is already dependent enough on whacky stuff.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bogofilter-unsubscribe at aotto.com
> For summay digest subscription: bogofilter-digest-subscribe at aotto.com
> For more commands, e-mail: bogofilter-help at aotto.com
>
>


For summay digest subscription: bogofilter-digest-subscribe at aotto.com