Author Topic: Horrifying lines of code  (Read 13258 times)

0 Members and 1 Guest are viewing this topic.

Offline blackhole

  • Still not over the rainbow
  • 29
  • Destiny can suck it
    • Black Sphere Studios
Horrifying lines of code
Because every now and then, we write them. Sure, they'll get chopped up into safer versions, but they're still fun to look at.

Code: [Select]
_events[i].first.second->getEvent(_events[i].first.first)->setFireID(RetrieveFromPointer<UNRELATEDDEF>(_events,refs[counter++])->first);
« Last Edit: July 06, 2008, 04:19:28 am by blackhole »

 

Offline Topgun

  • 210
Re: Horrifying lines of code
huh? why do you have objects and namespaces named like that? that is bound to be confusing.

 

Offline blackhole

  • Still not over the rainbow
  • 29
  • Destiny can suck it
    • Black Sphere Studios
Re: Horrifying lines of code
...there are no namespaces in that line of code  :wtf:

If your referring to .first and .second, those are pairs and therefore I have no control over the naming.

 

Offline Topgun

  • 210
Re: Horrifying lines of code
never mind.
miss read the code. thought you where using First::getEvent.first.first

 
Re: Horrifying lines of code
Thought I'd share one of the more difficult to debug ones I've seen (simplified for expository purposes, and to hide the guilty parties):
Code: [Select]
struct FunctionThreadData { };
RESULT function( )
{
   FunctionThreadData thread_data;
   ...
   afxBeginThread( thread_function, &thread_data );
   return SUCCESS;
}

If you're not sure what's going on above, it's passing a pointer to a stack allocated variable to a thread function and then returning.
If you're lucky, your threaded function gets half a chance to access data in the passed variable before it goes out of scope.

Took quite a while to track this one down.
STRONGTEA. Why can't the x86 be sane?

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: Horrifying lines of code
Code: [Select]
if( ((wip->arm_time) && ((Missiontime - wp->creation_time) < wip->arm_time))
|| ((wip->arm_dist) && (pobj != NULL && pobj->type != OBJ_NONE && (vm_vec_dist(&wobj->pos, &pobj->pos) < wip->arm_dist)))
|| ((wip->arm_radius) && (wp->homing_object == NULL
|| (wp->homing_subsys == NULL && vm_vec_dist(&wobj->pos, &wp->homing_object->pos) > wip->arm_radius)
|| (wp->homing_subsys != NULL && get_subsystem_pos(&spos, wp->homing_object, wp->homing_subsys) && vm_vec_dist(&wobj->pos, &spos) > wip->arm_radius))))
{
return false;
}

Just imagine that without newlines or indentation.

Here's another fun piece of code.
1) You start with two functions, add_collision_pairs and remove_collision_pairs.
2) You need to add collision pairs when a ship becomes collideable and was not collideable before, and remove collision pairs when a ship becomes non-collideable but was collideable before
3) A ship is collideable when it is not in limbo and has the collision flag set.
4) obj->flags contains the old bitflags, new_flags contains the new bitflags
-C

 
Re: Horrifying lines of code
After horsing around in the ATL and MFC headers trying to track down a compile error, I'd like to nominate the ATL/MFC macros.  :eek:
STRONGTEA. Why can't the x86 be sane?

 
Re: Horrifying lines of code
Not sure what I am going to do with this one..  (note the sole "delete"...)
Code: [Select]
void MapGraphics::ExecuteDelayedBlit()
{
for (std::list<DelayedBlitInformation>::iterator i = delayedBlitInfo_.begin(); i != delayedBlitInfo_.end(); ++i)
{
//SDL_SetAlpha((*i).sourceImage, SDL_SRCALPHA, 0);
if (*((*i).targetSurface) == mapBackground_) {
SDL_SetAlpha((*i).sourceImage, SDL_SRCALPHA, 0);
SDL_BlitSurface((*i).sourceImage, (*i).blitRect, *((*i).targetSurface), &(*i).destination);
}
else {
GfxEngine::BlitWithAlpha((*i).sourceImage, (*i).blitRect, *((*i).targetSurface), &(*i).destination);
}
UpdateRect((*i).destination);
delete (*i).blitRect; //delete the in MoveAndReplace with "new" created SDL_Rect
SDL_SetAlpha((*i).sourceImage, 0, 0);
}

delayedBlitInfo_.clear();
}
I also love the way to write the type of iterators..

 

Offline Flipside

  • əp!sd!l£
  • 212
Re: Horrifying lines of code
Ever read the Source Code for some of the Java functions? Some of them won't even compile in later versions of Java...

 

Offline phreak

  • Gun Phreak
  • 211
  • -1
Re: Horrifying lines of code
Code: [Select]
Int3();
Offically approved by Ebola Virus Man :wtf:
phreakscp - gtalk

 

Offline Mika

  • 28
Re: Horrifying lines of code
I vote for the Fortran one.

Sometimes I feel lucky I was never taught any kind of structural programming. Otherwise, I could, like, get involved with this kind of stuff. Life is simple as long as the only thing to do is computationally efficient algorithms.

As far as I remember, they said never to use multiple threads unless it is absolutely necessary. I, for one, have, of course, no idea what they were talking about but it sounded good enough to warrant writing it down here.

Mika
Relaxed movement is always more effective than forced movement.

 
Re: Horrifying lines of code
I'd like to nominate __if_exists and __if_not_exists C++ extensions... you can see them in the ATL headers.
STRONGTEA. Why can't the x86 be sane?

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
Re: Horrifying lines of code
I'd lke to nominate Microsoft for making this legal in MSVC6

Code: [Select]
for (int i=0; whatever) {
}

x = i;

Every other compiler on the planet will beat you around the head and yell "SCOPE!" at you if you tried that nonsense.
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: Horrifying lines of code
That's pretty blatantly unfair to Microsoft. C++ as a standard wasn't even ratified until the year that C++ 6.0 was released, meaning that there were at least 5 versions of the program released while C++ was in development. If this were something GNU/Linux related, I doubt you'd be just as quick to slap them around for not conforming to a standard during development that didn't even exist. I'm not saying that you, personally, are a Linux-lover, just that it's a lot more trendy to be quick to blame Microsoft for all the problems in their software.

Once somebody made the decision that "for loops are shorthand for while loops, so the declared variables should be accessible outside the loop" or something else happened, and it was released, and thousands and then millions of people started using Visual C++, Microsoft faces a conundrum. They can fix the language and piss off everybody who doesn't feel like they need to spend the time, and therefore money, to fix their code. Those people will hold it against Microsoft, possibly not buy the new version of their software, and go on holding Microsoft accountable for bugs in the old version of their software. Meaning Microsoft either has to support multiple versions of software, or they have to stick with the old behavior. Since sticking with the old behavior is less risky, it makes more sense while Microsoft is still competing with other companies. Nowadays, Microsoft doesn't really have to care and part of their business strategy is demonstrating that they're willing to go the extra mile to get "standards compliance".

As an example, look at all the crap I got for seriously revising the syntax for the scripting system once. I had experienced developers acting like I was incompetent just because I changed it, regardless of whether it actually made things better or not, when my changes affected all of a dozen people directly and maybe some hundred thousand people. Microsoft makes changes to the compiler, it affects millions of people directly, and billions of people indirectly. What kind of ****storm could they expect to hit the fan if there wasn't so much pressure to conform to standards as there is nowadays?

All that being said, MSVC2008 does give you
Code: [Select]
main.cpp(35) : error C2065: 'i' : undeclared identifier
So when I read your comment it comes across as a symptom of the problem that would cause Microsoft to say that they should keep things the way they are, because presumably if they left COFF support in and didn't change anything, you'd be upgrading to 2008 and using that instead. Granted, I don't see any good reason for them to take COFF out except to force people to use their proprietary debug files, but I doubt that's something that couldn't be fixed given time, effort, and some well-place #defines.
-C

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
Re: Horrifying lines of code
That's pretty blatantly unfair to Microsoft. C++ as a standard wasn't even ratified until the year that C++ 6.0 was released, meaning that there were at least 5 versions of the program released while C++ was in development. If this were something GNU/Linux related, I doubt you'd be just as quick to slap them around for not conforming to a standard during development that didn't even exist. I'm not saying that you, personally, are a Linux-lover, just that it's a lot more trendy to be quick to blame Microsoft for all the problems in their software.

If I encountered anything as stupid on Linux I'd be just as quick to blame them. :p

I don't encounter stupidity on Linux cause I don't use it. You can bet I'd complain more if I ever took leave of my senses long enough to install it. :p
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 
Re: Horrifying lines of code
wrt the for loop, there's been a compiler switch since VS2005 that will change VCs behaviour on this one /Zc:forScope
It's on by default.
STRONGTEA. Why can't the x86 be sane?

 

Offline blackhole

  • Still not over the rainbow
  • 29
  • Destiny can suck it
    • Black Sphere Studios
Re: Horrifying lines of code
That's pretty blatantly unfair to Microsoft. C++ as a standard wasn't even ratified until the year that C++ 6.0 was released, meaning that there were at least 5 versions of the program released while C++ was in development. If this were something GNU/Linux related, I doubt you'd be just as quick to slap them around for not conforming to a standard during development that didn't even exist. I'm not saying that you, personally, are a Linux-lover, just that it's a lot more trendy to be quick to blame Microsoft for all the problems in their software.

Once somebody made the decision that "for loops are shorthand for while loops, so the declared variables should be accessible outside the loop" or something else happened, and it was released, and thousands and then millions of people started using Visual C++, Microsoft faces a conundrum. They can fix the language and piss off everybody who doesn't feel like they need to spend the time, and therefore money, to fix their code. Those people will hold it against Microsoft, possibly not buy the new version of their software, and go on holding Microsoft accountable for bugs in the old version of their software. Meaning Microsoft either has to support multiple versions of software, or they have to stick with the old behavior. Since sticking with the old behavior is less risky, it makes more sense while Microsoft is still competing with other companies. Nowadays, Microsoft doesn't really have to care and part of their business strategy is demonstrating that they're willing to go the extra mile to get "standards compliance".

As an example, look at all the crap I got for seriously revising the syntax for the scripting system once. I had experienced developers acting like I was incompetent just because I changed it, regardless of whether it actually made things better or not, when my changes affected all of a dozen people directly and maybe some hundred thousand people. Microsoft makes changes to the compiler, it affects millions of people directly, and billions of people indirectly. What kind of ****storm could they expect to hit the fan if there wasn't so much pressure to conform to standards as there is nowadays?

All that being said, MSVC2008 does give you
Code: [Select]
main.cpp(35) : error C2065: 'i' : undeclared identifier
So when I read your comment it comes across as a symptom of the problem that would cause Microsoft to say that they should keep things the way they are, because presumably if they left COFF support in and didn't change anything, you'd be upgrading to 2008 and using that instead. Granted, I don't see any good reason for them to take COFF out except to force people to use their proprietary debug files, but I doubt that's something that couldn't be fixed given time, effort, and some well-place #defines.

I nominate this as an absurdly over-the-top totally-unnecessary response from a clearly disgruntled programmer.

 :p

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: Horrifying lines of code
I've never been happy about watching other people squander my hard work and, more importantly, my time.

I'm just glad it's all in the past now. :)
-C

 

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Re: Horrifying lines of code
Does that mean you're working on FSOpen again? Or that you are forever done?

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: Horrifying lines of code
It means I'm around to provide support, but I don't plan on coding on FS2Open for the foreseeable future.
-C