Re: Coding techniques

Posted by webmaster Guido on October 15, 2002

In Reply to: Coding techniques posted by Jodell Bumatai *DClub* on October 15, 2002

: How do you plan out source code so that you can design the code with separate and possibly re-usable units?
: In design time, how to you know when you should use a unit or form for code vs. adding to the same unit or form?

In a small project, it doesn't make much sense to separate everything, because that would make it harder to maintain. For larger programs, you can put "global" variables and invisible components like timers and database components,... in a data-module. That's like a form, but it's invisible.

For practical reasons, it's also clearer to keep the "interface" code separated from the "processing" code: put the processing code in new units, that have no related forms. There are no strict rules that you "must" follow, because theoretically there is no limit to the size of a unit. Here are some practical guidelines:

- separating processing code and GUI-interface code is a good idea for larger projects, or in projects with a lot of code for calculations;
- always use a separate unit for every "class" (object or component) that you wrote yourself. Although in some cases, it's easier to keep a few related classes together in one unit. For example, if you define a kind of list "TMyList" that is used to keep special items (objects) of type "TMyItem", it's usually clearer to put these two in one unit.

It's also a good idea to group functions and procedures in one or more units: a unit with date/time processing stuff, string related, math, and so on... That way, you built your own "libraries" that can be re-used in other projects.

It's impossible to give straight rules in this matter. Reading lots of code from other programmers helps, especially some larger sized projects, because in small example programs usually everything just sits in one unit.