Writing code so that it survives a recompile - feasible and practical?

Recently I've been stumbling over the problem, that I get a ton of null reference exceptions when I recompile during runtime. It is because certain variables aren't serialized and my input system has to be completely re-initialized on reload. So I've started doing some special null checks in update loops and lazy initialization via properties and it's working quite well. Here's an example:

Code (CSharp):

1.     InputObject Input
2.     {
3.         get
4.         {
5.             if(m_Input == null)
6.                 m_Input == InitializeInputObject();
7.             return m_Input;
8.         }
9.     }
10.  
11.     InputObject m_Input;
12.  
13.     void Update()
14.     {
15.         if(MyInputSystem.isReady == false)
16.             return; // skip update while InitializeInputObject() is running.
17.  
18.         if(Input.GetButton("My Action"))
19.             ;// use lazy initializing property instead of field.
20.     }

Of course this is quite some additional code the standard procedure...

Do you think, that it's useful to try and follow this pattern and make code survive a recompile in the editor, to make testing easier and quicker? Would you take other approaches? What about adding [SerializeField] to fields, which I know don't need to be re-initialized, but would otherwise be lost. I'm also using platform dependent compilation expressions, to minimize the performance impact for the final build.

I'd be happy to hear your thoughts on the subject!

 

You have to do it for the entire game, including middleware so it's seldom ever worth the bother for me. Unity would have to clamp down on external assets and how they can behave like keeping them to plugin folders so they don't get recompiled for me to be interested as I'm not interested in fixing everyone else's work which gets broken in an update regardless.

Generally I can just make a few editor scripts, if I'm testing things and run it there, I don't actually need the game to be playing for a lot of tweak-test cycles.

 

I really wish Unity would just not try to recompile scripts while the game is running. At least give me the option to disable it! Around here it's probably the most common cause of editor crashes.

 

I wrote up a post on how I fixed the issue. You essentially turn off automatic re-importing of stuff when you go into play mode, and then reactivate it when you leave play mode. If your editor crashes while in play mode, automatic reloads will be turned off until you enter and leave play mode again (or enable it manually in the menu), but that's not a big problem.

Hot code reloading in Unity is really an anti-feature. They must have done a bunch of work to have the code try to keep running on a new codebase, and it both is not neccessary, and consistently crashes the editor if there's too many errors happening at the same time.

 

Thanks for your answers so far! I wouldn't say hot reloading is a problem, if I just don't use it. If I don't want to edit code at runtime, I simply don't save my scripts or turn off play mode before making changes. But if nobody uses this feature commonly, I probably won't try to make it work, as well. ^^ It's just nice in some hard to test circumstances, but on the other hand it's always best to create things, that can be tested separately, so yea...

 

It sounds nice. But in practice it's very easy to get yourself into undefined or poorly defined state. How the game behaves after a recompile in play mode can be substantially different from how it behaves when restarted.

Anything that needs a lot of runtime changing I'll expose to the inspector.