Difference between revisions of "DoDont"

From Free Pascal wiki
Jump to navigationJump to search
(wikify)
Line 6: Line 6:
 
== Right ==
 
== Right ==
  
1. Use checks (Range, IO, Overflow) when developing. You can enable them with "-Crio" argument.<br>
+
#Use checks (Range, IO, Overflow) when developing. You can enable them with "-Crio" compiler switch.
2. Use heaptrace from time to time to see if you have any memory leaks. Enable via "-ghl" argument to get best result.<br>
+
#Use heaptrace from time to time to see if you have any memory leaks. Enable via "-ghl" compiler switch to get best result.
3. Split huge 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)<br>
+
#Split huge [[unit]]s. 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).
4. Split huge functions/methods. Big functions/methods are sign of bad design or logic.<br>
+
#Split huge [[function]]s/[[procedure]]s/[[method]]s. 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.
5. Name your variables/functions properly lest you will damn yourself with unmaintainable code.<br>
+
#Name your variables/functions properly lest you will damn yourself with unmaintainable code. Be consistent in how you do things.
6. Stick with one identation style. Change only if you didn't follow a standard one.<br>
+
#It is commonplace to use a "prefix code" to indicate what the type of a variable is, and to use somewhat longer names for variables. However, the variable names I, J and K are commonly used as general purpose FOR control variables and similar usage for loop counters, especially where the loop is only being used to initialize or display members of arrays.
7. The only right language for the job is the one you started the work with. And that's Pascal!<br>
+
#Stick with one identation style. Change only if you didn't follow a standard one.
 +
#The only right language for the job is the one you started the work with. And that's [[Pascal]]!
  
 
== Wrong ==
 
== Wrong ==
  
1. Put all points from Right section here and negate them<br>
+
#Put all points from Right section here and negate them.
2. Have doubts in pascal.<br>
+
#Have doubts in Pascal.
3. NEVER use -Ct (stack check) in win32 with threads! There's a "feature" which can be a problem.<br>
+
#NEVER use -Ct (stack check) in Win32 with threads! There's a "feature" which can be a problem.
4. Don't name your arguments with names of fields. Even if they are private ie: FField and Field in argument.
+
#Don't name your arguments with names of fields. Even if they are private ie: FField and Field in argument.

Revision as of 20:26, 10 May 2006

The right and wrong of Pascal Programming

All of these are almost generic tips for programing.
I've learned the right and wrong of programming the hard way, by doing things wrong first.

Right

  1. Use checks (Range, IO, Overflow) when developing. You can enable them with "-Crio" compiler switch.
  2. Use heaptrace from time to time to see if you have any memory leaks. Enable via "-ghl" compiler switch to get best result.
  3. Split huge 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).
  4. Split huge functions/procedures/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.
  5. Name your variables/functions properly lest you will damn yourself with unmaintainable code. Be consistent in how you do things.
  6. It is commonplace to use a "prefix code" to indicate what the type of a variable is, and to use somewhat longer names for variables. However, the variable names I, J and K are commonly used as general purpose FOR control variables and similar usage for loop counters, especially where the loop is only being used to initialize or display members of arrays.
  7. Stick with one identation style. Change only if you didn't follow a standard one.
  8. The only right language for the job is the one you started the work with. And that's Pascal!

Wrong

  1. Put all points from Right section here and negate them.
  2. Have doubts in Pascal.
  3. NEVER use -Ct (stack check) in Win32 with threads! There's a "feature" which can be a problem.
  4. Don't name your arguments with names of fields. Even if they are private ie: FField and Field in argument.