Next: Declarations Up: Some Notes on Previous: Comments

Variable Names

The choice of names for your variables makes a great difference for how easy it will be to read your program, hence for how easy it will be to spot mistakes. It also determines how difficult it will be for others to understand your program. Choosing the right names for your variables is a bit of an art.

Be consistent. For example, if the mesh point index is called j in the book, do not suddenly call it i in your program. In a case-insensitive language such as FORTRAN, you may want to denote the maximum value of j by jmax or j_max, but then do not denote the maximum value of an index k by kmx or klim.

Follow prevailing conventions. Do not call the time coordinate in your program z based on the fact that you already have an x and a y coordinate; call it t or time just like everybody else. If you need two different values for the mesh point index j at the same time, call the second one jj or j2, because that is what many people do. This makes it easier for someone else to guess the function of the variable. Popular programming books (and Microsoft?) often set such conventions since many people read and follow their example programs.

Choose a name that is simple to understand by anyone. Do not denote mesh point index j by LSD (for `Location in the Spatial Direction') or qqf (for `let's make sure there is no variable of this name yet'.)

Be concise. It does not improve clarity to call the mesh point index variable jvar or j_index instead of j. Actually the longer forms may increase the possibility of confusion. Some people use very long variable names in the hope of increasing clarity; for example Time_step, Spatial_step_size, Mesh_x_position, Mesh_old_temperature_values, and Mesh_new_temperature_values.
[0] These names do leave little doubt what each variable represents; however, your eye is assaulted by such a mass of text that the resulting source code can actually be quite difficult to read. Not worth the additional typing.

Deal with conflicts. If you are computing an unsteady heat conduction problem, a case-insensitive language like FORTRAN will not distinguish temperature T from time t. This is a toughie. Using the names temperature and time will certainly avoid ambiguity, but this leads to long, hard to read, statements. Further some compilers may not like more than 6 characters in the variable names. Also, doesn't (x,t) look better than (x,time)?. Abbreviating temperature to temp has the difficulty that temp is also often used to indicate `temporary'. Of course, you could cheat and denote time by time and temperature by T. Although the FORTRAN compiler ignores the upper case in T, someone reading your program will not confuse it with time. But the danger remains that you will pass temperature t to some subroutine while you really wanted to pass time time. Further deg, cent, fahr, or heat are all not really correct, and more likely to confuse. A name such as cT (for `capital T') may be a solution; the person reading your program would have to look up this one name in the declarations. For one or two names, that should be OK.



Discuss why the following variable names are not desirable:

1.
jlim for the maximum used value of mesh point index j.
2.
mxstor for the maximum dimensioned value of mesh point index j.
3.
jlim for the maximum dimensioned value of mesh point index j.
4.
jmax for the maximum dimensioned value of mesh point index j.
5.
Dimensioned_maximum_j_value for the maximum dimensioned value of mesh point index j.
6.
u for the temperature in a bar.
7.
tmp for the temperature in a bar.
8.
ar for the array of temperatures in a bar.
9.
dc (degrees Centigrade) for the temperature in a bar.

Next: Declarations Up: Some Notes on Previous: Comments