[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework

Syntax Difference C#/VB.NET when calling a Method

Mike

3/7/2008 6:59:00 PM

Hi. I'm a VB.NET developer learning C#, and I have a simple syntax question.
In C# whenever you invoke a method you need to include the parentheses ()
after the method name even if there are no parameters. In VB.NET you don't
have to do this. For example -

IDataReader oReader;
while (oReader.Read) //This will throw an exception
while (oReader.Read()) //This is the correct way.

I'm just curious why C# requires this but VB.NET does not.

Thanks!
Mike
17 Answers

Jon Skeet

3/7/2008 7:06:00 PM

0

Mike <Mike@discussions.microsoft.com> wrote:
> Hi. I'm a VB.NET developer learning C#, and I have a simple syntax question.
> In C# whenever you invoke a method you need to include the parentheses ()
> after the method name even if there are no parameters. In VB.NET you don't
> have to do this. For example -
>
> IDataReader oReader;
> while (oReader.Read) //This will throw an exception
> while (oReader.Read()) //This is the correct way.
>
> I'm just curious why C# requires this but VB.NET does not.

VB has traditionally not required it, but C-like languages (C, C++,
Java) have all required brackets for function/method calls.

Personally I like this explicit nature, differentiating between
property access and method calls, but no doubt a lot of VB-ers prefer
to be able to miss off the brackets. In other words, it's just a matter
of taste :)

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.... Blog: http://www.msmvps.com...
World class .NET training in the UK: http://iterativetrai...

Mike

3/7/2008 7:13:00 PM

0

Thanks for the info!

Mike

"Jon Skeet [C# MVP]" wrote:

> Mike <Mike@discussions.microsoft.com> wrote:
> > Hi. I'm a VB.NET developer learning C#, and I have a simple syntax question.
> > In C# whenever you invoke a method you need to include the parentheses ()
> > after the method name even if there are no parameters. In VB.NET you don't
> > have to do this. For example -
> >
> > IDataReader oReader;
> > while (oReader.Read) //This will throw an exception
> > while (oReader.Read()) //This is the correct way.
> >
> > I'm just curious why C# requires this but VB.NET does not.
>
> VB has traditionally not required it, but C-like languages (C, C++,
> Java) have all required brackets for function/method calls.
>
> Personally I like this explicit nature, differentiating between
> property access and method calls, but no doubt a lot of VB-ers prefer
> to be able to miss off the brackets. In other words, it's just a matter
> of taste :)
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.... Blog: http://www.msmvps.com...
> World class .NET training in the UK: http://iterativetrai...
>

sloan

3/7/2008 7:16:00 PM

0


Between methods, properties, indexers, arrays , etc....the VB.NET style is
somewhat ambigious in my mind.
And I also appreciate the more explicit nature of C#.


while(dataReader.Read())
I know its a method.

with
while(dataReader.Read) .. I don't know if its a property or method.....


...........

Also
http://msdn2.microsoft.com/en-us/librar...(VS.71).aspx

You might want to consider dropping the VB6 hangover naming conventions...
but as most things, its your choice.

...

Good luck.





"Mike" <Mike@discussions.microsoft.com> wrote in message
news:B3A410F8-F317-4D80-A09D-AF2C1F63A323@microsoft.com...
> Hi. I'm a VB.NET developer learning C#, and I have a simple syntax
> question.
> In C# whenever you invoke a method you need to include the parentheses ()
> after the method name even if there are no parameters. In VB.NET you
> don't
> have to do this. For example -
>
> IDataReader oReader;
> while (oReader.Read) //This will throw an exception
> while (oReader.Read() ) //This is the correct way.
>
> I'm just curious why C# requires this but VB.NET does not.
>
> Thanks!
> Mike


Mike

3/7/2008 7:37:00 PM

0

Yes, I'm appreciating the explicit nature as well. Having programmed in only
VB for a few years, it's taking some getting used to. But personally I'm
finding it much easier to look at and quickly read C# because of this.

I'll probably be adding those () into my future VB methods as well :)

"sloan" wrote:

>
> Between methods, properties, indexers, arrays , etc....the VB.NET style is
> somewhat ambigious in my mind.
> And I also appreciate the more explicit nature of C#.
>
>
> while(dataReader.Read())
> I know its a method.
>
> with
> while(dataReader.Read) .. I don't know if its a property or method.....
>
>
> ...........
>
> Also
> http://msdn2.microsoft.com/en-us/librar...(VS.71).aspx
>
> You might want to consider dropping the VB6 hangover naming conventions...
> but as most things, its your choice.
>
> ...
>
> Good luck.
>
>
>
>
>
> "Mike" <Mike@discussions.microsoft.com> wrote in message
> news:B3A410F8-F317-4D80-A09D-AF2C1F63A323@microsoft.com...
> > Hi. I'm a VB.NET developer learning C#, and I have a simple syntax
> > question.
> > In C# whenever you invoke a method you need to include the parentheses ()
> > after the method name even if there are no parameters. In VB.NET you
> > don't
> > have to do this. For example -
> >
> > IDataReader oReader;
> > while (oReader.Read) //This will throw an exception
> > while (oReader.Read() ) //This is the correct way.
> >
> > I'm just curious why C# requires this but VB.NET does not.
> >
> > Thanks!
> > Mike
>
>
>

schneider

3/7/2008 8:08:00 PM

0

Array indexer in c# is [] and I can't imagine a "Read" property...


"Mike" <Mike@discussions.microsoft.com> wrote in message
news:31ACF0A8-E79E-4FFA-BF40-9ADB97743371@microsoft.com...
> Yes, I'm appreciating the explicit nature as well. Having programmed in
> only
> VB for a few years, it's taking some getting used to. But personally I'm
> finding it much easier to look at and quickly read C# because of this.
>
> I'll probably be adding those () into my future VB methods as well :)
>
> "sloan" wrote:
>
>>
>> Between methods, properties, indexers, arrays , etc....the VB.NET style
>> is
>> somewhat ambigious in my mind.
>> And I also appreciate the more explicit nature of C#.
>>
>>
>> while(dataReader.Read())
>> I know its a method.
>>
>> with
>> while(dataReader.Read) .. I don't know if its a property or method.....
>>
>>
>> ...........
>>
>> Also
>> http://msdn2.microsoft.com/en-us/librar...(VS.71).aspx
>>
>> You might want to consider dropping the VB6 hangover naming
>> conventions...
>> but as most things, its your choice.
>>
>> ...
>>
>> Good luck.
>>
>>
>>
>>
>>
>> "Mike" <Mike@discussions.microsoft.com> wrote in message
>> news:B3A410F8-F317-4D80-A09D-AF2C1F63A323@microsoft.com...
>> > Hi. I'm a VB.NET developer learning C#, and I have a simple syntax
>> > question.
>> > In C# whenever you invoke a method you need to include the parentheses
>> > ()
>> > after the method name even if there are no parameters. In VB.NET you
>> > don't
>> > have to do this. For example -
>> >
>> > IDataReader oReader;
>> > while (oReader.Read) //This will throw an exception
>> > while (oReader.Read() ) //This is the correct way.
>> >
>> > I'm just curious why C# requires this but VB.NET does not.
>> >
>> > Thanks!
>> > Mike
>>
>>
>>


David Anton

3/8/2008 12:22:00 AM

0

The VB language designers have always been way too accommodating. Even more
confusing is that you can also include an empty argument list on property
calls - which makes the immediate visual distinction between a call to a
method without parameters and a property even more difficult. I've seen VB
code where the property calls looked like method calls and the method calls
looked like property calls...
--
http://www.tangiblesoftwaresol...
C++ to C#
C++ to VB
C++ to Java
Java to C#
Java to VB
Instant C#: convert VB to C#
Instant VB: convert C# to VB
Instant C++: VB, C#, or Java to C++/CLI


"Mike" wrote:

> Hi. I'm a VB.NET developer learning C#, and I have a simple syntax question.
> In C# whenever you invoke a method you need to include the parentheses ()
> after the method name even if there are no parameters. In VB.NET you don't
> have to do this. For example -
>
> IDataReader oReader;
> while (oReader.Read) //This will throw an exception
> while (oReader.Read()) //This is the correct way.
>
> I'm just curious why C# requires this but VB.NET does not.
>
> Thanks!
> Mike

Willy

3/8/2008 1:07:00 PM

0

The ambiguity existed in VB6 with default properties but there is nothing
ambiguous about the syntax in VB.NET - it's just different.
Again a matter of taste but in VB.NET they have chosen to make the most
common behavior (calling the method) simpler by not requiring the parens.
The less common behavior (passing a function pointer) requires an additional
keyword (addressof)

I personally like this (although I find *addressof* a little too
"implementation-oriented" as a keyword - after all if you pass an object to
a function you're also passing it's address. I guess they did it because
the same keyword existed in VB6).

"sloan" <sloan@ipass.net> wrote in message
news:ep8XPdIgIHA.5260@TK2MSFTNGP03.phx.gbl...
>
> Between methods, properties, indexers, arrays , etc....the VB.NET style is
> somewhat ambigious in my mind.
> And I also appreciate the more explicit nature of C#.
>
>
> while(dataReader.Read())
> I know its a method.
>
> with
> while(dataReader.Read) .. I don't know if its a property or method.....
>
>
> ..........
>
> Also
> http://msdn2.microsoft.com/en-us/librar...(VS.71).aspx
>
> You might want to consider dropping the VB6 hangover naming conventions...
> but as most things, its your choice.
>
> ..
>
> Good luck.
>
>
>
>
>
> "Mike" <Mike@discussions.microsoft.com> wrote in message
> news:B3A410F8-F317-4D80-A09D-AF2C1F63A323@microsoft.com...
>> Hi. I'm a VB.NET developer learning C#, and I have a simple syntax
>> question.
>> In C# whenever you invoke a method you need to include the parentheses ()
>> after the method name even if there are no parameters. In VB.NET you
>> don't
>> have to do this. For example -
>>
>> IDataReader oReader;
>> while (oReader.Read) //This will throw an exception
>> while (oReader.Read() ) //This is the correct way.
>>
>> I'm just curious why C# requires this but VB.NET does not.
>>
>> Thanks!
>> Mike
>
>

Alex Clark

3/8/2008 6:56:00 PM

0

Many people seem to be implying that it's wrong for VB.NET to have ambiguity
between property and method calls (by virtue of optional parentheses), but
it really doesn't matter IMO.

C# is not a naturally readable language the way VB.NET is, so explicit &
strict syntax is a necessity. VB.NET tends to be more concerned with
describing what the code itself is doing rather than over-zealous
punctuation.

In the example of DataReader.Read, where the following VB syntax is
acceptable...

While rdr.Read
..do stuff
End While

I don't find myself looking at the call to .Read and thinking "Oh no, I
can't tell whether that is a property or a method, however am I to determine
what the code is doing?!". I can clearly see it's a call that returns a
boolean value. Whether that's a property or a method call is largely
irrelevant, and when all is said and done properties are just syntactical
wrappers around methods and functions anyway. In this case, even if .Read
were a function, it would just be a redirected call to a function (get_Read
As Boolean).




"Mike" <Mike@discussions.microsoft.com> wrote in message
news:B3A410F8-F317-4D80-A09D-AF2C1F63A323@microsoft.com...
> Hi. I'm a VB.NET developer learning C#, and I have a simple syntax
> question.
> In C# whenever you invoke a method you need to include the parentheses ()
> after the method name even if there are no parameters. In VB.NET you
> don't
> have to do this. For example -
>
> IDataReader oReader;
> while (oReader.Read) //This will throw an exception
> while (oReader.Read()) //This is the correct way.
>
> I'm just curious why C# requires this but VB.NET does not.
>
> Thanks!
> Mike


Jon Skeet

3/8/2008 7:20:00 PM

0

Alex Clark <alex@microsoft.com> wrote:
> Many people seem to be implying that it's wrong for VB.NET to have ambiguity
> between property and method calls (by virtue of optional parentheses), but
> it really doesn't matter IMO.

I believe most people have actually said it's a personal preference,
whereas with this:

> C# is not a naturally readable language the way VB.NET is, so explicit &
> strict syntax is a necessity. VB.NET tends to be more concerned with
> describing what the code itself is doing rather than over-zealous
> punctuation.

.... it seems to me that *you're* claiming C# is wrong to behave the way
it does.

To me, C# is more readable than VB. To others, VB is more readable than
C#.

That's fine. It would be odd to expect everyone to have the same
preferences when it comes to programming languages. The good thing is
we can each use the language we prefer, and still interoperate easily.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.... Blog: http://www.msmvps.com...
World class .NET training in the UK: http://iterativetrai...

Alex Clark

3/8/2008 8:23:00 PM

0

> I believe most people have actually said it's a personal preference,

Well, depending on how you interpret it, many have stated that their
personal preference is for the "less ambiguous, more precise" nature of C#'s
parenthesising, almost as though it's impossible to determine what a piece
of code is doing when the () suffix to a method call is optional.


>> C# is not a naturally readable language the way VB.NET is, so explicit &
>> strict syntax is a necessity. VB.NET tends to be more concerned with
>> describing what the code itself is doing rather than over-zealous
>> punctuation.
>
> ... it seems to me that *you're* claiming C# is wrong to behave the way
> it does.

Not at all, but if you code one routine in both C# and VB.NET and hand them
over to someone who's never really coded before, I would wager they're a lot
more likely to understand what the VB.NET code is doing than the C# code ---
precisely because VB.NET is, by its very nature, a much more naturally
readable language than C#. This doesn't make it better or worse than C#,
but it does mean that its focus is not on ensuring every semi-colon is
perfectly placed but rather on keeping the syntax closer to something a mere
mortal can understand, rather than just coders. :-)