After all, you derived the long names from the "mechanics" of the code. And now you expect an outsider to go the opposite direction, deriving the "mechanics" of the code from the long names? I don't think this is going to work for an outsider. Long names may even confuse him because he has to "see through" them in order to be able to understand the "mechanics".
Maybe you don't expect an outsider to understand the "mechanics" of the code by reading your long names and merely want to aid that process of understanding. How well that is accomplished through the use of long names, is, of course, still open for question. :)
Regards, chris
!DSPAM:4cd7f39b48584559617140!
Maybe you don't expect an outsider to understand the "mechanics" of the code by reading your long names and merely want to aid that process of understanding. How well that is accomplished through the use of long names, is, of course, still open for question. :)
well, it certainly helps the process of understanding to have one less indirection (e.g. not having to make the extra step to get from the abbreviated short name to its original long form).
and don't forget that the frequency the name is "used" plays a very important role regarding the decision about long/short names. you can easily convince me about short names of frequently used constructs (bind, let, ...), because even we prefer short names for them. but these names are only a tiny portion of all the names introduced in the codebase...
the extremum on this scale, namely writing code with abbreviated short names of infrequently used constructs is basically what code obfuscater algorithms do.
random thought re names: once a flat-text codebase has been parsed into a graph, then all the human given names could be dropped because they are redundant. the machine can execute the semantics encoded the same way without identities having human parsable character strings.
conclusion: names should/could have much less important role regarding identity management and restoring a graph from flat-text, and much more important role in helping human understanding of such a graph. e.g. having a long and a short names for the same identity; the ability to have personalized names (e.g. let shown as a special graphical element in my editor instead of using a three letter word); etc...
i have a lot more thought on this (partly because we worked at intentsoft.com), but it's a bit out of scope on this list... and writing code has much more utility than talking about writing code... :)
but reading your mails makes me think that you are already getting far ahead of most people when it comes to giving good names to abstractions. spending brain cycles to think about the problem is already more than what most people do.
cl-rdbms-devel@common-lisp.net