- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I delebate two times per day
Admin
I guess something reversing polarity (debits to credits or whatever it's doing) will always look a bit WTFy, especially if there's been an "interesting" choice of variable type, surely the real weirdness here is having 11 identical classes doing the same thing with different names .... I don't get why he needed to do that? or why he thought he needed to, maybe?
"but only one the person doing it to themselves enjoys it." ... uh?
Admin
As long as you don't delegate your delebating to your junior dev ....
Admin
shudder This one hits really close to home. Our codebase is such a gross violation of DRY that the lead dev actually wrote a PHP script to generate boilerplate C++ classes, when he then tweaks a bit to fit whatever need he has. There are over 4 dozen of these classes, which basically serve as database views.
Oh, and the whole "store everything in a generic buffer" anti-pattern? We have that too, although it's a char buffer; everything going into it is stringified (except when it's not), and the caller is responsible for knowing the proper type and converting it back before use. But then we one-up that and combine these weakly-typed buffers into a weakly-typed map. And of course it's all implemented from scratch - none of that new-fangled STL stuff for us, thanks.
So all this leads to the weirdest application framework I've ever seen: for DB access we have a plethora of almost-but-not-quite-identical classes, while most everything else is lumped into generic collections of key-value pairs.
Admin
"Such a Violation of DRY".... The key is "yourself", having the computer repeat something is not part of principle. Consider a common optimization of loop unrolling: The computer repeats the body. Or function inlining... Or...
Now, I am not justifying the other aspects of the code, merely that resulting duplicate code (which a number of compilers now automatically fold back into one) as a result of auto-generation is not necessarily a "bad thing".
Admin
Pfft. I've seen worse. Surprised the sign-flipper wasn't implemented as a SOAP service.
Admin
"It’s like delegation, but only the person doing it to themselves enjoys it."
A delegation celebration like this would rather be called "delebration". Delebration time... come on! ;-)
Admin
This incomplete code raises a lot of questions. What's going on with that base and why is the classname in there (which is converted to bytes presumably, which surely has length unless they keep char length in there or put the 1 in there)? The map is the wrong way around for the check it should want to perform.
Admin
Yeah, I don't have a big problem with code that's generated at compile-time, as long as the template is understandable and easy to use/maintain. (After all, what is a high-level language but a template for a compiler to generate machine code?) What I'm talking about is a script that generates files that are then hand-edited and added to the project. Which means that if we someday want to change something that's fundamental to the class template (such as, say, changing the interface on some of our utility classes because those have severe deficiencies as well), every one of those 8-dozen files (cpp and header) would potentially have to be hand-edited again. So considering the purpose of DRY, which is ease of maintenance, I still say it's a horrible system.
Admin
"I'm talking about is a script that generates files that are then hand-edited and added to the project" --- That is indeed horrible. In an ideal (rarely perfectly achieved) situation, humans would never even be overly aware of their existence.
Admin
"humans would never even be overly aware of their existence."
That's what I see as a problem at all. If you generated code that's to be used, to use it you need some awareness. The problem I see is that the files are hand edited then added to the project. Your generated sources should never be changed by hand and you should have a build process. They should instead be extended. The exception to that being a quick one shot process (genuine boilerplate usually without much functionality going in there).
Admin
And in a practical situation, at the top of the generated files there's a massive warning saying "THIS IS GENERATED CODE, DO NOT TOUCH". Any non-boilerplate code required for a class should be put in a manually written class that inherits from the generated code. That will still occasionally require changing the manual code if the generation is fundamentally changed, but most of the time will require no maintenance.
Admin
Yeah, like if you use QtDesigner (or whatever gui framework is hip next week), it will autogenerate you a class, which you then either inherit or use as member in your manually written class.
Admin
Don't touch your own code that way! Delebation is a terrible sin, and causes hairy palms and blindness, donchanau.
Admin
My own immediate thought was something like this - actually, in reading the description, mu immediate expectation was that it was basically an ad-hoc implementation of aspects (which it wasn't, quite, though it sort of has an aspect-ish quality in some of it).
However, TRWTF here is that the entire process was unnecessary - it was dictated by the choice of base type, or at least, the decision to manipulate the integer value in situ after it is in the byte array buffer, rather than as an integer.
I am assuming here that there was some specific need for it to be a byte array (possibly for some interop raisins, I suppose), but the code doesn't make it clear. However, even of that is the case, it would make more sense to either postpone putting into the byte array until after it is modified, or else have methods to cast from the byte array to an integer and back - something they would probably need anyway.
Admin
Could've just put the method in, you know, the base class.
Admin
doubting_poster, I would like to think this is something that people would be aware of from having to generate code during setup, etc. It's a bit like, don't edit code in 3rd party includes folder (you can always make the generated code a 3rd party include as well but then you're adding a version boundary if it's external)... VCS ignores should also give it away.
It's occasionally tricky though. I'd like to put things in a writable folder, the var equivalent, but then you have to be extra careful about security, if you're including code from the writable folder. It can't really be avoided though in all cases.
If in doubt, just stay away from idiots, idiots will be idiots and putting a do not edit header wont accomplish much. You can never foolproof your codebase, you can only strive to keep the fools out.