Gabriel Sechan wrote:
> ----------------------------------------
>
>> Date: Wed, 2 Jan 2008 15:01:21 -0800
>> From: [EMAIL PROTECTED]
>> To: [email protected]
>> Subject: Re: Introducing Cobra
>>
>> On Wed, Jan 02, 2008 at 04:57:05PM -0600, Gabriel Sechan wrote:
>>
>>
>>> The problem is that its much easier to get whitespace wrong than it is to
>>> get braces wrong. For example- one of my most frequent refactors is
>>> changing the nesting of a chunk of code- either moving it into a loop,
>>> out of a loop, or into a new function. If you use braces, the code will
>>> work, but may be indented in an ugly matter. If you do it with
>>> whitespace, it will be broken.
>>>
>> I would instead argue that this particular example is evidence of why
>> indent-based blocking is a good thing, rather than bad.
>>
>> When I move a block of code in python, it is immediately obvious to me what
>> kind of nesting change is needed. It is just a few keystrokes to shift the
>> block to the right place. With braces, it is very easy to have them wrong,
>> but get the indentation right.
>>
>
> I have never in my life seen the indentation wrong but the braces right. I
> have seen the reverse, frequently.
>
You need to get out more. If I had a dime for every time I've seen this
crud:
if (blah)
doSomething();
doSomethingElse();
In some C code, I'd be retired.
The other fun ones are deeply nested braces that *look* like they all
balance out but actually don't. Then you have to figure out what the
intent was.
> While you can put a brace in the wrong spot as a bug, you can do the same
> with whitespace. You'll never get that type of error from just moving code
> around. THis is absolutely a reason why indent based blocking is a bad
> thing.
>
Sadly, I see that error happen all the time, particularly when people
are too quickly factoring out code in to functions, even more so when
they are copy and pasting from one indenting style in to another
(magnified if their editor has different tab widths than the original code).
> Indent based blocking is an attempt at solving a social problem (people who
> don't indent, although I've never actually met one of these people) with a
> technical solution (indentation as semanticly meaningful). That just doesn't
> work- you're causing at least as many problems as you're stopping (probably
> far more, because I've never met a programmer who didn't indent predictably)
> and adding in whole new classes of bugs. The correct answer is to educate
> the people who don't indent.
>
You rarely meet programmers who don't consistently indent, but it is
pretty easy to find a team and/or collection of code that doesn't
consistently indent.
By doing things the way Cobra does (or did ;-), you enforce a
consistency that ensures people can confidently and quickly read the
code correctly.
> You're right, I meant to type auto-shift. Same issue though- if your
> language requires an editor to have a specific tool to avoid a common bug,
> your language is fatally flawed. Python isn't even a remote consideration
> for me due to this. I've actually rewritten small (
>
Umm... isn't this why people like/use auto-indenting editor for
languages *other* than Python? This seems like an argument *for* using
Python, not the other way around.
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
