What's in a Name?

This is a wide topic, but I intend to consider it here:

• bottom-up from the case of ClearCase objects, such as label types or directory elements;
• as an opinion in the context of an open controversy upon whether names should or not contain themselves information—please consider expressing adverse opinions in distinct pages, possibly linking the arguments one to one, but not assuming to close the debate unilaterally;
• in a way consistent with the SCM view (see also Yet Another SCM Manifesto);
• hopefully drawing more general conclusions towards the end or later.

I'll suggest that what applies here is the principle of separation of concerns, and thus offer that only minimal information is carried in the names. I am ready to admit that there are tradeoffs to consider, which depend as usual from the practical support offered by the tools.

A name gives access to a resource. It should be:

1. easy to find, and thus to remember;
2. easy to discriminate from other names;
3. easy to associate with the other names in the context, so that the new names can be added.

The issue is one of optimizing a signal/noise ratio, in a special context.

(1) will have to be performed by different people, using different approaches (e.g. generic string match, or context based navigation), from different contexts.

• Properties which feel essential to one, may feel irrelevant to another.
• If you have already used a name in the past, you'll expect it to lead you to the same information again: names should be stable. There should be minimal pressure to change them ever:
  • either to fix or update information they would contain
  • or to take into consideration changes in their environment, e.g. clashes with new names...
    Examples:
    • what to do with gcc-3.2 after one has added gcc-3.2_64?
    • what to do with gcc-3.3.3_32 after one has added rhgcc-3.3.3_32?
• Names are only ever unique in a context: a label type in a VOB, a directory name in the context of its parent.
• Users should not be encouraged to have expectations which cannot be verified, or enforced.

(2) is best served by having short names, with clear (even redundant) differences near the beginning. A tool to help with discrimination is sort. It is a good idea to ensure that names within a context will sort in the order of their creation. This is not as trivial as it may seem, and requires that one keeps some clevel of control over the names.
Examples:

• BDB_4.5.20 is sorted after BDB_4.10.10
• rhgcc-3.3.3_32 and ... 64 are missed by a search with: ls -d1 gcc*, which returns all the names of directories starting in gcc...

-- MarcGirod - 28 Jan 2007