Why not allow empty code blocks?

[Michael Torrie]

On 07/24/2016 07:14 PM, BartC wrote:
> I've done little Python coding but still, having to use kid gloves for 
> indents does figure quite a bit in that.
> 
> I can give some more examples but I'll probably be told that I'm using 
> the wrong tools! Which suggest there is a problem, but the effort has 
> gone into working around them using external tools. (But understandable 
> if the language design was fixed 25 years ago.)

I only code in Python these days and I simply do not find the indenting
syntax to be a problem.

Far more often I'm bitten by the dynamic nature of Python (would happen
in any dynamic language).  I'll be using a particular member attribute
which I accidentally misspell somewhere and sometimes that results in
silent failure.  Something doesn't work, but no exception is thrown.
Unit tests, and perhaps lint, are required to catch these errors.  That
is one thing about a dynamic language: comprehensive testing is required
as you go along.

> 
> For example:
> 
> if cond:
>      a
>      b
> 
> I want to comment out the if statement temporarily, but I also have to 
> fix the indents:
> 
> #if cond:
> a
> b

Good example, and I've encountered this one, but honestly fixing the
indent is best programming practice anyway.  If I want to preserve
context, copying the entire block and then commenting it out to preserve
it is what I prefer.  Anyway, I'd want to fix indenting even if I was
using braces.  Just to make the code readable and maintainable over time
as more often than not temporary becomes permanent.  If it's truly a
temporary removal, your "if 1:" idiom seems most correct to me, with the
original condition commented out.

Also there are times when I simply don't worry about commenting things
out.  I just delete them and fix the indenting and move on with life.  I
can always revert my changes if I end up barking up the wrong tree.

> 
> (Or add the comment and insert a dummy 'if 1:'.)

This is a good idea for temporarily taking out the condition.  Sounds
like good practice to me.


> 
> Or I want to add a temporary condition around:
> 
> a
> b
> 
> which again requires me to indent those statements (and unindent them 
> again later). Or I want to permanently have a commented out #if guard 
> around some code:
> 
> #if cond:
> a
> b
> 
> to be uncommented from time to time (to do with debugging). But it's not 
> as simple as just uncommenting that one line.

With a end statement you'd of course have to comment out both the if and
the end lines.  Just to nitpick.

> 
> Or I want to have a temporary print statement within a block, but it 
> needs to be at the right indentation. Not a great imposition, but it's 
> now less visible as a temporary addition.

Pretty much all print statements in my code are visible as a temporary
addition.  There is really little other reason to use it.  So every so
often I'll search for all my print statements and comment them out or
delete them once the code is operational.  But even then, using a
logging function is probably even better solution.

> Or I need to move or copy code from one location to another, but the 
> indentation levels are different. This would need fixing in other 
> languages too, but if this is part of a temporary try out which will 
> change again a few minutes later, I can dispense with the correct 
> indentation in another language, until the code is more permanent.

In venerable old ViM I just highlight the block and move it in or out.
Not having editor support would make this very painful. But you'd be
wanting to adjust the indenting anyway, in any language.  So while it
would cause an error in Python, in any other language you'd want to do
this anyway, just to make the code readable.

> In short, because correct indentation is required at all times, it's 
> less flexible when you want to do a lot of messing around.

I guess I just don't find this to be particularly problematic.  And
Python is great for doing a lot of messing around in for me.

> Now, if I was going to do a LOT of Python coding, then I would solve 
> most of those problems (by having my own tool to superimpose a more 
> amenable syntax on the language). For casual work though I have to go 
> along with the indent scheme. (And there are usually other issues with 
> Python that are more troublesome than getting the layout right.)

I tend to not have a lot of strong opinions about languages I have
little experience in.  What is it about your experience that leads to
such strong opinions about a language you do very little in?  I dislike
what I see of Ruby but I have no opinions strong enough to voice on the
Ruby lists (or even read them).  Just curious.

> I'll leave you with a code fragment that might be pasted from elsewhere 
> (it's not meant to mean anything):
> 
> if cond:
>      a
>      b
>      c
> 
> The question is: is this the whole block? We don't know, as we can't see 
> what came next. But if now I add the next line, and it was this 
> (anything actually with one less indent):
> 
> if cond2:
> 
> then yes it was the whole block, IF we assume an indent didn't get 
> clobbered in the process! But if the line happened to be:
> 
> else:
> 
> now we know for sure.

I've never had this problem in Python.  I have the source file in front
of me. I can scroll down until the block ends. And if the programmer
keeps his functions short, it's as readable or more readable than in any
other language.  I submit you'd have the same readability problem with a
very long and deeply blocked C function without the help of something
like brace matching in your editor.  It's true I can reformat the file
to clean up the indenting in a C program, but the author should have
done that to begin with.  Just because a C function compiles doesn't
mean it's correct, and if the indenting is all over the place you can't
easily follow the logic and judge its correctness anyway.