Hi,

I do care about style. I do think that style is important. 

I just don't think that a "style rule" that says "if you have more than N
variables then you have a BAD or POORLY WRITTEN method" is a rule that I
would follow. 

RELATIVE IMPORTANCE OF RULES AND GUIDELINES
I think that other "style rules" like "names of variables" is "MORE"
important. I am reducing the importance of the "temporary variable count"
rule to be less than the importance of the "variable name" rule.

STYLE GUIDELINES VS STYLE RULES
I consider "style" to be a "suggestion" or "guideline" that is taken with a
grain of salt. I don't think that "style" should be enforced as if it's
"rigid rules" or "laws". I think of styles as guidelines that provide
suggestions for improvement and quality acceptance.

COMPLYING WITH A STYLE
Certainly you can be "compliant with" or "using" a "style". Certainly it
would be valid to say that some program (or portion thereof) does not meet
the "criteria for A PARTICULAR style". For example, if asked to attend a
"formal tuxedo" party and you arrived in "punk style" clothing you would
not be meeting the requested style.

ONLY ONE SMALLTALK SYTLE?
I think that there is MORE THAN ONE "Smalltalk Style". If you have
identified, as others have done, elements of a "Smalltalk Style" that you
have "encoded" by some means "into rules" this is fine. I have no objection
to your "Definition of Smalltalk Style" as long as you don't force it on me
(and others) as "THE ONE AND ONLY VALID SMALLTALK STYLE". This is all I am
saying.

MANY SMALLTALK STYLES
So far we've identified a few differing styles of writing Smalltalk code.

STRICK SMALLTALK STYLE
There seems to be a "Strict Smalltalk Style Rules" that says that it's
"bad" style to write "methods with more than 5 or 10 temporary variables".
Actually, this "Strict Smalltalk Style Rules" seems to go further and say
that all such methods "MUST" be re-factored at all costs to meet the style
rules. 

Correct me if I am mis-stating this. Actually, I would like to know
your "defintion of your Smalltalk Style". If you had to name you style what
would you name it.

I certainly don't have an objection to your saying something like
"according to Strick Smalltalk Style Rules method x is poorly written, due
to too many temporary variables, and must be rewritten in order to comply."

SMALLTALK STYLE GUIDELINES
Another style, "Smalltalk Style Guidelines", is more relaxed about the
issue of the number of temporaries. A guideline would say something like
"if you have more than 5 or 10 temporary variables you may wish to CONSIDER
refactoring the method". It's a "hint" or "indicator" for you but it is not
manditory.

IMPORTANT DISTINCTION
Certainly the "distinction" of "counting variables" is something that can
provide information about the "complexity" of a method. I think we are
disagreeing on the "action" that "must" or "could" be taken in the light of
the information gained from this "counting variables distinction".

FUZZY LOGIC and THINKING
I think "Style" is too fuzzy to have "definate rules" that "must" be
applied. This is why I use the term "guidelines" instead to "suggest"
potential "improvements".

I also wonder if all of the "rules" in a "style" are even self consistent
and non-contradictory?

All the best,

Peter William Lount