Re: Bicycle Repair Man usability


Sybren Stuvel wrote:

> > -Get rid of extra variables by shifting them inline (e.g.:
> > a=1;b=2;c=a+b --> c=1+2)
>
> This is already excess functionality IMO.

I don't think that Rex talked about his programming style but about
three and only three refactoring methods survived in BRM from ~30
Fowler described in his book. By the way I can't remember the one you
picked up but I remember the reverse i.e. introducing intermediate
variable names for readability and debugging purposes.

Instead of writing f(g(h(...))) it is sometimes adaequate to write

x = h(...)
f(g(x))

I use this a lot in particular in C++. Optimzing compilers eliminate
runtime penalties. This is of course different in CPython.

In case of BRM I'm not sure why it is particular hard to implement
"Move Method" for instance? BRM is shipped with a lot of testcases
which is good but neither defines requirements nor leads a discussion
about refactoring methods in Python. Needless to say that the code is
not well documented.

Kay

.