is there any principle when writing python function

[Stephen Hansen]

On 8/27/11 3:21 PM, Emile van Sebille wrote:
> On 8/27/2011 2:57 PM Ben Finney said...
>> Emile van Sebille<emile at fenx.com>  writes:
>>
>>> Code is first and foremost written to be executed.
>>
> 
> 
>>      “Programs must be written for people to read, and only
>> incidentally for
>>      machines to execute.”
>>      —Abelson&  Sussman, _Structure and Interpretation of Computer
>> Programs_
>>
> 
> That's certainly self-fulfilling -- code that doesn't execute will need
> to be read to be understood, and to be fixed so that it does run. Nobody
> cares about code not intended to be executed.  Pretty it up as much as
> you have free time to do so to enlighten your intended audience.

Er, you're interpreting the quote... way overboard. No one's talking
about code that isn't intended to be executed, I don't think; the quote
includes, "and only incidentally for machines to execute." That's still
the there, and its still important. It should just not be the prime
concern while actually writing the code.

The code has to actually do something. If not, obviously you'll have to
change it.

The Pythonic emphasis on doing readable, pretty code isn't JUST about
making code that just looks good; its not merely an aesthetic that the
community endorses.

And although people often tout the very valid reason why readability
counts-- that code is often read more then written, and that coming back
to a chunk of code 6 months later and being able to understand fully
what its doing is very important... that's not the only reason
readability counts.

Readable, pretty, elegantly crafted code is also far more likely to be
*correct* code.

However, this:

> Code that runs from the offset may not ever again need to be read, so
> the only audience will ever be the processor.
> 
> I find it much to easy to waste enormous amounts of time prettying up
> code that works.  Pretty it up when it doesn't -- that's the code that
> needs the attention.

... seems to me to be a rather significant self-fulfilling prophecy in
its own right. The chances that the code does what its supposed to do,
accurately, and without any bugs, goes down in my experience quite
significantly the farther away from "pretty" it is.

If you code some crazy, overly clever, poorly organized, messy chunk of
something that /works/ -- that's fine and dandy. But unless you have
some /seriously/ comprehensive test coverage then the chances that you
can eyeball it and be sure it doesn't have some subtle bugs that will
call you back to fix it later, is pretty low. In my experience.

Its not that pretty code is bug-free, but code which is easily read and
understood is vastly more likely to be functioning correctly and reliably.

Also... it just does not take that much time to make "pretty code". It
really doesn't.

The entire idea that its hard, time-consuming, effort-draining or
difficult to make code clean and "pretty" from the get-go is just wrong.

You don't need to do a major "prettying up" stage after the fact. Sure,
sometimes refactoring would greatly help a body of code as it evolves,
but you can do that as it becomes beneficial for maintenance reasons and
not just for pretty's sake.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20110827/67ad4ad5/attachment.sig>