Is it better to declare a "private" field as private or as internal?

Question

Is it better to declare a property as private or as internal? And...why is one preferred over the other?

Someone I work with declares "private" fields as internal all the time and I see no point to it...so I must be missing something.

EXAMPLE:

/// Someone I work with does this
public class SomeClass
{
    internal Document _document;
    internal Contractor _contractor;
    internal IUser _user;
    internal Project _project;
}

/// I usually do this
public class SomeClass
{
    private Document _document;
    private Contractor _contractor;
    private IUser _user;
    private Project _project;
}

Why would you want to create a property as private? – Martin Hennings Apr 14 '11 at 15:49 — Martin Hennings, Apr 14 '11 at 15:49

JaredPar · Answer 1 · 2011-04-14T19:25:52.077

11

A field, and any other member, should be declared with most restrictive access modifier that allows the member to be used as needed.

internal will only allow it to be used from within the same assembly or friend assemblies
private will only allow it to be used from within the type itself

Whichever of these satisfies your scenarios is the one that should be chosen.

I'm guessing though that private is more appropriate here. Given the field name is not compliant with the .Net Design Guidelines it seems like it's meant to be private to the type. Hence I would make it private or give it an appropriate name.

edited Apr 14 '11 at 19:25

answered Apr 14 '11 at 15:49

JaredPar

733,204
149
1,241
1,454

Could you please re-vamp your answer? I realized I formatted the original question incorrectly. – Prisoner ZERO Apr 14 '11 at 19:20

Jon Skeet · Accepted Answer · 2011-04-14T19:40:42.657

4

Usually a purely private automatically implemented property might as well be a private field.

As a brief rule of thumb, restrict everything as much as you can without causing too much pain. If nothing else in your assembly uses those properties (or should reasonably use those properties), then making them private (and possibly making them plain fields) is a good approach.

EDIT: Okay, now that we're talking about fields, definitely, definitely make them private. Non-private fields should be incredibly rare - pretty much the only use I can think of would be constants (whether actually const or just readonly static fields of an immutable type). Even then I'd normally use properties. Just occasionally for games and other performance-critical situations, it's worth breaking the rules - but you need to understand and respect those rules first.

Fields are an implementation detail - exactly how you store the data within an object shouldn't be interesting to other code trying to use that object. Focus on the difference between the API that a type should support and the implementation of that API.

edited Apr 14 '11 at 19:40

answered Apr 14 '11 at 15:49

Jon Skeet

1,421,763
867
9,128
9,194

You can make properties final? I'm not sure I even understand what that would mean semantically. – John Kraft Apr 14 '11 at 15:52
@John: I meant private. Oops :) – Jon Skeet Apr 14 '11 at 15:55
Could you please re-vamp your answer? I realized I formatted the original question incorrectly. – Prisoner ZERO Apr 14 '11 at 19:21
@Prisoner ZERO: Your question still *talks* about properties, but *shows* fields. Which are you really interested in? – Jon Skeet Apr 14 '11 at 19:29

score 2 · Answer 3 · edited May 23 '17 at 12:26

2

This depends on your requirement I suppose. If you need other classes to have access to the variables in the same assembly, then internal is the way to go. If you don't need other classes to have access, then declare them as private.

More can be found about internal here:

Practical uses for the "internal" keyword in C#

edited May 23 '17 at 12:26

Community

1
1

answered Apr 14 '11 at 15:49

tjg184

4,508
1
27
54

Is it better to declare a "private" field as private or as internal?

3 Answers3