|
|
|
The XML-Comment in VB.NET are three ' like this :
'''<summary>My Summary is written here</summary>
|
|
|
|
|
[Visual Basic]
Public Class MouseEventArgs
Inherits EventArgs
Dim x As Integer
Dim y As Integer
Public Sub New MouseEventArgs(x As Integer, y As Integer)
me.x = x
me.y = y
End Sub
Public Property X As Integer
Get
Return x
End Get
End Property
Public Property Y As Integer
Get
Return y
End Get
End Property
End Class
[C#]
public class MouseEventArgs : EventArgs
{
int x;
int y;
public MouseEventArgs(int x, int y)
{ this.x = x; this.y = y; }
public int X { get { return x; } }
public int Y { get { return y; } }
}
|
|
|
|
|
...but it doesn't have to take up as much vertical space as you represent:
Public Class MouseEventArgs : Inherits EventArgs
Dim x, y As Integer
Public Sub MouseEventArgs(ByVal x As Integer, ByVal y As Integer)
Me.x = x : Me.y = y
End Sub
Public Property X() As Integer
Get
Return X
End Get
End Property
Public Property Y() As Integer
Get
Return Y
End Get
End Property
End Class
|
|
|
|
|
Actually, sometime i find the End Sub, End Class and etc kinda informative although it is verbose.
Normally, I would find it useful when i have tons of curly braces and compiler complaining for extra or lacking few curly braces (in C#) which I could missed out by accident. Although the IDE will do a good job in highlighting the opening and closing of braces (by placing the cursor after the curly brace) but thing solve quicker with End XXX sometimes.
I even sometime come to an extend to comment my closing curly braces in C# to have something like
}//end foreach (.....
Anyway, this is just me.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
I was looking for an article which would give an in depth knowledge about difference betn VB.NET and C#
Your article comparision for VB.NET and C# is a single stop for almost everthing about them
Great Job. Keep it up
|
|
|
|
|
function a(){ if (x==5) { switch(b) { 1: if (a==1) { ... }}}}}
One line of code only!
|
|
|
|
|
well....
stupid ppl write codes that not many ppl understand.
smart ppl write codes that everybody can understand.
well again, unless you're working in your own little world, tht's fine =)
why force yourself writing codes that shouldn't be in one line only?
don't you think it's kinda messy and make reader reluctant to read?
wht's your intention?
Rgds,
ksboy
hello world!
|
|
|
|
|
<br />
[C#]<br />
function a()<br />
{<br />
<br />
if (x==5) <br />
{ <br />
switch(b) <br />
{ <br />
1: if (a==1) <br />
{ <br />
...<br />
}<br />
}<br />
}<br />
}<br />
<br />
[Visual Basic]<br />
Private Function a() As Object<br />
If x = 5 Then<br />
Select Case b<br />
Case 1<br />
...<br />
End Select<br />
End If<br />
End Function<br />
<br />
If you wanted to make a point, that was a bad example.
Writing code in one line has no benefit other than low disk space (and page space) usage
on source code.
Yet a similar example to this could present a disadvantage in VB.NET
Some cases VB.NET won't return values from a function or sub directly into
your working code, thus the need of declaring variables to temporarely store the values
returned.
(i remember i was programming one day and i thought, wow i could write this in c# with a lot
less lines of code and performance issues)
|
|
|
|
|
What is the point of writing all that stuff in one line?
I personally prefer it to be nicely formatted so one can tell what is going on, regardless of the language.
I remember back in College I had an idiotic professor who used to teach us Java and would make this very long lines of code in this manner. I was young and learning and even then I still thought it was stupid and wondered why would someone would want to do that to themselves?
Juan Romero
Sr. Web Developer
|
|
|
|
|
This article compares VB to C# and most of the VB programmers here tend to say that VB is equal to C#.
So, how would you write this C# code in VB in one line of code?
|
|
|
|
|
When we compare VB to C# we talk about capabilities. How can you make a case based on syntax?
You can write two hundred instructions in one line but the resulting MIL code is [almost] the same.
Performance wise there are only minor, neglegible differences. Please take a second to read Microsoft's white paper on VB vs C#. As they state it, the difference is a matter of taste. Salary also plays a big role as for some reason statistically, C# developers are better paid than VB developers, but that is beyond the scope of this article.
Juan Romero
Sr. Web Developer
|
|
|
|
|
I disagree. We do indeed talk here about capabilities of C# versus VB.
Imagine you had the choice of communicating with somebody by using one of two languages.
Imagine that in language B, you would need twice the amount of sounds as in language A to express the same concepts (such languages do exist...).
I am sure that you would immediately choose language A to communicate!
(in case you knew language A...)
You wouldn't want to make your life harder, would you?
C# versus VB has also to do with readability and concision: '}' (closing curly brace) versus Endif, End Sub, End Function, End Case, Next, End Loop, etc, etc, etc... without talking about Dim, Dim, Dim, Redim, Function, Sub and all the useless rest.
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.
C# does not restrict me as a programmer as much as VB does. For example like I mentioned in my previous message, with lines holding several small instructions.
Here is an other example:
Casing: VB would not allow you to write a variable camel cased and another variable Pascal cased.
C# lets you do it.
If you do not understand what I mean, try to compile this in VB:
Public Class Class1
Dim count As Long
Property Count() As Long
Get
Count = count
End Get
Set(ByVal value As Long)
count = value
End Set
End Property
End Class VB cannot compile this. It would not even let you type it without messing it all up.
In C#:
public class Class1 {
int count;
public int Count {
get { return count; }
set { count = value; }
}
} And before flaming me by saying this is all useless, you must first learn that camel and Pascal casing is a way of discriminating members from properties in curly-braces languages, in some companies. It definetely has its purpose.
And VB lacks it.
Forget about VB, and use C#, C# rocks!
|
|
|
|
|
My dear friend,
In terms of readability and concision, I actually find VB to be better. While I do concede that VB is more verbose, it is this very same thing that makes it more understandable to the naked eye.
While curly braces may be more convenient in terms of length, I find them more confusing to follow, and to prove it, I will use YOUR example:
function a(){ if (x==5) { switch(b) { 1: if (a==1) { ... }}}}}
Count the curly braces at the end and you will see that you are missing an opening brace. Nevermind that, if I ask you what the 3rd curly brace closes, can you tell me without going over the code? Chances are you can't. In fact, many C# developers do this:
} // End for
} // End if
Which amounts to the same thing as VB.
Another point I forgot to bring up on my last post is that the reason why you can do this sort of thing (multiple inline statements) in C# is because of the terminating character [;]. VB's terminating character is the line break, hence, the need for multiple lines or an underline (_) to denote multiple lines of code. The compiler needs to know where to break each line. Some people find it to be a good thing, some people don't. In any event, if you want to write multiple instructions in one line in VB, you can always use the [:]. Again, a matter of taste.
As far as being able to see more lines of code in the screen, unless you still use a dinosaur in 800x600 display mode, I don't see why this should be a problem.
In terms of coding style (notation), I also find the case sensitivity fact to be an inconvenience. On this topic I can gladly say I am not alone, as this is one of the biggest complaints I have heard from C background people. You can easily make a mistake while typing and use the other one instead, or things will not compile because you have made this mistake.
VB will not let you type it without messing it up because it shouldn't. It takes care of the casing for you, which helps maintain code readability and consistence.
I personally prefer to prefix member variables with "m_" and use Camel notation. This clearly defines the scope of the variables within a class and if I am not mistaken is part of Microsoft's recommended coding standards.
Finally, with over 7 years of experience, a Bachellor's Degree in Computer Science, experience in Basic, Fortran, Pascal, Cobol, Fox Pro, C++, VB.NET and C# (and others), and after having worked in multiple big corporations (8000+ employees) I can tell you with confidence that I understand the benefits and downfalls of each, not only at the language level, but also at the compiler level. Granted, C# does have some features that I would want, but in the end in my personal opinion VB.NET has become a first level programming language with more benefits that C#, even though most of these benefits come from the IDE rather than the language itself (again, they pretty much do the same thing). The 2.0 (and consequently VS.NET 2005) version leverages on a lot of things for both languages, specially on the IDE side. It makes life easier for C# developers (which were at a loss with intellisense among other things) and it adds some important features to both languages. I think the arguments are going to be better than ever with it!
Dynamic arrays is one topic we did not discuss here but I find it to be a BIG plus in VB.NET. I wonder if v2.0 has done anything about that for C# developers? To be honest, I don't know. I haven't updated my C# skills lately.
Once again, a matter of taste in my opinion. Which weapon you choose makes little if no difference as they both fire the same bullet. I recall reading an article on this same subject in which the header went something like this:
"Choose your flavor, .NET Coke vs .NET Pepsi"
Juan Romero
Sr. Web Developer
|
|
|
|
|
Marc Greiner wrote: public class Class1 { int count; public int Count { get { return count; } set { count = value; } }}
This violates more than one good programming convention but the most glaring is that using the same name for more than one variable/object is like tossing in a bunch of "goto" statements. It is not only bad form, hard to read, harder to troubleshoot, it's just plain bad, I.E: worse than useless, its dangerous.
You can camel/pascal case in VB, with the added benefit of it not allowing you to break several good programming rules in the process.
This reminds me of those developers who love to name all their variables "x" or "myvar" and then re-use those same names all through their code for vastly different things.
|
|
|
|
|
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
|
|
|
|
|