Heh, timely:
"You should always write your code as if comments didn't exist."
-- Jeff Atwood, July 24 (http://www.codinghorror.com/blog/archives/001150.html)
--
Avdi
Home: http://avdi.org
Developer Blog: http://avdi.org/devblog/
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com
# It is worth considering that if your favored style leads to unclear
# code in your favored language, it may be time to reconsider your
# favored style.
maybe, i was not clear enough. When a short var, like x is clear enough in the context of the set of codes it will be used, then i use it. And since i tend to code short (less than 20 lines) of methods/functions, i do frequently use short var names. I do not like strict enforcing "longer names always better" rule..
eg,
5.times{|number_element| p number_element}
vs
5.times{|x| p x}
names_of_people.each{...}
vs
names.each{...}
i hope i am clear enough now.
kind regards -botp
From: avdi.grimm@gmail.com [mailto:avdi.grimm@gmail.com] On
No argument there, but my comment goes equally for the Rename refactoring.
On Fri, Jul 25, 2008 at 12:15 AM, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Global search and replace is a poor substitute for refactoring.
--
Avdi
Home: http://avdi.org
Developer Blog: http://avdi.org/devblog/
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com
My 10p:
/* this does look too much like a regex for my comfort */
# but this is a pain
# in the neck, leading me
# to make terse, short
# comments, even when
# I really need to make
# a longer one
=begin
I really think that this is ugly and
only good for temporarily commenting
out code
=end
assert_true me.agree( Ruby.should(:document, self) ) #most of the time...
On Fri, Jul 25, 2008 at 6:10 AM, Peña, Botp <botp@delmonte-phil.com> wrote:
From: avdi.grimm@gmail.com [mailto:avdi.grimm@gmail.com] On
# It is worth considering that if your favored style leads to unclear
# code in your favored language, it may be time to reconsider your
# favored style.maybe, i was not clear enough. When a short var, like x is clear enough in the context of the set of codes it will be used, then i use it. And since i tend to code short (less than 20 lines) of methods/functions, i do frequently use short var names. I do not like strict enforcing "longer names always better" rule..
eg,
5.times{|number_element| p number_element}
vs
5.times{|x| p x}names_of_people.each{...}
vs
names.each{...}i hope i am clear enough now.
kind regards -botp
--
Me, I imagine places that I have never seen / The colored lights in
fountains, blue and green / And I imagine places that I will never go
/ Behind these clouds that hang here dark and low
But it's there when I'm holding you / There when I'm sleeping too /
There when there's nothing left of me / Hanging out behind the
burned-out factories / Out of reach but leading me / Into the
beautiful sea
Shadowfirebird wrote:
assert_true me.agree( Ruby.should(:document, self) )
On a line-by-line basis, it's certainly true that code should be
self-documenting. But it's no good knowing what each line does if you
can't see the big picture. Usually you want to see the big picture
first, before you delve into the details.
Ancient Fortran codes typically started with a nice big block of
comments describing each subroutine, detailing its calling sequence
(parameters) and return values, and saying how it worked. I know this
went out of fashion many years ago, but it's still a good idea IMHO. At
any rate, I always do it even though my code is solely for my own
consumption. Time wasting? Not in my experience.
In Ruby the =begin ... =end syntax is the obvious way to do that. My
only gripe is that no whitespace is allowed before =begin and =end, so I
can't indent them appropriately. 
Dave
--
Posted via http://www.ruby-forum.com/\.
