On Sunday, 07/13/2008 at 11:47 EDT, Chip Davis <[EMAIL PROTECTED]> wrote:
> The problem with Rexx code is that it is, in general, so transparently clear > that one rarely encounters more than the most desultory commentary. For this > reason, clean logic, descriptive variable and routine names, and explicit > argument passing become far more important. That (and the presence of "Signal > ON NOVALUE" at the top) are my primary indicia of a good Rexx programmer. A good software developer (Rexx or otherwise) will document his or her objective (intent - what is this program is supposed to achieve), design to achieve the objective (how it is supposed to work), and code (implementation). But you only document what isn't obvious to a person of reasonable skill. The more obvious you make your code, the fewer comments will be required. That is, there may be no need to document Call Process_Command_Parameters(parms) as opposed to Call DoIt /* process cmd parameters in global var PARMS */ Of course, there are no hard and fast rules (unless your organization has them), so the extent to which you [need to] adopt good development processes is a matter of good judgement and professionalism. Alan Altmark z/VM Development IBM Endicott
