Re: Declaration design preference: type or name first

Mike Sieweke wrote:
> In article <4727ee13$0$20603$4c368faf@[EMAIL PROTECTED]
>,
>  Logan Shaw <lshaw-usenet@[EMAIL PROTECTED]
> wrote:
>> And for that, I draw a parallel to human language.  Human languages
>> are almost evenly split among those which have an adjective-noun
>> order and those which have a noun-adjective order.  English, which
>> is my native language, has an adjective-noun order ("black cat");
>> Spanish has a noun-adjective order ("gato negro")[1].

> I think you've chosen the wrong language model.  Variable definitions
> are more like a dictionary than like a sentence.  Have you ever seen
> a dictionary where the definition came before the defined word?

I've seen a few weird variations on dictionaries, but I guess one where
the entire definition comes before the word is not among them.

By the same token, I think pretty much all dictionaries I've seen have
been arranged in alphabetical order.  If we wanted to model variable
declarations on dictionaries, we'd have the variables declared in
alphabetical order.  But I wouldn't want to do that; I like putting
related things together.

> "Name first" has a subtle advantage:  Programmers tend to line 
> definitions up in columns, and name-first causes the names to
> be lined up.  The name-first form makes it easier to find a
> variable name in a list, just like in a dictionary.
> 
> x : integer
> y : float
> t : type = integer
> c : constant := 4
> a, b : character

> "Type first" tends to line up the types, leaving the names at
> random columns, as in C:
> 
> int x
> float y
> typedef int t
> const int c = 4
> char a, b

Sure, they do line up better, and that helps, but you've stacked
the deck a little bit by using " " to separate the items in the
second example and the more-visually-distinctive " : " to separate
them in the first.

The fairer comparison would be this:

     integer : x
     float : y
     type : t = integer
     constant : c := 4
     character : a, b

It's not as easy for the eye to search for variable names as it is
when they all start in the same column, but it's easier with the
trail of colons to guide the eye along.

Incidentally, variable name is not *always* what I want to visually
scan for.  When I'm looking at some code for the first time, I've
often seen what its interface is like and I know what some arguments
to its functions are.  So I'm often coming from a point of view where
I'm familiar with the types that the module deals with much more than I
am with what variable names it uses internally, and at least initially
I'm thinking in terms of the types and trying to find variable names
for them.  (Of course in your example it's very easy to find the types
as well, but that's because you chose variables names that are all
one length.)

Anyway, I guess this all goes to show that once you start making
analogies and deciding things are natural because of them, somebody
will make a different analogy that you thought of and think whatever
decision you made is quite unnatural since it doesn't harmonize with
the first analogy *they* thought of.

   - Logan