Since last week, I've written around 2000 LOC of C++ of a new subsystem. I'm a day or two from completing it. I've avoided compiling or testing it so far, and am using a simple text editor.
I'm testing myself to see if I can write something this size with zero bugs the first time. Probably not, but who knows. It's just for fun. I keep going over the code carefully, pass after pass, and making adjustments as I notice things, running the code in my mind. One effect of this process is it's a lot more modular and better documented than my code normally is. It's like I'm prefactoring - refactoring extensively before even the first compile or test.
We'll see how this turns out. I'm kind of wondering if the result will be that it takes less time overall since if I really do get it down correct, there will be no coming back to it in 6 months to find some bug and spending a whole day getting back to speed with the code.
July 3rd, 2007 4:27pm
Please, keep a close log of WHEN you discover a bug, and HOW LONG it takes to fix each one.
July 3rd, 2007 8:25pm
I sometimes code like that, but it has a high failure rate for me if it's not a new project or isolated module. When I do it on an existing code base, I tend to end up with all these plates spinning up in the air and if one of them doesn't fall into the right place in the end then they can all stack up wrong and I end up with a pile of garbage. I then have to admit that I wasted a lot of time, revert to the previous code base, and start over with incremental changes.
July 3rd, 2007 8:32pm
OK, I'll keep track of it.
This might be a special case though. I have a specification in this case, which is a relatively unusual situation, and there is no user interface.
The spec is for a very elaborate binary file format from an old mainframe system. The file contains a mixture of data and obsolete executable object code. This module is going to translate to and from that format into other more usable formats. Since the spec is very old, it's more complete than most specs.
I am not sure it would work for this size a module if I was coding something completely new, or if I had to figure anything out. As it is, IF I understand the spec correctly and IF I don't make any errors, I can theoretically get it right the first time. I don't know how likely that is though, probably a long shot.
I have in the distant past, when you paid for time share, written modules in assembly language with no bugs by writing them out on graph paper very carefully and checking and rechecking and rewriting before finally entering and testing them, but those were on the order of 100-200 lines of assembly. I think long ago people did it that way and could get bug free stuff the first time through.
It's very easy to make mistakes though. I've found countless typos, each time I read the code I find a new one. Or realize I haven't thought to include a special case.
We'll see what happens. Gotta do something other than the usual I suppose just to mix it up a bit.
July 3rd, 2007 8:56pm
OK, well I finished the module and compiled it. It compiled with zero syntax errors. Hurray for me. So, I ran it and... segmentation fault. OK, well so that was a small bug, easy to fix, and run it again and... segmentation fault due to some other bug.
Hm, seems that this is not even close to bug free. I wonder if it is a waste of time to spend so much time reviewing, maybe better to start doing live tests earlier and just see what fails.
July 4th, 2007 11:54pm
I was really hoping there, that you could do it. I knew the odds were against you, but I still hoped.
Ah, well, please do document the bugs. If you get less than one per 10 lines of code, you're in pretty good shape.
July 5th, 2007 12:06am
Personally, I try to use the Dijkstra approach -- build primitive modules, debug them till I'm SURE they're robust, then assemble them into larger sections of code.
That, or create a really good debug message facility, with 'flush' turned on, so I get my debug message out BEFORE the program crashes.
July 5th, 2007 12:07am
The first one was kind of obscure, one I'd never done before. I was trying to be all const correct. The stored data has chunks that are pointer aligned according to some rules and the whole translator has to be portable.
So I have this:
char *AlignPointer(char *pointer)
change according to various rules
and then, to accept when the pointer is to const data:
const char *AlignPointer(const char *pointer)
return (const char *)AlignPointer((const char *)pointer);
Knowing that I can overload functions that have different argument types, and const x is a different type from x.
But I screwed up there...
July 5th, 2007 1:32am
The rest of the problems so far are due to the spec not accurately describing the actual file format that was used. The code that generated these files no longer exists, so there's just the spec, but it has proven to not match the state of the actual format that was used in a big way, and so I'm now embarking upon some serious analysis and reverse engineering. This spec might be years out of date.
July 5th, 2007 3:20am