goran.krampe at bluefish.se wrote:

>Hi all!
>
>This thread slided away from what I was trying to talk about. Sure,
>interesting as always but...
>
>Personally I think pretty printing is useful - but I never use it. I
>tend to agree with Andreas that the code *as written* includes hints and
>information that I don't want to loose, like whitespace and various
>formattings of nested blocks.
>

(Sorry to slide the topic back to pretty printing here... :) )

I think I agree roughly with Dan's position... the current pretty 
printer loses formatting information on a couple of important things, 
blank lines (for separating sections of code) and comment locations 
(whether at the beginning of a line or trailing an existing line of 
code).  But other than that, I think it's perfectly legitimate to lose 
all other formatting information.  If we had a *good* pretty printer 
which kept the blank lines and comment locations and was reasonably 
customizable, I'd probably use it all the time.

>Another thing is that I think pretty printing is *hard*: For example
>code with blocks tend to be hard to format according to rules so that it
>always "looks good". I have given up on trying to figure out what my own
>personal rules are - I seem to always adapt my style to the code at
>hand.
>

Agreed that it's not easy.

>...
>  
>
>I just want us to think if we can agree on *a few simple rules*.
>
>For example - is it really too much to ask that comments which are meant
>to be full sentences are formatted accordingly to proper english? (first
>word with capital letter, ending with a period)
>
>Or is it really too much to ask that all classes have a class comment?
>Even if it is only one or two lines? Missing class comments is IMHO
>totally unacceptable *in the standard packages*.
>
>So please people, could we get back to this issue? Do you agree with me
>that a few simple rules could actually be a good thing to have regarding
>the code in the "standard" Squeak packages?
>  
>

I would agree with the couple of simple rules you just mentioned.

This reminds me that I am still planning on finishing a "changeset 
validator" tool which could make some simple automated checks before a 
changeset could be incorporated as an update.  The validator could run 
whenever someone uses "send to list" from the changesorter or BFAV, and 
also when approving an item, etc.  This could enforce a few basic 
things, such as the rule that all new classes must include class 
comments.  (This would make my job as update stream maintainer easier 
too, as it would prevent things like missing method timestamps, etc.)

I should actually have some time to work on this after 3.7 goes beta...

- Doug