Some words about error checking

Bugs. Whatever you program, there'll always be bugs because you did something wrong, forgot to add something here or just because were pretty dumb the moment worked on it. Actually, the can prevent most of this by simply adding proper error checks and error reporting methods. Pretty standard so far, but I can't believe how often people don't check function return values or even passed parameters. It's one thing to completely omit it and treat the stuff like a macro or high performance function. Still, the shouldn't be the normal case and only used in basic stuff that's so deep underground that you may call a million or thousands or times (and don't do non-inlinable library calls there). Everything else should properly respond to problems and atleast shutdown everything down if something didn't work. Or maybe continue to work and mark the error very explicitly.

Problem is, no programmer I have met so far kept this in mind or even tried to do some sort of quality-assuring overhaul if the knows that there's stuff he is responsible for. It always comes from others, though it shouldn't even happen. I'm having a hard time to overlook the problems I see everywhere in the code cause I don't have the administrative power to just order it. I could actually shit in every shoe of every programmer here and they still wouldn't do it. You're at the bleeding edge of problems when doing QA work. I definitely know that I don't really want too much into their code as the nightmare continues each time I'm taking a look at it. Even worse, a lead programmer shouldn't try to advise you with stuff always already knew while not programming completely correct by himself, right? Yeah, but it simply happens. It had to happen of course, it's a human bug after all... Personally, I'm trying to always decide between functions that do so deep stuff that performance is necessary, functions that return valid pointers or NULL and functions that return a custom logic value along with debug macros I defined in ITK. If something goes wrong or threatens program flow (not counting options or rare "tolerated" incorrect parameters), it should shut down and give a detailed list about everything that was part of the program. That's not necessarily a stack trace, but a very proper lo with all happened events. If you do this by default, there isn't really a point where missing files or stupidly ignored script interpreter errors could get past you. I know it's cumbersome and takes time, but even me, the snail of get-it-done and let's-do-it is able to archieve complicated features in in a short time.

I don't know when, but some day I'll freak out about this. Some day I'll tell everyone to properly debug if they don't want to get more overhaul tasks than planned. I mean seriously, shit's breaking down due to ignorance and just cause they don't have the balls to tell their boss where everything stinks. Even if the boss knows where it stinks, it's a loss of programming honor, a clear mark of spaghetti. I may over-amplify this, but it's the most annoying thing ever if you want to get into code but notice that everything's just a total mess - conceptually and realistically. I mean they don't use exception as these provide a better than plain, simple ignorance of problems. And if you even hesitate to test a whether a new piece of codes generates an error, asking the QA department to test it for, THEN you're a really lazy bum.

Fuck, I cannot express how frustrating this is. It's like you're coding with a bunch of half-ass students and a lecturer who believes in the fact that logic doesn't outsmart own believes. Thus rendering a situation in which someone falsely thinks that new programmers do all mistakes of older programmers and apply their "advanced" way of programming. I long for a fully fledged workflow where new concepts will be introduced before enough brainstorming and old concepts abandoned if a new one was found. Too bad that this doesn't include the huge amounts of artifacts every larger project has from older versions. Well, maybe I'm just thinking too covering to appreciate the used concepts, maybe I believe too much in my own tech - that could be quite possible.

No comments: