From: "Milan Maksimovic" <maksa@...>

Date: Fri, 30 Jan 2004 07:53:29 +0100

Sorry if this list is just meant for us to post interesting stuff that we
find, but I have to follow up on this.

>> The "standard" refactoring book is probably -
>> http://www.amazon.com/exec/obidos/tg/detail/-/0201485672
>> - it's OK, but mostly obvious (like basic pattern books, really)

For very thoughtful people with enough experience it is probably 'mostly
obvious' and 'basic', but for others it is a nice shortcut to get there (or
closer to that). For me it was far more then 'OK'. Back in 1999 when I first
read it I just got out of maintaining a pretty big and pretty poorly written
legacy C++ Windows application. I can still remember the pain, which was
mostly caused by my total unpreparednes for 1200-line functions
copied/pasted/changed-just-a-bit, 200+ Kb CPP files, pseudo-object and
pseudo-procedural code, and similar horrors I inherited. I understood that
things were very wrong somehow, but I didn't really have very clear ideas on
how to go about them. On some places I instinctively factored out my things
and tried to put new functionality in classes separate from the Tar Pit, but
in some places I didn't and it hurt. The sheer amount of things was
imobilizing my very small cerebrum. I wish I did better there. Some people
get it without external help of any kind, some need books to tell them. I
wish I was in the first camp, but I'm still glad that there are books out
there.

The Refactoring book drastically changed the way I think about (both my and
other people's) code, and the first thing that always comes to my mind when
I think about it is - "I wish I read this sooner. Oh how I wish.".

A meager attempt to stay on topic follows: by following the advice found in
that book, after a while I realized that as a side effect void member
functions started appearing far, far less in my classes (I still don't live
in a functional programming world), which automatically meant less state,
and less state is good. Which in it's extreme form leads us to FP - less
state (actually - no state) is partially what functional programming is
M.