# Is hacky code allowed in industry?

This topic is 2072 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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);
}

}
}


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.

Edited by warnexus

##### Share on other sites

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?"

##### Share on other sites
I interned at Microsoft and before I could commit my code to the master code repository other people had to review it and they would point out anything I did poorly. They would sometimes suggest alternatives but other times I had to fix it up myself. I realized that many times I would to a hacky solution more because I didn't want to take the time to find a better solution but in the long run you save time by making good design decisions for more elegant solutions. Hacky solutions usually are parts of more bugs later on. If it is allowed will depend on where you work but as I a rule of thumb I think it is good to avoid the hacky solutions, with the possible exception of if you are working on a prototype that you will throw away later.

##### Share on other sites

It depends how close you are to a deadline

If the game has two months of work left before it's finished, but the publisher wants to see a working/finished version of the game in two-weeks, then all sorts of horrible looking "duct tape" code starts appearing, which may work for now, but is barely managing to hold itself together!

##### Share on other sites

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.

##### Share on other sites

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.)

Edited by Petter Hansson

• 9
• 17
• 10
• 11
• 18