Modernizing .NETpad: Refactoring the Code (Premium)

My work modernizing the WPF version of .NETpad this year has taken me down multiple paths, often simultaneously. There's the straight-up updating that I've documented so far. And then some work I've mentioned in passing or not at all, much of it related to the quality of the code.

For example, I've restarted my work several times using the now-dated GitHub-based version of the app, sometimes just to make sure I can duplicate the improvements, and sometimes to experiment with different, perhaps more efficient ways to achieve the same end. Recently, I literally started over from scratch with a blank WPF project in Visual Studio to see what it would look like to build the current app in a cleaner, more logical way. That effort is particularly daunting because I really want to get it right, and I've had to revisit some app functionality I stopped thinking about a long time ago. It's like riding a bike, I guess.

This process is called refactoring: The goal is to improve the code while not changing its runtime behavior. "Improving" code can mean all kinds of things, and I went into this process with only a vague idea of what it would mean for .NETpad specifically. Perhaps not surprisingly, this job grew bigger and became more complex as I went.

The basic app structure is set in stone. There's a XAML file (MainWindow.xaml) representing the structure of the main app window, which is now the only app window, though I still use old-school Message Boxes and Input Boxes for various pieces. And then there is an associated C# file (MainWindow.xaml.cs) containing all the event handlers and other code that constitutes the app. Beyond that, there are also secondary files like a resource dictionary (for custom control themes), a per-user app settings file, and various other files associated with the project.

To the user, .NETpad is a simple app with a title bar, a menu bar, a text box, and a status bar. For this new, more modern version of the app, there's also a Settings page that's implemented in the main app window's XAML file and is shown and hidden to the user as needed. And so all the code associated with that Settings page is likewise found in the main app window's C# file. There's a lot of code in both those (XAML and C#) files, and adding the Settings interface to the main window dramatically expanded the lines of code in each. For example, the XAML for the main app window was under 150 lines of code before this modernization effort, but now it's over 400.

There's not much I can do about that: XAML is verbose. But the C# file contained event handlers and other code, and I was curious if it made sense to perhaps separate those into separate files. That is, keep the event handlers in MainWindow.xaml.cs but move all the other methods and code into a new C# file. This isn't difficult to do in C#, generally, or in WPF specifically: Because MainWindow.xaml and MainWindow.xaml.cs are both partial classes representing the same code structure...