|
You can also use the OrElse keyword.
Tomer Pintel
|
|
|
|
|
I think you might be interested in checking out VB's short-circuit boolean operators, namely AndAlso and OrElse. They allow the same type of logic you are refering to.;)
|
|
|
|
|
Is it still so in VB.NET that you cannot have an instruction span over several lines without having to add this horrible "_" character at the end of every line?
If this is still the case, forget about VB (Net or not).
|
|
|
|
|
As far as I know yes.
Briga
|
|
|
|
|
In case of a multi-line instruction, how could I add a comment at the end of each line?
In all previous versions of VB, this is totally impossible but absolutelly no problem in any other C, C++, Java, C#, etc. language.
I would like to be able to do so in case, for example, where I have a function call with several parameters, and some of them need a small comment at the end:
Public Sub ActualizePersInfo(ByVal strPersID As String, _<br />
ByVal datFrom As Date, _ 'Some comment. Impossible here...<br />
ByVal datTo As Date, _<br />
ByVal blnIsImportant As Boolean)
|
|
|
|
|
I don't like such commenting (at the end/middle of the parameters) Use good parameter names that explains itself. Do refactoring. Spend some time to do this and for good names when naming params, vars, methods and classes et.al.
...Ashok
|
|
|
|
|
This thread is about how C# (and C, C++, Java and the like) easily allows multi-line instructions + commenting in between, and not necessarily commenting at the end of the line (which both VB cannot do).
I have met several cases where it would have been usefull for me to be able to put a short comment at the end of a multi-line instruction and I could not do it. I am not speaking of comments regularily put at the end of the line, which I do also dislike, as you do.
|
|
|
|
|
Yes, but you dont have to write the ";"
|
|
|
|
|
Unfortunately, yes, and I see absolutely no reason for it.
Before anyone argues that because VB.NET doesn't have block containers, the compiler couldn't figure out when a line is continued without the "_" token, I beg to differ.
Python has a similar "by-line" syntax (like VB) rather than a "by-statement" syntax (like C#), and it allows line continuations. For example, Python allows this:
<br />
def someFunction(arg1,<br />
arg2,<br />
arg3):<br />
print "I do nothing"<br />
|
|
|
|
|
Is it still so in C# that if you have an instruction that spans a single line you need to indicate this by a semicolon?
Honestly, on average if I code 100 lines of code roughly 5 lines span over more than one line.
So in C# I need 95 semicolons, in VB I need 5 underscores.
I'm not saying that VB's technique is better, but to suggest it is worse sounds a bit silly to me.
Eric Roosendaal
VB and C# instructor
|
|
|
|
|
Let me explain myself a bit more, for you to understand the problem:
In VB, have you ever tried to type something at the right side of an "_" ?
In fact, it is totally impossible (please, read my second (under-) message in this topic, about comments in code).
The semicolon ";" in all C-based languages (C#, C++, Java, etc.) solves syntatically elegantly two functions:
1) In C#: Long lines instructions can be cut in as many bits as necessary, without any special character or formating. I can also add comments wherever I want.
This is in some cases hard to achieve elegantly in VB: The number of lines per instruction is limited (VB6: limit = 15 lines). Comments: impossible (not even one).
I could almost hear you: 15 lines of code for one instruction, this is not good programming.
Sorry, but have you ever, for example, build a dynamic SQL command? I am sure you have.
That's where I reached the VB-limit for the first time...
Indeed, some SQLs can be very long, and for the sake of readability, it is so good to be able to dispatch then on several lines.
2) In C#: Several short instructions can be put on one line.
VB can do that, with the help of another character: ":"
By the way, why do differently from all the others and take ":" instead of ";"?.
But with ":", the editor performs some special formating, which is not always welcomed... (characters get lost/eaten, for example).
And if you start mixing "_" and ":", you might get into some strange editor problems... (VB6 at least, as for VB.Net, I hope to never have to figure out...).
Actually, what is disturbing in VB is that the line-ending is implicit.
Would you imagine a book author writing a book without "." to delimit sentences? No!
As for the verbose point:
If you really want to count the characters needed to programm and compare which of VB and C# are less verbose, let's go and start it!
How many times did you type the "Dim" keyword in C#? None indeed.
And what about those other VB exclusiv and useless "reserved words" over which my eyes constantly need to pass over, to try understand this silly programm I need to maintain :
- Function
- Sub
- End Function
- End Sub
- Call Sub()
- Dim, Dim, Dim, Dim (and the light goes off).
- As, As, As, As...
- Let
- Set
- Property
- And / Not / Or (not to mention the silly logic of them!)
- Nothing, Empty
- EndIf ElseIf
- Do Loop While Whend (at least one or two of them do not bring anything).
- Have I forgoten one of them?
Conclusion:
VB didn't bring anything by introducing the "_" to work-around long lines of code.
|
|
|
|
|
I personally like both VB and C#
In C# if you have a block of code like this one:
function a()
{
if (x==5)
{
switch(b)
{
1:
if (a==1)
{
...
}
}
}
}
}
In VB it would look like
Function a()
If x=5
Select Case b
Case 1
If a=1 then
Endif
End Select
End If
End Function
Placing a line place in the wrong block is less likely as each block is clearly named.
Also, the VB syntax is slightly more robust as it syntaxically check what the block us.
Finally, the vb code is more compact, I personally don't think that lines containing a single character { add any meaning
|
|
|
|
|
How would I type this in VB?
function a(){ if (x==5) { switch(b) { 1: if (a==1) { ... }}}}}
One line of code only! Freedom of C#. No chains and limits of VB-scripting dialect syntax.
|
|
|
|
|
Test for an object variable that does not refer to an object:
The correct VB.Net syntax is
obj Is Nothing
|
|
|
|
|
"The VB.NET parts of Visual Studio .NET compiles your code in the background."
Is it possible to turn this off?
|
|
|
|
|
No... This is part of what makes VB, well, VB.
|
|
|
|
|
I came across one C#/VB.NET difference that actually became cricial for the project.
Being close to its predecessor, VB.NET allows you to
create (COM) objects even if you do not have a COM wrapper.
In short, I had to send an e-mail from C# code using CDO, and
I could not use either CDO itself or its type library.
VB.NET allows you to
iMsg = CreateObject("CDO.Message")
iConf = CreateObject("CDO.Configuration")
and, more importantly, does not object when you call methods
on these objects, which are - here is the trick - unknown to the
compiler, like:
Flds = iConf.Fields
' set the CDOSYS configuration fields
With Flds
.Item("...") = cdoSendUsingPort
' . . . <whatever is necessary>
.Update()
End With
and (assuming that strings ToWhom, From, Subject and strHTML are
filled in properly):
With iMsg
.Configuration = iConf
.To = ToWhom
.From = From
.Subject = Subject
.HTMLBody = strHTML
.Send()
End With
The point is that VB, as opposed to C#, did not require
CDOSYS.dll's RCW (run-time callable wrapper) and accepted
iMsg.Subject and others happily.
One may consider this as a drawback (type safety is the victim)
or a plus (feel free to program whatever you want as long as
you know what you are doing), I let the readers decide for
themselves.
|
|
|
|
|
For what it's worth, you can still late binding in C#, you just have to use reflection. Things can be made a bit simpler by using the Microsoft.VisualBasic reference from C#. I saw a blog post on this: http://swigartconsulting.blogs.com/tech_blender/2005/03/c_late_binding.html
Nonetheless, it's still a lot easier to do in VB.
|
|
|
|
|
> you just have to use reflection
... and how big this "if" is, depends on the project.
It was big enough in my case.
> ... simpler ... using the Microsoft.VisualBasic reference
True, but at this time what we are comparing is the
_languages_, not workarounds.
I went from C# to unmanaged C++ and back when I needed to,
but was it simple? No, it was not.
BTW, I am too lazy to check: did the author mentioned one
more important difference - VB.NET allows you
to filter exceptions better, than C#.
The "When" part of a construct
Catch ... As ... When
is not available in (my beloved) C#.
|
|
|
|
|
"Various legacy VB functions (provided in the Microsoft.VisualBasic namespace, and can be used by other languages with a reference to the Microsoft.VisualBasic.dll)."
The VB namespace is not only about compatibility with previous versions of VB. These methods exist to enhance the framework and they should be considered part of the .NET Framework.
"The .NET Framework class libraries contain functions and subroutines designed specifically for Visual Basic .NET programmers. These methods provide functionality not found in other places in the Framework, or they provide functionality that is compatible with previous versions of Visual Basic. Although they are designed for Visual Basic .NET programmers, they are usable by any language supported on the .NET Framework and are considered part of the Framework. They will always be available anywhere the .NET Framework is installed." -- Paul Vick, The Visual Basic .NET Programming Language, Lead Language Designer of Visual Basic .NET
"Many of these can be harmful to performance if used unwisely, however, and... "
Although what you say is technically true, the statement comes across as making the *whole" namespace "useless". There are some areas in this namespace where performance, well, sucks. For example the FileXXX methods. However, there are some methods that pretty much blow the doors off of the methods in the System namespace. Such as Microsoft.VisualBasic.Strings.Split vs. System.Text.RegularExpressions.RegEx.Split when wanting to split a string using multiple-character delimiters. When using single character delimiters, System.String.Split is faster (For "proof", see http://www.addressof.com). There are other areas in this namespace, when used with the VB compiler, that are actually optimized by the compiler. For example, I've seen Microsoft.VisualBasic.Strings.Asc be treated differently in certain circumstances once the code has been compiled to CIL. My point here is that this statement can be applied to *ANYTHING* in the .NET Framework, isn't localized to Microsoft.VisualBasic methods and isn't a blanket statement on all methods in this namespace; as such, shouldn't even be mentioned in this context.
"...many people believe they should be avoided for the most part."
This is because of people like you regurgitating information about methods contained in the Microsoft.VisualBasic namespace that other people before you have stated... and for the most part... are false, anti-VB statements by people who aren't interested in VB to begin with. Many of these people who state this haven't explored the performance and make an assumption based on false information, or more likely, because the namespace includes the words Visual Basic.
Also, keep in mind that the number of useful features within the Microsoft.VisualBasic namespace will increase significantly in .NET 2.0.
Someone mentioned that this article was a little biased toward VB... my opinion is that it's biased against VB with all of the "advantages" carrying a disclaimer attached to each one. "It has this... but don't use it" sort of verbiage.
|
|
|
|
|
Evaluate an object expression once, in order to access multiple members
Although there is no built-in functionality, you can generate exactly the same code by using a local variable to store the reference:
[Type] o = objExpr [.member] [.member];
Reallocate array
The ReDim keyword in VB is directly equivalent to assigning a new array:
a = new int[5]; The ReDim Preserve statement is only slightly more complicated:
int[] temp = new int[5];
Array.Copy(a, temp, 5);
a = temp;
Exponentiation
Whilst there is no built-in exponentiation operator, the Math.Exp function performs the same task.
Parameter Passing by Value / Reference
"Note that there is no way to pass reference types (objects) strictly by value."
This applies to VB as well. The only difference is that VB allows you to call a method with ByRef parameters as though they were ByVal . For example:
Sub Test(ByRef i As Integer)
i += 5
End Sub
Dim i As Integer = 0
Test(i)
Console.WriteLine(i) ' Prints 5
Test((i))
Console.WriteLine(i) ' Still prints 5 To achieve the same effect in C#, you would need to use a temporary variable to pass a copy of the data to the method. This is what VB is doing behind the scenes - compiling the example above and viewing it with Reflector[^] produces:
int num1 = 0;
App.Test(ref num1);
Console.WriteLine(num1);
int num2 = num1;
App.Test(ref num2);
Console.WriteLine(num1);
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
|
|
|
|
|
C# supports operator overloading but vb doesn't.
|
|
|
|
|
One more addition, VB.NET supports parameterized properties while C# doesn't.
|
|
|
|
|
C# supports operator overloading but vb doesn't.
|
|
|
|
|
Look's like comparation oriented to prise VB: just look on VB comments and C#. To biased. You forgot to concentrate on the biggest advantage C# (witch derrived from C++): code structure and language symantics force you to use OOP basics and write a better, clearer code than in VB.
Two bee or not two bee?
|
|
|
|
|