Coding style

[Gerhard Fiedler]

On 2006-07-23 06:24:09, Antoon Pardon wrote:

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

Correct. But if someone with the potential to help shudders, I might just 
rephrase my "question" (the code) to suit that person's preferences. Why 
not?

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

I'm not sure, but I've seen in the short time I've been here that a few of 
the regulars both have their specific "shudder" issues, and post helpful 
alternative solutions and corrections. So I think it definitely can help to 
address their "shudder" issues and get this out of the way. 

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

No contest to that. But why not talk to the others, who in a way insist on 
their idiom but otherwise contribute to helpful solutions, in their idiom?

> I have never seem a bug go away because someone suggested to write "if
> Number:" instead of "if Number != 0:"

Of course. I didn't mean to imply this. But if the only thing that's 
required from me is to rephrase my code idiom and replace the "number != 0" 
comparisons with "number", that's a small price to pay. 

You are right, IMO, that this stuff comes over as petty sometimes. And that 
it often is far away from the original question. But just as often 
corrections that at first seem petty lead to different ideas about 
implementation that the OP didn't consider. 

My view is: I ask for help on a public forum. I get what I get... and if I 
consider that someone who responded with something that's not immediately 
helpful has a potential to help me better, I try to get in a dialog and 
address what has been suggested, carving out my real problem in the idiom 
of that person. This is my responsibility -- after all, I'm the one who 
wants to learn how that person would solve my problem. Later then I can try 
to separate what I want to use from that solution from what I consider 
personal preference of the helping person.


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

Correct. But if it helps the person who suggested it to see the original 
problem, now not hidden (for that person) under offending idiom, then the 
change was relevant -- not for the problem, but for the communication about 
it. 

It's like if you want good stock advice from your uncle, who's experienced 
in the matter but very formal, ask him without using the f*** word. You can 
use it when asking your other uncle, who's also experienced but doesn't 
really care about formalities. Tune in if you want a good channel...


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

I agree that mere aesthetic changes usually don't address the problem in 
itself. But it's just like posting here in a distant Chinese dialect won't 
do you any good (and neither in a distant, say, Scottish dialect :). If you 
want to get up a helpful communication, you need to use the right language. 
Here it is English and Python :)  and if making my example code more 
pythonic (and my textual part more English) helps me creating a better 
communication about the issue I'm interested in, that's what I do (and what 
I'd recommend everybody else to do). 

If there is a valid reason for a part of the code being different 
("non-pythonic"), and that difference may be relevant, then there's a way 
to show that reason in the example code. It may be that exactly this 
process of boiling the code down to the relevant pieces shows you the 
answer. That happens more often than most people realize, and is a process 
that's quite valuable. 

To apply that to your example... If there's no particular reason to write 
"number != 0", then just repost the problem code with "number" instead and 
you're done. But if there's a reason, try to set up your example code so it 
shows that reason. This both helps people understand your problem better, 
and may just show the reason for the problem -- after all, you most often 
than not don't know where exactly your problem is, so you're not in a good 
position to judge what you can leave out of the code without taking out the 
problematic part. So: boil down your code to what shows the problem, and 
nothing more, as much as possible, and present it in an idiom that helps 
the others to help you. 

Gerhard