Pages

Summarize Your Life.

2017/02/27

Another Hot Mess

Alright, just on the heels of the recently-released previous post -- a couple hours ago, give or take -- and watching more game development videos has sparked another chance to ramble on about a couple personal pet-peeves I notice other developers using.
I see this first one from time to time in code; using an if/else to return a value from a method, specifically for a boolean return value.
if(someCondition() || i > 0) {
  return true;
} else {
  return false;
}
which in any recent Java version this side of the Kessel spice run, could be simplified like this:
return (someCondition() || i > 0);
and the boolean state will be calculated and returned the same as the beginning code. It's simply that the second version does look neater, and is somewhat easier to type. Why not be nice to your fingers?
And then, for the second bugaboo. In cases where an if condition is used maybe correctly but somewhat "appears to be" not as orderly as could be. In for and while loops, if the if statement is to specify that execution should continue to the next iteration, then why not invert the if statement and just enclose the remaining lines within the loop inside of the rewritten if?
for(Room room : rooms) {
  if(room.name == "kitchen") {
    continue;
  }
  // Additional code performed if not the kitchen.
  // Can be as complex as you want it.
}
could instead be simplified to not say "continue" but instead check to see that it is not the kitchen, then perform the tasks that would be skipped if it were the kitchen.
for(Room room : rooms) {
  if(room.name != "kitchen") {
    // Additional code performed if not the kitchen.
    // Can be as complex as you want it.
  }

}
It isn't often that I see this, but, there is one more special instance that does bug me, and it's the case of constraining or clamping a value to a minimum or maximum value. I know this happens often enough (in some game entities, the X and Y positions maybe modified and constrained at least once per game tick), and the code might actually look a little cleaner if it could be rewritten a bit.
Well, every game project is likely to have at least one utility class with static methods, and the following clamping methods are sure to be one that you want to add somewhere. I also borrow from my first example in this post in some of it:
public static final int clampMax(int value, int max) {
  return (value > max) ? max : value;
}
public static final int clampMin(int value, int min) {
  return (value < min) ? min : value;
}

public static final int clampMaxMin(int value, int max, int min) {
  return (value > max) ? max : (value < min) ? min : value;
}
That third one looks like it would be useful for a lot of game entities and other objects; let's examine the case of constraining an entity's X and Y coordinates on a map. If these methods were included in a class named UtilityStatics, then usage of the last method might look something like this:
posX = UtilityStatics.clampMaxMin(posX, world.maxWidth, 0);
posY = UtilityStatics.clampMaxMin(posY, world.maxHeight, 0);
Depending upon how the lines were spaced out or wrapped before this, this could give you a savings of maybe six lines of code in each entity, just by simplifying the update tick constraining to a templated static method.

No comments: