Pikt Rule Sections
[The following is the gist of a message sent to another contributor.]
In looking at your script, I noticed that you group all of the =postfix_checkfor()'s under a single rule. I would instead have each =postfix_checkfor() in its own separate rule.
The idea behind Pikt rule sections is to group together code to check for one thing. It seems to me that you are checking for five different things here, hence my thinking there should be five separate rules.
I would have done something like this
rule // Check for attachments =postfix_checkfor(...) rule // Check for unknown recipients =postfix_checkfor(...) rule // Check for relay attempts =postfix_checkfor(...) ...
The PIKT Reference has this to say about rules:
The input processing loop comprises one or more rule sections. Strictly speaking, there is never a need to break up the set of input processing statements into separate rule sections, but doing so helps clarify program logic. (A rule line is also a handy place to put comments.) A rule section, then, usually groups together program statements pertaining to a single thing, just one attribute of the current input line.
There are several other non-trivial benefits to employing multiple rule sections (more than the required single rule). You have a few additional flow control statements to play around with, including
again repeat the current rule leave leave the current rule and go on to the next
not to mention
skip n skip ahead n input lines, and resume with the first rule
Also, pikt-1.16.0pre2 introduces the new #rule() (aka #rulenumber()) function. See the item at the PIKT NEWS web page for #rule()'s use as a debugging aid.
I think that employing multiple rules versus just a single rule is more than a mere stylistic question (akin to debates about what's the best brace-and- indent style in Perl or C). Using Pikt rule sections and multiple rules intelligently can have important benefits, most especially for script intelligibility (also for encouraging code comments).
The script as you wrote it is pretty clear enough. I'm only trying to point
out a nuance you may have missed.
For more examples, see Developer's Notes.