Ironically the acronym often becomes the name. Everybody knows what NASA
is. What the CIA is. But people have to think to figure out what the real
name is. Take ICE. I'll bet that half the people don't even know what the
actual name of the ICE organization is. A long name, particularly with lots
of words in it is like many objects, not one object. Did you know that
"grep" is an acronym for "globally_search_a_regular_expression_and_print"?
A non-unix person could understand the full self-documenting name but not
the acronym. But one would still be in the dark as it didn't say what a
"regular_expression" is. And I don't think I would want to type all that
whenever I did a search, even with auto completion. Intelligent acronyms
are fine when are commonly used. Long names built by compilers to assure
uniqueness are awful.

As to tacit. Which is easier to read?
   range =: (>./ numbers) - (<./ numbers)
   range =: (>./ - <./) numbers
Actually it depends on the reader's background. For me the second line the
use of a tacit fragment makes it easier to read as "numbers" is one object,
not two. And the fragment is easy to read knowing the definition of a fork.

Self-documenting code makes me nervous because it is inadequate. It misses
references to company documents, legal issues and technical papers
describing algorithms. It misses the "why".

Documentation and naming conventions are necessary but not easy to do
properly. But a programming language should not define and enforce
standards for documentation and naming conventions. Leave that up to the
company or individual.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to