Return to Answer

Hard-coding strings is fine for prototyping, but makes it quite painful to localize afterward: it's better to have the strings in a resource file from the start, so if/when you localize all that's left to do is, well, localize the strings. Then you can use a value converter or a markup extension to support the easy-to-use .resx resource format. The problem with localization is that it's often an afterthought, something that's "I don't need this"... until you do. And if you haven't set yourself up for it from the start, you're in for a lot of pain. The solution is simple: don't hard-code string captions into your markup - put your strings in a resource file... where they belong anyway.

Hard-coding strings is fine for prototyping, but makes it quite painful to localize afterward: it's better to have the strings in a resource file from the start, so if/when you localize all that's left to do is, well, localize the strings. Then you can use a value converter or a markup extension to support the easy-to-use .resx resource format. The problem with localization is that it's often an afterthought, something that's "I don't need this"... until you do. And if you haven't set yourself up for it from the start, you're in for a lot of pain. The solution is simple: don't hard-code string captions into your markup - put your strings in a resource file... where they belong anyway.

But the double-underscores and misplaced this qualifiers aren't the worst offender. Hungarian Notation is. I didn't think there still existed programmers writing C# code in 2016 using Hungarian Notation. Seriously - drop that. There is no need to use type-hinting prefixes for any identifier in any .net code (see why).

But the double-underscores and misplaced this qualifiers aren't the worst offender. Hungarian Notation is. I didn't think there still existed programmers writing C# code in 2016 using Hungarian Notation. Seriously - drop that. There is no need to use type-hinting prefixes for any identifier in any .net code (see why).

As for your concern with calling ParseName 4 times, I'm not sure I understand why - it looks like a case of a want-to-be-helpful framework is actually making a simple task rather complicated. Again I don't know and have never used reactive, and it's probably super-useful otherwise, but it to me it looks like your ViewModel is simply missing the forest for the trees:

public Name Model { { get { return _name; } set { RaiseAndSetIfChanged(ref _name, value); } }

Your markup could bind its LastName box to Model.LastName, and so on. But I might be missing something.

As for your concern with calling ParseName 4 times, it looks like your updated code is what doing that with system.reactive might look like - although again, I've never used that namespace before.

public MainViewModel()
{
    this.WhenAnyValue(x => x.Full).Where(x => x != null).Select(x => ParseName(x))
        .ToProperty(this, x => x.NameObject, out __oapName);
}

Seems legit. It might read a little easier like this though:

public MainViewModel()
{
    WhenAnyValue(name => name.Full).Where(name => name != null)
                                   .Select(name => ParseName(name))
                                   .ToProperty(this, vm => vm.Name, out _name);
}

(ignore the name parsing bit!)

Why? It's a really interesting bit of code!

You're populating these arrays every time you call the function, but you shouldn't have to:

// Might want to add more to this list
string[] prefixes = { "mr", "mrs", "ms", "dr", "miss", "sir", "madam", "mayor", "president" };

// Might want to add more to this list, or use code/regex for roman-numeral detection
string[] suffixes = { "jr", "sr", "i", "ii", "iii", "iv", "v", "vi", "vii", "viii", "ix", "x", "xi", "xii", "xiii", "xiv", "xv" };

Make them private static IReadOnlyList<string> fields, that will create them only once for the type instead of per call.

Then, I'd try to extract a private method for each member I'm trying to parse out of that string, to up the abstraction level a bit.