Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!husc6!mailrus!umix!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.misc
Subject: Re: Readable names
Message-ID: <2921@enea.se>
Date: 26 Mar 88 22:32:59 GMT
References: <2857@enea.se> <25668@cca.CCA.COM> <2883@enea.se> <25810@cca.CCA.COM> <2902@enea.se> <25938@cca.CCA.COM>
Reply-To: sommar@enea.UUCP(Erland Sommarskog)
Followup-To: comp.lang.misc
Organization: ENEA DATA AB, Sweden
Lines: 70

Me and Richard Harter have been exchaning points of view on identifier
names for a while. First I thought I should give Richard the last word
here, but then I changed my mind and decided to add some short notes
to his last article. It seems to me that we have the same basic ideas,
but we put the limit differently. While I'm getting doubts for names of
15-20 characters, Richard gets worried at 6-8.

>	Not on your life!  Praising your own accomplishments works much
>better if you don't embarrass yourself by making them public.  :-)

Coward! :-)

>	Oh, I see your point alright.  I find NumberOfAccidents hard
>to read and unpleasant, whereas Number_of_Accidents is more pleasing to
>mine eye.  

Underscore of case shifts doesn't really matter to me, as long as it is 
not "numberofaccidents". It was there my discussion started. These days 
I prefer underscores, before I used case shifts. Underscores are not
standard Pascal, that's why.

>	However the issue is not, as I see it, one of reading variables,
>it is one of reading lines of code and blocks of code.  Suppose, for example,
>that you use names 15-20 characters in length and that the statement has half
>a dozen names in it  -- you now have statements ~100 characters in length.

Sure names can get too long. I dislike having to split a statement in two 
lines. It's fairly OK when an assignment looks like:
   Some_variable := Quite_long_expression + 
                    Another_long_expression;
But when it declines to
   Record_field_with_long_prefix_or_a_slice := 
                                  Another_long_one_that_does_not_fit_the_line;
I'm not too amused. However, to cure these problems I rather split
statements in two or something like that, than cutting down the names.
   
>Depends -- procedure names are usually 6-8 characters to avoid portability
>problems in the software I am working with now.  Also, cross reference

If you have problem with such a limitation, you have a valid argument.
I wouldn't say I'm envious of you...

>all compressed names with standardized abbreviations, e.g. cmpdir is
>'compress directory', assion is 'assign insertion order number', 'dspbib'

Oh, I would have guessed "compare". As you may guess I would have
called it Compress_directory.

>Also relevant is the fact that I annotate every line, ala assembly language
>code, unless it is too long to fit a comment field in.  Normal format is
>a code field of about 40 chars wide and a comment field of about 35 chars
>wide with all comments aligned.  As you may imagine, short names are more

Good habit. You need a lot of discipline to keep them updated. 
  Mine is about the opposite. I usually put a describing comment in the 
procedure header, explaining parameters if their names doesn't say it all. 
For local variables I add a describing comment, except the most trivial. 
  The code itself does only contain comments if I do some special trick. 
I don't know if this is a good habit, but I tend to feel that the comment 
tends to make code unnecessary verbose. And since I am using longer names 
than Richard I have to add extra lines for them, which makes it harder to 
keep the procedure in the desired one-page limit.
  (And besides, I don't write in obscure languages like C, so I don't
have to write that much comments :-) :-) )


-- 
Erland Sommarskog       
ENEA Data, Stockholm        
sommar@enea.UUCP