Working on code has to be a continual job. Especially if it's an evolving product. You can't just sit back and assume that once it's written, it's "done". It's not. Certainly, there are shared libraries that get to the "done" state - for components. But for a product where features are being added, sources are being added and removed, it's just next to impossible to believe that something written years ago is still going to be relevant and useful years later. It needs to be looked at, checked, and where necessary, updated.
Case in point today was the codebase for an app I've been asked to work on at The Shop. The functional description of the project is pretty simple - get data from some network feeds - like multicast or direct tcp data feed, and distribute it to 29West in a manner such that it can be subscribed to easily, and then the 29West data feeds terminal processes that decode it and serve it up on tcp to the clients.
It's a pretty simple message router with a pub/sub content. Not trivial, as it needs to be fast, but not conceptually that hard. Certainly, I've worked with some guys that would say that it's a simple receiver that rebroadcasts on 29West in a set of channels and the receivers just get it off 29West. I happen to like that there's a terminal app and clients don't hit the 29West feed directly - it allows the replacement of 29West in the event that it comes to be a problem.
In any case, this codebase is C++, but it's written as a lot of C with structs and a few classes, but very little really good design. There are a lot of odd little things based on the source control method - and it's a horrible source control system. There are more little odd things they put into the project for NetBeans. For C++?
OK, I can see people wanting to use an IDE, but why put the IDE artifacts in the SCM? That doesn't make sense. If you want to see something slightly different than I do, then that's OK, just don't force me to look at it that way, too. I don't understand that at all. But that's not the worst of it.
I can see using C in C++ for speed. But it's really a fool's errand. Face it, once the method call is made form the vtable, the execution of any one method's code is really the "speed of C". The issue some may take is that the using of the vtable is more costly than the jump table of C - and in that, they are right. But the time of using the vtable is only on the call invocation, and not in the execution.
Time-critical sections should be within a method, and not calling methods. So in that, you're going to get the performance you want when you need it, and the convenience and design simplicity of C++ when you need it.
But that's still not the worst I've seen in this project which I'll call The Magic School Bus, no... there is even worse.
I was reading the code, trying to get an understanding of what goes where and how it all works, and I ran into biggie.h... it's currently got 277,695 lines of C/C++ code. Yeah... over a quarter million lines in one header file. It's really next to insane. Because it's got the implementation with it, every single inclusion of this file essentially statically links in all this code. It's crazy.
Now I will say that the code isn't horrible, it's a bunch of messages, and it's decent, but it's not using any subclassing, and I'd sure like to do that. It's not using any really good designs, other than it does have a nice suite of operators built into each of the messages. It needs a serious re-write - but there's the rub: if the comments are right, the code is generated by a perl script.
Amazing to me that they didn't make it a pair of files for each message - if they are generating the code from perl, it'd be easy. Make a header file, make an implementation file, and then make a directory where they all co-exist and build them into a shared library. That's what I'd like to do, but I can't make these kinds of changes to the codebase without really understanding the implications. And the implications of this could be severe.
If the clients to the Magic School Bus are expecting to get the complete functionality by just including the header file, and not linking anything, then they need it to be this grotesque blob. But if we can move them to something better, it'll make the maintenance and support so much nicer.
I'm just hoping that we can make this entire message library a lot cleaner and nicer. There's no reason for a 250,000+ line header file in decent designs.
