|
Hi Shakti,
Why would this violate any good convention ?
You certainly did not look at the Microsoft C# naming recommendations/conventions or many others.
"Count" is indeed not the same variable in C# than the variable "count" (notice the lower casing).
This is true in every programming language based on C (C++, java and the likes).
This characteristic is used to discriminate fields from properties in languages than can handle it.
This characteristic does not exist in VB since the very V. 1, and will most probably never.
Regards,
Marc
|
|
|
|
|
Simply because something can "handle" it does not mean it is good practice.
I am familiar with the naming conventions of many languages, but they do not condone the use of the same name for multiple disparate objects no matter what the casing is; actually they say to not do that explicitly.
Directly from the MSDN :
http://msdn2.microsoft.com/en-us/library/04xykw57(VS.71).aspx[^]
"
To avoid confusion and guarantee cross-language interoperation, follow these rules regarding the use of case sensitivity:
Do not use names that require case sensitivity. Components must be fully usable from both case-sensitive and case-insensitive languages. Case-insensitive languages cannot distinguish between two names within the same context that differ only by case. Therefore, you must avoid this situation in the components or classes that you create."
From the same MSDN page :
Do not create a function with parameter names that differ only by case. The following example is incorrect.
void MyFunction(string a, string A)
Also from the same MSDN page :
Do not create a type with property names that differ only by case. In the following example, int Color and int COLOR are inappropriate property names because they differ only by case.
int Color {get, set}
int COLOR {get, set}
The list goes on and on. There is just no good use/reason for disparate objects to be named the same, differing only by case. This is a troubleshooting/readability/style nightmare.
This is like vb.net allowing you to late-bind, or turn off "option strict" in the IDE. Just because you "can" dosent mean you "should".
|
|
|
|
|
Hi Shakti,
Yes, this is true for public members so as to allow case insensitive languages to interact with curly braces languages in projects which are mixing several languages (C# and VB, for example).
This is not what I was speaking about.
How would you code the following snippet in VB, and still adhere to MS coding conventions ?
I am refering to the class naming conventions recommending not to use prefixing.
Note that the coding conventions you mentionned in your previous post do not apply here.
private string shortText;
public string ShortText {
get { return shortText; }
set { shortText = value; }
}
Regards,
Marc
|
|
|
|
|
I'm sorry, you are just simply wrong. There is no special case where the conventions do not apply. It is a very simple, plain, and direct set of guidelines to never, under any circumstances use names for -anything- that require case-sensitivity.
To reply to your sample directly:
Marc Greiner wrote: private string shortText;
public string ShortText {
get { return shortText; }
set { shortText = value; }
}
To re-write this in Vb you would of course not use the same name for two completely different variables; it just makes no sense, is not necessary, and is the foundation for problems.
This is one of the worst possible coding nightmares in an enterprise sized application of several hundred thousand(and more) lines of code; trying to sift through hundreds/thousands of objects with the same name, whose scope/type/etc are completely different.
This is an example of the type of thing that costs companies millions of dollars in lost hours spent troubleshooting/tracking through bad code.
|
|
|
|
|
Hi Shakti,
I wasn't meaning to offend you, really.
I need to reiterate my question, because it wasn't answered :
How would you code the following C# snippet in VB ?
private string shortText;
public string ShortText {
get { return shortText; }
set { shortText = value; }
}
Note that "shortText" represents the storage for the public property called "ShortText".
These do indeed have things in common.
Some VB programmers would do it like this :
Dim _shortText As String
Property ShortText() As String
Get
ShortText = _shortText
End Get
Set(ByVal value As String)
_shortText = value
End Set
End Property
But then this will get into conflict with MS recommending not to use the "_".
Some others would do it like this :
Dim mshortText As String
Property ShortText() As String
Get
ShortText = mshortText
End Get
Set(ByVal value As String)
mshortText = value
End Set
End Property
But then this will get into conflict with MS recommending not to use prefixing. It also looks inelegant.
So how would you program it ?
You wrote (extract from MS recommendations) :
> Do not use names that require case sensitivity.
> Components must be fully usable from both case-sensitive and case-insensitive languages.
> Case-insensitive languages cannot distinguish between two names within the same context that differ only by case.
> Therefore, you must avoid this situation in the components or classes that you create.
In the code snippet, "ShortText" is declared as public, this means only "ShortText" can be part of a component interface.
Thus, this C# code snippet is perfectly compatible with the MS recommendations.
Regards,
Marc
|
|
|
|
|
I took no personal offense to your posts, but rather want to make a very strong point that this type of construct is the recipe for problems and lost hours of troubleshooting and is also completely un-necessary.
The word component is not limited to one narrow band of object, it is a description of a much larger concept. The idea behind it all is that the use of casing to name vastly different objects with the same name is problematic.
Marc Greiner wrote: Note that "shortText" represents the storage for the public property called "ShortText".
These do indeed have things in common.
The only thing they have in common is their name, their scope is completely different.
There are many ways to re-write your sample, one of which is the following:
Private ShortenedText As String
Public Property ShortText() As String
Get
Return ShortenedText
End Get
Set(ByVal value As String)
ShortenedText = value
End Set
End Property
Another, if the variable "shorttext" is to be used for say, removing spaces, would be :
Private NospacesText As String
Public Property ShortText() As String
Get
Return NospacesText
End Get
Set(ByVal value As String)
NospacesText = value
End Set
End Property
There are literally limitless ways to re-write this using -meaningful- variable names, without resorting to having to re-use names just because you "can" and then having to differentiate them by case, which is itself a clue that something is not right.
Maybe describing it like this will make more sense to you :
private string ShortText; public string Shorttext { get { return ShortText; } set { ShortText = value; } }
private string ShOrtText; public string shortText { get { return ShOrtText; } set { ShOrtText = value; } }
private string SHortText; public string shorTText { get { return SHortText; } set { SHortText = value; } }
private string SHorTText; public string ShorTText { get { return SHorTText; } set { SHorTText = value; } }
private int SHorTTexT; public int ShorTtext { get { return SHorTTexT; } set { SHorTTexT = value; } }
private string ShorTTexT; public string ShoRTtext { get { return ShorTTexT; } set { ShorTTexT = value; } }
I mean, they are all "different", the language lets me, and I "can"...right?
Can you imagine having to read through/troubleshoot that?
What if those lines were spread out over 100,000 lines of code?
What if those statements were also complicated by re-using that one name (shorttext) for other things like classes?
Just because you "can" does not mean you should, that it's good, useful, or necessary.
|
|
|
|
|
Hi Shakti,
It seems that you are not aware of the use of "camel" casing versus "Pascal" casing.
Why not google those two words right now and learn something...
Here somemore thoughts about identificators discrimination :
A programmer needs to be able to read small signs on his screen and differenciate them from each other.
He needs to be able to differenciate "." from ":", and also lowercase "s" from uppercase "S", and several other signs.
If a sign as small as a point is missing in some critical program, it might compile.
But if for example the program pilots a rocket, it might make the rocket explode unexpectedly during execution and even kill somebody.
So we all better check that every identificator is spelled correctly, and certainly not only those which are differenciated by casing.
The compiler is here to help, although it does not find every mistake, but once you know how it works, you can rely on it.
There is also the Ctrl+F keyboard combination to the rescue, which will allow you to find every occurence of a given identificator (you can even launch the search with a click of the mouse in the menu or toolbar). Do not forget to check the "Match case" option, if it is important for you.
Try to name two boolean fields like follows in VB:
GodIsNowhere and GodIsNowHere
These two variables have very different meanings, even opposite meanings.
But only the casing of one letter differs.
In a big program, such kind of identificator collision happens sometimes.
In C#, you wont care.
In VB, you will have to find another word for your identificator, like you did in the snippet of your previous post.
GodIsNowhere and GodIsNowHere :
Impossible to get it in VB !
C# can do it effortless ! (and every other programming language can do it...)
VB narrows the creativity of so many artists.
VB only frustrates curly braces programmers.
Regards,
Marc, a frustrated VB programmer (but hopefully not for long anymore...)
|
|
|
|
|
Your post makes no sense.
You say :
"But if for example the program pilots a rocket, it might make the rocket explode unexpectedly during execution and even kill somebody."
But then stick to re-using the exact same name, differing only by case, for multiple vastly different objects; This would cause anyone having to read through thousands of lines of code like this to pull all of their hair out.
Marc Greiner wrote: GodIsNowhere and GodIsNowHere :
Impossible to get it in VB !
C# can do it effortless ! (and every other programming language can do it...)
Impossible?? I think not : GodIsNowhere, GodIsHereNow.
You did say something interesting though, "effortless". It actually takes effort to construct good, well thought out code. The effort required for the "impossible" above? About one extra second.
Marc Greiner wrote: These two variables have very different meanings, even opposite meanings.
But only the casing of one letter differs.
In a big program, such kind of identificator collision happens sometimes.
This kind of "collision" only happens when people refuse to use good practices and end up with hard to read, hard to modify, hard to troubleshoot code. We have applications that reach into the millions of lines of code, and nowhere does this "collision" occur. People receive training or are fired when this type of damage occurs.
I give up. I don't see anything more productive coming from this, and I don't think you will be swayed by example or debate.
I am just glad it won't be me having to parse through thousands of lines of code where hundreds of different objects have the same name but do different things
|
|
|
|
|
Hi Shakti,
Come on, do not give up ! I was wishing you would trust C# as a better language as VB.
And what about "camel" versus "Pascal" casing ?
From what I read in your post, you did not google it, did you ?
If you follow good advices, you will go to bed more intelligent as you were in the morning. Google it now !
Here some more links about naming conventions :
http://www.irritatedvowel.com/Programming/Standards.aspx[^] There you will find an interesting discussion about the use of "_" for private fields (I disagree with the author on this one, though).
Here is a link to Microsoft Naming Conventions (Property Usage Guidelines)
(I had hoped you would find this one alone, as it was just a few clicks away from an other link you mentioned).
http://msdn2.microsoft.com/en-us/library/bzwdh01d(VS.71).aspx[^]
Here a snippet extract :
In C# :
string dataSource;
public string DataSource {
get { return dataSource; }
set {
if (value != dataSource) {
SetActive(value != null && dataField != null);
dataSource = value;
}
}
}
Note the use of casing discrimination in C# (MS recommendation).
For VB :
Private m_dataSource As String
Public Property DataSource() As String
Get
Return m_dataSource
End Get
Set
If value <> m_dataSource Then
' Set the property value first, in case activate fails.
m_dataSource = value
' Update active state.
SetActive(( Not (m_dataSource Is Nothing) And Not (m_dataField Is Nothing)))
End If
End Set
End Property
Note the use of hungarian notation in VB, which is a contradiction only because of VB syntax limitations.
I personally do prefer the simplicity and elegance of C#.
Casing difference is enough for me, but then again, I got a very good eyesight.
With it, I am able to see by the first look whether the letter is Upper or lowercase.
Note also that C# got invented only recently, and could benefit from good and bad experiences made with other languages. It is the accumulation of C, C++, (java), others, even VB for sure, that makes C# so nice.
C# also did not need to remain compatible with previous versions, as it was all new.
For example, no need to write "Option Strict" on top of every file, no need to ask yourself "Do I code Dim or Private ?", no need to write "Dim..., Dim..., Dim...", "As..., As..., As...,", "Sub", "Function", "Property", "End Property", "End Sub", "End Function", "End If", "Next", "End Get", "Then", etc... But I repeat myself...
Regards,
Marc
|
|
|
|
|
If b = 5 Then Select Case b : Case 5 : b = 1 : Case Else : b = 7 : End Select
So it is also on one line AND it's more readable compared to the C# version!
But it's still quite horrible and I hope I never have to work with programmers that implement methods like that.
As for the "count" vs "Count" being impossible in VB.NET, you are right there. However, Microsoft states that for Framework development you should never have two variables that differ only in casing because once you start doing so, everyone using case insensitive languages (Such as VB.NET) can no longer use your framework. You are thus limiting the target audiance of your framework which can never be your intention as it results in less copies being sold etc.
"In C#, I can see more usefull lines of code as in VB in a given height of my screen, with no compromise over the readability."
As stated earlier, it doesn't really matter if you have "End If" or "}" on your line now does it and if you are placing multiple } on one line I can only assume you work in a team of exactly 1 programmer. You.
What I think is a real advantage over VB.NET is the use of anonymous delegates, that really saves code-lines.
The "real" language comparison is just plain silly. A language where you have to use more sounds usually indicates that the other language is less expressive. So you translate Japanese and end up with a correct and shorter translation but you have sacrificed "emotion", which cannot be translated to English. But that is entirely irrelevant to the issue at hand.
|
|
|
|
|
In C#, a function is represented as a string of symbols mathematical formula.
In VB, a function is represented as a paragraph of text for a word problem.
|
|
|
|
|
Here you go in 3 lines:
Function a()
If x = 5 Then : Select Case b : Case 1 : If a = 1 Then : End If : End Select : End If
End Function
Not that I say I write my code this way
Svetlana
|
|
|
|
|
Thank you Svetlana, obviously it works in VB.NET !
But in VB6, this syntax is not allowed, although VB6 allows ":" at some places.
VB.NET got some enhancements finally.
I aggree with you, I also would not write it this way in VB.
|
|
|
|
|
you can on 3 lines ( function header and function end should be on separate line)
function a()
Dim x, b, c As Integer : If (x = 0) Then : Select Case b : Case 0 : If (c = 0) Then : MsgBox("hi") : Return 0 : End If : End Select : End If
End Function
function declaration is on one line, all body is on one line, and function ending is on one line
This is an old feature in the old ancient basic, but it is still working, i tested it with vb5
id not know why non c people are using c# as it waste of development time. i event do not know why microsoft encourages new programmers to use c#. with vb.net i can make 2 programs, in c# in the same time i can develop 1 only.
now you can do your own one line things like the c and php people ;P
Nader
|
|
|
|
|
When converting/translating code from VB.Net to C# or vice versa, you can also run into this syntactical difference, for values in hexadecimal format (f.i. byte values):
VB: &H<value> example: Dim returnByte As Byte = &H12
C#: 0x<value> example: byte returnByte = 0x12;
I must say you created a nice reference list, good job!
Teun Roodvoets
The only person who got all his work done by Friday was Robinson Crusoe
-- modified at 10:55 Tuesday 25th July, 2006
|
|
|
|
|
Very nice article with a few minor nuances
|
|
|
|
|
Good ,Informative and Knowledge sharable
"Every morning I check Forbes 40 richest Indians list , if i'm not there I go to work."
|
|
|
|
|
|
Hi,
I have noticed a strange (to me) difference in the way the two compilers are dealing with the following scenario:
I have an interface definition, containing several methods, one of them being marked as Obsolete, with the error flag being set to true (meaning the compiler will treat any attempt to use this method as an error). The rest of the methods are normal methods.
If I create a class that IMPLEMENTS the interface, I have to implement all the methods, offcourse. The difference is that in C# this is perfectly possible, while the VB compiler will not compile the class, complaining about the obsolete method.
Does this mean that in VB, if ONE method is obsolete, the ENTIRE interface is un-implementable ?
PS: I'm a C# programmer and I just recently started to learn VB. So if the above problem has a simple answer, please excuse my ignorance
|
|
|
|
|
The ENTIRE interface is un-implementable.
Thats the way it should be.
If you want to allow it to use the interface then set the bool flag to false [ no compile error])
Schneider
Schneider
|
|
|
|
|
VB.NET does not use the String::op_equality but it's own implementation in order to take "option compare [text|binary]" into account. This makes string comparision a bit slower.
IL_0069: ldstr "Hello"
IL_006e: stloc.2
IL_006f: ldstr "Ade"
IL_0074: stloc.3
IL_0075: ldloc.2
IL_0076: ldloc.3
IL_0077: ldc.i4.0
IL_0078: call int32 [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Operators::CompareString(string,
string,
bool) The boolean value tells CompareString whether to compare the strings as text.
|
|
|
|
|
In C#, output parameters can be declared with "out" keyword ; parameter is then assigned in the method and passed by reference to the caller and doesn't have to be assigned by the caller as for "ByRef" VB keyword
In VB.NET, you must use "Property" keyword to explicitely declare a property and you must add "ReadOnly" ("WriteOnly") keyword if it is a readonly (writeonly) property ; in C# you don't.
yfoulon
|
|
|
|
|
One thing I never have figured out is why both VB.Net and C# allow for public implementation of interfaces.
Forget whether or not renaming a method implementation in VB.Net makes the implementation hard to find. You shouldn't be able to see interface methods unless you do a cast first. And if you do a cast you'll find the method is right where you expected it to be.
Unless people say that you can't find the implementation in the source code, well then I think they're nuts. In C# you need to remember the method of the interface to find it. In VB.Net you need to search for the implements keyword, but you can find things relatively easily. But this is a moot point. Most times the author knows where things are. And if you're not the author you are more likely just wanting to consume the class, not edit it.
VS.Net should force good OOP by making interface methods private. Why on earth would calling the method on the host class be a good idea?
|
|
|
|
|
See it this way.
You have an instance of some class and it happen to implement an interface you want to use as well, what do you do?
Anyway you could make them private in C# if you realy want to:
interface IFoo
{
void Bar();
}
class FooBar : IFoo
{
void IFoo.Bar() { }
}
This way you cannot write:
FooBar fb = new FooBar();
fb.Bar(); // <== error
instead you should write:
((IFoo) fb).Bar();
In fact you have an excellent common exemple with
System.IO.Stream : IDisposable
although Dispose() is not publicly visible.... (You have to use Close() instead)
|
|
|
|
|
Here's my classic example of why public interface implementations are bad. If I were a nasty coder I could make some poor programmer's life rather painful by purposly doing this. But worse, what if I did this accidently?
Public Interface IFoobar
Sub Foo()
Sub Bar()
End Interface
Public Class Foobar
Implements IFoobar
Public Sub Bar() Implements IFoobar.Foo
Debug.WriteLine("Foobar.Bar/IFoobar.Foo")
End Sub
Public Sub Foo() Implements IFoobar.Bar
Debug.WriteLine("Foobar.Foo/IFoobar.Bar")
End Sub
End Class
James.
|
|
|
|
|