How to avoid lots of ugly math code and constants-hoarding?

Question

In a lot of the games I've (tried) making in the past, I often run into the problem of the code getting really heavy on ugly mathematical code. This happens especially frequently in setting up user-interfaces such as choosing the positions of things on screen. Just to get an idea of what I mean, here is some code from the setup for the level selection screen in a recent project:

It gets really verbose, as you can probably tell. I try to mitigate it with descriptive variable names and detailed explanations of the purposes of constants such as INITIAL_LEVEL_SELECT_Y_OFFSET, but then it becomes verbose just in a different way.

I considered making everything, rowNum, totalWidth, totalHeight, etc., constants, but to me it looked really weird to have 30+ constants attached to every class. I also tried using local variables with smaller names, such as xOffset and yOffset, but then it defeats the purpose of having descriptive variable names (as you can see I use INITIAL_LEVEL_SELECT_Y_OFFSET anyways 5 lines after declaring yOffset).

Another problem this causes is that some constants are used by multiple classes, but aren't really general enough to be included in some static "Constants" class. For example, the constructor for LevelSelectButton uses INITIAL_LEVEL_SELECT_X_OFFSET, and the class in the picture above does the reverse and uses a constant defined in LevelSelectButton.

I originally placed the constants according to "what they were most attached to" if that makes any sense. For example, BUTTON_WIDTH makes most sense in the LevelSelectButton class since it describes a level select button's width.

Another problem is that some of these constants refer to the width and height of images that haven't been loaded statically. For example, LevelSelectButton.BUTTON_WIDTH is supposed to be the same as the width of the button sprite that class uses, but my current setup requires that the sprite for LevelSelectButton be loaded in the constructor for that class (I can think of ways to remedy this based on my current system however).

Any tips on how to avoid these problems? More comments? More constants? Less constants? A static Constants class?

Answer 1

I'd move all those UI constants to a centralized file. It doesn't matter if they are only used in one class or not. The reason is that if you ever want to adjust that type of stuff, it is nice to have it all in one location. You don't want to have to muck with a dozen different classes just because you decided you wanted to change the overall look and feel of your UI.

Make a LookAndFeel static class (or some similarly descriptive name) to contain all those types of UI properties and constants. You might also want to have nested classes within your LookAndFeel class to namespace and categorize all your constants and properties, rather than having very verbose constant names.

Namespacing is particularly nice if you have code completion or intellisense like in Visual Studio. Then you don't have to remember all those long names and if you have documented your code, you can get descriptions for that stuff as you write.

Also, don't be afraid to use functions to self-document and contain your code bits. It doesn't matter if it's only used once. It won't really hurt performance at all and will make your code more organized.