Convention question

[GC]

Within a class, do you use the private keyword for your
internal member variables or do you leave it off like you
would for variables within a function?

 

[Jon Skeet]

Within a class, do you use the private keyword for your
internal member variables or do you leave it off like you
would for variables within a function?

I leave it off in C#, but use it in Java. It's important that they
*are* private, but as that's the default in C# it's not really a
problem.

 

[Drebin]

I am a fan of explicitly writing things like that - because A) I didn't know
that was the default for C# and I'm sure there are others that don't.. B)
when I come back to my code 8 months (and dozens of small projects later) -
I'm not going to be able to remember all the assumptions I made...

"Software bugs are born solely from assumptions." (my quote, although - I
keep refining it.. I'll have the final one soon)

So for the 1/4 second it takes to write this, might save me hours later on
when I'm (or some poor soul) is trying to fix my code..

 

[Jon Skeet]

I am a fan of explicitly writing things like that - because A) I didn't know
that was the default for C# and I'm sure there are others that don't.

I would personally like to hope that everyone I work with will know the
language well enough to know that - or else they'd ask. Non-private
writable (or mutable) member variables are enough of an eye-opener that
I know *I'd* check what was going on if I suspected some code I was
working with was using them.

B)
when I come back to my code 8 months (and dozens of small projects later) -
I'm not going to be able to remember all the assumptions I made...

Does that mean you're not going to accept all the other things that the
C# specification explicitly states then?

Accepting that C# works as per the specification isn't the same as
assuming that the implementation of something will work in some
particular (undocumented) way.

"Software bugs are born solely from assumptions." (my quote, although - I
keep refining it.. I'll have the final one soon)

Software bugs are often born from *false* assumptions. It's easy to
absolutely *prove* that the assumption is true in this case - you just
look at the C# specification.

So for the 1/4 second it takes to write this, might save me hours later on
when I'm (or some poor soul) is trying to fix my code..

Could you give an example of a bug which leaving out "private" might
cause?

 

[Drebin]

I can't believe you'd even argue these points!! This is a matter of
principle, to me. This is simply a case of how much does it hurt versus how
much does it help. And the odds are against you, the ONLY advantage to
leaning on the assumptions of a standard is that it lets the developer be
lazy. The Up side FAR outweighs this, by making sure you don't have any
assumptions - documented or not. Mean what you type and type what you
mean... Oh!! I think will be one of my next quotes!! )

I don't have a specific problem with private/public - all I know is I spent
most of my career cleaning up and rewriting apps, and running into so many
assumptions. 98% of any problem I've ever had was trying to figure out what
the developer meant and figure out what assumptions they had in thier head
while they were writing this. For example, in VB6 -off the top of your head-
are array's zero-based or one-based? Are enums (that don't have values)
zero-based or one-based? What about VB3? Are you sure?

Things like that - I don't want me, or anyone else looking at my code having
to look up specifications. Especially since what you're saying is fine right
now. What about when C# 2.0 comes out and they change the spec - and you're
looking at this assumption-based code - and you don't know if I wrote it in
the "olden 1.0 days when *these* were the assumptions" or was it written
with the "new improved spec"?? If instead, I just TYPE where my head is at.
If I type public blah, private blah, protected blah - there is ABSOLUTELY no
room for interpretation or assumption. So, if it takes no time to type it -
why WOULDN'T you? Except out of laziness... You have so little work to do,
to gain so much clarity!!!

And I'll tell you, I've been burned SOOOOO many times with the above-type
scenario with developers like you!! And I just like doing my little part to
make my life easier and hopefully some guy that will have to fix my code in
a year from now.. You're applying a very academic viewpoint to real-world
coding, and that's what makes all this such a mess.. on behalf of some
random person that might work for your company and have to fix your code,
please reconsider.. )

Lastly, this will really burn you too - but even though I use "using ...;"
statements, I just about always preface the first instance of a class with
the fully-qualified namespace. That is, unless it's regularly used ones,
like System.Data.OleDb. or System.IO.... I wish every developer would adopt
these simple concepts - I believe this is a huge part of being a responsible
developer...

 

[Jay B. Harlow [MVP - Outlook]]

GC,
I normally explicitly list them as Private. Independent of the language.

As Jon stated, private is the default, so its really not needed.

Hope this helps
Jay

 

[Jon Skeet]

I can't believe you'd even argue these points!! This is a matter of
principle, to me.
Likewise.

This is simply a case of how much does it hurt versus how
much does it help.
Likewise.

And the odds are against you, the ONLY advantage to
leaning on the assumptions of a standard is that it lets the developer be
lazy.

On the contrary - I gain readability (see below) precisely because I
*haven't* been lazy - because I've read the standard! I've put in a bit
of effort up front to make my life easier in the long term.

The Up side FAR outweighs this, by making sure you don't have any
assumptions - documented or not. Mean what you type and type what you
mean... Oh!! I think will be one of my next quotes!! )

You still have assumptions though - you just choose different ones to
make.

I don't have a specific problem with private/public - all I know is I spent
most of my career cleaning up and rewriting apps, and running into so many
assumptions. 98% of any problem I've ever had was trying to figure out what
the developer meant and figure out what assumptions they had in thier head
while they were writing this. For example, in VB6 -off the top of your head-
are array's zero-based or one-based? Are enums (that don't have values)
zero-based or one-based? What about VB3? Are you sure?

I don't do VB, so I don't know. However, when I'm writing in a language
I like to know what it does - so unless it actually makes things harder
to understand (as knowing and always relying on operator precedence as
opposed to grouping things with brackets does), I'll use the guarantees
the specification makes.

In this case, the keyword private is not only redundant, but I believe
it's distracting. I find it clearer to read code which doesn't have the
modifier when it's not needed - it means that any modifiers which *are*
there stick out more.

Things like that - I don't want me, or anyone else looking at my code having
to look up specifications.

Just how far does that go? What about knowing the default values for
static/instance variables?

Insisting on the modifier reminds me of people setting variables to
null when they're not needed any more, "just in case".

Especially since what you're saying is fine right
now. What about when C# 2.0 comes out and they change the spec - and you're
looking at this assumption-based code - and you don't know if I wrote it in
the "olden 1.0 days when *these* were the assumptions" or was it written
with the "new improved spec"??

If they make breaking changes like that to the spec, I'd be very
surprised - and if you don't know the spec to start with, you're not
going to know which of *your* assumptions have been broken by changes.

If instead, I just TYPE where my head is at.
If I type public blah, private blah, protected blah - there is ABSOLUTELY no
room for interpretation or assumption.

In this particular case. As I say though: you *do* rely on guarantees
the specification makes, otherwise you'd have no language to code in at
all. For instance, I bet you assume that "i" isn't a keyword - that
it's a valid identifier. Better watch out if they change that in C#
v2...

So, if it takes no time to type it -
why WOULDN'T you? Except out of laziness... You have so little work to do,
to gain so much clarity!!!

No, to *lose* clarity in my view - it means that those things which
*do* have modifiers no longer stand out as much.

And I'll tell you, I've been burned SOOOOO many times with the above-type
scenario with developers like you!!

Developers like me who are making accurate assumptions based on
specifications, or developers who *aren't* like me and who are guessing
at behaviour?

I'd be surprised if you have been burned often by people rigidly
following specifications.

And I just like doing my little part to
make my life easier and hopefully some guy that will have to fix my code in
a year from now.. You're applying a very academic viewpoint to real-world
coding,

Not at all - I'm applying my practical experience to the situation.

and that's what makes all this such a mess.. on behalf of some
random person that might work for your company and have to fix your code,
please reconsider.. )

On behalf of people who know the spec and who don't like reading
redundant and distracting code, please reconsider.

Lastly, this will really burn you too - but even though I use "using ...;"
statements, I just about always preface the first instance of a class with
the fully-qualified namespace. That is, unless it's regularly used ones,
like System.Data.OleDb. or System.IO.... I wish every developer would adopt
these simple concepts - I believe this is a huge part of being a responsible
developer...

Again, I consider that pointless. If I have any doubts about what
namespace the class comes from, I can always hover over it and find
out. Sure, that doesn't help if the code is being viewed other than in
an IDE, but I don't see that as a problem: the gain is readability for
the vast majority of situations, ie where the developer actually knows
full well which classes they're using.

As for "the first instance" - that sounds like a recipe for
inconsistency, as what is originally the first instance may well not be
in the future, and more to the point it may *very* well not be the
first time that a developer sees the class referred to, as they may
well be looking in a specific method or property rather than reading
the whole class from the top down.

 

[james]

Jon,

What's it like to never make a mistake ?

JIM

 

[Jon Skeet]

I have to agree with you Drebin, I believe that by explicitly writing
private
you show future readers that you truly meant private and didn't just forget
to put it there because you were lazy !

If you see a variable with no specifier you have to ask yourself, did the
programmer mean for it to be private or just get sloppy and forget to type
it ?

Variables should almost always be private. When was the last time you
actually wanted to make something non-private, but forgot and
*accidentally* made it private, without the compiler whinging because
you then tried to use it?

I virtually never use non-private variables other than for constants
etc - I would hope that any developer I work with would take the same
attitude. Given that, it's entirely reasonable to assume that someone
working in a language which has private as the default modifier
actually *means* private when they don't put anything else on.

Note that there are various other parts of the spec where in fact
modifiers aren't even *allowed* because there's no real choice - if you
*could* put modifiers on constants, for instance, would you declare:

public static const int Foo = 5;

etc everywhere as well?

There are places where redundancy is good for readability. I don't
believe this is one of those places.

 

[Jon Skeet]

What's it like to never make a mistake ?

I make mistakes - but I can't see how this particular situation would
lead to a mistake. Could you enlighten me with an example?

Congratulations on not addressing any of my points, by the way.

 

[james]

Jon,

I read all your points but I see no point to it at all. I believe
that you are more likely to make a mistake when you
fail to type private than when you take the time to put it
in, because when you are typing you are thinking and
when not, you may not be. Since you admit you do
make mistakes, you could leave a variable private
when it should have been protected.

JIM

 

[Jon Skeet]

Nope, what about protected ?

Remember, private means subclasses cannot access it,

Absolutely - and a good job too!

and there are many subclass situations where it is not an
error to access the variable directly.

It is by my convention, and by Microsoft's. I'd want a protected
*property* instead. (And in a future version of C# I'll finally be able
to have a property with, say, protected read access by private write
access. I've also proposed a way of making sure that *only* the
property (and perhaps members with a certain attribute applied) had
direct access to the variable.

From the MSDN Field Usage Guidelines:

<quote>
Do not use instance fields that are public or protected (Public or
Protected in Visual Basic). If you avoid exposing fields directly to
the developer, classes can be versioned more easily because a field
cannot be changed to a property while maintaining binary compatibility.
</quote>

<quote>
Expose a field to a derived class by using a protected property that
returns the value of the field. This is illustrated in the following
code example.
</quote>

Having protected variables is *much* more likely to lead to bugs than
not including a redundant modifier, in my experience.

 

[Jon Skeet]

I read all your points but I see no point to it at all. I believe
that you are more likely to make a mistake when you
fail to type private than when you take the time to put it
in, because when you are typing you are thinking and
when not, you may not be. Since you admit you do
make mistakes, you could leave a variable private
when it should have been protected.

Even if I *did* use protected variables (which I don't; see my other
post) I'd surely notice that when I got a compiler error saying that I
didn't have access to the protected variable.

Making something accidentally public or protected when you meant
private is much more of a problem though - and that's where *not*
writing private makes it more obvious:

int foo;
int bar;
string baz;
public object grumble;
long somethingElse;

Look at the above in VS.NET, then look at:

private int foo;
private int bar;
private string baz;
public object grumble;
private long somethingElse;

It's much clearer to me that there's "something different" about
grumble, as it has two keywords highlighted instead of one. Thus the
error is more obvious, as well as there being less redundant
(information-free) text on the screen when the code is actually
correct.

 

[james]

Ok,

So when you have multiple developers working on their own parts of code and
they turn in there code for review and some have explicitly called out
private
and the others have not, how will you resolve the conflict ?

1. Tell the developer who explicitly used private to change their code?
2. Tell both developers that in the future NOT to use private?
3. Allow the code to be inconsistant?
4. Fire everyone and leave the software field for ever, start surfing ?

JIM

 

[Daniel O'Connell]

generally, when declaring a variable, most people think about its protection
level, i don't see how that works.

Most of hte time when i decide a variable must be protected its when i've
inherited and realized that my design was wrong, then i realize that by
requiring that variable to be accessable from inheritiing code, my design is
REALLY wrong and i need to reconsider what i'm doing, considering i'm really
screwing my intent of encapsulation and hiding implementation.
I think protected members should be provided via properties as well, as they
are external pieces of code that you have little control over. (and yes, at
times, i have used event properties too for various reasons)

Jon,

I read all your points but I see no point to it at all. I believe
that you are more likely to make a mistake when you
fail to type private than when you take the time to put it
in, because when you are typing you are thinking and
when not, you may not be. Since you admit you do
make mistakes, you could leave a variable private
when it should have been protected.

JIM

 

[Jon Skeet]

Example :: I have a UserControl MyGridView that conatins a GridControl
and a button. My UserControl then customizes the look and feel of the Grid
and button.
Now, my developers come along and SubClass MyGridView to lets say
EmployeeGridView or OrdersGridView so that they can make a specific
implementation
of that View. Now, the code generated in Initialize compnonet by Microsoft
directly
accesses the base class GridControl and Button. Microsoft DOES NOT use the
getter and setter, they access the Controls directly. Is this valid ? MS
must think so.

How did you add the button to the user control? I just tried this: I
added a new user control class, and in the designer added a button to
the control. The code generated had:

private System.Windows.Forms.Button button1;

In that case, the subclass couldn't possibly access the variable
directly - how did you get the designer to generate a non-private
variable? If you did it with the designer itself (with the modifier
property) then I hardly think that counts - it's letting you shoot
yourself in the foot deliberately, but not doing it for you
automatically.

Only using private members is a well-established design principle these
days. It's suggested for all kinds of languages, in all kinds of
places.

 

[james]

Rock climbing !

No, I guess I wouldn't care as long as the code functioned as it should.
I would continue to do it my way though

JIM

 

[Daniel O'Connell]

winform design is one area that this is a problem.
Jon, to answer your question, the designer has a field in the property grid
called modifiers that lets you change the protection level of controls, its
a very ugly solution, but due to the large number of possible variables
involved, manually generating properties would be a task (i hope VS provides
a better method of this in the future, autogenerating properties perhaps
instead of simply changing access modifiers)

Jon,

You are correct that you must make it protected so that the
child class can manipulate the properties. This is completely
valid. Our application has many views that all contain a Grid
but speicifc sub-class implementation use that grid in different
ways, like the grid may dock.fill or may be docked at the top.
Initialize component in the subclass directly accesses the grid
control to assign these properties

JIM


use

 

[Drebin]

Why the HECK did Microsoft generate that code and put "private" in there?
Don't they know that we all assume that it's private??

) COME ON!! I couldn't resist!!

 

[GC]

Man, I come back from lunch and look at all these
messages!

James,

But don't you leave out the private modifier for function
variables? If so, I think I would do the same with class
member variables. Plus, public and protected are actually
modifying something where private is redundant.

Good points to both sides, not really a big deal but I
slightly side with leaving the keyword out.