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]

GC <gc********@yah oo.com> wrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[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" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@news.microsof t.com...

GC <gc********@yah oo.com> wrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jon Skeet]

Drebin <tR************ *@hotmail.com> wrote:

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?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[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!! :o)

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

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.Ole Db. or System.IO.... I wish every developer would adopt
these simple concepts - I believe this is a huge part of being a responsible
developer...
"Jon Skeet" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@news.microsof t.com...

Drebin <tR************ *@hotmail.com> wrote:

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?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[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

"GC" <gc********@yah oo.com> wrote in message
news:02******** *************** *****@phx.gbl.. .

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]

Drebin <tR************ *@hotmail.com> wrote:

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!! :o)
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.. :o)
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.Ole Db. 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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[james]

Jon,

What's it like to never make a mistake ?

JIM
"Jon Skeet" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@news.microsof t.com...

Drebin <tR************ *@hotmail.com> wrote:

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!! :o)

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

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.Ole Db. 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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jon Skeet]

james <no****@hyperco n.net> wrote:

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 - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Jon Skeet]

james <no****@hyperco n.net> wrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too