I have a question about how ruby-like is it to capitalize
instance variables. Often I think of the first character
of an instance variable to be the first character following
the ‘@’ sign.
So, with this thinking, I am NOT inclined to use @Foo,
because I tend to think of it as a member form
of Foo, which is a constant. So, although @Foo is perfectly
legal, I don’t see it used much.
Is there a good reason that I should avoid using capitalized
instance variable names?
···
–
"And what will you do when you grow up to be as big as me?"
asked the father of his little son.
“Diet.”
I have a question about how ruby-like is it to capitalize
instance variables. Often I think of the first character
of an instance variable to be the first character following
the ‘@’ sign.
So, with this thinking, I am NOT inclined to use @Foo,
because I tend to think of it as a member form
of Foo, which is a constant. So, although @Foo is perfectly
legal, I don’t see it used much.
Is there a good reason that I should avoid using capitalized
instance variable names?
Isn’t adherence to an informal convention reason enough? If it’s so
seldom used (though legal) it might surprise people who haven’t seen it
before and may make code harder to read.
I have a question about how ruby-like is it to capitalize
instance variables. Often I think of the first character
of an instance variable to be the first character following
the ‘@’ sign.
So, with this thinking, I am NOT inclined to use @Foo,
because I tend to think of it as a member form
of Foo, which is a constant. So, although @Foo is perfectly
legal, I don’t see it used much.
Is there a good reason that I should avoid using capitalized
instance variable names?
You’ve questioned its ruby-like-ness (correctly, I think), and
stated that you’re not inclined to use it, and that it isn’t
used much.
Personally, I have never used capitalized instance variables and I
can’t recall seeing it in any of the stdlibs. But while reviewing one of
my colleague’s code, I noticed that he had several instance
variables that were capitalized. At first I thought, how is
he not getting a constant warning. Then I realized that Ruby
was ok with ‘his’ coding standard.
So, one of the things I like about Ruby is that, for the most part,
it keeps you from being stupid (e.g, making it obvious that
instance variables are different from local variables, making globals
and constants immediately recognizable, and so forth).
But, allowing @Foo is somewhat troubling to me since it ‘feels’ like
a constant.
···
On Friday, 20 February 2004 at 23:00:58 +0900, David A. Black wrote:
On Fri, 20 Feb 2004, Jim Freeze wrote:
You’ve questioned its ruby-like-ness (correctly, I think), and
stated that you’re not inclined to use it, and that it isn’t
used much.
How about because using lowercase for instance variable names is a
Ruby idiom?
Here’s a quote from The Practice of Programming by Brian Kernighan
and Rob Pike: “Like natural languages, programming languages have
idioms, conventional ways that experienced programmers write common
pieces of code. A central part of learning any language is developing
a familiarity with its idioms.”
K. and P. go on to explain that not respecting a language’s idioms
makes programs harder to understand and masks bugs. Therefore we
should adopt recognized conventions instead of making up new ones.
···
On Sat, 21 Feb 2004 00:56:00 +0900, Jim Freeze jim@freeze.org wrote:
For me, but I don’t think that will fly for everyone else
in the company. I was looking for a more concrete reason.
You’ve questioned its ruby-like-ness (correctly, I think), and
stated that you’re not inclined to use it, and that it isn’t
used much.
Is there any reason not to avoid it?
It just bugs me?
But surely that’s a reason to avoid it
For me, but I don’t think that will fly for everyone else
in the company. I was looking for a more concrete reason.
Surely you can come up with one David.
I’m definitely an advocate of traditional Ruby style, and I like to
use the Ruby source as the arbiter of style. Not that it’s absolutely
uniform, but certain practices, such as avoiding camelCase for
variable method names, are adhered to in the overwhelming majority of
cases.
I’m definitely an advocate of traditional Ruby style, and I like to
use the Ruby source as the arbiter of style. Not that it’s absolutely
uniform, but certain practices, such as avoiding camelCase for
variable method names, are adhered to in the overwhelming majority of
^^^^^^^^^^^^^^^^^^^^^^
variable and method names, …
On Saturday, 21 February 2004 at 3:24:51 +0900, Tim Hunter wrote:
On Sat, 21 Feb 2004 00:56:00 +0900, Jim Freeze jim@freeze.org wrote:
For me, but I don’t think that will fly for everyone else
in the company. I was looking for a more concrete reason.
How about because using lowercase for instance variable names is a
Ruby idiom?
Here’s a quote from The Practice of Programming by Brian Kernighan
and Rob Pike: “Like natural languages, programming languages have
idioms, conventional ways that experienced programmers write common
pieces of code. A central part of learning any language is developing
a familiarity with its idioms.”
K. and P. go on to explain that not respecting a language’s idioms
makes programs harder to understand and masks bugs. Therefore we
should adopt recognized conventions instead of making up new ones.
–
Maybe Computer Science should be in the College of Theology.
– R. S. Barton
On Sat, 21 Feb 2004 00:56:00 +0900, Jim Freeze jim@freeze.org wrote:
For me, but I don’t think that will fly for everyone else
in the company. I was looking for a more concrete reason.
How about because using lowercase for instance variable names is a
Ruby idiom?
Here’s a quote from The Practice of Programming by Brian Kernighan
and Rob Pike: “Like natural languages, programming languages have
idioms, conventional ways that experienced programmers write common
pieces of code. A central part of learning any language is developing
a familiarity with its idioms.”
K. and P. go on to explain that not respecting a language’s idioms
makes programs harder to understand and masks bugs. Therefore we
should adopt recognized conventions instead of making up new ones.
