Coding style

[Gerhard Fiedler]

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. 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.

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. 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.

(In case that sounds too general -- it is <g>. But it answers a general
point...)

Gerhard