Any reason to write the "private" keyword in C#?

As far as I know, private is the default everywhere in C# (meaning that if I don't write public, protected, internal, etc. it will be private by default). (Please correct me if I am wrong.)

So, what's the reason to write that keyword, or why does it even exist for members?

For example, when an event handler is auto-generated it looks like this:

private void RatTrap_MouseEnter(object sender, CheeseEventArgs e)
{
    
}

But why does it even write private if that's implied and default? Just so that novice developers (who don't know it's the C# default) know that it's private? Or is there a difference for the compiler?

Moreover, is there a case where writing "private" (alone) will change the accessibility of the member?

> AFAIK, private is the default everywhere in C# (meaning that if I don't write public, protected, internal, etc. it will be private by default). (please correct me if wrong).

This is not true. Types defined within a namespace (classes, structs, interfaces, etc) will be internal by default. Also, members within different types have different default accessibilities (such as public for interface members). For details, see Accessibility Levels on MSDN.

Also,

> So, what's the reason to write that keyword, or why does it even exist?

Specifying this explicitly helps denote your intention to make the type private, very explicitly. This helps with maintainability of your code over time. This can help with other developers (or yourself) knowing whether a member is private by default or on purpose, etc.

> AFAIK, private is the default everywhere in C#

Not quite - the default is "the most restricted access available for this declaration". So for example, with a top-level type the default is internal; for a nested type the default is private.

> So, what's the reason to write that keyword, or why does it even exist?

It makes it explicit, which is good for two reasons:

• It makes it clearer for those who don't know the defaults, as per your question (I've never liked this argument, personally, but I figured it's worth mentioning)
• It gives an impression that you've deliberately decided to make it private, rather than just gone with the defaults.

As for your last part:

> Moreover is there a case where writing "private" (alone) will change the accessibility of the member?

Yes, for making half of a property more restrictive than the other:

// Public getter, public setter
public int Foo { get; set; }

// Public getter, private setter
public int Bar { get; private set; }

I used to go with defaults everywhere I could, but I've been convinced (partly by Eric Lippert) that making it clear that you've thought about it and decided to make something private is a good idea.

Personally I wish there were a way of doing that for sealed / unsealed, too, for type declarations - possibly not even have a default. I suspect that many developers (myself included if I'm not careful) leave classes unsealed just because it's less effort than making them sealed.

private adds visual clutter. To those who insist that it makes things explicit, I would ask: Do you do this with mathematics, too? For instance:

var answer = a + b / c;

Do you find that unclear without redundant parentheses around b / c?

The rule in C# is very simple: By default, everything is as close to private as it can be. So if you need something to be more visible than the default, add a modifier. Otherwise, don't add needless keywords to your code.

> As far as I know, private is the default everywhere in C#

Explicitly declaring private, means you know it is private. Not just think it is, because as far as you know, it is the default. It also means that someone else who looks at the code knows what it is.

There is no "I think it is", "I'm pretty sure it is", etc. It just is. And everyone is on the same page.

I am not a C# developer. If I had to work with some code that wasn't explicitly declared private, I would probably assume it was internal.

I dislike when things are implicitly set. It's never as clear as when they are explicitly set.

Readability - Not everyone may know that private is the default behaviour.

Intent - Gives a clear indication that you have specifically declared the property private (for whatever reason).

Readability, demonstration of intent are two great reasons I can think of.

One good reason for explicitly specifying the visibility is so that you don't have to think about what is the default for the context you are in.

Another good reason is because FxCop tells you to do it.

A lot of people (people like me!) regularly program in a handful of different languages. Being explicit with things like these prevents me from needing to remember all the arcane details of all the languages I program in.

I'd say for consistency with the readability of the scope of the rest of the class.

I like to explicitly add the private keyword so that I know it's private. Plus, private isn't always the default access specifier everywhere. Also, you can use private set in properties to effectively make a read-only property that can only be set by the class it was declared in.