[Idle-dev] Re: idlefork tasks

[Stephen M. Gava]

Kurt B. Kaiser wrote:
> > > I can see that the RPC is modeled after
> > > some spec, maybe the Sun RPC spec, but it's though a glass, very
> > > darkly.  It seems to be more general than needed to do the job.
> > 
> > Well as one of your references mentionned, Guido even suggested xmlrpc,
> > but then someone else thought that might be too heavy weight. 
> 
> Drake, I think.  The parsing might slow it down compared to cPickle.
> We don't need the generality, xmlrpc is good for talking between
> different languages on different OS on different machines.
> 
> > I'll leave these kind of things up to you and Chui (and Guido) to
> > decide since I can't afford the time to get too deeply into the
> > rpc/spe stuff as well.
> 
> [...]
> We probably should add comment strings to the sections of code we're
> working on.
>
> > I think so. I also think a good doc string at the top of each class
> > and method, that documents the in and outs, is a huge benefit to
> > those coming later.
> 
> What are your and Guido's thoughts on cleaning code as we work on it?
> An advantage is purer code, a disadvantage is obscuring the changes in
> the CVS.
> 
> > I like to hack something that works, then tidy it up and improve the
> > algorithms etc.. I do often nit pick here and there in what I'm forced
> > to revisit also, but I'm very very wary in 'cleaning up' code I didn't
> > write unless I'm 1000% certain of every possible ramification. (great
> > maths there)  
> 
> Yes, good point.  But sometimes I see what appears to be excess
> factoring such that a three line def is only used in one place and
> could easily be in-lined for improved clarity.

Certainly I think we should all try to stick to some basic procedures
(which, in my rush to get some code out the door I didn't always do in
my earliest config stuff :( ) for commenting, such as: using docstrings
as mentioned above, commenting new code where we think there could be
later confusion, and, to my mind most importantly of all, and at the
very least, using meaningful and descriptive variable/attribute and
function/method and class names, _even if it means they are longer_ (ie
forget everything you ever knew about naming when coding in c ;).
 
As far as applying this to existing code, certainly clean up where you
are _certain_ there are no 'implications', but also if you happen to
penetrate the mysteries of a particularly 'intense' ;) piece of existing
code by all means comment it so others can benefit from your
enlightenment.

Stephen.
-- 
Stephen M. Gava  <elguavas@users.sourceforge.net>
IDLEfork ( http://idlefork.sourceforge.net )  " just like IDLE, only
crunchy "