Reusability & Readability are two attributes of good software. Actually, they are also sub-attributes of MAINTAINBABILITY, which I consider the most important attribute of good software.
Define once & reuse. What we lack is a good standard way to examine dictionaries and their related pieces. A standard listing is very disjointed. I think Ray Jones & Brian Leach both have tools they are proud of. I keep threatening to look into that, but haven't yet. Comments interspersed below. Chuck Stevenson > DEPDATE > 001 I The displayed deposit date (if not voided). > 002 IF VOID = "" THEN DEPOSITED ELSE "*Voided*" > > or > > DEPDATE > 001 I The displayed deposit date (if not voided). > 002 EXTRACT( @RECORD, 2, 0, 0 ) ; EXTRACT( @RECORD, 12, 0, 0 ) ; > IF @2 = "" THEN @1 ELSE "*Voided*" I prefer attribute names for the same reason I would name basic program variables VOID & DEPOSITED instead of ATT2and ATT18. ( or, defined via a standard $INCLUDE, something like SALES.REC< SALES$VOID > or SALES_VOID instead of SALES.REC<2> or SALES.REC(2). You get the idea.) Also, you can nest I-descriptors, referring to a calculation by name, instead of re-coding the calculation in every I-descriptor that needs it. (Caveat: for UV they have to be structured without multiple ";"-delimited expressions.) > The obvious concern is if a direct field definition is > renamed, then all references to the old field name need to be > changed. Same logic can be applied for opposite conclusion: if you renumbered the fields then you would have to rewrite all the I-descriptors that used explicit numbers. > I rarely rename a field, Renumbering fields would be more rare, admittedly, but... BUT: It is NOT rare for calculations to be refined over time. Sometimes what is originally a stored value gets redefined as a calculation. Example: TAX. Suppose somebody originally defines it as a stored field, then you go interstate and it needs to be computed differently for each state. Then you're more successful, so you write a subroutine to handle Canada & European tax... If you had 1 dict item called TAX and always referenced it, then it could migrate from D-item, to I-item, to I-item with called subroutine, and so on. You would _CHANGE_IT_ONE_PLACE_ & recompile the dictionary. If you had coded all & sundry I-descriptors referring to TAX via an extract, or later by recoding the calculating repeatedly, you're stuck with less maintainable code. This is an argument for using ITYPE() functions in programs, too. READ TAX.IDESC FROM SALES.DICT, 'TAX'... TAX = ITYPE( TAX.IDESC ) ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
