Naming Convention in C#

On C# naming conventions for member variables

That is definitely a very popular naming convention and I don't see why you should be against it.

I would simply recommend following the Naming conventions for C# provided by MSDN and also General Naming Conventions provided by MSDN.

Specifically they have this to say about properties:

Do name properties using a noun, noun
phrase, or an adjective.

Noun phrases or adjectives are
appropriate for properties because
properties hold data.

Do not use properties that match the
names of Get methods.

For example do not name a property
EmployeeRecord and also name a method
GetEmployeeRecord. Developers will not
know which member to use to accomplish
their programming task.

Do name Boolean properties with an
affirmative phrase (CanSeek instead of
CantSeek). Optionally, you can also
prefix Boolean properties with Is,
Can, or Has, but only where it adds
value.

Consider giving a property the same
name as its type.

When you have a property that is
strongly typed to an enumeration, the
name of the property can be the same
as the name of the enumeration. For
example, if you have an enumeration
named CacheLevel, a property that
returns one of its values can also be
named CacheLevel.

I think if there were a compelling reason to be against what you are suggesting they would have mentioned it in their guidelines.

Naming Convention for var in C#

I think you misunderstand what var means and confuse between what is the class, the reference and the var (and therefore naming conventions of each).

So what var is? From docs:

variables that are declared at method scope can have an implicit "type" var. An implicitly typed local variable is strongly typed just as if you had declared the type yourself, but the compiler determines the type

From Implicitly Typed Local Variables:

The var keyword instructs the compiler to infer the type of the variable from the expression on the right side of the initialization statement

So in this case var converter = new Converter();:

The compiler determines the var as Converter.
You are creating a reference named converter - which should be named using camelCaseing.
The explicit type of the reference is Converter - which should be named using PascalCasing.

Writing var converter = new Converter(); is identical to writing Converter converter = new Converter();

In C# var is for for cases where you do not know the explicit type such as anonymous types or as a easy way to write:

Dictionary<SomeTpye, List<SomeOtherType<AndSomeGenericParameter>> variable = 
    new Dictionary<SomeTpye, List<SomeOtherType<AndSomeGenericParameter>>();

as this:

var variable = new Dictionary<SomeTpye, List<SomeOtherType<AndSomeGenericParameter>>();

As it is an "alias" for the type but not the type itself it keeps to the conventions of the language keywords (and not types) and is written in lower case.

C# naming conventions for acronyms

There is a convention, and it specifies initial uppercase, the rest lowercase, for all acronyms that are more than 2 characters long. Hence HttpContext and ClientID.

What is naming convention for C# arrays?

You'll notice in C# examples and .NET framework naming, that in general, everything is camelCase:

All variables should have a lowercaseCamelCase name.
All types (class, struct, enum, delegate), methods, and properties should have an UppercaseCamelCase (aka PascalCase) name.

Here is an example:

// Types are CamelCase
class Foo {

    // Properies are PascalCase
    public int SomeProperty { get; set; }

    // *Private* fields are lowerCamelCase
    private int aField;

    // By some conventions (I use these)
    private int m_anotherField;            // "m_" for "member"
    private static object s_staticLock;    // "s_" for "static"

    // *Public* fields are PascalCase
    public int DontUsePublicFields;        // In general, don't use these
    public const int ConstantNumber = 42;

    // Methods are UpperCase
    // Parameters and variables are lowerCase
    public SomeMethod(int myParameter) {
        int[] localVariable;

        //string names[] = {};     // Not valid C#! 
        string[] names = new string[] { "Jack", "Jill" };
    }
}

Naming Conventions in C# - underscores

A good article to read on the development of C# style guidelines is here at C# coding conventions.

The original guidance for .NET was to never use underscores unless they were part of a private member variable, and then only as a prefix, e.g. _customerId. This was probably inherited from MFC where 'm_' was used as a prefix for member variables.

Current practice is not to use underscores at all. Disambiguation between private member variables and parameters with the same name should done using 'this.'. In fact all references to private members should be prefixed with 'this.'.

The only place underscore seems to be used a lot is in unit test methods. I'm not a fan, but it may make the methods more readable, for example Throw_If_Customer_Is_Null(){...}.

c# Naming Convention

The C# naming convention recommends everything that is public as well as classes, interfaces etc., to start with an uppercase letter. The rest should start lower case.

There is no problem with:

private User User { get; set; }

... since the position of each name (word) defines what is what.
The English language works the same way.
e.g.: "I love love." (pronoun, verb, noun)

C# Field Naming Guidelines?

Follow the Microsoft Naming Guidelines. The guidelines for field usage indicate that it should be camelCase and not be prefixed. Note that the general rule is no prefix; the specific rule is not to prefix to distinguish between static and non-static fields.

Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to distinguish between static and nonstatic fields. For example, applying a g_ or s_ prefix is incorrect.

and (from General Naming Conventions)

Do not use underscores, hyphens, or any other nonalphanumeric characters.

EDIT: I will note that the docs are not specific with regard to private fields but indicate that protected fields should be camelCase only. I suppose you could infer from this that any convention for private fields is acceptable. Certainly public static fields differ from protected (they are capitalized). My personal opinion is that protected/private are not sufficiently different in scope to warrant a difference in naming convention, especially as all you seem to want to do is differentiate them from parameters. That is, if you follow the guidelines for protected fields, you'd have to treat them differently in this respect than private fields in order to distinguish them from parameters. ~~I use this when referring to class members within the class to make the distinction clear.~~

EDIT 2

I've adopted the convention used at my current job, which is to prefix private instance variables with an underscore and generally only expose protected instance variables as properties using PascalCase (typically autoproperties). It wasn't my personal preference but it's one that I've become comfortable with and probably will follow until something better comes along.

Naming conventions for private members of .NET types

Technically, underscores are a violation of .NET conventions (or at least used to be -- see comment thread), but Microsoft programmers themselves often use underscores, and many examples in the documentation use underscores. I think it's very helpful to be able to see at a glance which variables are member variables (fields) and which are local. The underscore really helps with this. It also nicely separates private member variables from local variables in intellisense.

Please see this very useful page for .NET naming conventions:

http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices

And here's a page with Microsoft's official recommendations:

https://msdn.microsoft.com/en-us/library/ms229045%28v=vs.110%29.aspx