[Haskell-cafe] Re: Allowing hyphens in identifiers

[Richard O'Keefe]

On Dec 18, 2009, at 5:00 PM, Luke Palmer wrote:

> On Thu, Dec 17, 2009 at 8:39 PM, Richard O'Keefe <ok at cs.otago.ac.nz>  
> wrote:
>>
>> On Dec 17, 2009, at 4:45 AM, Ben Millwood wrote:
>>>
>>> By the way, I like camelCase because I think that in most cases you
>>> *don't* want to break identifiers up into their component words
>>
>> My experience has been that in order to make sense of someone else's
>> code you *HAVE* to break identifiers into their component words.
>> With names like (real example) ScatterColorPresetEditor, the eye
>> *can't* take it in at once, and telling the difference between that
>> and ScatterColorPresentEditor would be a pain.  Break them up
>> Ada-style as Scatter_Colour_Preset_Editor and
>> Scatter_Colour_Present_Editor and you're away laughing.
>
> I don't know what experience you could have had that led you to
> believe that *I* have to break identifiers into component words.

Instead of writing "you", I could have written "one".
The meaning would have been essentially unchanged.
Come ON, I explicitly wrote "my experience", what more do you want?

Quite by coincidence, just before opening Mail, I was looking
at some Objective C source code.  It's part of quite an interesting,
indeed, award-winning, program.  I would like to understand it.
But this is how it's written.

+ (FSManagedObjectContextInspector  
*)managedObjectContextInspectorWithmanagedObjectContext:(id)theContext  
interpreter:(FSInterpreter *)theInterpreter;

That's all on one line.

Now maybe YOU can see

managedObjectContextInspectorWithmanagedObjectContext

whole and entire as a single word without even trying, not for an
instance, to break it into pieces, but here sit I, and the ONLY
way I can make sense of it is to break it up as

	managed object context inspector
	with managed object context

This is *real* "other people's code".  Maybe Haskell is immune
to this sort of thing, but that's how baStudlyCaps plays out
in other languages.  I am not making this stuff up.  I didn't
even go looking for horrible examples.  This is just the kind
of stuff that hits me in the eye.
>

> I don't like to get caught up into this kind of argument, but my own
> opinion is that phrases don't make good words.

The question is not whether phrases make good words or not,
although there are very strong recommendations in software engineering
textbooks (going back at least as far as Ledgard and Tauer) that
program identifiers *should* be phrases.

The point is that in the code I find myself trying to read these
days identifiers *ARE* phrases, whether you or I or anyone else
like it or not.

Take another line from that same program (but another file).

     [predicateTextView setFont:[NSFont userFixedPitchFontOfSize: 
[[NSUserDefaults standardUserDefaults]  
floatForKey:@"FScriptFontSize"]]];

"Tell the (predicate text view) to (set [its] font [to])
  (NextStep Font's (user (fixed pitch font) (of size))
   (Next Step User Defaults' standard user defaults) float[ing point
   number] for key "FScript font size")".

That's presented as one (very wide) line of source code.
It *is* an English sentence with a bunch of words deleted and
some funny punctuation marks added.

This is code that I am not familiar with.
It is obvious that nearly *all* code in the world is code that I am
not familiar with.  Talk about how you can read this once you have
become so familiar with it that you can see all these big blobs of
text as single words is talk about what will happen on the Greek
Kalends, as far as I can see.  In order to get to that point, FIRST
I must make sense of it from a position of ignorance.

And to do that, I *HAVE* to break the identifiers into words and
read the natural language text that is very nearly there.

How else can I determine the meaning of these identifiers than by
reading them as phrases?  They *ARE* phrases!  They are MEANT as
phrases.  Am I supposed to divine the meanings by Platonic
intuition?

Is there really, honestly, anyone on this list who DOESN'T have to
approach code like
  1. - (void)updateAction:(id)sender
  2. {
  3.  [window setTitle:[NSString stringWithFormat:@"Inspecting %@ at  
address %p",descriptionForFSMessage(inspectedObject), inspectedObject]];
  4.  [printStringView setFont:[NSFont  
userFixedPitchFontOfSize:userFixedPitchFontSize()]];
  5.  [printStringView setString:printString(inspectedObject)];
  6. }
(numbers added to show where the lines start)
by breaking these identifiers into words?


>  My preferred way to increase the readability of code is to
> keep names short and *limited in scope*.

That's good.  Haskell code is chock full of one and two letter
highly local identifiers.

I have to (and I do mean have to, there's a group project I'm
supposed to contribute to) read stuff like

  1. double ANT_mean_average_precision::average_precision(long topic,  
ANT_search_engine *search_engine)
  2. {
  3. ANT_relevant_topic *got;
  4. ANT_relevant_document key, *relevance_data;
  5. long long current, found_and_relevant;
  6. double precision;
  7.
  8. if ((got = setup(topic, search_engine)) == NULL)
  9.   return 0;
10. if (got->number_of_relevant_documents == 0)
11.    return 0;
12.
13. key.topic = topic;
14. precision = 0;
15. found_and_relevant = 0;
16.
17. for (current = 0; current < results_list_length; current++)
18.    if (!results_list[current]->is_zero_rsv())
19.       {
20.       key.docid = results_list[current] - accumulators;
21.       if ((relevance_data = (ANT_relevant_document *)bsearch(&key,  
relevance_list, (size_t)relevance_list_length,  
sizeof(*relevance_list), ANT_relevant_document::compare)) != NULL)
22.          {
...

About the only good thing here is that it uses underscore_separation,
at least I can see at a glance that it's about relevance and
documents and results.  And yes, I did have to run it through a number
of tools, not least 'astyle', before I could _really_ start to read it.

Reading your own code is a VERY different experience from trying
to read someone else's.  It appears that Luke Palmer and I agree
about "keep it local and keep it short".  Other programmers do not:
the experienced and indeed very capable C++ programmer who wrote
the code above is vehemently opposed to single-letter identifiers
even of the "for (int i = ...) ...a[i]..." variety, but for some
strange reason he is comfortable with lines up to 300 columns wide.
The really rather capable Objective C programmer who wrote the code
I quoted before seems to have the same kind of opinion.

This really is the kind of stuff I face every day, and it's ONLY
by reading the words in the identifiers that I have a hope of coping.