Hi,

My point is that the "style" rules are actually subjective "guidelines" and
not "inherent" in the universe like laws of nature. That's why we call them
styles. You have yours and I have mine. This is as it should be for it
would be a boring universe if we were all the same.

> It is very dangerous to say that it is just a matter of style
> and you can make up your own mind.
Nonsense. Prove it.

> It is common in our culture to say that everything is relative, that
> there is not one right way of doing things.  We make fun of people who
> set standards.
I have not made fun of you. You may have set a standard. Who elected you to
make it the one right way? What is the standard? Where is it written down?
Who has adpoted it? I centainly haven't adopted these "rigid style rules".
I am glad this is a free country (or at least the illusion of a free
country ;--).

While I might be an expert, of some sorts with Smalltalk, I'm not saying
that ALL the rules are unimportant, even if they are only style rules. I'm
saying that they are not "rules" at all but "guidelines" or "hints" that
have exceptions. In any system of rules there are often exceptions. Since
"styles" are just subjective "guidelines", and not cast in stone, there is
a lot of flexibility. Obviously I choose to flex this "style guideline"
more than you do.

I am saying that the "rule" of the count of the number of variables is just
an indicator that the method could be refactored. Yes, it may be possible,
it may even be desirable, but it is not required for it to be a vaild
program that works and is understandable. The choice lies with the author
or maintainer of the system. This is as it should be. While programs must
follow the "logical" rules to form a valid executing program I'm glad that
we humans have the ability to be more flexible, artistic, and free.

> >Peter William Lount wrote:
> >I really think that method size and complexity is a more important issue
> >that the number of temporaries in a method. The names you choose for the
> >variables is also more important than the number of them. Often what a
> >large number of variables illustrates is a potential opportunity to
> >refactor the method. But it may be fine as it is. The number of
temporaries
> >is really a non-issue in comparison.
The relative importance of "counting temporary variables" is NOT AS
IMPORTANT as having well named temporary variables. I value readability
more than size. This is where we seem to differ.

I object to the notion that "JUST BY COUNTING TEMPS A METHOD IS POORLY
DESIGNED". This is nonsense. It might give you a hint that refactoring is
necessary but it ain't the law. It just does not consider many other
external factors that may be actually important in the whole context.

By the way, I've never said that you are "wrong". I've just said that we
have seem to be making different "jugement calls" or "choices" with regards
to the importance of the "sytle rules/guidelines". I hope that this has not
devolved into a flame war.

> If you are an expert then it is OK to break the rules, but if you don't
> know what the rules are then you are not an expert! Peter is an 
> expert, so he can break the rules.
Wow. So by breaking the "rules" I'm not an expert. Nice hidden implication
and paradox like statement. 

It seems to me that we're in agreement about the general cases but that we
disagree about the edge cases. It appears that you have a "rigid and strict
set of style rules" that you apply while I have a "loose set of style
guidelines" that are more flexible and consider edge cases and exceptions
to be acceptable. My guidelines seem to offend your sense of what should
be. This is a common occurance in the human experience.

My "loose set of style guidelines" allows for consideration of many factors
that may "diminish the importance" of any particular rule in the
guidelines. Factors such as cost, time, scope of the project, reuability
v.s. one time, size, zen minimalism v.s. get it done, and others have a
influence on real projects. 

In regards to the choices in building a VM it's up to the designer and I've
said as much. I pointed out in a previous posting that they can choose
whatever limits they want for the needs of their implementation. I disagree
with imposing a low limit and I think that the Smalltalk standard should
not impose a limit. I'm just saying that 31 temporaries is far too few a
limit for my taste. It's kind of like limiting variable names to 8
characters. Not a problem most of the time or for some of us. But... even
31 characters would limit a "few" of my variable names.

Peter William Lount
http://www.smalltalk.org
peter at smalltalk.org

----------
From: Ralph E. Johnson <johnson at cs.uiuc.edu>
To: squeak at cs.uiuc.edu
Cc: peter at smalltalk.org
Subject: Style
Date: June 18, 1999 8:18 AM

At 3:43 AM 6/18/99, Peter William Lount wrote:
>Obviously I have a different style then some of you. This is fine. Your
>style is fine. There is not any one right style.  I would hope that all
his
>methods are not this large and I would recommend that he see if he can
>refactor the method in some way to shorten it but ultimately it's his call
>and not mine. It's a judgement call for him to make and Smalltalk should
>not enforce some arbirtary limit to satisfy the "temporary variable
>police".

I am writing a reply to this paragraph because it is so important.
It is also wrong in a very important sense.

It is common in our culture to say that everything is relative, that
there is not one right way of doing things.  We make fun of people who
set standards.  So, it is natural to sympathize with Peter.

However, for code to be readable, it has to follow conventions.
The C++ world shows what happens when every development group
has its own set of standards.  Chaos reigns.  Conventions are
partly arbitrary.  There is not really a good reason why one
should drive on the right or left side of the road; either direction
works as long as everybody follows it.  Other conventions have good
reasons.  Long methods are hard to read in a browser, for example.

One of the big advantages of Smalltalk is that the original
Xerox PARC SMalltalk-80 had a very consistent style.  Because the
people who developed other Smalltalks usually had used Smalltalk-80,
they learned its style and propagated it.  None of the other
versions of Smalltalk are as consistent as it, but Smalltalks in
general have a more consistent style than other languages.  This
makes Smalltalk code easier to read than it otherwise would be.
Part of learning Smalltalk is learning how to write code that fits
into the image.  So, as long as there are new Smalltalkers, there
will be discussions about how to rewrite methods to make them
shorter, how to name methods, how to handle control flow, and
other low-level coding questions.  It is very dangerous to say
that it is just a matter of style and you can make up your own
mind.  If you are beginner, you need to learn the standard style
so you can read other people's code and so you can write code
that fits in.  If you are an expert then it is OK to break the
rules, but if you don't know what the rules are then you are not
an expert!

Peter is an expert, so he can break the rules.  But I will not
let him get away with saying that rules are not important!

Peter is also wrong about the reason the VM limits the number
of variables.  All VMs limit the number, the question is what
the limit should be.  It is easier to implement VMs with smaller
numbers.  The VM designers looked at real code, decided it didn't
require large numbers, so made a decision that allowed them to
make programs smaller and faster.  I have been programming in
Smalltalk for 15 years, and have never written a method that
the compiler wouldn't accept because it had too many temporaries.
However, I once wrote a program that generated code that the
compiler wouldn't accept!  That was how I found out there were
limits.  Yes, VisualWorks (which is what I use the most) has
big limits, but it used to have the same limits as Squeak.
I used Tektronix Smalltalk for a long time, which had the
same limits, too.

So, the limit is small because Smalltalk programmers don't
use lots of variables.  It is not small to prevent people
from using lots of variables.

-Ralph Johnson