What for should I mark private variables as private if they already are?

Question

As far as I know, in C# all fields are private for default, if not marked otherwise.

class Foo
{
  private string bar;
}

class Foo
{
  string bar;
}

I guess these two declarations are equal.

So my question is: what for should I mark private variables as private if they already are private?

Answer 1

I've been on the fence for a while about this. I used to argue for leaving it implicit, but now I think I'm tipped over towards making it explicit.

Reasons for leaving it implicit:

• It means there's a bigger difference for non-private members (or anything with more access than the default); this highlights the difference when reading the code

Reasons for making it explicit:

• Some developers may not know the defaults: making it explicit means it's clear to everyone
• It shows you've actively made a decision, rather than just leaving it up to the default

These latter points are basically the ones made by Eric Lippert when we discussed it a while ago.

Answer 2

Now; fields should pretty-much always be private anyway, so it is an edge case whether you should bother.

For the wider subject, I remember a comment by Eric Lippert - essentially saying that given a method / class / whatever:

void Foo() {}
class Bar {}

Then it isn't clear whether they are private/internal deliberately, or whether the developer has thought about it, and decided that they should be private/internal/whatever. So his suggestion was: tell the reader that you are doing things deliberately instead of by accident - make it explicit.

Answer 3

Yes they are equal but I like to mark private variables as private, I think it improves reading.

also I use this common notation for private members, it's very useful :

private string _bar;

Answer 4

This is purely a coding standards question but, for what it's worth, I always explicitly mark private members as private.

Answer 5

If you were switching between Java and C# on a regular basis I imagine it would be fairly important to specify the access modifier explicity. For example in Java

void myMethod()
{

}

any class in your package has access to that method. In C# it's obviously private to the class and inner classes.

Answer 6

Don't make people guess, don't let them make false assumptions, and don't think fewer characters in any way equates to clarity.

There's no good reason not to make this explicit, and imho it's a mistake for C# to support it (especially if they're willing to do what they did to switch statements for the same reason)

Answer 7

Explicitly using private can improve readability in certain edge cases.

Example:

        /*
        Tomorrow when we wake up from bed,
        first me and Daddy and Mommy, you, eat
        breakfast eat breakfast like we usually do,
        and then we're going to play and
        then soon as Daddy comes, Carl's going
        to come over, and then we're going to
        play a little while. And then Carl and
        Emily are both going down to the car
        with somebody, and we're going to ride
        to nursery school [whispered], and then
        when we get there, we're all going
        to get out of the car...
        */

        int spam;

        /*
        Does this style look at all familiar?
        It should!
        */

Looking at this fragment you may be unsure whether you're in method or class scope.

Using either private or underscore in field name (private int spam;, int spam_; or int _spam;) will eliminate the confusion.

Answer 8

Up to you. Do what's best for readability or makes sense in your case. I mark them as private just to make it clear though.

Answer 9

I think for readability it is always best to be explicit.

As a side, You may wish to have a look at a visual studio plug-in called Code Style Enforcer (http://joel.fjorden.se/static.php?page=CodeStyleEnforcer) which uses the dxCore extensions to provide real-time feedback on your codes adherence to coding standards (fully customisable).

Answer 10

I personally prefer marking the default private and default public fields explicitly. You may well know the defaults but your brain will like verbosity whenever you quickly scan the code.