Comments 5
Now the fun part, for starters just prove that
thing->Energy = thing->Mass() * np.math.pow(lib.constants.speedOfLightInVacuum, 2)is a better practice than this:
E = m * c^2If you avoid acronyms until they become well recognized, how they become well recognized?
An advice to conceal properties named create and destroy is silly, this is a design advice not the naming advice, choosing whether to expose it or not has nothing to do with «naming» it, if it creates something, it will still be called «create».
If you avoid acronyms until they become well recognized, how they become well recognized?
Why should they be recognized in programming?
E = mc2 is a bad example. It is a product of quite complicated math-backed work done by Albert Einstein with the help of Marcel Grossmann. The work took years of fiddling with equations and doing that is essentially focusing on the form ignoring the meaning. That's where single-letter variables are handy and that's what mathematics is about: it is refactoring of the form to make it simpler. Meaning doesn't matter until refactoring is done. In case of Einstein it took large part of his life so, I guess, he got used to the naming because he was writing these more than reading.
In programming it is different. We introduce our own variables that usually are unique per domain we implement. Therefore, there is not much to reuse from other domains. Unlike math, we cannot work without understanding initial problem because while form matters, our job is to solve problems.
Now the fun part, for starters just prove that
thing->Energy = thing->Mass() * np.math.pow(lib.constants.speedOfLightInVacuum, 2)
is a better practice than this:
E = m * c^2
I think, one-letter variable names are good when you write one-line programs, a.k.a formulas. Usually, formulas are accompanied with a sheet of text explaining meaning of all things inside the formula.
So, if you want write something like this
$E = $m * $c ** 2Then you need to write some documentation explaining meaning of $E, $m, and $c. But you don't need to write such documentation when you write something like this
$energy = $mass * $lightSpeed ** 2thing->Energy = thing->Mass() * np.math.pow(lib.constants.speedOfLightInVacuum, 2)
is a better practice than this:
E = m * c^2
Did you mean, that this is a better alternative?
thing->E = thing->m() * np.math.pow(lib.constants.c, 2)
I mean, you're comparing non-programming notation with an example of code. And the code example uses different language constructs which are specific to the language and which are not learned in school by everybody.
Indeed, such a long names are stupid but Box_2 isn't a good name as well. In case we're talking object-oriented paradigm, the variable in question is likely to belong to a class. Class context will clarify part of the variable context so that part could be subtracted from the variable name. Then, another part of the context could be namespace or package name. Likely, after taking the context into account, variable name won't be that long anymore.
From my experience, naming takes time and names like Box_2 are used when developers do not care about naming or are in a big hurry.
Naming things