Long is good. Too long is too bad.
Steve McConnell tells us in Code Complete, that long variable names are good. I think it’s in the section on “Self-documenting code”.
In object oriented languages, you have the object name, the name of a possible sub-object, and the name of a particular field or item in the object, which all add up to a descriptive long name, but split into different parts.
Example: mypack.special-effect.color = chartreuse
However, I have been working in Gnu Make lately. Gnu Make recommends that you only use numbers, letters, and underscores in Make, as other characters may be used for other special purposes now or in the future. Now, in Gnu Make, you don’t have real objects. You do have “constructed variables”. By using recipes with wildcards in them, and constructing variable names with pattern substitution, you can get some of the same effect as objects. However, the variable names look kinda ugly.
Example: testset_special_effect_color = chartreuse
Its easy in make to get a few lines like the following. The intent here is to make a copy of one pseudo-object that will only be used when code coverage is in effect:
# Initial special effect setup
regression_mypack_special_effect_targets = \
testset_chartreuse \
testset_bland \
testset_monochrome
regression_mypack_special_exec = mypack_special_exec
# copy for code coverage
regression_mypack_special_effect_ccov_targets = \
$(testset_mypack_special_back_targets:%=%_ccov)
regression_mypack_special_back_color_iterations := 4
My problem was that I copied the variable name wrong. In line 8, I wanted to make a copy of the list of targets, with the names modified to be the ccov version of the targets. The difference is nearly invisible in the middle of the long variable name.
Verbose, clear variable names are an important part of self documenting code. Monotonous names with only underscore separators make that hard. Yet another reason to avoid “make” for complex projects.
Like this:
Like Loading...
Talk Software 