Don’s List
Some
1. Each class should be in its own unit.
This is to force communications via the public interface. I regularly break
this rule by having container and contained classes in the same unit.
2. Only the main form should be auto created.
Why load start up with unwanted form creation, and why create forms which
may not be needed at all? Delete the automatically created global variable.
3. The public interface should not contain data members.
You're exposing your implementation, so can't change it. Plus you can't include
data members in IInterface.
4. Avoid the use of initialization and finalization sections.
You tend to lose control of the order of execution
5. No Globals.
The main form in a GUI application is a global. I tend to have one other:
an instantiation of a lookup class which provides access to all methods and
attributes which need to be globally accessible.
6. Avoid Back Pointers, that is the situation when
a class has a reference to its container.
Reason: you have to look at the class to see what it does with it. I prefer
to include an event in the contained class, and have the container pass in a
handler.
7. If an object needs a resource to function, pass
it in on construction.
- rather than create a property which requires
assignment. This is referred to as dependency injection, I think.
8. No more than two local (nested) methods in a routine.
Even if a candidate local method is only used by the containing routine,
make it a private method of the class. Makes routine easier to read, and the class declaration more informative.
Roger’s List
I
have been programming for many years starting with Basic, Assembler and Fortran this introduced many techniques which would now be
considered bad practice. In many cases I take these issues on board and change
my ways but in some instances I find the so called correct solution to be more
convoluted and complex than my preferred bad practice.
1. Close coupling between
objects is universally bad.
I
often have to pre-declare types and put uses clauses in the implementation section
in order to enable a group of closely related objects to contain and/or
interact with each other. I find this very powerful and enabling but am
repeatedly told it has a bad smell.
I
am interested in the justification for this claim.
John’s List
The topic of
"good programming practice" has a lot of potential. Some of the rules
already on the list will be very interesting to discuss.
I'll suggest a couple more rules:
1. Try to make classes that are black boxes
This is where
users of the class don't need to know any implementation details, and can only
access the class through its defined interface.
2. Use Assertions.
3. Don’t fix problems you don't understand.
I think it would be good to also discuss exceptions
·
When
to raise them.
·
What
to do about unexpected exceptions (by default
Phil’s List
1. Contain
Rather Than Inherit
I prefer
classes to contain other classes rather then inherit from them. Generally only
inherit from an abstract class.
2. Declare an
Item Class and a List Class
I tend to
create an item class and a list class to contain a list of these items. Some of
these item classes contain other list classes thus building up a hierarchy.
3. A Manager
Class Contains all Top Level Lists.
A manager
class contains all the top level list classes. This forms the primary
application object when the application is started.
4. Separate
DB Control from Business Classes
Keep database
stuff separate from these business classes. The database class gets passed an
item class (or a visual control such as TListView) to
populate.
If a list
class will always know how many items it will have at construction use an array
of these items rather than a TObjectList descendant.