3 ms·
For me, local variable names are short -- usually a single letter. Names that will face external code -- parameters, function names, class members -- should be
by csense 14y ago
For me, local variable names are short -- usually a single letter. Names that will face external code -- parameters, function names, class members -- should be longer. At least a single word, but often multipleCamelCase or multiple_underscore_delimited words.
Mathematical functions are a special case, in terms of variable naming. Equations usually use short variable names. For something like the parent's situation, I would use the short names (actually shorter names -- prefixing every double with the letter "d" is stupid, as others have already noted, and very confusing since to a mathematically knowledgeable reader dR would denote a delta-radius, i.e. a change in radius).
Also, realize that in mathematics specific letters are often used for specific purposes. I usually use r for radius, p,q for prime numbers, u,v for vectors or lists, s for a set, s,t for time, x,y,z for coordinates, theta,phi for angles, f,g,h for functions, h,i,j,k for indices/loop counters, m,n for counts/lengths, k for a material constant (e.g. spring constant). Since most mathematics textbooks and papers use similar conventions, mathematically trained readers usually have no trouble. Those who have a programming background but little mathematical training may struggle, since as far as I know these conventions aren't documented anywhere -- they're just something you sort of pick up over time as you read mathematics.
But, if it is not obvious, I would write in a function-level or module-level doc comment what each of the variables stands for, even more descriptively than the author. I would include a description of the geometric object the code is dealing with. Perhaps even an ASCII art diagram.
As others have noted, it would definitely also be good to describe what equation or algorithm is being implemented -- not necessarily a full description or proof of correctness, but at least a URL describing the situation more fully (I often cite Wikipedia articles), a Google-able name, and (if appropriate) a literature reference to a paper or textbook. (My preference is to include a citation to something online without a paywall, to make it as easy as possible to get at the information later, but less readily available resources like textbooks or papers can be very helpful as well -- they are sometimes the best or even the only resource that describes a particular algorithm.)
The bottom line is to use whatever's most consistent with existing work, and communicate most effectively to others -- collaborators, future maintainers, and most importantly your future self -- what the code does.