Compare source code
steve at REMOVE-THIS-cybersource.com.au
Wed Nov 3 20:36:05 CET 2010
On Wed, 03 Nov 2010 02:40:11 +0000, Seebs wrote:
> Sure, but there's also no way for you to spot that something looks
> suspicious. In Python, if something is misindented, it does what you
> told it to do, and there's no way for you to tell, by looking at it,
> that it isn't what was intended. In C, if something is misindented, it
> does what you told it to do, but it's obvious looking at the code that
> something went wrong.
If it's that obvious, why do people keep causing those indentation-
related bugs in C?
I'm glad for you that you have a finely trained attention to detail that
is able to instantly spot misindented C code (or is that misplaced braces
and correctly indented?), but it is a notoriously common error which
suggests that it's not anywhere near as obvious as you think.
It's *far* more common than Python code being misindented.
There's even a commonly suggested style for C programmers: always use
braces any time the syntax allows them, even when they're not needed,
because the next guy who maintains the file may not be as careful and may
forget to add the braces when needed.
>> But I can see the other end of the block in Python. I don't need any
>> tricks to make sure that it is the end. And if your block is too big
>> to see the structure easily then that just means that some code should
>> be factored out to a method.
> This level of dogmatism about what should always be the case is not
> conducive to good software engineering practices.
I question that assertion. Good engineering practices is about setting
best practices, and following them, not avoiding them because there might
be the odd exception here and there.
> It is not obvious to me that it's *always* the case.
So what if there is an exception one time in twenty thousand? You don't
design a tool (such as a programming language) on the basis of what's
good for the rare exceptional cases, but on what's good for the common
cases. The common case is that functions and methods should be short
enough to see the structure by eye. If it isn't, you have more problems
than just the lack of begin/end markers. The language shouldn't make
everyone carry the burden of supporting two-page functions all the time,
just to save you an insignificant amount of trouble on the vanishingly
rare occasion you need a function that is two pages long.
More information about the Python-list