Re: Assertions and Such

[Sean Middleditch <sean middleditch iname com>]

Lauris Kaplinski wrote:

> On Mon, 21 Aug 2000, Sean Middleditch wrote:
>
> > Ya.  Like I said, if a piece of my code has so much as one warning, I won't
> > release it till the warning is squashed and gone...  Maybe everyone just
> > isn't as picky as I am.
>
> Yeah. Unfortunately we are living in real world, where you sometimes just
> need working solution now, not in some unknown future date.

Again, I don't consider it a working solution if its not warning free.  If it has
warnings, then obviously its not working the way its supposed to, and chances
are, if there's warning, the programmer wasn't meticulate enough to ensure
his/her code is free of other problems...

> If you are writing application, you are free not to release it to general
> public before it is 'warning clear' - although it is often good idea to do
> it. We are not killing warnings just for the sake of killing - warnings
> are often notices, that there are bits of code needing rework - and the
> rework can be costly.

I'm completely missing your point, I think.  Why wouldn't you kill warnings?  The
messages from compilers and GTK don't say: "Notice: you are using a deprecated
API or your code needs restructuring", they say: "Warning: there's a bug in your
code else this wouldn't be printed to the screen!!"

> If you are writing library you often want to thow it out in half-finished
> state:
> 1. To encourage people using your API

I never said don't throw it out half-finished.  The last release of AweMUD I put
out was 0.4.5.  Of course it wasn't finished.  I just bothered to make sure it
compiled OK and ran.  If there were warnings, I fixed them first.  Not just
released it and then fixed them (which seems rather stupid, why not do it the
first way), or (as I see way too often, and this is what I'm complaining about)
people releasing software that obviously has flaws (you can tell by the warnings,
for a start) and then never fixes them: 5 releases later there are only more
warnings, and a lot of the old warning start turning into REAL bugs.  If you want
to stop bugs, you have to stop warnings.  That's what they're FOR.

I mean, simple things like an app always causes GTK to generate a warning about
passing a NULL pointer to some function.  If your code was designed to allow a
NULL value for whichever pointer, the programmer should check that the value
isn't NULL before calling the function: if the library wasn't built with
debugging, your app would crash.  Using debugging features as a fall-back is pure
laziness for a 10 second fix.

I've yet to run into a situation with warnings that requires 'a rework' of code:
if the problem's that bad, and the code needs reworking, it should be done ASAP
before you build even more code on top of the unstable code, and really cause
yourself a problem.

> 2. To find more real-world test situations
> In every case the decision is of developer to do - whether users will be
> happier using buggy software than not using it at all. The problem is, of
> course, that many open-source projects will never be finished - because at
> the moment they are bug-free enough to disable warnings, they are already
> seriously outdated and main development team is strongly encouraging fresh
> buggy version.

Again, you shouldn't release software with a known bug.  There's a big difference
between saying, "OK, this snapshot of the code is running nice, lets make a
release", releasing a beta copy of the software, and then finding a bug; or
saying, "OK, well, the app generated 2 warning every time I click this button,
but what the Hell, flaws don't matter much, and I don't feel like taking 10
minutes to fix it," and making a release.  I'll put this in a way a lot of
open-source people might be able to understand:  That's how Microsoft does
things.

Yes, lots of open-source software DOES have bugs because its in development.  But
it doesn't really have to.  Why not fix the warnings the first time they occur
and never worry about them again, and potentional stop a slew of other problems
that might develop in the future?

I'm definitely a code purist, I know that: most of you probably think I'm a nut.
(and those that do are right  ;-)

I just have trouble understanding how anyone could just let that kindof stuff
slip past when there is absolutely no good reason: releasing software with a lack
of features, or something not behaving 100% correct is understandable, you're
testing what you have to see what is needed.  Slapping together a bunch of code
that barely compiles on your own system, much less other people's, is complete
laziness and lack of effort.



Sean Middleditch

> Lauris