There are a lot of people who say that you must follow a traditional pattern or a notation like Hungarian notation, but I feel it is rather better to establish a naming convention within your project and stick to it, of course, it should be documented somewhere as well. This way any new developers to the team will be able to read the code quickly as there is an imposed standard. In my current project we use the following naming conventions:

namespace MyNameSpace
{
    public class MyClass
    {
        // Constructor
        public MyClass()
        {}

        // Private members
        private int _myPrivateMember = 1;
        // Public & Protected Members
        public int myPublicMember = 1;
        protected int myProtectedMember = 1;

        // Methods
        public int MyMethod(int a, int b)
        {
            return a + b;
        }

        // Properties
        public int MyProperty
        {
            get { return _myPrivateMember; }
            set { _myPrivateMember = value; }
        }
    }
}

Internal variables within methods names are not really governed by our naming convention but the generally accepted idea is that someone who doesn’t know what it is used for, should be able to see what it is used for by the name.

While it is perfectly acceptable to use Hungarian notation, I prefer project specific conventions for naming. This allows team members to draw up their own convention, which in turn makes it more readable to the team, especially if team members need to learn a generic convention that they don’t know.

There is a downside to developing your own convention for the project. The convention could make no sense to outsiders reading the code, or it could be very lax. Developers should always get one or more developers who aren’t part of the project and definitely did not partake in the drawing up of the convention to review the conventions at some point to make sure that they are not internalising the convention, and that it is readable.