Lord, if there were gigabytes of comments that would be bad.
Horrible. A disaster. Something to cry about. However, there are
not. So that is good. Very good. Something to smile about. If
there is anything like a whole bunch of comments, that is the sign of
an amateur and the same is true a
This is directly contrary to best practices. What really would have
helped in Struts would have been if someone had discussed some of the
naming conventions prior to committing them. They are particularly
bad in Struts. However, best practices is to make the code clear
first. If that is not pos
I think the idea is to make code clear. If you cannot possibly make
the code clear without comments, then put the comments into the code.
Gratuitous comments are counter-productive.
On 9/29/05, Dave Newton <[EMAIL PROTECTED]> wrote:
> Frank W. Zammetti wrote:
>
> > Let me ask this question... wh
Braun, James F wrote:
In my defense:
No need--we go off on these dumb tangents (well, _I_ do, anyway) all the
time. It's just one of those stupid religious flamewars.
I'm reminded of the guide on Mt Everest who said, "If they need my help,
they shouldn't be here!" That was the year 17 peo
Users Mailing List
Subject: Re: [OT] Re: writing images from a database
Frank W. Zammetti wrote:
> Let me ask this question... what's the HARM in "read in the bytes"?
Having comments that are superfluous:
(a) still requires brain processing, and my brain is in short supply :/
(
Norris Shelton wrote:
It is better to be over-documented, than under. Also, I would
use the full package name on objects. Nothing is more fun than
trying to figure out an object when it's in more than one
package (like ALL the client certificate code) or it's in some
library that you have neve
Frank W. Zammetti wrote:
Let me ask this question... what's the HARM in "read in the bytes"?
Having comments that are superfluous:
(a) still requires brain processing, and my brain is in short supply :/
(b) obscures what's actually being done (see note below)
(c) requires maintenance
Note: If
Let me ask this question... what's the HARM in "read in the bytes"?
Murray, have you ever actually had a compiler choke on a source file
because of comments?!? *That* might be the harm indeed! :)
Frank
Dave Newton wrote:
Murray Collingwood wrote:
I agree with Frank, we all started with Jav
Yes and no.
If it's his production code no, but if it's a how-to or
something that goes in a wiki, it should leave no details
uncovered.
It is better to be over-documented, than under. Also, I would
use the full package name on objects. Nothing is more fun than
trying to figure out an objec
Murray Collingwood wrote:
I agree with Frank, we all started with Java/Struts somewhere and back then the more
comments in the code made it so much easier for us to understand.
If you're documenting functionality, I totally agree.
If you're commenting "inputStream.read(xxx)" with "read in th
I agree with Frank, we all started with Java/Struts somewhere and back then the
more
comments in the code made it so much easier for us to understand. The people
who
come after us will also be learning, let's make it easier for them.
The only time you should reduce comments is when your comp
Frank W. Zammetti wrote:
Well now, *this* is a good way to go off-topic in a hurry Dave! :)
I'm sorry, I have a cold. (Marginally obscure Monty Python reference.
Every OT post needs one.)
I didn't mean to start a debate here?
I personally feel just the opposite... the more comments the b
On 9/29/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> For instance, take this line:
>
> String s = s1.toUpperCase().trim().replace('A', '-');
>
> Now, that's pretty straight-forward. But, if someone added a comment:
>
> // Convert s1 to all upper-case, trim whitespace from both ends and
> rep
On Thu, September 29, 2005 11:57 am, Dave Newton said:
> Oh god remove the comments. Bottom line: if someone can't figure out
> what's going on here w/o relying on the comments then they're fired.
Well now, *this* is a good way to go off-topic in a hurry Dave! :)
I personally feel just the opposi
14 matches
Mail list logo
