Three-function calculator

I'll blame the extra-weird broken indentation on copy/paste difficulties, and ignore that.

There are as many ways to write a calculator as there are programmers willing to write one. So I'm not going to suggest other ways, instead I'm going to hint at how you could improve the flexibility of what you've got.

The first concern you have, is getting user input. Your code works when the sky is blue and the user isn't being too clever.

QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.

_{https://twitter.com/JimFraeErskine/status/527564769302433792}

What happens if you play the QA engineer here?

Console.WriteLine ("What is your first number?: ");
num01 = double.Parse (Console.ReadLine());

Your code is making the assumption that the user will enter a valid double! Look into TryParse, and write a separate function with the sole purpose of turning a string into a double. I'd actually make that function return a double? (or Nullable<double>, so that the calculator knows the number isn't valid when that function returns a null).

Console.WriteLine ("\nPlease select one of the following (1-4)");
Console.WriteLine ("1 - Add");
Console.WriteLine ("2 - Subtract");
Console.WriteLine ("3 - Divide");

Console.Write("Select number 1-3: ");

That's ...rather interesting. It looks like at one point it was intended to support 4 - Multiply, but the idea was dropped and now 4 is an invalid input despite the instructions at the top saying (1-4), and the instructions at the bottom saying 1-3!

How about you take the concern of creating the menu out of there, find a way to encapsulate each operation into its own strategy object, and generate the menu based on how many available strategies you have?

Say you had an enum:

public enum CalculatorOperation
{
    Add,
    Subtract,
    Divide,
    Multiply
}

You could then "map" each enum to a function taking two double values and returning another - that's a Func<double,double,double>:

var strategies = new Dictionary<CalculatorOperation,Func<double,double,double>>
{
    { CalculatorOperation.Add,      (x, y) => x + y },
    { CalculatorOperation.Subtract, (x, y) => x - y },
    { CalculatorOperation.Divide,   (x, y) => x / y },
    { CalculatorOperation.Multiply, (x, y) => x * y },
};

What just happened here? You've given yourself the tools to eliminate that switch block - given userChoice is parsed into a CalculatorOperation instead of just an int, you could do this:

var result = strategies[userChoice](num01, num02);

How does that work? Delegates, my friend. And generics. But delegates, my friend. You see, this:

(x, y) => x * y

Is shorthand for:

delegate(double x, double y) { return x * y; }

Which could just as well be this:

private double Multiply(double x, double y)
{
    return x * y;
}

And, if you had one such method for each operator, you could just as well define your dictionary like so:

var strategies = new Dictionary<CalculatorOperation,Func<double,double,double>>
{
    { CalculatorOperation.Add, Add },
    { CalculatorOperation.Subtract, Subtract },
    { CalculatorOperation.Divide, Divide },
    { CalculatorOperation.Multiply, Multiply },
};

Because the signature double Multiply(double x, double y) matches that of a delegate taking two double parameters and returning a double - that's really all delegates are: functions that you can encapsulate, and pass around as parameters, or store inside a dictionary to execute later.

You could then generate the menu items simply by iterating the dictionary keys.

Now, you'll still have to worry about division by zero and overflows (what happens if you add double.MaxValue and double.MaxValue?), and then separate the concerns.

One of the most important principles, IMO, is the Single Responsibility Principle. Your current code has user input/feedback, validation(?) and the actual logic intertwined, which makes it harder to maintain/extend than it needs to be.

Identify what the concerns are, and extract them into their own methods; monolithic blocks of code are the easiest to write, but the hardest to maintain.