Rule 1: Create a unit (One Class, One Unit) for each class, keep this: Private and protection (Protected) part only for classes and processes in other cells (procedure) Hidden. So if you want to get effective encapsulation, you should use a different unit for each class. For some simple classes, such as those that inherit other classes, you can use a shared unit. However, the number of classes that share the same unit is limited: don't place more than 20 complex classes in a simple unit, although Borland's VCL code has been doing so. If you use a form, Delphi will default to follow the rules of "a class using a unit", which is also very convenient for programmers. When you add a class without a form to your project, Delphi creates a new independent unit.
Rule 2: It is important to give each form and unit for each form and unit. The names of the form and unit must be different, but I tend to use similar names for them, such as using AboutForm and About.PAS for them, using the descriptive name for the component. It is also very important. The most common naming method is to start using the lowercase of the class, plus the components, such as btnadd or editname. With this naming method, there will be a lot of similar names for component naming, and there is no best name. In the end, it should be chosen that should be based on your personal hobbies.
Rules 3: Name Event is more important for event processing methods to give appropriate names. If you give a proper name for the component, the system default name ButtonClick will turn btnaddClick. Although we can guess the function of this event handler from this name, I think it is a better way to use a name that describes the role of the method, not the name of Delphi attached is a better way. For example, the BTNADD button's onclick event can be named ADDTOLIST. This will make your program more readable, especially when you call this event handler in other methods of this class, and this helps programmers use the same way to similar events or different components. But I have to declare that the action (Actions) is my favorite approach when developing important procedures.
Rules 4: Use Form Methods Forms All class, so the form of the form is organized in methods. You can add event handlers to the form that completes some special features, and they can be called by other methods. In addition to the event handling method, you can add a specially defined method for the form and a method of accessing the form state. Add some public (public) methods to other forms to other forms to do his components directly than other forms.
Rules 5: Add Form Constructors, the second form created at runtime, except for a default constructor (inherited from Tcomponent class), other special constructors will also provide other special constructors. If you don't need to consider compatibility with Delphi4 previous version, I suggest you overload CREATE method to add the necessary initialization parameters. Specific code can be found in the following code:
Public Constructor Create (Text: string): reintroduce; overload; Constructor TformDialog.Create (Text: string); Begin Inherited Create (Application); Edit1.Text: = Text; End; Rule 6: Avoid global variables (Avoid Global Variables) It should be avoided using global variables (that is, those defined in the unit's interface part). There will be some suggestions to help you do it. If you need to store additional data for the form, you can add some private data to the form class. In this case, each form instance has its own copy of the data. You can use unit variables (variables defined in units of the unit) declare those shared by multiple instances of the form. If you need to share data between different types of forms, you can define them in the main form to achieve sharing, or use a global variable, how to use methods, or attributes to get data.
Rule 7: Never use Form1 in the TForm1 class (Never USE Form1 in TForm1) You should avoid using a specific object name in the class, in other words, you should not use Form1 directly in the TForm1 class. If you really need to use the current object, you can use the Self keyword. Keep in mind: Most of you don't have to use the method and data of the current object directly. If you don't follow this rule, when you create multiple instances for a form class, you will fall into trouble.
Rules 8: Try to avoid using Form1 in other forms, even in other forms of form, you should try to avoid direct use of global variables, such as Form1. Define some local variables or private domains For other forms, it will be better than the direct call global variable. For example, a program's main form can define a private domain for a dialog. Obviously, this rule will be very useful if you plan to create multiple instances for a derived form. You can keep a list within the code range of the main form, or you can easily use the form an array of global SREEN objects.
Rules 9: Remove Form1 (Remove Form1) In fact, my suggestion is to remove the global form object that Delphi automatically created in your program. This is also possible even if you prohibit the automatic add function of the form, because this form may still be added in Delphi. The suggestion for me to give you should try to avoid using a global form object. I think it is useful for Delphi's newcomers, which is useful to remove global form objects so that they are not confused about the relationship between classes and global objects. In fact, after the global form object is removed, all the code related to it will generate errors.
Rules 10: Add form property, as I have mentioned, when you need to add data to your form, add a private domain. If you need to access other classes, you can add properties to your form. Using this method You can change the code and data of the current form (included in its user interface) without having to change the code of other forms or classes. You should also use attributes or methods to initialize the partial form or dialog, or access their final state. As I said earlier, you should use the constructor to complete the initialization work.
