begin quoting Andrew P. Lentvorski, Jr. as of Sun, Mar 13, 2005 at 08:25:43PM
-0800:
>
> On Mar 13, 2005, at 7:50 PM, Stewart Stremler wrote:
>
> >1) Don't hard-code data. Constants aren't. Besides, it's hard to know
> > why the magic value of 6.28 works. Paths to dependent programs may
> > change. You never know when something on the system will be moved,
> > and your program should still work if everything is moved around.
>
> This is probably more an artifact of programming. I hardcode a lot of
> things as I am building up a prototype. Overgeneralization kills
> projects, too. As I need more flexibility, I start building it in.
Yes. And a lot of prototypes are shipped as the final product. :(
> While I never know if something will be moved, I also never know if
> something *won't* be moved. Adding unneeded generalization also adds
> bugs.
Actually, I think lacking *any* generalization _counts_ as a bug. There
is a curve -- a tradeoff -- and it isn't linear. Either extreme results
in broken code.
Designing in the ability to handle runtime change is much like adding a
"hinge" to the program -- it's a point of flexibility. Too many hinges,
and you're looking at pinched fingers; nothing but hinges, and it doesn't
even stand up by itself. So yes, overgeneralization kills.
But the operating system provides a set of prebuilt hinges; subverting
these in the name of avoiding overgeneralization makes the program
brittle. Fragile. Not robust, in other words.
For programs you write yourself, you can build in flexibility where you
need it. But if I'm running your code, I want that flexibility where I
need it -- and editing your non-commented code and recompiling isn't a
sensible use of my time.
> >2) Don't spread out your platform-dependent code. Put it all one file.
> > That way you can rewrite just one file for each system, and porting
> > involves selecting the appropriate machine-specific file to link in
> > to the rest of the system.
>
> Who cares? Everything is x86 running Windows.
Heh.
> While that sentiment is a bit harsh, it is pretty much true. As a
> software developer, there is *zero* reason for me to acknowledge the
> existence of anything else.
Except for the Open-source community. And the BSD community. And the
Mac community. I'm not running MSwindows, and I have just one x86
machine running right now... so I'm self-selected into a group where
that sentiment does _not_ apply.
Plus, porting software to other platforms tends to expose subtle bugs.
So it's a useful exercise.
I really do want a world where nobody controls "most" of the market. I
think it results in better programs all around. If your programs have
to compile for several different target platforms, I think you end up
spending time cleaning up the code.
> Actually, the biggest breakthrough in this arena is probably the fact
> that games programmers now have to target Windows *and* Playstation 2.
Don't have a PlayStation 2 either. Although I'm tempted (not for games,
unless I can figure out how to port ULarn to it) just to support Yet
Another System.
> >3) Comment. Explain your intent. "Self-documenting code" is a myth
> > promulgated by the lazy and/or illiterate. It's better to have
> > well-documented but non-working code than to have undocumented but
> > working code -- because then someone else can fix your code instead
> > of having to rewrite it. 80% of the lifetime of a program is spent
> > in maintenance mode.
>
> Disagree. *Strongly*. All comments eventually become obsolete.
And all code becomes incorrect.
There's a lot of bad commenting out there, and I agree, it's a terrible
thing. The key is to document _intent_. What do you MEAN to do here?
Don't tell me what I can deduce from the code.
> As a consequence, I have to disregard comments *anyway*. Don't waste
> the time putting them in as I don't believe you anyhow.
If the code doesn't match the comment, it's a bug. If I'm looking at
the code, there's a strong chance that it's because I think you screwed
something up.
If I see:
for ( i = 0; i < limit; i++ ) {
a = foo( i );
b = foo( i + 1 );
if ( bar( a, b ) ) {
baz( b );
}
}
Versus:
/* pairwise compare elements, and do baz on odd matching elements */
for ( i = 0; i < limit; i++ ) {
a = foo( i );
b = foo( i + 1 );
if ( bar( a, b ) ) {
baz( b );
}
}
...I'll have a hope of figuring out that my incrementor is broken.
Also, unless you're writing in a language like Java or Smalltalk that
encourages CompleteSentenceMethods, a comment that expands the name of the
method/function/variable should be a matter of habit.
This doesn't mean that *bad* comments should be preserved.
/* loop limit times */
for ( i = 0; i < limit; i++ ) {
a = foo( i ); /* get a */
b = foo( i + 1 ); /* get b */
if ( bar( a, b ) ) { /* compare a and b with bar */
baz( b ); /* call baz with b */
}
}
...annoys me to no end.
The difference is in _intent_.
> >I cannot *make* anyone do anything. I can write MY code so that it is
> >as "clean" as possible. Otherwise, I can only argue. Create memes and
> >set them loose. Alas, it seems that my memes aren't terribly
> >infectious.
>
> Well, your memes cost developers time but don't gain them much, by and
> large. They clearly aren't going to be very infectious.
Naturally. Doing The Job Right when Not Doing The Job Right doesn't have
any negative consequences just won't appeal to most people. That's why
I threw some of the blame on the users -- there are people out there who
want to pass laws to "improve code quality", which annoys me. Why? The
market clearly doesn't care.
> >The current meme is that it's my machine, not yours, not theirs, but
> >mine. I should get to decide where things go, how things are arranged,
> >and I should be able to do this whenever.
>
> Maybe. But I think the bigger meme is going to be that PC's need to go
> away. Most users would rather have a closed box that is the
> responsibility of someone else and would likely pay for the privilege.
Alas, I'm again self-selected out of that group.
> They will not realize what they just gave up, but I bet that most
> wouldn't care anyway.
If you phrase it differently -- "Do you want quality programs, or cheap
and fast as possible programs?" They'll probably indicate the former,
but only be willing to pay for the latter.
> Yes, I'm being intentionally antagonistic.
And, as always, you make good points.
> I actually *agree* with
> your points to a certain extent (except for the comments thing).
:)
I think we can reserve that for a separate thread. :)
Maintenance includes making sure the comments are correct. This is not
sexy work.
> However, Microsoft has now conditioned everyone to believe that
> computers/software are crappy. Creating non-crappy hardware/software
> has no market advantage for the moment. Therefore, your memes garner
> no traction.
Yup. I agree.
> Actually, one of my hypotheses about open-source is that it only gains
> traction in areas where being able to fix a bug *today* is an
> advantage; otherwise it fails or, more likely, just flounders
> indefinitely.
Back to the sexy work thing, I suspect.
-Stewart "All programmers should start out maintaining a program." Stremler
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
