[EMAIL PROTECTED] wrote:
> Its not the typing, its the fact that when you say the same thing
> twice, there is the potential for them to get out of sync. If the
> method the compiler uses (braces) and the method the human uses
> (indentation) to determine what the code does don't agree, then a
> reader will be likely to misunderstand what it will actually do. One
> of the driving principles behind Python is that, because code will be
> read more often than written, readability is more important.
Not to mention the errors that creep in when code is maintained, like
when C code starting out as
if (i < SOME_CONSTANT)
doSomething();
gets "maintained" to
if (i < SOME_CONSTANT)
doSomething();
doSomethingDangerous();
without the programmer adding the surrounding braces. The programmer's
intent is clear to me as a human, but the C compiler will disagree with
me, and in this case, the compiler will be right and I'm wrong.
You can (and we do, at my company) have coding standards that mandate
braces around single line if()s in C/C++, but that's really just
patching around the problem (and it counts on humans being consistent).
Pushing the scutwork down onto tools is not as good a solution as
eliminating the scutwork, especially when it shouldn't be necessary at
all...
--
// Brett g Porter * [EMAIL PROTECTED]
// http://www.bgporter.net/blog
--
http://mail.python.org/mailman/listinfo/python-list
