DoDont: what changed
Revision 0 to 1. Removed lines have a minus sign; added lines have a plus sign.
Title: DoDont
| Old | New | Line | |
|---|---|---|---|
| 1 | + | # The right and wrong of Pascal Programming | |
| 2 | + | ||
| 3 | + | All of these are almost generic tips for programming.\ | |
| 4 | + | I've learned the right and wrong of programming the hard way, by doing things wrong first. | |
| 5 | + | ||
| 6 | + | ## Right | |
| 7 | + | ||
| 8 | + | 1. Use **checks** (Range, IO, Overflow) when developing. You can enable them with the "-Crio" compiler switch. | |
| 9 | + | 2. Use **[[heaptrc|heaptrace]]** from time to time to see if you have any memory leaks. Enable via the "-ghl" compiler switch to get best result. | |
| 10 | + | 3. Split huge [[Glossary|units]]. Big units are **almost always** a sign of bad design or logic. (you know it's bad when you have unrelated constructs in one unit). | |
| 11 | + | 4. Split huge [[Function|functions]] / [[Procedure|procedures]] / [[Method|methods]]. Big functions/procedures/methods are sign of bad design or logic. A good rule of thumb is to have no function, procedure or method longer than one printed page (about 55 lines) or, even better, one screen if you can. What you can visualize in one screen (or on one printed page, if you use printed listings) you can probably understand better than what you can't see or have to flip from page to page to read. | |
| 12 | + | 5. Name your variables/functions properly lest you damn yourself with unmaintainable code. Be consistent in how you do things. | |
| 13 | + | 6. It is commonplace to use **meaningful identifier names.** While every language advises this, it is a much more common practice in Pascal. However, the variable names I, J and K are commonly used as general purpose FOR control variables and have similar usage for loop counters, especially where the loop is only being used to initialize or display members of arrays. Loop variables must be local anyway. | |
| 14 | + | 7. Hungarian notation (a "prefix code" to indicate what the type of a variable is) is frowned upon (Pascal has strong enough typing) except maybe for components on a Lazarus form, e.g., edsomething for an edit field and labsomething for the corresponding label, etc. | |
| 15 | + | 8. Stick with one indentation style. Change only if you hadn't followed a standard style till then. | |
| 16 | + | 9. The only right language for the job is the one you started the work with. And that's [[Pascal]]! | |
| 17 | + | ||
| 18 | + | ## Wrong | |
| 19 | + | ||
| 20 | + | 1. Put all points from Right section here and negate them. | |
| 21 | + | 2. Have doubts in Pascal. | |
| 22 | + | 3. NEVER use -Ct (stack check) in Win32 with threads! There's a "feature" which can be a problem. | |
| 23 | + | 4. Don't name your arguments with names of fields, even if they are private, e.g., FField and Field in an argument. | |
| 24 | + | ||
| 25 | + | --- | |
| 26 | + | *From the Free Pascal wiki, page "DoDont", as it stood on 2016-11-10 after a change by E-ric, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).* | |
| 27 | + | Category: Pascal |