Talk:Local Declaration Guidelines - Revision history

Peter gummer at 21:46, 12 January 2009

2009-01-12T21:46:50Z

Jfiat at 16:25, 12 January 2009

2009-01-12T16:25:37Z

Peter gummer: "l_" considered harmful

2009-01-10T00:55:05Z

"l_" considered harmful

Paulb at 20:47, 9 January 2009

2009-01-09T20:47:36Z

Clemahieu: New page: 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 o...

2009-01-09T19:43:32Z

New page: 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 o...

New page

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.

← Older revision		Revision as of 21:46, 12 January 2009
Line 27:		Line 27:
	Hopefully, the human brain is able to adapt easily to different conventions (as far as there is a convention, and logical behind all that).		Hopefully, the human brain is able to adapt easily to different conventions (as far as there is a convention, and logical behind all that).
	--[[User:Jfiat\|Jocelyn]] 16:25, 12 January 2009 (UTC)		--[[User:Jfiat\|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.
		+
		+	--[[User:Peter gummer\|Peter gummer]] 21:46, 12 January 2009 (UTC)

← Older revision		Revision as of 16:25, 12 January 2009
Line 22:		Line 22:

	--[[User:Peter gummer\|Peter gummer]] 00:55, 10 January 2009 (UTC)		--[[User:Peter gummer\|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).
		+	--[[User:Jfiat\|Jocelyn]] 16:25, 12 January 2009 (UTC)

← Older revision		Revision as of 00:55, 10 January 2009
Line 10:		Line 10:

	--[[User:Paulb\|paulb]] 20:47, 9 January 2009 (UTC)		--[[User:Paulb\|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.
		+
		+	--[[User:Peter gummer\|Peter gummer]] 00:55, 10 January 2009 (UTC)

← Older revision		Revision as of 20:47, 9 January 2009
Line 2:		Line 2:

	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.		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.
		+
		+	--[[User:Paulb\|paulb]] 20:47, 9 January 2009 (UTC)