Hacker News new | ask | show | jobs
by brundolf 1961 days ago
Your link appears to be broken

We can debate the value of one-word (or even acronym) vs five-word variable names, but the key factor in my view is that the name holds some sort of intrinsic meaning to the person looking at it, vs being an arbitrary symbol. For example, x and y - despite being one-letter variable names - are perfectly sensible in a context where you're talking about euclidean geometry and referring to values on the x and y axes. But they are not reasonable names in the context of business logic where they represent customers or transactions. Alternately, a software shop may establish a convention that generics A and B mean something specific across all contexts in their codebase. A company-specific convention this arbitrary will still increase the barrier for newcomers to comprehend the code, but once learned they will at least be able to re-use the knowledge and A and B will become meaningful to them. In this way, "meaningful" may be relative. Usually meaningful names will take the form of one or more words, but not always; I wouldn't say the actual length itself is what's important.

With that established: by choosing names that have intrinsic meaning to the reader, the reader's mind is allowed to skip a step of indirection where they would otherwise have to perform a mental "dictionary lookup" from symbols to concepts. To be frank: study or no study, it's literally unbelievable to me that removing this step wouldn't help the slightest bit with both comprehension and recall.

Addendum: There's a further dimension to this which is that code is more than what it does. Take the following function:

  function m(a, b) {
    if (a < b) {
      return a;
    } else {
      return b;
    }
  }
Is this code wrong?

Because the function lacks a meaningful name (or documentation), it's not simply hard to tell, it's a question with an undefined answer because the intent is not represented in any way. This function currently returns the minimum of the two arguments, but there's no indication whether it was meant to return the minimum, or the maximum, or even the sum for that matter.

Maybe you could argue that we should be writing comments anyway, but that still moves the meaning across a step of indirection, where you have to go find it instead of seeing it inline. We absolutely should be writing comments, but they don't completely replace good naming.

1 comments

By all means, use long or short or whatever consistent naming convention you'd like, even with the study I provided, the difference is not going to make or break any project.

All I'm saying is that as professionals, there is a mismatch between how strongly we believe things to be true and how much time and effort we invest in validating those beliefs. People here will argue very strongly about long vs. short variable names and this discussion could go on and on and on, but no one here will actually try to find existing research or conduct any research of their own.

My position is until you, or me, or anyone wishes to hold a strong belief about what is truly beneficial in terms of productivity, human psychology, etc.. we should hold off on making claims about objective engineering facts and instead simply accept that our claims are stylistic in nature and used out of consistency and convention, rather than because we have evidence that it's superior.

Finally, it really is worth noting that it was literally unbelievable to Aristotle that heavy objects fall at the same speed as light objects, so much so that no one bothered to test that assumption for thousands of years.

If you, or anyone, is so convinced that some coding convention is more than just stylistic but actually objectively superior, why not put in some degree of effort to conduct a scientifically reliable test to validate your belief? If the answer is that it's too hard to put in the work to objectively validate your opinion, then you should also accept that it's too hard to accept your opinion as an objective fact.

If we as professionals are not willing to validate our beliefs in a rigorous manner, then we as professionals should not feel so compelled to proclaim those beliefs as being objectively true instead of simply a matter of preference.

The problem is that things like "project maintainability" and "programmer productivity" are so hard - perhaps impossible - to objectively measure