Hello there, I’ve noticed I have a lot of raw numeric values and strings in my project and I’m wondering what the best practice is to keeping projects tidy from raw values and strings. From what I remember when working with Window Forms in Visual Studio it was good practice to use a Resource class to store all raw strings, but I don’t think Unity has anything like this by default. And I don’t know if it’s frowned upon to have raw numeric values in methods like shown below.
If they are something fixed, then you can probably declare them using 'const’ keyword. Otherwise, you might want to make them into properties so you can modify their values in the inspector. If they are something shared, then you can probably make a ScriptableObject and use it as a kind of global settings for such values.
Seems like a situation-dependent question, in my mind.
If you are content with those values, and don’t plan on changing them… I see no harm in it.
If you want them to be adjustable, I’d make them variables.
If they are shared, then I’d think about setting something up to share them…
had this window open for some time before replying, another good answer posted above
So like ‘Resources’/‘Settings’ from .Net winforms, this is usually used for configurable settings that can be modified post build. This can be done with a loadable xml file, json file, or any other serializable file format you want to use.
If they are constant values that may be used in several places, then it’s often nice to create 'const’s for them that can be referred to by name. Usually they’re scoped to where they’re required. For instance if they may be used all over the project you might create a ‘Constants.cs’ static class full of the const values that can be accessed from anywhere. Where as if it pertains to your UI layout you might stick it in one of your prominent UI classes. Or if they’re really localized, just in the scope of where they’re needed.
If the value is unique to the one time place… well there’s no reason to do anything. Just leave them as is.
I changed the color for numeric and string literals to a red color that immediately catches my attention, as I usually avoid all literals in my code. Even when I’m sure it’s never gonna change, I’ll still define it somewhere - at least to give it some descriptive name and documentation. The only exception to this that I can think off are a few cases such as index initializer in for-loops or similar counters.
Might happen that you come back later and think “why’s that 20 again, why the hell did I use -30… and what is it at all?”.
This is exactly what I’m worrying will happen as I’m prone to taking long breaks and often starting over when I return. Thank you everyone for your advice.
To expand on this, often you don’t know if you’ll change them; or how you’ll change them; or even if you’ll rip out the entire thing later. For example, when I’m messing with anchored positions, I usually realize the real solution is to move constants out of the code by wrapping the prefab in a tweakable empty container.
I’ve found that in almost every case where I made unnamed constants nicer without a definite reason, it was a waste of my time. Even when I did need to tweak it later, the way I set it up was completely unhelpful for what I realized through experience was the real way I needed. I’ve found it’s best to only clean things up when that you can do in your sleep (for example, I can type out: const float TOP_KLUDGE=-30; while thinking about how I want to set up the next button.)
If I would have to side-track myself at all, merely adding the comment “// values are arbitrary” was usually the right call.
