Best Practices - brandoncimino/fortune-fountain-g GitHub Wiki

Nickname Practice Explanation

Unity

Editor vs. Runtime

Consider Runtime to be the default in all scenarios.
Only consider something Editor if it specifically should be executed outside of Play Mode.

Unity’s official documentation likes to constantly define everything - code, assets, tests, etc. - as either Editor or Runtime:
- Package layout
- Assembly definition and packages
"Runtime scripts" are often described as "scripts extending MonoBehaviour " (e.g. http://answers.unity.com/answers/689112/view.html)
This is also supported by Unity emitting a warning for any script that doesn’t contain a MonoBehavior, stating No MonoBehaviour scripts in the file, or their names do not match the file name.
In practice, there is an extremely important third category - " Utilities " or " Libraries ".
- These are uninstantiable classes that group together static utility methods.
- In Unity, these methods don’t know or care where they will be called (be that by an Editor script or a Runtime script), and do not extend MonoBehavior (though they may import UnityEngine or UnityEditor!)
The Editor folder is special (see Special Folders)

Note	Though often referred to as "the `Editor` folder", "special" treatment is actually given to any folder named `Editor` located within `Assets/`, regardless of location in the hierarchy.

Note	The "special" treatment of folders named `Editor` is overridden by the use of `.asmdef` files, though the `.asmdef` system mimics the behavior of that special treatment (see Assembly Definition Files)

Warning	Unity can execute tests in either the `Editor` or `Play Mode`. It feels wrong to execute tests that don’t require `Play Mode` - such as the `SaveData.cs` unit tests - in `Play Mode`, but unless it is particularly slow, we should continue that way for now.

Capitalization

X.Tests.Runtime vs. X.Runtime.Tests

For one "feature" X, there are 2 "axes" of code organization:
- Runtime vs. Editor
- Production vs. Test
This results in 4 combinations, each of which need their own directory & namespace
As a general rule, namespaces should match their folder path (i.e. if the path is Yolo/Swag, the namespace should be Yolo.Swag, not Swag or Butts.Yolo.Swag)
HOWEVER, in Package Layout, Unity contradicts this rule, having the folders prefer to separate by Production vs. Test first, but the .asmdef files separate by Editor vs. Runtime first.
Extrapolating the rule from Names of Namespaces, when Unity’s conventions deviate from standard .NET conventions, we are prioritizing Unity’s conventions.

const vs. static readonly

Prefer static readonly > const

If you understand static and you understand readonly, you understand static readonly.
A const can’t include string interpolation (i.e. $"{email}@{domain}.{tld}"), only concatenation.
A const can’t convert data types, even implicitly - i.e. a const string must be built out of additional const string variables, and not, say, numbers.
Passing const values between assemblies can cause problems. This may or may not affect Unity .asmdef assemblies, but better safe than sorry.
There are subtle differences in performance between the two that might matter for game development, but are most likely negligible.
static readonly is a commonly used pattern - see string.Empty