New to C#

  • Thread starter Thread starter Dan
  • Start date Start date
D

Dan

Hi All,
I am switching over from Visual Basic (actaully VBA) and am concerned about
naming conventions in C#.

I am accustomed to using Leszenski's convention for a variable is always
preceding by it's data type, such as intWidth (designating an Integer
variable)
dblQuantity (designating a Double variable) and so forth.

Is there an industry standard naming convention for C# ?

Might as well start off correctly.
 
Dan said:
I am switching over from Visual Basic (actaully VBA) and am concerned about
naming conventions in C#.

I am accustomed to using Leszenski's convention for a variable is always
preceding by it's data type, such as intWidth (designating an Integer
variable) dblQuantity (designating a Double variable) and so forth.
Click to expand...

That's generally not used in .NET - at least not for public members.
It's up to you exactly how you name private members. Personally I can't
stand that convention - and don't like prefixes for distinguishing
member variables from local variables either, but it's a matter of
preference.
Is there an industry standard naming convention for C# ?

Might as well start off correctly.
Click to expand...

See http://tinyurl.com/2cun for the MS guidelines.
 
In Addition to this ( If its not mentioned somewhere in the guildines) ,
dont use capitalisation to differentiate identifier names as this causes
porting problems to VB.NET
 
Mad Murdoch said:
In Addition to this ( If its not mentioned somewhere in the guildines) ,
dont use capitalisation to differentiate identifier names as this causes
porting problems to VB.NET
Click to expand...

Only if both of them are non-private. My preferred naming convention
uses a private variable of name foo with a public property of name Foo.
That doesn't cause any problems with VB.NET, as no other class can see
the private variable.
 
You will get a "Already Declared" error in VB.NET on the identifier name for
the Property itself
 
I've tested that last year in the summer, it's quite good really but I found
it a bit over the top. I think it would prevent me from having a decent
throughput if I were using it in anger.
 
I agree..however I learned about some stuff like assembly permissions etc
that I had no idea existed..eg
[assembly:SecurityPermission(SecurityAction.RequestMinimum,
UnmanagedCode=true)]
 
Jon Skeet said:
That's generally not used in .NET - at least not for public members.
It's up to you exactly how you name private members. Personally I can't
stand that convention - and don't like prefixes for distinguishing
member variables from local variables either, but it's a matter of
preference.
Click to expand...

I agree, that annoying m_ prefix for member variables. And Hungarian
notation...bane of all developers who want pronounce-able le names.

-Mark
 
Mad Murdoch said:
You will get a "Already Declared" error in VB.NET on the identifier name for
the Property itself
Click to expand...

What, when trying to use a class written in C#? I'm not suggesting
trying to do use that convention when writing classes in VB.NET - only
in C#, and then consuming the class in VB.NET.
 
Mad Murdoch said:
OK, I was talking about converting code, not just consuming it.
Click to expand...

Right - that shouldn't be an issue for the OP, who is converting *from*
VB *to* C#.
 
Yes, Jon, I see that; but it is nevertheless something to beware of. I have
experience of this when converting code written by others and have had
headaches as a result. Do you resent me adding to your reply with what I
considered a useful watchpoint ?
 
Mad Murdoch said:
Yes, Jon, I see that; but it is nevertheless something to beware of. I have
experience of this when converting code written by others and have had
headaches as a result. Do you resent me adding to your reply with what I
considered a useful watchpoint ?
Click to expand...

Not particularly - I thought it was just worth adding that it needn't
be a problem, while you're in C#, even if other developers who use your
class use VB.NET. That wasn't clear from your post - you just said not
to use a fairly common convention, despite the fact that it works fine.
 
Jon Skeet said:
Only if both of them are non-private. My preferred naming convention
uses a private variable of name foo with a public property of name Foo.
That doesn't cause any problems with VB.NET, as no other class can see
the private variable.
Click to expand...

Mine too, though I've come across people who hate it.
 
Back
Top