Difference between revisions of "Talk:Local Declaration Guidelines"

Latest revision as of 12:46, 12 January 2009

What about putting the character at the end of variable name instead of the beginning? Prepending seems similar to prefixing features with the class name which we don't do, or the C way of prepending things with _variable.

I don't know, maybe it's just a preference but I don't like l_ at the beginning of all local variables I use.

--???

There is a lot of Eiffel Software code using this convention already, hence the page for contributors. These are guidelines for contributing to the Eiffel Software code repository and not rules for Eiffel itself, saying that consistency all around would be better :)

p.s. Don't forget to include a signature so the discussion is split correctly.

--paulb 20:47, 9 January 2009 (UTC)

You're not the only one who finds these prefixes harmful to legibility, Clement. When I am reading source code, in search of the meaning of an identifier, my eye goes to the start of the identifier. For example, if I'm interested in things called "customer", the little lexical analyser in my head seeks out that word (surrounded by space or punctuation), with a definite preference for finding the sequence of characters "customer" at the start of an identifier.

This process is subverted when every local starts with "l_". Instead of almost effortlessly recognising "customer", I have to expend some mental energy on filtering out the "l_" prefixes in the code in order to recognise that "l_customer" is really "customer".

I suppose with practice I would get used to this. After all, I did get used to writing "==" rather than "=" when coding in C. Nevertheless, littering the source code with this "l_" noise contradicts Eiffel's principles of clarity.

I understand the motivation for doing this. Eiffel variables are not scoped as they are in block structured languages, so a "customer" local in a routine of a descendant class may cease to be valid if a future release of an ancestor class introduces a feature called "customer"; or, conversely, the introduction of a local "customer" in the ancestor might invalidate an already-existing feature called "customer" in a descendant. Personally, I don't think I've ever encountered this problem, or if I have it was so trivially corrected that I can't remember it.

These "l_" prefixes are fixing a very rare and very easily rectified problem. It's the epitome of the cure that is worse than the disease.

--Peter gummer 00:55, 10 January 2009 (UTC)

I agree this adds noise to the Eiffel code, in many cases (with small body), we can/should use the short name for locals and arguments (in ideal world the body would not contain more than 10 instructions). However for big body, the convention l_, and a_ can be quite helpful to quickly know which value is local, argument, or attribute. Since it is good to keep a global convention, I would prefer to use l_ and a_ convention rather than using the short name, or real word (which might prevent the descendants to use a specific word as name). Hopefully, the human brain is able to adapt easily to different conventions (as far as there is a convention, and logical behind all that). --Jocelyn 16:25, 12 January 2009 (UTC)

Yes, the human brain is able to adapt to all kinds of noise, Jocelyn. But even after you've adapted to it, the noise still slows you down and tires you faster when you're working. That's why it would be much better, in my opinion, if you guys stuck to the principles of clarity of style espoused in OOSC2.

--Peter gummer 21:46, 12 January 2009 (UTC)