The best code separates concerns. For example the Player class shouldn't update the UI directly, instead it should fire an event which in turn the UI script should listen to it and do whatever it needs to do. Separating the UI from the underlying logic is one of the best (and also slightly easiest) things you can do to keep your code quality high. Ideally your game should be able to compile and work just fine without any UI at all, because none of the logic scripts should depend on the visual interface. Another example, if you have score in your game, it shouldn't be the Enemy class' responsibility to increase the score when an enemy dies, instead it should fire off an OnAnyEnemyDiedEvent which some kind of ScoreManager should listen to in order to update the total. Decoupling is one of the best things you can do to keep your code quality high. It keeps things smaller so you don't have to maintain a huge amount of data in your brain's working memory as you're building something.

@UnityCodeMonkey Hey @UnityCodeMonkey I'm learning unity and I often wonder which event setup is ideal. I'm sure you've heard of the infamous Ryan hipple project from 2017. I love doing the scriptable object event system for stuff...but is a regular event more ideal. I'd love your thoughts!

@UnityCodeMonkey Maybe it’s just me nitpicking a bit. But honestly? Most indie games should focus on put their game live. Ship. Early abstraction, early caring for “xyz principles” and other elements can and often do, hinder progress and builds up in the solo first time developer frustration.

@UnityCodeMonkey The UI's job is to display state. It shouldn't duplicate it via retained copy, and yes you do want it to not compile if it can no longer directly access the data it needs directly (yes, public). Bugs caught at compile time are the easy good ones. You have a compiler, use it!

@UnityCodeMonkey Bro it's so difficult to just say "apply SOLID principles and integrate Observer Pattern" ?