 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / March 2008Syntax Difference C#/VB.NET when calling a Method
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 > 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 () [quoted text clipped - 6 lines] > > 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 :)  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk Thanks for the info! Mike > > 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 () [quoted text clipped - 14 lines] > to be able to miss off the brackets. In other words, it's just a matter > of taste :) 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/library/x2dbyw72(VS.71).aspx You might want to consider dropping the VB6 hangover naming conventions... but as most things, its your choice. .. Good luck. > Hi. I'm a VB.NET developer learning C#, and I have a simple syntax > question. [quoted text clipped - 11 lines] > Thanks! > Mike 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 :) > Between methods, properties, indexers, arrays , etc....the VB.NET style is > somewhat ambigious in my mind. [quoted text clipped - 33 lines] > > Thanks! > > Mike Array indexer in c# is [] and I can't imagine a "Read" property... > Yes, I'm appreciating the explicit nature as well. Having programmed in > only [quoted text clipped - 43 lines] >> > Thanks! >> > Mike > Array indexer in c# is [] and I can't imagine a "Read" property... > [quoted text clipped - 45 lines] >>> > Thanks! >>> > Mike I can imagine a Read property....where Read is pronounced "Red" ... but a proper name for a property that is a boolean state should be prefixed with Have, Is, Was, or Will (although, the latter is kinda crap IMO). So, HaveRead, IsReading, WasRead, WillRead.... (hmm, WillRead still sucks). lol HTH, Mythran 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). > Between methods, properties, indexers, arrays , etc....the VB.NET style is > somewhat ambigious in my mind. [quoted text clipped - 33 lines] >> Thanks! >> Mike 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... Signaturehttp://www.tangiblesoftwaresolutions.com 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 > 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 () [quoted text clipped - 9 lines] > Thanks! > Mike 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). > Hi. I'm a VB.NET developer learning C#, and I have a simple syntax > question. [quoted text clipped - 11 lines] > Thanks! > Mike > 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. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk > 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 [quoted text clipped - 3 lines] > ... 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. :-) > > 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. I don't think anyone's said they've found it impossible. They've just expressed their personal preference, and I don't see what's wrong with that. Do you really not think there's a difference between "I find it easier to tell the difference between a property and a method when a method call always has brackets and a property access never does" and "I find it 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 [quoted text clipped - 5 lines] > > Not at all Surely the word "over-zealous" implies that C# is being *too* zealous, i.e. that it is wrong to behave in the way it does. If you had suggested that C# was merely zealous, that would have not have been as judgemental IMO. > 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#. ... for someone who's never really coded before, yes. Using words instead of symbols has that effect, certainly. > 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 Ironically, when it comes to *placement* VB is sometimes fussier than C#. VB requires that you explicitly say when you want a statement to span more than one line. C# could care less whether you place the statement-terminating semi- colon on a line on its own, at the end of a line, of several (blank) lines later. It does require it to exist, however. > but rather on keeping the syntax closer to something a mere mortal can > understand, rather than just coders. :-) I tend to find that non-coders don't really *want* to read my code much - does your experience differ? It's an interesting dilemma though - do you design a language so that people can read it easily if they have no experience, or so that if they *do* have experience they can read it even more easily? Obviously going too far in either direction is a bad idea, but I think it's not unreasonable to think it owes something to heritage. I *suspect* that going back to C and VB "classic", most C developers who wrote any code as part of their job were writing code as *most* of their job. I believe, however, that many VB developers were writing VB as part of doing a different job - VB made their lives easier, but without them needing to get really interested in how it all worked. Before anyone gets worked up, I am *not* saying that this applied to all VB developers - but a far greater proportion than C programmers. I also believe this is part of why VB is able to reasonably claim it is the most popular programming language. I'd be interested to see how the numbers might change if "amount of time spent working with language" became part of the statistic. On a more general note, both languages have been getting more complicated - C# 3 is very significantly more complex than C# 1, to the extent that I have sympathy for anyone starting from scratch at this point. To a C# 1 programmer, a piece of code using query expressions, generics, iterator blocks and the like would be hard to understand (particularly in terms of deferred execution and other nuances). To an experienced C# 3 developer, it's likely to be significantly easier to understand than the semi-equivalent C# 1 code. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk > On a more general note, both languages have been getting more > complicated - C# 3 is very significantly more complex than C# 1, to the [quoted text clipped - 4 lines] > experienced C# 3 developer, it's likely to be significantly easier to > understand than the semi-equivalent C# 1 code. Wow, you hit the nail on the head about C#1 understanding C#3 code! I am finding it difficult to understand the C#3 code since I haven't been allowed to develop with it yet! :P It does look cool, but I don't have the time at home to jump in on it yet... Mythran > > On a more general note, both languages have been getting more > > complicated - C# 3 is very significantly more complex than C# 1, to the [quoted text clipped - 9 lines] > to develop with it yet! :P It does look cool, but I don't have the time at > home to jump in on it yet... Okay, I feel a shameless plug is justified here. My book, C# in Depth, is specifically written for people who already know C# 1 but want to learn C# 2 and 3 in a fair amount of depth: http://www.manning.com/affiliate/idevaffiliate.php?id=876_112 Out very soon... SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk Book Related- I know this is debated, but I really like when books cover both C# & VB.NET. I have one on generics I like: Professional .NET 2.0 Generics (Tod Golding) http://www.amazon.com/Professional-NET-2-0-Generics-Programmer/dp/B000PY4KPC/ref =dp_kinw_strp_1 I use C# for work and VB.NET for everything else. It's nice to see the syntax differences, especially for new language features. Schneider >> > On a more general note, both languages have been getting more >> > complicated - C# 3 is very significantly more complex than C# 1, to the [quoted text clipped - 19 lines] > > Out very soon... > Book Related- > I know this is debated, but I really like when books cover both C# & VB.NET. It's fairly simple for me - that's really good for people who use both C# and VB.NET, but a waste (and a distraction) for people who only use one or the other. I personally only use C# (other than answering an occasional newsgroup question about VB) so books with VB examples in aren't as helpful to me. There's also the potential risk of an author spreading themselves too thinly, in terms of not being sufficiently adept with *both* languages to really do them justice. But yes, I can quite see how it's really interesting for people who use both :) SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk >> Book Related- >> I know this is debated, but I really like when books cover both C# & [quoted text clipped - 14 lines] > But yes, I can quite see how it's really interesting for people who use > both :) Jon, if you included samples in both languages, you might not be able to call the book "C# In Depth". ;-) RobinS.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.