Talk:Local Declaration Guidelines
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)
