|
|
|
| The overall goal of style guidelines is to lower the maintenance costs of
software
Application Development Guidelines: Abstraction of Functions - When developing an application, you should avoid the hard coding of values. If you need to control the behavior of a code item, then you should place an unambigous option on a code item and lookup this value. For example, a taxable flag on an AP category should reside in the AP CATEGORY lookup file and have a value of Y/N/T for yes, taxable, no, not taxable and is a tax item itself. Your reports should lookup this value and react accordingly. You should not develop the application to contain hard coded AP CATEGORY codes and program the taxibility behavoir for each into the program. Byt abstracting the behavior one level you will avoid a lot of needless programming changes and allow the users greater flexibility in modiling their processes in the system. File Design and Layout - Attributes should contain all like data and you should not encode values into specific value locations. There is nothing to be saved by placing something in VALUE 2 of an attribute instead of adding an attribute to the file. You should layout your files to be access friendly so that you can easily verify the results of any report in basic using a simple access sentence. It is important to cross check all report programs using access. Aggregate files - If you have a file that contains summary information (aggregate) then you MUST design the rebuild program for this file up front. You should not build complicated files strucutures that do not self-heal or without utilities to rebuild them if needed. Your file design should record data at the smalled, unit record and this detail can be summarized from the unit record detail into summary files. You shoudl always verify against the unit record in order to ensure accuracy. Counters and other assumptions - When you access a counter and will create an item on a file you MUST always verify the accuracy of the counter. Do not allow your program to create invalid data by relying on the accuracy of a summary, counter. The counter is not a unit record. you need to verify that an id created by from a counter item, is not on file before allowing the program to continue. |