On 10/13/06, Kevin Olemoh <darkintent / gmail.com> 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
-- 
Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/
               * austin / halostatue.ca * http://www.halostatue.ca/feed/
               * austin / zieglers.ca