What are the conventions for variable naming in .NET to avoid confusion between parameters and properties?

In the example below, what would you name the parameter given that it is used to initialize the property FromDate?

For class constructor methods, I like to have the name of the constructor parameter variable match the name of the property which is being initialized. For example, the parameter "fromDate" is used to initialize the module level variable "_FromDate" with the statement _FromDate = fromDate. Likewise, I could have alternatively written Me.FromDate = fromDate.

Proponents of C#'s case sensitivity would probably say that using a leading lower cased letter for the param variable name, which I believe is MS convention, is an acceptable approach to distinguish it from the Property of the same name but different casing.

However, VB is not case sensitive, which I generally appreciate. In the following example, I am using a param name that matches the property name, 'fromDate," and VB refers to the local instance when there is ambiguity. However, many would probably argue that this "ambiguity" introduces the opportunity for the developer to get confused and not realize which variable is being used. For example, my intent below was to have TWO params passed in, "fromDate" and "toDate" but I accidentily ommited one and as a result, the VB.NET did not warn me of the mistake because it assumed that the statement _ToDate = ToDate was equivalent to _ToDate = Me.ToDate instead of informing me that the variable on the right side of the assignment statement was undeclared.

Public Class Period

    Property FromDate As Date
    Property ToDate As Date

    Public Sub New(ByVal fromDate As Date)

        If fromDate > ToDate Then
            Throw New ArgumentException("fromDate must be less than or equal to toDate")
        End If

        _FromDate = fromDate
        _ToDate = ToDate

    End Sub


End Class

So what is the best solution for VB.NET?

In my judgement, we should have a convention for prefixing all parameter variable with a prefix, but hasn't the use of开发者_如何学运维 prefixes been discouraged by Microsoft? For example:

Public Sub New(ByVal paramFromDate As Date, paramToDate As Date)

..or maybe it could be shortened to pFromDate, pToDate...

Whatever approach is taken, I feel that it should be a consistant approach that is used throughout the application.

What do you do?

Use the clearest code possible, which I would suggest is not a prefix. I think using the same name (first letter lowercased) is the clearest code. To avoid the problem encountered I'd rely on a tool, like compiler warnings, FxCop, or ReSharper to alert me that I'm assigning something to itself, since that is almost certainly a mistake in all scenarios.

I know this is against all Microsoft convention, but we use v_ for ByVal parameters, r_ for ByRef parameters and m_ for Module level variables. This allows you to have

m_FromDate = v_FromDate

And you can see straight away what is going on without needing to check the definitions of the variables. I think the biggest argument for non-Hungarian was that modern IDE's allow you to see type on hover over, and changing the type will leave incorrect variables. This scope prefix doesn't clash with that theory and also with CodeRush and ReSharper you can update every instance of a variable if it is required.

Personally, I prefer the _ prefix convention, but there are others I like too. In PL/SQL, my parameters are prefixed with in_, out_, or io_ for in, out, or in/out parameters.

I dislike using only upper and lower cases to distinguish in any language.