Coding style

[Antoon Pardon]

On 2006-07-21, Gerhard Fiedler <gelists at gmail.com> wrote:
> On 2006-07-21 09:00:43, Antoon Pardon wrote:
>
>> So we have code with certain shudder characteristics. And instead
>> of trying to help the OP with his problem, some people react
>> to the shudder and come with all sort of comments that might be
>> true if the code as shown was production code, but which totally
>> miss the point the code was illustrating and thus aren't much
>> helpfull.
>
> In general, I'd say that in this case the example was not well-chosen.
> After such a "shudder removal", a poster should IMO review what caused the
> shudder, and rephrase the original problem without the shudder.

The shudder is not with the poster. The poster can't predict how
the readers will react.

> That might
> take a few iterations, but in general, either one or more of the "shudder
> removals" actually address the OP's issue, maybe without any individual
> helper understanding all of the problem (due to incomplete example code),
> or the iterations lead to a code that's "shudder free" and still shows the
> original problem -- now usually in a clearer form, because free of other
> issues that are not relevant to the OP's point.

I doubt that. My experience is that you have more chance of being helped
by people who try to understand where the OP is trying to go form than
from those who react to style issues. I have never seem a bug go away
because someone suggested to write "if Number:" instead of "if Number != 0:"

> E.g. if someone makes a suggestion that is valid with the example code I
> posted but not with the real code I have, I need to post an updated example
> code that introduces a restriction similar to the one I actually have,
> which then correctly invalidates the formerly valid suggestion -- and helps
> getting more helpful responses.

Not necessarily. A valid suggestion doesn't imply a relevant suggestion.

If someone come with code like:

  if Number != 0:

And someone suggests that the python idiom is

  if Number:

Then that suggestion is valid, but it also is irrelevant. A bug doesn't
disappear because the latter is the python idiom for the former.

> This is a process that in the past has
> taught me a lot (not Python, but that's just because I'm too new here :).
> Once you get good at this process, it often helps you find the problem even
> before posting, because boiling code down to what the /real/ problem is can
> show you a lot you otherwise miss.

Sure, but if you do that, you sometimes have code that deviates from
the python idiom because there was originnaly a good reason for, but
that isn't obvious any more because you are temporarily working with
a boiled down piece of code. People making suggestions on how to
make that boiled down code look more pythonic by using the python
idiom are IMO not very helpfull because essentially those are just
aesthetic.

-- 
Antoon Pardon