Re: Types, packages & objects : the good old naming conventions question (without religious ware)

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

Hibou57 (Yannick Duch�ne) schrieb:

> There is on the other hand, this other convention, which came from
> Pascal I suppose : the one which ends types name with the suffix _Type

If you can't find a name for an object, ask more questions
about it, its use, its relations, the programmer, its purpose,
his purpose, etc:
What is the role of the object?  Does the role lead to a name?
It might not, at first.  For example, the role
can be given as "just any object" of the type.  I would not be
comfortable with such an answer (though, for practical reasons,
I live with it):
The person who says "just any object" should be able to give
a reason why "just any object" is sufficient.  The reason,
and in particular stating the reason using words, increases the
likelyhood of finding a name expressing the reason.
Or the reaons leads to other ideas which, again, lead to a
name.


Naming conventions always make me think of features
that a language does not offer.  I don't think this is
the case with types and objects in Ada.

> It's easy to accept large scale projects as being a proof of the
> relevance of a naming convention.

Microsoft's software is certainly of a larger scale.
They suggested "Hungarian" notation at some point.
Do they use, or suggest to use, "Hungarian" notation with .NET?
I don't think so.  So much for relevance of large scale.
If naming conventions help with missing features,
does Ada lack features that .NET offers
and that need to be compensated by a _Type suffix?

Mass alone, or big projects, are, IMHO, not a sign
of relevance without further corroboration.
Big projects can fail, too, but to define success is
more likely a political issue in large projects than
in small projects.  Whenever success or failure involve
"politics" and incomplete information, it is more difficult
to attribute success or failure to reasons given or
to reasons hidden.  (Let alone the effects of disiring
cognitve consonance...)

Here is a prossible study that is much less political,
yet will never happen, I think:
A group of programmers, equally skillful, separates itself
into two groups, along a dividing line between personal coding
preferences:
The first group consist of programmers who are fond of
the _Type suffix, the second group consists of programmers
who avoid these mechanical names.  Both groups set out
to solve the same problem.

- Which group finishes first?
- Which group can change things faster than the other?
- Again?
- Which group's members are better at explaining
  the software?

Etc.

The study needs to be augmented by performing it again,
trying conventional alternate research setups, to make
data valid and reliable.  (Switching the group preference,
using a third group that does not know about
conventions, ...)

Does such a study exist?  If not, why not?
The last question is the important one, I think:
It costs money.  It is personal (about style) and
personal information is kept personal, not studied.
Its findings might reflect on pride and fashion,
most important aspects of all craftsmanship, a no-no
when there is a risk of a negative result.
A study might have as a result: Do NOT wear the ties
you like so much (_Type or else wonderful names).
If the result of the study must be assumed to be regulation
of programming style, prohibiting personal preferences
for members of one group but not the other,
then is there any programmer who would want the study
to happen?

Is there a manager who understands the issue?