Variable

  • Thread starter Thread starter Dang Tran
  • Start date Start date
At said:
Whereas IMO, it makes it more readable. It makes it easier to instantly
see which members *aren't* private, because they're the ones with
access modifiers.
Click to expand...

Don't you think that the word "private" is a clear hint of private access
as well?

I think that readability is much easier achieved by grouping them
together (if possible, tucked away in a nice #region), instead of mixing
all kinds of access and relying on the shorter form of the private parts
(pun intended <g>).
 
Rudy Velthuis said:
Don't you think that the word "private" is a clear hint of private access
as well?
Click to expand...

Yes - but the point is that everything that *can* be private *should*
be private, so anything that *isn't* private should stand out. Using
access modifiers only for those things which are non-private achieves
that, IMO.
I think that readability is much easier achieved by grouping them
together (if possible, tucked away in a nice #region), instead of mixing
all kinds of access and relying on the shorter form of the private parts
(pun intended <g>).
Click to expand...

The benefit of the way the defaults are set up is that you basically
aren't going to introduce many bugs by leaving things as default by
accident - you'll usually just fail to compile, because another module
wants access to something you've left "too private".

Regions are okay, but can make it difficult to navigate around
sometimes - I use them, but sparingly.

I find that only specifying the access modifer when it's not the
default gives me greater readability *and* less typing, which is always
a nice combination. (The latter is never a good reason on its own, but
here it's (to me) an added benefit.)
 
Rudy Velthuis said:
True.

But it doesn't hurt to explicitly specify the access modifier, even if it
is implicit. I always prefer explicitness over implicit rules.
Click to expand...

Well, it doesn't hurt if you believe you get greater readability with
the explicit statement. I don't - I believe you get greater readability
by only explicitly stating things you want to be more accessible, so in
that sense it *does* hurt.
 
Jon said:
If it made the code more readable, I'd agree. I believe it makes the
code *less* readable, because it means there's less of a highlight when
something *isn't* private.
Click to expand...

As I see it, the main problem with the keyword "private" is that it's
too similar to "public". Due to this, when quickly scanning your code
for public members among private members, when the private accessibility
specifier is used, it's not very easy to notice the public members.

If the keyword "private" was changed to something different, I might use
it. As it stands, though, I won't because it makes distinguishing
between public and private members at a quick look, too hard.
 
At said:
Yes - but the point is that everything that can be private should
be private, so anything that *isn't* private should stand out.
Click to expand...

Perhaps. I simply like the explicit denotations more than the implicit
rule.
The benefit of the way the defaults are set up is that you basically
aren't going to introduce many bugs by leaving things as default by
accident - you'll usually just fail to compile, because another module
wants access to something you've left "too private".
Click to expand...

True. I agree that private being the default is good. That does not mean
that we should not denote private members, IMO.
Regions are okay, but can make it difficult to navigate around
sometimes - I use them, but sparingly.
Click to expand...
I find that only specifying the access modifer when it's not the
default gives me greater readability and less typing, which is always
a nice combination.
Click to expand...

I prefer explicit mention of all access specifiers. I see we simply
disagree.
 
At said:
Well, it doesn't hurt if you believe you get greater readability with
the explicit statement.
Click to expand...

Yes, I see we have different preferences here. I see your point, but I
like mine more. <g>
 
During my many years of OO development, I have worked on a lot of different
projects with a lot of different people and I haven't spoken to anyone
(until now) who prefers to leave off the definition for default member
accessibility. IMO, code is without a doubt more structured and more
readable with clearly defined member accessibility against all members
regardless of whether or not they are using the default accessibility.
Books are a generally good example to go by. If you take a look at any book
written by the professionals (and that includes the MCAD/MCSD ones), then
nowhere will you see code examples that omit the accessibility definition
for default access. There may be general mention that this can be done but
they do not preach the use of doing so throughout their code examples.
Although nothing compares to real-world experience, books generally teach,
or at least try to point you towards the best practises in development &
coding and I have yet to see a book that shows code examples without
accessibility defined on all members. If you can show me a book where this
is the case then I would certainly be interested to see it.

Of course, everyone has their own personal preference in coding methodology
and I respect yours and everyone else's opinions on this but at the end of
the day we have to accept that we have differing views on this particular
subject and leave it there.

If everyone agreed with each other all the time and had the same opinions
then the world would be a very dull place :-(

Gary
 
Gary Milton said:
During my many years of OO development, I have worked on a lot of different
projects with a lot of different people and I haven't spoken to anyone
(until now) who prefers to leave off the definition for default member
accessibility.
Click to expand...

In many languages it wouldn't be appropriate - and in those languages I
would explicitly state the access. (Java has the unfortunate situation
where the default access *can't* be stated explicitly. This is
certainly something to be avoided in language design.)
IMO, code is without a doubt more structured and more
readable with clearly defined member accessibility against all members
regardless of whether or not they are using the default accessibility.
Click to expand...

To me, it's still clearly defined. I never have to "guess" at the
accessibility - but with my scheme, non-private members leap out at me
more, which is exactly how I wish it.
Books are a generally good example to go by. If you take a look at any book
written by the professionals (and that includes the MCAD/MCSD ones), then
nowhere will you see code examples that omit the accessibility definition
for default access.
Click to expand...

Not true. I've just picked up a random book off my bookshelf, and the
first page I turned to had an example where the private members don't
have the accessibility explicitly stated. I agree, however, that most
books do include the private modifier.
There may be general mention that this can be done but
they do not preach the use of doing so throughout their code examples.
Click to expand...

No, but then frankly code examples in books are often far from great
examples anyway. They have public fields for the sake of code
simplicity, for example, where most people would suggest they should be
private with public property access instead.

In this case, it's also understandable that you might want to make
explicit in a book for relative beginners the access which you might
leave defaulted for those who are already comfortable with the
language.
Although nothing compares to real-world experience, books generally teach,
or at least try to point you towards the best practises in development &
coding and I have yet to see a book that shows code examples without
accessibility defined on all members. If you can show me a book where this
is the case then I would certainly be interested to see it.
Click to expand...

The book I looked at before was Joe Mayo's "C# Unleashed".
Of course, everyone has their own personal preference in coding methodology
and I respect yours and everyone else's opinions on this but at the end of
the day we have to accept that we have differing views on this particular
subject and leave it there.

If everyone agreed with each other all the time and had the same opinions
then the world would be a very dull place :-(
Click to expand...

I'm happy to accept it's a personal preference - but I do take issue
with your statement that it's bad practice.
 
Apart from the scope, the C# language stresses that the programmer
declare his intentions quite clearly in the code and declaring the scope
of an object is the 'in' thing and even if it is of the default scope it
is advisable to declare the scope of the object.

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
Ravichandran J.V. said:
Apart from the scope, the C# language stresses that the programmer
declare his intentions quite clearly in the code and declaring the scope
of an object is the 'in' thing and even if it is of the default scope it
is advisable to declare the scope of the object.
Click to expand...

Surely if the C# language *really* stressed that, there would be no
default in the first place.
 
At said:
Surely if the C# language really stressed that, there would be no
default in the first place.
Click to expand...

Not necessarily. Defaults are usually a fall-back mechanism.
--
Rudy Velthuis

"The man who does not read good books has no advantage over the man who
cannot read them."
-- Mark Twain (1835-1910)
 
Rudy said:
Not necessarily. Defaults are usually a fall-back mechanism.
Click to expand...

Regardless, I doubt this C# default was implemented primarily as a
fall-back mechanism, because of the general explicative nature of other
syntax elements of the language.
 
At said:
Regardless, I doubt this C# default was implemented primarily as a
fall-back mechanism, because of the general explicative nature of other
syntax elements of the language.
Click to expand...

I have no idea what you mean. I have been programming in many languages,
and in all these languages, I found it to be safer to explicitly state
things (not only "visibility" or "access"), even if they were the default.
--
Rudy Velthuis

"In the End, we will remember not the words of our enemies, but the
silence of our friends."
- Martin Luther King Jr. (1929-1968)
 
Rudy Velthuis said:
Not necessarily. Defaults are usually a fall-back mechanism.
Click to expand...

But if C# was *stressing* being explicit everywhere, there wouldn't be
a fall-back mechanism at all - you'd just have to give the access
everywhere. There's no *need* for there to be a default, after all.

Also, if C# really stressed being explicit, there wouldn't be implicit
operator overloads.
 
At said:
But if C# was stressing being explicit everywhere, there wouldn't be
a fall-back mechanism at all
Click to expand...

C# leaves you the freedom to omit it, and rely on a default. Doesn't mean
that is good practice to do so, IMO.
--
Rudy Velthuis

"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth."
-- Sherlock Holmes (by Sir Arthur Conan Doyle, 1859-1930)
 
Rudy Velthuis said:
C# leaves you the freedom to omit it, and rely on a default. Doesn't mean
that is good practice to do so, IMO.
Click to expand...

No, it doesn't (nor does it mean it's bad practice, of course).

My point is that the fact that it gives you the freedom to omit it
undermines Ravichandran's argument that C# stresses being explicit. If
I were designing a language where I wanted the programmer to be
explicit about everything, I'd make the access modifier mandatory.
 
At said:
No, it doesn't (nor does it mean it's bad practice, of course).

My point is that the fact that it gives you the freedom to omit it
undermines Ravichandran's argument that C# stresses being explicit.
Click to expand...

C# the language does not. But I can imagine it is stressed by the
documentation.
 
Back
Top