Should you use the private access modifier if it's redundant?

Given that these two examples are equivalent, which do you think is preferrable?

Without explicit modifier

public class MyClass
{
    
    string name = "james";
    
    public string Name {
        get { return name; }
        set { name = value; }
    }

    void SomeMethod() { ... }

}

With explicit modifier

public class MyClass
{
    
    private string name = "james";
    
    public string Name {
        get { return name; }
        set { name = value; }
    }

    private void SomeMethod() { ... }

}

---

I've always used the latter, but recently I've started adopting the former style. The private is redundant as that's the default accessor modifier, so doesn't it make sense to exclude it?

I think explicity stating private helps in readability. It won't allow for a programmer to interpret its visibility differently.

It looks that we are the only one, but personally, I support the let's remove private campaign.

My concern is that public and private are so similar, 6-7 chars length, blue, starting with 'p', so it's much harder to point a public method between 10 explicit private ones than between 10 that have no access attribute.

Also, it's an advantage since lazy people in your team tend to save writing the modifier and making the method private, which is actually a good thing. Otherwise you end up with everything public.

I usually prefer explicit over implicit, but that's more important in language corner cases (tricky cheats) that in a widespread feature. Here I think long-rung maintainability is more important.

Also, I usually like when code is simple and clear in a mathematical way over when the code is explicit in order to preserve future coder's ignorance. That's the VB way, not C#...

Marking it as private makes it clear that it is deliberate, rather than "I didn't actually think about it, so I don't know if it would be better as something else."; so I do like making it explicit. I wouldn't get religious about it, though.

Also - this prevents having to remember rules... members are private by default, (outer) types are internal by default; nested types are private by default...

Make it clear... make it explicit ;-p

I always omit it for two reasons: to reduce visual clutter, and to do the right thing by default.

In C#, everything defaults to the least visibility possible. A class member (field, method, property) defaults to private. A class defaults to internal. A nested class defaults to private.

Thus if you omit your visibility except where you need it, you'll be automatically using the least visibility possible, which is the right way to do things anyway.

If you need something to be more visible, then add the modifier. This makes it easy to see items that deviate from the default visibility.

(Unfortunately, this rule only holds for C#. In VB .NET and in F#, the defaults are quite different and definitely not "least visibility possible" in most cases.)

I've been developing full-time in C# for about 7 years now, and until I read this topic I didn't know what the default access modifier is. I knew that one existed, but I've never, ever used it.

I like explicitly declaring my intent as I code. Both because the declarations are there for me to see when I go back and look at it, and because actually thinking and typing the word "private" when I write a method makes me think just a little more about what I have it in mind to do.

Personally, I prefer the private modifier - I like explicitness. For fields, it also highlights that it's a member variable as opposed to a function variable (the only difference otherwise is location - which is okay if folks can indent properly, but can be confusing otherwise).

I like to be super-explicit usually. I will go for specifying "private" always. However there is another reason : Programmers coming from programming languages where the default visibility is NOT private but public, for example PHP.

I always prefer to be explicit, even if it is redundant. This provides built-in code comments and can be helpful for the next guy, especially if he's a noob. :-)

Always use the explicit form. If for whatever reason the underlying assumption changes, the code with an explicit denotation of access won't break, whereas the implicit connotation my easily break.

Also, when you are talking about different types of structures, they may have different default accessibilities. Without the explicit modifiers, the ownus is on the reader to know which structure has what default. E.g. in C#, struct fields default to public, class fields default to private, and class definitions default to internal.

I go for explicit all the time. If nothing else it demonstrates your intention more clearly. If I want something to be private I will say so. Explicitly typing the modifier makes sure I think about it, rather than just leaving things private because its quicker. That an a long list of members line up better :)

I always specify the visibility explicitly. I prefer not letting the compiler guess my intentions.

you are correct but since you want your code to be understandable for everyone i think you should include, you never know when if someone does not know this

First I will ask if there is a previous code convention/standard about that being used by the team. If there is any, you should follow it.

If you have to define the convention, I will push for the explicit way.

My reasons?;

• I like to keep the same structure (I mean a.-access modifier, b.-return-type/type, c.-name).
• I don't want (and I don't expect others) to remember all the modifiers by default (which are here).
• Not all the languages have the same rules.
• And somehow I think that, somehow, forces the developer to think and be more conscious about the scope of the variable/method and the exposition of those. If you have some experience this will probably not apply, but if you are a newbie, or you work with people with less experience, I think that is useful.

My understanding has always been members have "internal" accessibility unless stated otherwise. If that's true, the "private" modifier would be required to ensure those members are in fact private.

Regardless of whether I'm correct about the above or not, leaving the modifier in place will increase the readability of the code in case another developer is later modifying this class and is curious about the accessibility. Hope this helps!