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

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?

• Have you considered storing the GUI constants in a file - something like xaml in wpf? I am not sure if that would not produce more problems than it would solve though. Aug 22 '15 at 23:46
• @wondra I tried something similar, it was an xml file where you defined groups of similar constants that were loaded in the static constructor of a class and could be accessed as Constants.GetGroup("name").Constant("other_name") but that only made things more confusing. I'm sure there are simpler ways of doing it, but I shied away from a file-based solution after this. Aug 22 '15 at 23:57
• This question might be a good candidate for code review codereview.stackexchange.com Aug 23 '15 at 0:20

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.