: Just to be fair...
:
: _AnonCoward wrote:
:
: > If var1 = 1 Then
: > For Index = 0 to 10
: > If var2 = Index Then
: > DoThis
: > Else
: > Select Case var3
: > Case "A"
: > DoThisToo
: > Case "B"
: > DoThisInstead
: > End Select
: > End If
: > Next
: > End If
: >
: > compared to:
: >
: > if(var1 == 1){
: > for(Index = 0; Index < 11; Index++){
: > if(var2 == Index){
: > DoThis();
: > }else{
: > switch(var3){
: > case "A":
: > DoThisToo();
: > break;
: > case "B":
: > DoThisInstead();
: > break;
: > }
: > }
: > }
: > }
: >
: >
: > I personally like the VB examples as being cleaner and easier to read -
: > the curly braces in particular can be very confusing when you have
: > deeply nested logic. VB isn't without its difficulties in this respect,
: > but at least you can more quickly know if you're looking at the close
: > of an IF-THEN block or a SELECT-CASE block.
:
: But in C# most of those braces are optional. You could just as easily
: have written
:
: if(var1 == 1)
: for(Index = 0; Index < 11; Index++)
: if(var2 == Index)
: DoThis();
: else
: switch(var3) {
: case "A":
: DoThisToo();
: break;
: case "B":
: DoThisInstead();
: break;
: }
Yes, as long as there aren't any mutliline statements. The following
statements are not equivalent
if(test == 1)
doThis();
doThat();
if(test == 1)
{
doThis();
doThat();
}
I personally find it irritating to read C# code (or Java or JavaScript) that
doesn't consistently use curly braces. From my perspective it allows for
bugs to be introduced because a programmer inadvertantly fails to allow for
the fact that both lines are to be constrained by the conditional, not just
the first line. When I write in C# (infrequently) or JavaScript (very
frequently), I always use curly braces for just that reason (even single
statements). If I need to add a new statement to an existing code block, I
already have defined the limits of the conditional. If in the example you
offer I needed to also include an additional function call inside for loop
once the second conditional has been evaluated, I'll need to make the
following changes
if(var1 == 1)
for(Index = 0; Index < 11; Index++)
{
if(var2 == Index)
DoThis();
else
switch(var3) {
case "A":
DoThisToo();
break;
case "B":
DoThisInstead();
break;
}
doThisforEachLoop();
}
To do this, I had to spend some effort figuring out just where exactly the
for loop and second conditional statements were finished. That is time
consuming and potentially error prone as I may misread the original code. If
the {} were all ready in placed, the change would have been much simpler and
more likely to be correct the first time out.
: > But of course that is a purely subjective opinion based
: > on years of experience with VB versus C or its derivatives. C++ or Java
: > programmers would likely prefer the C# examples.
:
: Yes, I agree.
:
: > Further, the VB compiler is tolerant of the occasional wrong use of case
: > (e.g.: for Index as integer = 0 to 100 complies without issue, just as
: > it should). Sometimes, knocking out some quick code as a test is
: > helpful. You can dispense with worrying about caps in VB - but C#
: > (and C/C++ and Java) throw a fit if you type Console.WriteLIne instead
: > of Console.WriteLine - how ridiculous is that?
:
: But Intellisense makes this unlikely... in either language, you'd type
: Console.W, and use the up-and-down arrows to select WriteLine.
Agreed, if you are using intellisense. However, I sometimes bang out code in
a small module using notepad and the vbc or csc compilers. In C#, I have to
make sure I don't screw up my case statements. Further, intellisense only
goes so far and case errors do in fact creep in when using C# that would be
overlooked in VB.
: > Another problem with case sensitivity is that it can lead to the
: > introduction of hard to find bugs. For example, say you have two
: > variables myVar and myvar in a C# function. It is easy to accidentally
: > type myvar when you meant myVar (and vice versa) and locating the
: > inappropriate variable name can waste time that a VB coder doesn't
: > have to worry about.
:
: Sure, but the opposite problem exists with VB... if I try to declare
: two variables myVar and myvar in VB, I get an error:
: Local variable is already declared in the current block.
: It's all a matter of mindset. To be a good VB programmer, you have
: to think in VB; to be a good C# programmer, you have to think in
: C#. If a VB programmer thinks in C#, then even after all of the syntax
: and logic errors have been fixed, the code will "look" wrong... and
: vice-versa.
Yes, I agree. In the end, it's what you are used to and comfortable with.
: > (And let's
: > not even discuss how many times using = instead of == in logical
: > compares causes hours of wasted man hours trying to figure out why
: > a function isn't working correctly...)
:
: Yeah, that can be a problem.
:
: > When all is said and done, VB.net and C# are just languages - each do
: > pretty much the same things. Both languages bring strengths and
: > weaknesses to the table and neither is inherently better than the
: > other - it usually comes down to personal preference as to which
: > language is used.
:
: Yes.
:
: > Frankly, it sounds like your co-worker is a language bigot.
:
: But this is nothing new. Ever since there were two "high-level
: languages" (COBOL and Fortran), there have been people sneering
: at others who used the "wrong" language. They were wrong then,
: too.
:
: Back in the days of Visual Basic 3, the choice between the two
: languages was much more fundamental. There was a basic
: tradeoff -- VB was considered by most knowledgable people to
: be the "Rapid Development" system because it was easy to
: throw a few controls onto a form and wire them together. But
: VB programs loaded and executed much more slowly. If your
: program had to load and run quickly or use fewer resources,
: or if you wanted to accomplish things that couldn't be done in
: VB, then C++ was the way to go. On the other hand, it usually
: took a lot longer to get a C++ program written and debugged.
:
: This distinction is gone now. Almost every significant
: capability in either language has been added to the other,
: and they now have the same back-end (.NET). There are
: probably a few exceptions, but for most business programs,
: developers knowledgable in either language should take
: about the same amount of time to develop and debug the
: program, and they should be virtually identical when running.
: This is excellent for managers -- they can now pick a language
: based on what type of talent they have available, rather than
: having to do research about which development environment
: is more appropriate and then searching for someone competent
: in that language.
Yes. The different .net languages are very close to one another. I prefer
VB.net in part because I believe it is a better contruct but mostly because
I come vrom a VB6 background. Thanx for the input.
Ralf
