November 2008
Software Rules an Historic Background – Jim Duff (UCars)
Jim put general software rules in an historic context. Jim’s ancient but enlightening research can be obtained here. It includes a plethora of references.
Software Rules and Myths – The Assembly
Good coding practice abounds with “rules” – One object per file, Variable naming conventions, Close coupling is universally bad, etc. But when did these rules originate and on what justification, and do they apply to the modern development environment? Members are asked for their contributions. The plan was to have a wide ranging discussion around these facets. Phil, John, Don and Roger put together some points for discussion
- Each class should be in its own unit.
- Only the main form should be auto created.
- The public interface should not contain data members.
- Avoid the use of initialization and finalization sections.
- No Globals.
- Avoid Back Pointers, that is the situation when a class has a reference to its container.
- If an object needs a resource to function, pass it in on construction.
- No more than two local (nested) methods in a routine.
- Close coupling between objects is universally bad.
- Try to make classes that are black boxes.
- Use Assertions.
- Don”t fix problems you don’t understand.
- Contain Rather Than Inherit.
- Declare an Item Class and a List Class.
- A Manager Class Contains all Top Level Lists.
- Separate DB Control from Business Classes.
For more details on these topics Click here. By the close of business we had only considered Don’s submission. We plan to revisit the issue early in the New Year.