Considering "private" is the default access modifier for class Members, why is the keyword even needed?
Explicitness. I never use the default and always explicitly add the modifier.
This could be because of my Java background where the default was 'package' (roughly equivalent to 'internal' in C#) and so the difference always bothered me. I found explicitness to be preferable.
I also use ReSharper now which defaults to being explicit, so it only confirms and reinforces my bias :)
For symmetry and to conform with coding styles that like everything to be explicit (personally I like it ...)
Some coding styles recommend that you put all the "public" items first, followed by the "private" items. Without a "private" keyword, you couldn't do it that way around.
Update: I didn't notice the "c#" tag on this so my answer applies more to C++ than to C#.
For completenes. And some people actually prefer to be explicit in their code about the access modifiers on their methods.
Actually, if the class or struct is not declared with an access modifier it defaults to internal.
So if you want to make it private, use private.
Not sure about C#, but in some languages you can go back and forth:
public:
int var1;
int var2;
private:
int varA;
public:
int varB;
private:
int varC;
etc.
The private modifier explains intent.
A private member variable is not intended for direct manipulation outside the class. get/set accessors may or may not be created for the variable.
A private method is not intended for use outside the class. This may be for internal functionality only. Or you could make a default constructor private to prevent the construction of the class without passing in values.
The private modifier (and others like it) can be a useful way of writing self documenting code.
Using private explicitly signals your intention and leaves clues for others who will support your code ;)
Private is only the default for methods on a type, but the private modifier is used elsewhere.
From C# Language Specification 3.0 (msdn) Section 3.5.1
Depending on the context in which a member declaration takes place, only certain types of declared accessibility are permitted. Furthermore, when a member declaration does not include any access modifiers, the context in which the declaration takes place determines the default declared accessibility.
- Namespaces implicitly have public declared accessibility. No access modifiers are allowed on namespace declarations.
- Types declared in compilation units or namespaces can have public or internal declared accessibility and default to internal declared accessibility.
- Class members can have any of the five kinds of declared accessibility and default to private declared accessibility. (Note that a type declared as a member of a class can have any of the five kinds of declared accessibility, whereas a type declared as a member of a namespace can have only public or internal declared accessibility.)
- Struct members can have public, internal, or private declared accessibility and default to private declared accessibility because structs are implicitly sealed. Struct members introduced in a struct (that is, not inherited by that struct) cannot have protected or protected internal declared accessibility. (Note that a type declared as a member of a struct can have public, internal, or private declared accessibility, whereas a type declared as a member of a namespace can have only public or internal declared accessibility.)
- Interface members implicitly have public declared accessibility. No access modifiers are allowed on interface member declarations.
- Enumeration members implicitly have public declared accessibility. No access modifiers are allowed on enumeration member declarations.
I usually leave private out but I find it useful for lining up code:
private int x;
public string y;
protected float z;
VS:
int x;
public string y;
protected float z;
As pointed out by Jon Skeet in his book C# In Depth, there is one place in C# where the private keyword is required to achieve an effect.
If my memory serves correctly, the private keyword is the only way to create a privately scoped property getter or setter, when its opposite has greater than private accessibility. Example:
public bool CanAccessTheMissileCodes
{
get { return canAccessTheMissileCodes; }
private set { canAccessTheMissileCodes = value; }
}
The private keyword is required to achieve this, because an additional property accessability modifier can only narrow the scope, not widen it. (Otherwise, one might have been able to create a private (by default) property and then add a public modifier.)
As Robert Paulson said in his answer, the private
modifier is not just used on members, but also on types. This becomes important because the default for types is internal
which can leak unintentionally if you use the InternalsVisibleToAttribute.
There's a certain amount of misinformation here:
"The default access modifier is not private but internal" - well, that depends on what you're talking about. For members of a type, it's private. For top-level types themselves, it's internal.
"Private is only the default for methods on a type" - no, it's the default for all members of a type - properties, events, fields, operators, constructors, methods, nested types and anything else I've forgotten.
"Actually, if the class or struct is not declared with an access modifier it defaults to internal" - only for top-level types. For nested types, it's private.
Other than for restricting property access for one part but not the other, the default is basically always "as restrictive as can be."
Personally, I dither on the issue of whether to be explicit. The "pro" for using the default is that it highlights anywhere that you're making something more visible than the most restrictive level. The "pro" for explicitly specifying it is that it's more obvious to those who don't know the above rule, and it shows that you've thought about it a bit.
Eric Lippert goes with the explicit form, and I'm starting to lean that way too.
See http://csharpindepth.com/ViewNote.aspx?NoteID=54 for a little bit more on this.
Jon