Spacing conventions

[Steve D'Aprano]

On Wed, 27 Sep 2017 05:50 pm, Bill wrote:

[...]
> If you are teaching beginning students, do you expect them to try to
> follow these sorts of conventions?

Yes, but not to the point of being a dick about it. It is better to learn good
habits first, rather than to learn bad habits then unlearn them later.

The PEP 8 spacing conventions are based on similar English and/or maths
conventions. For instance, in English, you should never put a space before the
colon.

    This is wrong : ...

any more than you would put a space before a comma , or before the full stop at
the end of the sentence .

oR capitalise the *second* letter of the first word in a sentence .

Yes, the rules are fundamentally arbitrary, but violating them makes your text
harder to read, whether that text is English prose, source code, or
mathematics.


> Is it perfectly fine to let "taste" 
> guide you (I'm just trying to get a feel for the philosophy here)?

To some degree. Consistency with common standards is a valuable thing, but its
*your* code and if you want to write in an idiomatic style that gives everyone
else a headache, go right ahead. Just don't expect me to contribute to it.

One of Raymond Hettinger's videos talks about writing beautiful Python code, and
how slavishly obeying PEP 8 is not really productive. I'll try to find a link
later and post it.


> I 
> also notice "break" and exception handling is used much more in Python
> than in C++, for instance.  I was taught "break" and "continue" led to 
> "unstructured code"--but that was a while back.

That's weird. break and continue are perfectly structured. They are no more of
an unstructured GOTO than are if...else, for or while.

It is the nature of human beings to gravitate to extremes, rather than finding a
happy medium. When the idea of structured programming was first introduced into
the programming community used to BASIC and other unstructured languages, there
was a tendency among many people to slavishly apply the principle that every
function, or even block of code, must have exactly one entry point and one exit
point.

Of course enforcing one entry point is easy: few languages allow you to jump
into the middle of a function, because that would be really bad. But having
multiple exit points is not just harmless, but actually useful.

Nevertheless, because of this overly strict, foolish insistence on a single exit
to a block of code, some people prefer to write code like this:

done = False
result = None
for i in range(0, 2**64):
    if not done:
        ... code here
        if condition:
            result = value
            done = True
return result


rather than the simpler code that violates the "one exit" rule:

for i in range(0, 2**64):
    ... code here
    if condition:
        return value
return None


Similarly for break and continue.

> I can still see their 
> use  causing potential trouble in (really-long) real-world code.

How so?

Besides, if your code is "really long", you probably should factorise it into
smaller, meaningful chunks.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.