From: Emiliano <emile@...>
Date: 2001-10-24T17:13:06+09:00
Subject: [ruby-talk:23153] Re: Bruce Eckel's opinion of Ruby

Kero van Gelder wrote:

> > That's not to say you can't enforce coding standards for other
> > languages, but for Python it's been a clear decision to make it part
> > of the language, and many people appearantly see a benefit to this.
> > 
> > And you can't enforce a coding standard everywhere.
> 
> hehe :)
> I don't abide the rules (of C coding guidelines), but they can not
> punish me for it. I'm too valuable.

IOW, a prime candidate for Python :)

> In the very same project, I've seen code adhering to the guidelines
> that was so subtly wrong, that you need to read it several times to
> realize there might be something wrong. That was code by one of the
> qualified programmers, not written by the majority.

Coding guidelines are no guarantee for code correctness. It's an aid
in readability.

> Coding guidelines are some way of managers to get control.

Nonsense. The managers won't care in the least. The poor bastard that
has to maintain other peoples code will.

> It seems to
> me, at least. But controlling software is so much more. I've read so
> many code from starters (as student assistant) and kernel and other
> open source projects, that I hardly care about coding
> standards. Consistency and naming are more important than a required
> description of the second parameter of some function.

They're not _alternatives_, they're _complimentary_.

> Somehow, there are lots of funny Ruby conventions that get enforced by
> matz optimizations as well. Most of those are really good. There have
> been a few discussion about this, recently.
> 
> In C:
>    if( myfunc (param))
> 
> I mean, get real. as if ``if'' is a function and (param) is a boolean
> expression. C'mon. ``If'' can be a function (in certain languages!), param
> can be a boolean expression, but (param) is a (set of) parameters to
> the function myfunc. There should not be a space there. Period. Or am
> I being obnoxious here?

Not in my eyes, but the same will probably be argued by Python
enthousiasts.

> > And there's the issue: what's more clear to you could well be utterly
> > unreadable to another.
> 
> That's a huge part of the problem in Software Engineering.
> It's psychological, not mathematical.

I don't understand this point. Coding standards aren't mathematical
either.

Emile