Hacker News Reader

Comment by roskilli | Hacker News Reader

Searching 1897 files for "goto " ... 603 matches across 121 files

cocks gun, blows brains out

(Yes I know the evil goto supposedly has its time and place, blah blah blah)

Use of "structured gotos" for error handling is perfectly reasonable. Internal returns are far, far worse sources of error (mostly resource leaks, in my experience). Having functions with single exit points and avoiding contortions that involve extra control variables is better than the mindless avoidance of 'goto'.

Goto is just fine if it is used responsibly.

If you are going to write functions like this [1], gotos are not your worst problem. :)

[1]: http://sourceforge.net/p/jediacademy/code/ci/4bebb8ec23200ee...

I was also surprised to see these huge functions with multiple nested layers. Is it common for game development? Or it was just a quick hack on top of Quake engine?

Yes, it's very common in player / vehicle controller code.

People start with a clean model of how the player should move, using minimal physics, then add layer upon layer of special case code for various environmental / state / networking edge-cases.

It's usually what makes the game actually feel good to play.

I've heard looking at the first person movement code for Valve's games will make you wish for your own death, but stripping out the weird stuff which looks ideologically wrong just makes the game play worse.

What exactly is wrong about that?

The nesting is too deep imho, but apart from that it looks ok. This looks more like a design problem, because there are lots of special cases, but the code style is ok.

Look at the size of that thing

That function is almost 1500 lines long, full of complex nested if conditions and commented out blocks. I understand how code (especially game character control code) grows to become like that, and I've probably been guilty of some similar horrors myself, but the most I can do with such code style is excuse it.

Sometimes the program logic consists of hundreds of cases and putting it all into one function is a good solution, since you see the complexity.

I know that object-oriented best practice would suggest a lot of different classes and using dynamic dispatch for switching. That might even be faster. However, I dislike the fact that this scatters the logic across hundreds of files.

The best solution would be to simplify the logic, but this is also the most costly/time consuming variant.

I think you agree with the parent poster. By "code style" I assume they meant what you're calling "design problem".

I'm equally repulsed by huge, highly nested functions. However, I'd have to say that the game play provided by this function was one of my favorite parts of Jedi Outcast.

Skimming through the academy source, some are fine, some are not.

For example, codemp/game/g_saga.c uses goto just fine. Three "goto failure" jump to the end of the function to handle the error case differently than a normal return. Not a very good example for proper goto use, but ok.

In contrast, codemp/cgame/cg_players.c should be refactored. It seems to be model loading code. If the loading fails, some gotos jump to the start of the function and using a flag variable a default model "kyle" is used instead of the arguments. If the default model is broken, this becomes an infinite loop. My style suggestion:

  if (loadModel(foo)) return;
  if (loadModel(default)) return;
  assert (false && "fallback/default model broken");

What's the most popular "proper" use of goto in the code? The implementations of finite state machines?

I would guess error handing (freeing memory, closing fd's). A goto lets you avoid deeply nested if statements.

Reply on news.ycombinator.com