Re: Re: Comment Block Creator

[jpfarmer]

I think your comment is a little snide and extremely discouraging.

I'm making a concerted attempt to create thoroughly commented code, and am trying to keep it formatted so it's clear to read. If the format is offensive to you, I'd appreciate suggestions on how to make it less so, but a blanket "it's too ugly to be used in public" reply makes me want to do exactly what you suggest and avoid contributing any code.

In any event, I'll think two or three times before sharing anything in the future.

[Anonymous Monk]

Please don't let the lack of social skills of a few discourage you too greatly.

On the other hand, many experienced programmers find the kind of comment block formatting you are doing to be both excessive and hard to maintain. At the very least, consider leaving the right side of the comment box open rather than closed. Many editors can reflow text with comment characters on the left, making updates relatively painless. But closed-box comments require additional effort and/or tools to maintain, which hinders their usefulness.

[merlyn]

I didn't intend for you to stop sharing!

But you did post here, and posting here implies inviting critique and comment. Hence my comment.

The problem with "fancy comments" is that they are either making into comments what should be POD or a separate document, or they are making it hard to rewrite the code, because you don't want to touch the "sacred" fancy comments. Also, being set off that way, you might trust the comments more than the code, and many years of programming has lead me to believe that in "live" code, the comments eventually lie, because someone has edited the code and not the comments.

Keep your comment style simple. Keep it describing the "what" and not the "how", unless the "how" is particularly tricky. (And most "how" comments should be inline anyway.) Keep it describing any tricky presumptions, assertions, or dependencies. Keep it being for other programmers, not for users of the code (which should be in POD anyway).

I think once you figure out what really does need commenting, you'll comment less and code more.

[Anonymous Monk]

Hmm, the merlyn method
1. criticize (often in a creative manner with extra sarcasm, always giving the wrong impression)
2. wait for reply asking for "constructive" criticism
3. respond to this reply explaining original criticism, finally offering something more than a "boo"
Did I miss a step?

[merlyn]

No, more like:
1. I call it like I see it, presuming the recipient is a mature programmer and understands that they aren't their code, and can understand that what i'm saying is also just my opinion, and not the voice of the Almighty.
2. Presumption is shown false.
3. I take a different approach, because if the message was important enough for me to type one way, it's also important enough for me to type a different way.
I really don't do anything different when I post. Some of them are heard the first time, some of them take clarification. It's the same in reverse: some questions make sense the first time, and some require feedback for adjustment. That's what dialogue is about.