Prefix methods

[Rob]

Hi,

Would it be safe to prefix private and protected methods and properties with
and underscore? Would this cause any issues with other languages?

Cheers,

 

[Karthik D V]

Hi,

Would it be safe to prefix private and protected methods and properties with
and underscore? Would this cause any issues with other languages?

Cheers,

Prefixing the underscore is not acceptable in .net standards..

type qualifiers are enough to differentiate.

 

[Barry Kelly]

Would it be safe to prefix private and protected methods and properties with
and underscore? Would this cause any issues with other languages?

It would be safe, but not recommended for protected members. Protected
members should conform to the framework guidelines (PascalCase for both
methods and properties). Think of 'protected' as 'public, only slightly
less so'. There's a huge gap between private and protected.

What you do in private, well, nobody really cares

-- Barry

 

[Rob]

Thanks for the reply. I do however feel that you misunderstood my question
but I'll replay as follows.

I honestly don't really care about the acceptable .net standards, all
standards change and sometimes not for the good. This has been happening
since the beginning of programming so I believe if you don't have to follow
standards(which sometimes aren't as good), do what feels right and makes you
most productive.

My motivation for prefixing protecteds and privates are simple, one of them
are: when you type the underscore and activate intellisence you get all your
custom members not available to the "outside" so to speak. This is very
helpful to me since you don't have to hunt as hard for that method or
property you've created 3 months ago.

I've had a long and hard battle with myself regarding following the "current
standard" or using my own. To me it's just soo much simpler typing _^space
and getting a list of the internals that are actually performing the work in
my class.

If underscore would break things I'll just go with "z" as a prefix as I've
seen being used by other companies.

So, back to the original question, will prefixing private and protected
methods and properties with an underscore break anything?

 

[Barry Kelly]

Thanks for the reply. I do however feel that you misunderstood my question
but I'll replay as follows.

I honestly don't really care about the acceptable .net standards, all
standards change and sometimes not for the good.

Don't underestimate the value of consistency and convention!

This has been happening
since the beginning of programming so I believe if you don't have to follow
standards(which sometimes aren't as good), do what feels right and makes you
most productive.

Sure - as long as you understand the rationale behind the standard etc.

My motivation for prefixing protecteds and privates are simple, one of them
are: when you type the underscore and activate intellisence you get all your
custom members not available to the "outside" so to speak.

Protected members are available to the outside - all the outside has to
do is derive. Protected is almost, but not quite, public.

If underscore would break things I'll just go with "z" as a prefix as I've
seen being used by other companies.

So, back to the original question, will prefixing private and protected
methods and properties with an underscore break anything?

I beg of you, if you write code that will be used or maintained by
anybody else, stick with the .NET standards for protected members.

Private and internal members aren't visible to the outside world, so
they will not cause any problems. If you're using IL, you have a much
broader palette of characters to choose from, including '$', '.', etc.

-- Barry

 

[Rob]

Lol, Barry, some points taken and I do appreciate you time for making those
points. My days of low level stuff like mov ah,4c int 21 and vtables are
long gone Now it's high level all the way, not time to play. Have alook at
my inline comments.

Don't underestimate the value of consistency and convention!

Never had a problem with consistency, it's the convention thats not to my
liking. Why throw apples, oranges in one bag if you can have them in
separate bags? When I stick my hand in the bag I'd rather know what I'll be
taking out.

Sure - as long as you understand the rationale behind the standard etc.

I've always had the "Guidelines for Names" in my VS Help Favorites although
I've never seen any reason why not to prefix. All I see is things like "Do
not use a prefix for field names. For example, do not use g_ or s_ to
distinguish static versus non-static fields.". Then again I can always buy
the book "Framework Design Guidelines: Conventions, Idioms, and Patterns for
Reusable .NET Libraries" that the MSDN refers to.

Protected members are available to the outside - all the outside has to
do is derive. Protected is almost, but not quite, public.

By "outside" I meant outside the class. They are still protected in the
derived class.

I beg of you, if you write code that will be used or maintained by
anybody else, stick with the .NET standards for protected members.

Not to worry, that's where the "Convention" wins hands down.

Private and internal members aren't visible to the outside world, so
they will not cause any problems. If you're using IL, you have a much
broader palette of characters to choose from, including '$', '.', etc.

Hmm, maybe I'll start using IL

 

[Barry Kelly]

Lol, Barry, some points taken and I do appreciate you time for making those
points. My days of low level stuff like mov ah,4c int 21 and vtables are
long gone Now it's high level all the way, not time to play.

Lucky you. I work on compilers now, both Win32 and .NET - I can't escape
the MOVs.

[...]

I've always had the "Guidelines for Names" in my VS Help Favorites although
I've never seen any reason why not to prefix. All I see is things like "Do
not use a prefix for field names. For example, do not use g_ or s_ to
distinguish static versus non-static fields.".

Yes, but those apply to public fields (which ought to be rare, if ever -
properties etc.). You can do whatever you like in private, and whatever
other people on your team can tolerate in internal.

Then again I can always buy
the book "Framework Design Guidelines: Conventions, Idioms, and Patterns for
Reusable .NET Libraries" that the MSDN refers to.

Most of the naming content (for example) is available in the SDK
guidelines, but it does collect together a lot of other info that is
spread out in blog postings etc. over the past few years. I didn't learn
a huge amount from it, but it's definitely worthwhile to bring it all
together. There are a few nuggets of info in the annotations too.

By "outside" I meant outside the class. They are still protected in the
derived class.

Sure. The larger point I suppose I was making is that when your classes
aren't sealed, you're designing for two different users: people who
instantiate the class, and people who derive from the class. I think too
many people overestimate how "protected" protected is - it isn't really
"protected" at all, only slightly less public. For example, invariants
still need to hold with protected methods (or be very well documented),
there can't be any less-secure methods in there, etc.

Don't get me started on virtual methods; that's even worse, because
there are two sides - the implementer and the caller, and the caller may
be the class itself, where the implement or might need to deal with
invariants not holding etc. Implementing virtual methods and esp.
documenting them is not that easy.

-- Barry

 

[Dave Sexton]

Hi,

Prefixing the underscore is not acceptable in .net standards..

The standards make no mention (anymore) of the format for private members,
unfortunately.

type qualifiers are enough to differentiate.

However, if by type qualifiers you mean Hungarian notation, it's not
recommended for class libraries:

General Naming Conventions
http://msdn2.microsoft.com/en-us/library/ms229045.aspx

"These guidelines apply to all identifiers"

 

[rossum]

Hi,

Would it be safe to prefix private and protected methods and properties with
and underscore? Would this cause any issues with other languages?

Cheers,

The C++ standard reserves all identifiers containing two consecutive
underscores, "__", for the implementation. In some circumstances it
also reserves identifiers starting with underscore followed by a
capital letter.

To retain C++ compatibility it is safest to either make sure that any
leading underscore is followed by a lowercase letter only or to use
the "m_xxxx" convention for private data or methods.

As others have pointed out, protected data and methods should normally
follow the standard naming conventions.

rossum

 

[Jon Skeet [C# MVP]]

Don't get me started on virtual methods; that's even worse, because
there are two sides - the implementer and the caller, and the caller may
be the class itself, where the implement or might need to deal with
invariants not holding etc. Implementing virtual methods and esp.
documenting them is not that easy.

Absolutely - inheritance is great when it's really, really what's
needed, but composition is much easier to cope with.

See http://msmvps.com/jon.skeet/archive/2006/03/04/inheritancetax.aspx
for my general rant about inheritance

 

[Dave Sexton]

Hi,

I don't mean to start up this discussion again, but I have to point out that
I think this is the problem - trying to preserve compatibility in managed
languages to unmanaged conventions for the sake of compatibility only.

Of course, people have brought to my attention the usefulness of having m_
or __ as a prefix for private fields, but I still believe that its limited
value (and its value doesn't apply to everyone who actually uses it) isn't
worth the degradation in readability or the confusion of programmers that
aren't accustomed to using it.

Now, if your entire organization is based on C++ or Java programmers that
want to retain the convention, then by all means do so

 

[Stefan Hoffmann]

hi Barry,

It would be safe, but not recommended for protected members. Protected
members should conform to the framework guidelines (PascalCase for both
methods and properties).

Where can i find these guidelines?


mfG
--> stefan <--

 

[Brian Gideon]

Sure. The larger point I suppose I was making is that when your classes
aren't sealed, you're designing for two different users: people who
instantiate the class, and people who derive from the class. I think too
many people overestimate how "protected" protected is - it isn't really
"protected" at all, only slightly less public. For example, invariants
still need to hold with protected methods (or be very well documented),
there can't be any less-secure methods in there, etc.

Barry,

Yep. Recently I've been sealing all of my classes immediately and
unsealing them only when I want to allow the class to be subclassed and
after I have thought out all of the consequences. To me anyway, one of
the biggest issues of non-sealed classes is versioning. Non-sealed
classes are more difficult to version because subclasses can tweak the
semantics of the class in ways that are difficult to predict.

I know there has been debate in the past about whether classes should
be sealed by default. I *think* the Framework Design Guidelines book
says that classes should remain unsealed unless there is a specific and
compelling reason to seal them (don't quote me on that though).
Admittedly, I've been wavering back on forth on this topic for awhile
now. Comments?

Brian

 

[Jon Skeet [C# MVP]]

Where can i find these guidelines?

http://tinyurl.com/2cun

 

[Stefan Hoffmann]

hi Jon,

http://tinyurl.com/2cun

Thanks.


mfG
--> stefan <--

 

[Dave Sexton]

Hi Brian,

I'd like to see classes sealed by default, unsealing them only when there is
a specific, compelling reason. To code inheritance properly isn't always
easy or straight-forward and can cause problems for programmers that derive
from your classes "hoping" that they can extend its functionality safely. A
sealed class lets them know that they probably shouldn't derive from your
class, and can't. If sealed is the default, then an unsealed class would
let developers know that they can safely derive from your class.

 

[Dave Sexton]

Hi,

That links to the old MSDN content. Here's the latest and greatest:

..NET Framework Developer's Guide
Design Guidelines for Developing Class Libraries
http://msdn2.microsoft.com/en-us/library/ms229042.aspx

 

[Jon Skeet [C# MVP]]

I'd like to see classes sealed by default, unsealing them only when there is
a specific, compelling reason.

Ditto. C# improved on Java by making *methods* non-virtual by default -
I'd have thought that making classes sealed by default would have been
the logical next step.

A sealed class lets them know that they probably shouldn't derive
from your class, and can't. If sealed is the default, then an
unsealed class would let developers know that they can safely derive
from your class.

Indeed - and that deliberate action invites the further deliberate
actions which are effectively required: documenting *how* to safely
derive from the class, what can be expected when overriding particular
methods etc.

 

[Dave Sexton]

Hi Jon,

Good point. One good practice leads to another (hopefully

I tend to mark classes as sealed as soon as they are created, by default,
but it's easy to forget. At least in Visual Studio a simple item template
could solve that problem, although I don't use one myself.