Compare source code

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Wed Nov 3 15:36:05 EDT 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.


-- 
Steven



More information about the Python-list mailing list