On 10/13/06, Kevin O. [email protected] wrote:
So I take it you all just assume that people know the same things you
do? That is real smart, just assume that a person is going to be able
to read your mind when he comes across your work. You cannot make the
assumption that your code is going to be perfectly clear to an
individual other than yourself; this would be like expecting anyone to
have the exact same command of English as you do. In programming we
have facilities for at the very least informing someone what a given
line or block is the idea that you should not actually use this
facility because whatever you wrote is going to be obvious to anyone
reading your code is a joke.
Not at all. Speaking as someone who’s been at the software development
business for a while, there’s nothing worse than a comment that reads:
// added to fix a coredump
If that isn’t bad enough, you look around, and you don’t see any code to
which this could possibly apply.
On the other hand, it might be worse to read:
// adding 1 to foo
foo += 1
Comments should be used sparingly: they interrupt the flow of the code.
Clearly commenting at the head of methods (especially complex ones) is
useful. Commenting inside of a method is usually useless. ESPECIALLY
when, as always happens, the code and the comment diverge.
I have literally come across comments that I’ve made a year after I’ve
made them and they make no sense – because someone else in the company
modified the code surrounding them but didn’t clean up the comments.
Why didn’t they? Because it’s easy to remove or change code that doesn’t
work the way it’s supposed to. It’s much harder to remove comments that
don’t apply any more, because since you’re just maintaining something
that someone else wrote.
No one is saying you shouldn’t comment things. But there is such a thing
as over-commenting and over-compensating. If case statements are part of
the language, it is reasonable to expect that anyone programming in that
language will understand a case statement.
Scratch that. It’s not reasonable – it’s a given that you’ll either
understand such syntactical tricks or you will ask someone to explain it
to you (and then you’ll understand). Yes, there are advanced tricks that
one can do in almost any programming language, and it’s often worth
commenting those tricks (or not using them without really good reasons),
but comments can detract from the code.
Actually I am asking for ruby to allow me the freedom to make my own
code readable to me. I personally don’t know perl so I can’t comment
on Perl however I will say that the interpereter should know when you
are using a block and search for the do keyword or { and ignore the
newline. In other words a method that requires a block as a parameter
(like each) should not be terminated by a newline they should be
terminated either by a closing brace or tne end keyword. Grabbing the
user by the balls with respect to how the code is formatted is not a
good thing even if it is a side-effect of how blocks work in the
language.
Then you’re welcome to try to patch the parser to make it do that, and
you’re welcome to fork Ruby when such a patch is refused because it’s
nonsensical.
In four and a half years of using Ruby, you are the very first person
who I have seen request this because they don’t think that the existing
block format is reasonable or readable enough. I have seen people ask
“why doesn’t this work”, but none say that the language isn’t good
enough.
Let me give you a small clue: all methods take blocks. Every single last
stinkin’ one of them. It just so happens that there’s a lot of methods
that don’t do anything with them.
def foo
puts “I have a block!” if block_given?
puts “I have no block.” unless block_given?
end
foo
foo {||}
There’s nothing that the parser knows that says that “foo takes a
block.” The interpreter will carry the block that was given to a method.
If the block isn’t used (with &block or yield or – to a degree –
super), then it’s silently discarded. If it’s used in execution, then
it’s executed.
So. Just because you’re not comfortable with:
foo do ||
end
and would rather have:
foo
do ||
end
You want to either (a) make the parser know something about execution
time [not smart] or (b) force extra lookahead interpretation for EVERY
METHOD CALL. No, thanks. You’d be much better off either getting used to
the way that Ruby works, or if you can’t, finding something that does.
Every spoken and written language has rules and conventions however
they all allow different ways to say one thing (some many more than
others.) all of them probably also have examples of unnessecary
rigidity however unlike programming languages spoken and written
languages are not exactly engineered in a controlled environment so
its not entirely possible to address those issues; it is indeed
possible with programming languages. So shouldn’t things that can
adversly affect the readability of the language itself be addressed
since it is well within human capacity to do so?
It has yet to be established that most people fine the standard block
formatting unreadable. All I’ve heard is one person who doesn’t seem to
know much about quality programming practices say that they find it less
readable, and they’ve done so by comparing it with, well, the wrong
thing. Most of us gave up on the One True Brace Style fight years ago.
-austin
