[SATLUG] Re: culture question (Bruce Dubbs)
afcasta at satx.rr.com
Thu Aug 28 18:09:49 CDT 2008
On Thu, 2008-08-28 at 12:34 -0500, Jason Meridth wrote:
> Prefix to your comments:
> I do Test Driven Development (TDD). I let me tests comment my code.
> Another developer can easily run my tests and see what the code is doing.
> Once in the source my method names say what they do (comment below about
> Bruce's 12 character limit)
Well, it's good your code explains itself without comments. My
experience goes back to progamming COBOL on USS San Diego (AFS-6) in
1976, but I don't have a PhD. I've never seen code explain itself
though method names, though, so it looks like my education is lacking.
> Bruce, I respect your experience and your position. Your response bothered
Bruce Dubbs wrote:
> > So you are a genius and understand all code in all domains without
> > comments.
> > Go take a look at the code for gzip and try to understand the compression
> > methods without comments.
Jason Meridth wrote:
> > > Code is organic
Bruce Dubbs replied:
> > What does this mean?
Jason Meridth answered:
> Code changes a lot. Especially when you refactor your code based off new
> features/defects/requirements. Common sense.
I'm glad you explained that - I always took "organic code" to mean that
which was local to the organization and this was a bit confusing.
Bruce Dubbs wrote:
> > It depends on the culture. I've seen a lot of bad code. If the code is bad,
> > then the comments really don't matter. If the code is good, then there are
> > probably enough comments to provide an outline.
> Thank you for re-iterating what I say below this.
> > But how long are the names that you use? Efficient comprehension means
> > that you should use tokens that are meaningful, but less than about 12
> > characters. This is backed by research.
> Can you provide link to the research please. We're not coding on 512K RAM
> PCs anymore. You don't have to limit your method names. Please don't give
> me the "waste of resources" speech. I'm sick and tired of hearing about
> geriatric ways of coding.
Ouch! Forget what I said about my programming experience. ;-) Then
again, I've never coded on a PC. A Sperry-UNIVAC yes, but never a PC.
> It's one of the many reasons I leave this mailing
> list on and off. I love the group, but the backlash when a younger person
> comes in and expresses ideas, and gets slammed, is unprofessional and
> non-conducive to a non-profit user group.
Some of the younger members have been a tad heavy handed in stating
their opinions are correct and others are wrong. Flame wars happen at
times because others get angry over the heavy handedness, but don't take
it personally. It's not really a youth versus greybeards issue, because
whenever you get a group of folks together who are passionate about
Linux or tuning pickup trucks, sometimes the passions collide.
> There is no such thing as a silver bullet. If the team agrees on comments,
> so be it. I can prove that you don't need them to make successful,
> maintainable code.
[further discusson pro/con commenting code]
A couple of years ago I inherited a project for running computer
databases in the Intensive Care Unit of a major hospital in California.
The code was a mix of Delphi and Java, running on Oracle on Sun SPARC
Solaris 8 and 9 servers. I migrated it to Linux and if the coders
hadn't commented their system calls, it would have been all but
impossible. Because I commented what I did to modify the code, I was
then able to replicate the systems from commercial Linux servers to
Scientific Linux (similar to CentOS) for our development servers.
This commented code was shown a few months ago to a new customer, who
agreed with our best practices model, and I'll be building some new
servers soon for another large hospital near Chicago. I didn't do all
of this on my own - our Oracle developers and programmers follow the
same practices, and we understand each other's work better because of
it. My company hired an Oracle DBA for the systems we installed in
California, and he's been able to maintain them with very little direct
assistance from me, except for growing and building new disk volumes and
a few firmware upgrades.
On the other hand, in 1991 I was given a GIS system with some of the
worst spaghetti code you could imagine, and very cryptic or nonexistent
comments - it took several months to unravel it all and get it into
production, when I could probably have had it fixed in a week if the
code had good comments (then again, when have I ever seen bad code with
good comments?). It would have taken probably a few weeks to fix even
with bad comments, so I could see where the original programmers were
headed. As it was, before I could read the code I had to decrypt it.
Al "yes my beard is grey" Castanoli
More information about the SATLUG