Class comments!?

goran.krampe at bluefish.se goran.krampe at bluefish.se
Tue Oct 19 21:32:03 UTC 2004


Hi Lex!

As usual we talk around each other :), or at least I hope we do.

lex at cc.gatech.edu wrote:
> goran.krampe at bluefish.se wrote:
> > > 	X + (good, uncommented code)  >  X
> > > 	
> > > A decent way to getting a higher volume of commented code is to put
> > > uncommented code in there and thus make it easy for people to contribute.
> > 
> > Eh... What? That is probably the silliest thing I have heard in this
> > thread. Really. ;)
> 
> It is an expression that volume matters.  "+" is combining two globs of
> code.  ">" means I like the left side better than the right.  You would
> not consider this to be a true formula in all cases, but I would.

I wasn't commenting on your formula - I was commenting on the paragraph.
Since I really don't believe the rule would leave good code outside of
the image the formula makes no sense.

> > And also - what you are proposing (?) is AFAICT what we have been doing
> > over the years. And it hasn't really worked, has it? I have just
> > collected some stats (code below and printout) on 3.5, 3.6, 3.7 and
> > current 3.8. If you look at percentage of classes without comments it
> > was about 43%->40%->37% (positive trend? hard to say, depends) and now
> > 42% (oops). Of course, 3.5 to 3.6 removed a LOT of classes so more
> > analysis is needed to get the whole picture.
> 
> Have you tried counting the *number* of *commented* classes?  That has
> surely increased over the years.  I really don't care that the
> percentage has gone down.  Truly.  So what if it has?

I intend to make a more detailed analysis, and since we also have
removed classes from the image I wouldn't be so certain that the number
of commented classes has increased. But why don't you care about the
ratio? If we are getting a larger and larger base image (well, 3.5 ->
3.6 made it smaller, but then it has increased steadily) that is less
and less commented - I consider that to be a problem. And please -
remember that we are talking about the *base image* here.

> > > If we reject code then we spoil the open source process we have going
> > > and make it hard for people to fix (comment) the code.  But of course,
> > > putting in uncommented code reduces the *percentage* of commented code,
> > > perhaps indefinitely.
> > 
> > Note that having a rule saying that all classes should have a comment
> > (no matter how small) is IMHO not a rule that will reject code. I
> > honestly believe that the author would take the little time needed and
> > just fix it.-
> 
> Well what is it then?  If it's just a statement of what we would like,
> then I am pretty well agreeing with you.  It's the rule part that
> bothers me.  We have enough barriers and enough load on the harvesting
> process already.

What I meant is that such a rule would IMHO not in practice make code
rejected.
I instead think it would make sure the code got at least minimally
commented before going in.

I mean, we are pushing *new* classes into the *base* image here! Stuff
that everyone relies on. We aren't talking about packages on SM.
Normally we don't push 80 classes into the base image, do we? So why are
you having such a problem with accepting this rule? Again, it *amazes*
me. And also, remember that I am not proposing any rule about the
comments - they can be short oneliners *if the author thinks that is
enough*.

> > > I agree the *percentage* of good code would be important if Squeak were at
> > > a stage that it is worth picking it up and studying it.  However, I think
> > 
> > *We* are studying it every day!!! Your reasoning strikes me as truly
> > odd.
> 
> Well then please try to see where I am coming from.  I don't know how
> better to express it than the difference between percentage and volume
> of nice code.

What do you mean? You say that we are not at a stage where it is "worth
picking it up and study it".
I responded that hey, we study it every day!! Everyone trying to
understand a new piece of the base image reads the class comments! Or at
least they should, I have heard at least one person denying reading them
- but he is most probably in the minority.

Anyway, then you responded with... what?
 
> To try and get concrete again, I am suggesting that we generally include
> code into the image at an early stage, if the image is where it belongs,
> so that we can use the standard open-source approach and let everyone
> start playing with it.  If there is some other way to make open source

Of course we do - but I say with the additional rule that the *author*
introducing *new* classes (doesn't happen very often, and when it does
they are generally few) includes a *minimal* class comment. Now... what
is so terrible with that?

I am really not interested in talking about this anymore, I am simply
out of breath.

> work, e.g. by sticking it on SqueakMap, then that would be fine, too, so
> long as it's really an optional package that isn't supposed to be in the
> image.
> 
> I really dislike the idea that the author is supposed to perfect the
> code before releasing it to play with.  Squeak is a work in progress.

Who the *hell* have said "perfect the code"?! I have said "include a
damn single line class comment in new classes in the base image!!!".
That is all. It is trivial. It is simple.
 
> -Lex

regards, Göran



More information about the Squeak-dev mailing list