...

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).

Agreed.

Nonetheless, in an (my) ideal world you would be able to derive the long form from the abbreviated form by:

1. knowing the outlines of your territory (files, dirs, packages, systems, context of all kinds)          2. looking at and hopefully understanding the "mechanics" of the code

Admittedly that isn't cheap, although it seems doable for an outsider. (eventually we are all outsiders)

All in the name of circumventing names that are hard to understand. (for outsiders)

The more I think about it I come to the conclusion that excessive use of long names are a way of "getting more intimate" with your code. That helps you personally (or a small group) over the short-, midterm (maybe even long-term or the rest of your life) but harms others.

In the end, it seems to me, it all comes down to not having any standards and a practically infinite number of possible meanings. (costs of sharing meaning, transaction costs)

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...

That makes sense to me. Sounds like you are making a case for using long names as an asset by having the contrast between long and short.

And the costs of sharing meaning about a name that gets used frequently are easier to justify.

Again, opens the question as to how much long names are capable of reducing costs of sharing meaning. Could they even increase the costs? I certainly made that case. Seems a little crazy from this perspective.

Surely the more words you use to describe something the easier it gets to share what it actually means? Does purpose come into play now? Maybe I should stop here.

the extremum on this scale, namely writing code with abbreviated short names of infrequently used constructs is basically what code obfuscater algorithms do.

Right, only context is missing in this picture.

Hm, the costs of sharing meaning often seem to be exceptionally low when it comes to context.

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...

Absolutely

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

Impressive, a testimony from the New York Times. Yes, this is awfully off topic.

As a side note: The relative low level interface of hu.dwim.rdbms I was talking about, on top of which as many extensions as possible can be build, seems to be already there. It's just that it isn't properly exposed, in my eyes at least.

writing code has much more utility than talking about writing code... :)

Hard to tell. On average you are probably right.

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.

I take this as an compliment. (normally I refuse compliments, tells me something)

Regards, chris

-- attila

!DSPAM:4cd81d6e48581330461277!