Hi all!

Funny, seems I can't let go of this, even though it feels so hopeless...

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> Lex wrote:
> > > On the flip side, bad code cannot be made good just by forcing it into
> > > some conventions.   Do we want to have to accept code just because it
> > > follows some list of rules?  I don't think so -- we should also require
> > > that the most important packages have a certain level of functionality
> > > and quality, for example.  There is no safety to be found in lists of
> > > rules; poor authors will always find a new abheration to circumvent
> > > them.  :)

Hmm, not sure if I replied to this before - but who ever said we should
"have to accept code just because it follows some list of rules"? Of
course not, that is just silly.
 
> goran.krampe at bluefish.se wrote:
> > Personal reflection:
> > I find it interesting that so many - at least considering the vocal
> > people - are so negative about trying to establish small little rules.
> > We do it all the time! The mistake I did this time was obviously to
> > *ask* about it. ;)
> 
> This is important to me.  Most rules will not improve the
> situation--they'll just make more rules.  If you want to make things
> better then someone has to go in and make some positive effort.  Rules
> are negative efforts that merely say what people cannot do.

Or what they *should* do. Not all rules are "negative". Often the
difference is in the eyes of the beholder.

Also - there are tons of Smalltalk coding conventions that we *do*
follow and that most of us would get upset about if they were not
adhered to in the standard packages. Now, most of these rules are so
"obvious" we don't bother listing them. And that is fine, no need to
clutter our minds with rules on stuff that everyone follow.

And then there are the things that people do differently. And that is
the area where it gets interesting.

> On coding
> conventions, I do not want to reject code merely because it disobeys
> some arbitrary coding convention.  That sounds like a net minus, given
> that we can all read the existing code fine, but a new contributor may
> well not be hip with the conventions.

Funny you mention a "new contributor". You do realize that it will be
much easier for new contributors if the standard packages follow the
same conventions? It will then of course minimize the problem. Doing as
the Romans will be much easier when Rome is clearly visible.

And also - I have always talked about these new rules to be easily
enforceable and probably also very easy to apply. Which means that it
would not lead to rejections.

> I am sorry if I am sensitive about this, but I see it in Debian and I
> see it in the laws of my country.  People pile on rules in order to try
> and protect themselves from bad stuff, but it doesn't work.  Life always
> has danger, and bad coders will always astound you with a new
> abberation.  The criterion for a good rule (or a good law) is that it
> improves things on the whole when it exists, not that it corresponds to
> good practice.

If I didn't believe having *some* rules could lead to an improvement I
would never have suggested it. Also - we have *no* spoken rules today
(only a big heap of unspoken ones) and you are already reacting against
it.

In that case I can only interpret your view as "I don't want any rules".

> Rules are a good tool for a community to use, but the
> tool must be used with care.  Let's make just a few rules, let's choose
> them carefully, and let's *not* have lots of small rules.  Let's hack
> code, not policy docs.

Eh... a few rules, chosen carefully. What do you think I have been
asking for?
 
> By the way, if you truly have made policy without asking, I am unaware
> of it and I do not feel compelled to comply.

Being the main drive behind SM and also a Guide I have been involved in
making tons of "rules". Lots and lots of them.

But if I instead say that I have "openly made decisions on how things
should work with the input from the community" - then perhaps I am not
triggering the same sensitive buttons. Still the same.
 
> -Lex

This discussion has actually made me lose some of my faith in this
community. I thought we were striving for excellence. I thought we were
collectively trying to move Squeak into a future were it is a superb
universal tool for novices and pros alike. Having consistency in the
standard code - when such consistency improves both the impression of
quality and actual readability - felt to me like a quite obvious path
for us to explore.

It turned out that even the most obvious thing - like having a class
comment for all standard classes - was something that I had to fight
for! Here Tim would insert a witty on-the-mark expression, but since I
am not Tim I just write:

Silly. faith := faith - 10.

regards, Göran