Advice on good practise.

Dalek, you're a mature developer, may need a serious answer.
I appreciate you're trying to refine technique for the elementary stuff.

Working with nested structures highly depend on the language. I used to avoid nesting with Pascal and allow myself 1-2 levels more with C#, due to several factors. Readability of C# is not one of them (it's actually worse); it's more of the ability to declare local variable anywhere in the body.

Generally, I try to avoid nesting like you describe by abstracting out nested parts to separate methods. Chances are, they will also can be reused. You may say that you cannot abstract out an if block as a function, because if may not be a predicate, but may have a body of different statements under the if block. In this case 1) you can always use a delegate as a parameter of such function; 2) if may give you a chance to re-view the code of the block and generalize/parametrize the actions under the branches. In other word, a mere attempt to reduce nesting might push you into better reuse and abstraction.

But here I wanted to mention a fun part. Do you want to know how you can eliminate switch block of an if block completely?

Tho is very useful if there too many switch cases of if branches. I more fight against switches and think about using this technique if the number of cases goes beyond 4 or so, and the branches are too long.
The technique is based on a dictionary. What was a case selector becomes a key of a dictionary, and a value of a dictionary is a delegate, used to "invoke some action in response to a key". Selection of action and a call to delegate instance ("action invocation") is done in a single call like result = Dispatcher.Invoke(key). Somebody demonstrated this technique, but mine is better. It is completely generic and has a multi-cast variant (a queue of delegates, invocation returns array of results). The funny part is that can server as a model of "another OOP". In fact, it was too parallel mechanisms of OOP in Object Pascal: one based in traditional VMT, another - on DMT ("Dynamic method table"). Internally, DMT should be what I describe. Also, sometime need to abuse OOP a bit -- keys could be types. I know at least one use case when such abuse if perfectly justified.

When you have many cases, it also essentially improves performance.

Maybe, I should publish it. If you're interested, I'll show you. This is C#, but with .NET there no essential language boundaries.