views:

521

answers:

10

Hello. 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?

+1  A: 

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.

Damien
+4  A: 

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

Richard Szalay
+5  A: 

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;
Canavar
sorry for downvoting but i really don't like underscore notation.
Jakub Šturc
I don't think that deserved a downvote (fixed) - naming conventions are a divisive issue, and downvoting based on it is unreasonable.
Marc Gravell
@Jakub - frankly, so what? That is unrelated to the actual question, and the truth is many people do find the _ prefix helpful. As it happens, I prefer it without, but a downvote on that is just petty.
Marc Gravell
Underscore for private/members variables is quite a common naming convention
Chris S
+1 to counter Jakub's downvote :)
Patrick McDonald
I'm use to this convention for the past 6 years so I'll give another 1.
Chris S
@Mark - well maybe it's little petty but I still don't think that "use underscore" is good advice.
Jakub Šturc
I gotta agree, that doesn't really belong - the question isn't about your naming conventions (and how this is any better than hungarian is beyond me).
annakata
sorry but the question is exactly related to code readability, so I think it belongs to here.
Canavar
I agree with Jakub about using underscores. I prefer camelStyle for fields and CapitalStyle for properties
abatishchev
@abatishchev you still use camelcase, you just prefix _ to distinguish between local and member variables. It's a preference but I find it helps with intellisense
Chris S
on the contrary, it's useful when you don't have intellisense, but gets in the way when you do.
Simon
I used to use this notation: private string mMyPrivateVariable;
Javier Morillo
+25  A: 

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.

Marc Gravell
Jon dug out the comment in question: http://csharpindepth.com/ViewNote.aspx?NoteID=54
Marc Gravell
The developer shouldn't "decide deliberately" if something is private. It should be private automatically, hence the default. Only public and protected members require conscious decision to make them so.
Constantin
@Constantin - and what about if you go through that thought process, and decide that `private` is, in fact, correct. Tell the reader! For classes, there is another very good reason (partial class ambiguity).
Marc Gravell
@Constantin - strongly disagree. Defaults are terrible for readability. What if void became the default output for a method, would you be happy to let that be implicit? What if it was string[]?
annakata
@annakata - indeed; for another: what is the default accessibility of a class? Many people say "internal", but that is not correct; it is "internal" for top level, "private" for nested. Another case where being explicit pays dividends.
Marc Gravell
@annakata, @Marc Gravell. Proof by analogy is not proof. The question is about default access for fields, not default access of classes or default return types. What class of programming errors would be eliminated if default private access for fields is removed from C#?
Constantin
@Constantin: Defaulting to private protects the coder who might have accidentally left it off. Showing it tells the reader the coder thought about it and made it private deliberately. This does amount to syntactic salt, though, so it's up to you. I think for teams, being explicit is probably better.
Mike Rosenblum
@Mike Rosenblum, please add an example of situation where explicit private protects the coder from something bad to http://stackoverflow.com/questions/552857/what-for-should-i-mark-private-variables-as-private-if-they-already-are/553085#553085 . There is already one example, albeit weak.
Constantin
+1  A: 

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).

David Christiansen
+14  A: 

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.

Jon Skeet
To me the second argument for making "private" explicit is a bit like "I'm writing 'i = +42' instead of 'i = 42' to show maintenance programmer that i'm aware of negative numbers! I am actively making a decision here!" :)
Constantin
@Constantin: Proof by analogy is not proof, as you said elsewhere. I'd say that if your coding standard requires you to specify the access, you're more likely to think about it, which means you're more likely to make the right decision.
Jon Skeet
A: 

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.

User
My brain certainly prefers succinctness, not verbosity, when i quickscan code. I don't think remembering the default is a problem, since it's the most logical default i can imagine.
Constantin
For classes "private" is default, for structs "public" is default. If you work with different languages it just becomes worse. I prefer to help myself.
User
@so-tester; I wish I could +1 that comment...
Marc Gravell
@so-tester, it's a C# question, not C++. Private is still default for C# structs.
Constantin
+4  A: 

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.

Chris S
Oh, that's a good one. I like.
Marc Gravell
+3  A: 

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)

annakata
+2  A: 

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.

Constantin