Rob van der Heij writes: <begin snippet> PS In my "programming quality metrics" I frown upon duplicated comments (so the same remark multiple times in a module). Either they are trivial and describe the instruction rather than its purpose, or it's copied code where the programmer did not bother to change the comment accordingly... </end snippet>
and this seems to me to be an admirable sentiment when its target is, notionally at least, code written ab initio. I have some difficulty with it because almost the only such code I write is within macros. When these macros are expanded the comments they contain then often appear repeatedly, so that the comment attached to the protoype statement | DC AD(&bt_label(&j)) --branch-table element within a loop within such a macro may appear in a dozen successive statements in generated code. Or again, I may use such a construction as |&consistent setb (&losub le &hisub) --consistent bounds? | aif (&consistent).consistent_bounds --if so, ok |&abort setb 1 --no, set quit switch | mnote &el,'&mnpfx.017. . . ' | .consistent_bounds anop repeatedly mutatis mutandis within a macro, and this stereotypy seems to me to be a virtue rather than a vice. There are many ways to write code well; and there is probably nothing to be gained from trying to identify some one best way to do so. In examining another programmer's code I expect to discover that, since he or she has not done something the way I would have done it, the result is 'bad' ; but this predictable conclusion is not helpful. I try then to push on to a second-stage evaluation: has a good job been done within this [alien and eccentric] framework? The answer to this question is the important one. John Gilmore, Ashland, MA 01721 - USA
