begin quoting Andrew Lentvorski as of Sat, Jun 03, 2006 at 05:32:41PM -0700: > Stewart Stremler wrote: > > >Rewriting logic, yes. Fixing up formatting, variable names, adding > >comments (function, file, and module-level).... ought not introduce > >any bugs -- far less, at least, submitting a patch to add functionality. > > > >But you're quite correct that "rewriting" is often a quick way to add > >bugs. Been there, seen that, glad I wasn't involved. > > Sorry, I don't buy it.
Don't buy what? That you're correct? > Simply rearranging indentation often introduces > bugs. Or reveals 'em. > >I'm seeing more and more code that doesn't lend itself to simple tests. > >It takes a fair effort just to configure the environment to get the > >damn thing to *run*. > > Yeah, so? Welcome to development. There's development, and then there's gratituous bullshit. I wouldn't expect you to spend so much energy defending the latter. Perhaps I wasn't clear in what I was trying to convey. I wasn't talking about code that handled problems that were intrinsically difficult and complex... I'm talking about problems that were *made* difficult and complex. (Yes, I'm venting frustrations regarding code that I have to work with. If you can't let me vent a little, let me know, and I can solve the problem on this end.) > Writing code to handle NFS file locking is annoying. Setting up a test > to make it work is even more annoying. If you don't set up that test, > you get buggy NFS file locking. > > See rpc.lockd on Linux. Oh, good testing is necessary. I don't mean to dispute that. > Fortunately, people are starting to get the fact that emulators are good > for setting up testing. I shouldn't have to set up an emulator because some programmer decided that his program would always write to and/or read from some hard-coded path, or be able to hit some machine on the network to parse a config file. A functional test can be Just Fine for some programs. > >Trying to write a test for that sort of application is a tad daunting. > >What do you do when confronted with a program that takes a half-day to > >set up before you can get it to run at all? > > Suck it up or write buggy code. Your call. How about I shoot the programmer responsible for the monstrosity in the head? Far more satisfying, and it would make the world a better place, too. > No one said development was always easy. That's a cop-out. No one said that it was okay to make it more difficult that it has to be, either. Software is complicated enough. Needless complications are just spitting in the faces of anyone who has to deal with your code. If you have no tests, an all-day setup procedure, and a bag full of assumptions that the production machine will be set up just like the developer's machine... saying "it's not supposed to be easy" is like the old aphorism that "code that was hard to write should be hard to read". It's a sign that self-important egotistical geniuses are more concerned with showing off how smart they are than in doing their job. Sure, development won't always be easy... but that's no excuse for going around and making it difficult, either. > >I'm seeing some hype about automated code-quality tests, and I'm > >wondering if we aren't heading towards another annoying fad. > > Maybe, but I just consider them to be Lint on Steroids. Fortunately, > most of them are pretty innocuous. I hope so. We'll see. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
