[Seaside] Re: too many comments
Jason Johnson
jbjohns at libsource.com
Sun Apr 15 08:20:16 UTC 2007
Andreas Raab wrote:
> Well, I'm glad Seaside is to your liking then. No pesky comments
> getting into your way. Oh, and I'm glad you have these great design
> documents and tutorials, too.
>
> Sorry, but this is getting ridiculous and I'm outta here. Seaside is
> one of the worst documented frameworks I've ever seen (and given that
> I'm used to Squeak that's saying something). And people actively
> defending that state of affairs ... shudder. Just *shudder*.
I think you are taking this wrong. At least you're taking me 100%
wrong. I wasn't defending the state of Seaside, I was only talking
about commenting in general. No, Seaside is not documented in a way to
get things done in it fast. I have been using it since last August or
so and anytime I want to do something new I spend maybe up to an hour
digging to figure it out, or in the worst case sending a mail to the
list. Of course that needs to (and according to Step, will) change.
I just saw a lot of folks building up on the one side and thought I
would mention that this needs a balance. Perhaps it has to do with the
code we have had to support. You asked if I have ever seen too many
comments. In Smalltalk? No, not yet. In C/C++/Java/etc.? Yes, every
time I have to modify someone's code at work. In the worst case, one
individual has huge preambles for every. single. function. And what's
worse, this person uses global variables all over the place for (his)
convenience, but the comments make no mention of dependencies or
anything so you can never just go in and fix one function ever. So I
would call that too many comments: they aren't helping me determine how
to make changes, but they are literally 70% of each source file.
So once again; Documenting the architecture with class comments, what a
method is supposed to do (as Tim mentioned) and similar coupled with
well named functions, well catagorized etc. = good.
Writing enormous preambles complete with ASCII art, author of the
method, change history to the method (all things that can easily be
gotten elsewhere), cryptic or downright misleading method names, that
don't even clearly explain what is supposed to happen or anything about
assumptions made = bad.
More information about the Seaside
mailing list