I find myself doing something like this alot. Basically setting a condition to false to avoid the if block from running more than once.

If I do not turn it off, the mushroom will keep appearing.

The hacky code is isHit = false;

Given a update method that constantly get executed from the game loop in this pseudo code.
 
[code]
public class Mario{
 
public void collide()
{
        Block.setHit(true)
}
 
}
[/code]
 
[code]
public class Block
{
    public void setHit(boolean hit)
    {
        this.hit = hit;
    }
  
 
   public void update(long milliseconds)
   {
      if(isHit)
      {
                // hacky code
                isHit = false;
                Mushroom mushroom = new Mushroom(50,50);
                Game.getInstance().add(mushroom);
      }
 
    }
}

So my question is: is hacky code allowed in the industry?

Do industry professionals or game developers use hacky code in their game code?

I always found hacky code to fix all the bugs in my game and let me progress faster in my game development process.

There are kludges in any industry, though with varying degrees of frequency. The question isn't whether or not they exist but why they happen. I've only done games as a hobby, so I can't comment much on patterns for that industry, but my experience with them is that a kludge happens when deadlines loom, developers gloom, and project managers give out ultimatums of doom. In general, a kludge is a sign that either your design isn't working, you don't understand how to work with your design, or you're in a very funky context. The last one being rather uncommon.

Given that Mario.collide is calling a method on Block, is there some reason you can't have Block.createMushroom or Block.collide(thingHittingMe)? Does it need to be in update for some reason? An event makes more sense to me than an update loop for a context like this--the collision happens once at one moment and really only needs to fire off, "Hey, I've hit something!" to the interested parties (usually those involved in the collision). It's a lot cheaper than every few milliseconds, "Am I hit? Am I hit? Am I hit? I'm hit! Am I hit? Am I hit?"

Read this: http://gamasutra.com/view/feature/194772/dirty_game_development_tricks.php

Hacky code is frowned on and there are code reviews and code style guidelines to try and prevent it. However hacky code still gets through. In the games industry you are likely to find a lot more hacky code than anywhere else though because most games code is throwaway code.

Depends on where you work entirely, and the general stress level. Good programmers would rather fix stuff like that properly, but management and/or reality may disagree about that priority.

IMHO hacky code is OK if it's used as a stepping stone. Actually, many times I've found that adding a lot of hacky dependencies allows you to use the resulting code smells as a guide to find the architecture.

Agree on this one, if I can't immediately see a clean solution I may start out with a hacky one and then refactor it later once it becomes clear exactly how the related code meshes together. (Or I don't even start implementing it until analyzing it further. Starting to code when you don't know what you're doing is a major time waster.)