|
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.
|
|
|
|
|
mhhh... this sort of accident can't happen in C#.
I mean it can happen in C#, but that would be no accident.
Anyway why should interface implementation be private?
Not only it is NOT specifically OO.
but it's like saying:
DataObject should not hane its GetData(), GetFormat() and IsDataPresent() because they are defined in IDataObject...
Let me tell you, that would just make the API way messier....
|
|
|
|
|
I agree with you super lloyd. I mean, implementing an interface is a "promise" like a contract between the callee and the caller, that the callee would have a certain set of methods. I don't see what the problem is there.
I'm have mainly worked with Java, but that VB example, that the function signature of the implementing class, is actually implementing another method in the interface. That seems really f*cked up to me. When would you ever want to do such a thing?
|
|
|
|
|
Thanks for the article.
Isn't the ability to program in C# using ordinary text editors and command-line compilation unique to C# ? Whereas VB.NET requires Visual Studio. Shouldn't this feature be listed among the advantages of C# ? Sometimes it's easier to get started with a minimal environment...
|
|
|
|
|
I think VB.NET can be coded using notepad too. It's not dependent on VS.NET.
Some VBers are dependent on VS.NET though and a few C#ers too
|
|
|
|
|
There isn't a commandline based VB.NET compiler but there is a C# one. So VB.NET depents on VS.
Correct me if i'm wrong!
|
|
|
|
|