I am new to developing with Visual Basic, but have lots of experience in C#/C/C++/JAVA/Haskell and a few others.
Is there some reason I am maintaining code and finding code examples where the type declaration just seems lazy? I have seen countless Strings, that are only ever used as the String type, declared as an object. Before the object oriented features of VB.NET came in, was this necessary to assure that methods could take in multiple types? Why would anyone do this?
At a guess...laziness and old VB6 habits being carried forward.
In VB6 there was the variant type that could take in various types and it was meant to be used with caution and care. When .Net came out the only conversion for that (besides changing your code a lot) would to have used object as the type.
I would definitely call it a hangover effect or code conversion effect from VB6 if the code appears to need that flexibility as you described for a method to take in multiple types.
However, if you are seeing code for string types that were declared as objects this is far worse than just laziness and a hangover from VB6! It sounds like horribly poor design and a lack of care.
Some VB6 experts, for instance "the Mandelbrot Set", advised using Variants for all variables. You could call it early duck typing?! This was rather controversial - many of us thought it was a recipe for disaster.
But there must be a lot of code like this out there. Before modern conversion tools appeared, upgrading it to VB.NET would be very hard. The Visual Studio upgrade tool simply panics every time it sees a Variant. If you really, really needed to upgrade with limited resources, I suppose changing all variants to Object might be the least-bad option. Obviously the resulting code would be horrible.
You could gradually refactor. When you work on an area of code, you could change the declarations to a more specific type.
Related
I've used Teleflex, developerfusion, and SharpDeveloper, and all these, to convert C# to VB, but as most know, there are always errors, and modules left out, and such.
Does anybody know of a good VB editor, preferably freeware, and can handle translated VB and offer suggestions to correct it for you?
Visual Studio underlines things and offers suggestions on some things, but other things it just underlines and leaves you to the guesswork, which doesn't help a non-coder like me.
Non-coders shouldn't be translating C# to VB.
No code translator will take care of everything for you. Even if it works programmatically, there are design patterns and code standards that are different for each language. Hire a programer.
No. And it's not always possible to convert C# to VB. Some features of C# have no equivalent in VB.
Unsafe code (e.g. pointers)
Iterators (yield)
Conversely some features of VB have no equivalent in C#.
Exception filters
XML literals
Why do you need to convert the code anyway? What's the business case?
VB and C# are different langages, so even the best translator in the world will miss some things. The person doing the translation shouldn't be a "non-coder" and should know at least some VB, so when a compile error is shown, he knows what to do with it, or at least knows how to search on the web (or ask on SO) to know how such part of code can be translated to VB.
Although vb.net and C# are both designed around the same .net framework, and consequently feature very similar features that work mostly the same way, many corner cases are handled differently by the two languages. While one could argue ad nauseum about whether a statement like myStruct = new myStructType(someParams) should affect the value of myStruct before the constructor completes (in C#, it does not; in vb.net, it does), and it's probably good to avoid designing code around corner cases, it's doubtful that any translator--much less a freeware one--will detect all of the corner cases and ensure that code which (possibly accidentally) relies upon them will still run correctly.
Which one would you prefer to extract a sub-string from the given string and why?
I am thinking that since Left and Right are VB functions and not .NET functions, they may cause problems in the future in terms of compatibility.
Please clarify my thoughts on that.
Use whichever makes most sense i.e. makes that piece of code easier to read.
I don't know why you'd think that they'd cause problems in the future, they're functions, they're provided as part of the VB.Net Language set, there is no earthly reason why they would be removed, and even if they were, they would be trivial to re-implement.
Use 'em, cause you ain't gonna lose 'em
When given the choice between a feature that is from Microsoft.VisualBasic vs a comparable feature that is provided in the core framework assembiles, I tend to stick with the latter in most cases.
I do this for various reasons:
It tends to be understood by more developers. (e.g. C# guy looking at my VB.NET code).
You're more likely to find online help (message boards, stackoverflow, etc) for the core framework version than you are for the VB-ized version.
Using them gives your code a "legacy" feeling to it. It's like making use of the Call statement.
Makes it easier for another person to "copy and paste" VB.Net code into their C# (or other .NET language) project and have it be one less language translation point/hangup. (Unlikely this is a real concern/reason, but I know I've many-a-time "copy and pasted" example C# code into my VB.Net project and anything that doesn't cause road blocks in the translation process (e.g. usage of yield) makes my life easier.)
While completely inconceivable they are going away (as most of these keywords/statements are a BASIC language construct), they do feel more likely to become marked obsolete than any of their core framework counterparts. Especially as VB6 is becoming more and more of a distant memory and the VB.NET language takes on a life of its own in conjunction with the core .NET framework advancing.
One notable exception to this, I tend to make use of the My namespace proxies offered; My.FileSystem.ReadAllText(...) is just sexy. :P
Do you work alone?
If no, the decision is simple.
If your team members have C# background, use Substring.
If your devs have some VB6 background, use Left and Right.
If you ain't sure, ask them.
.net SubString will throw if start + length is > than the string length where VB Left() will return the entire string if a length greater than the string length is provided. That's a substantial behavioral difference.
Also, given .Net Standard, avoid Microsoft.VisualBasic.
Yes, I know this is > 10 years old, but ended up here when trying to port some really old code. So, thought I'd share the difference.
I'm working on a project with a contractor we hired to do some VB.Net programming. I used to program for this project, but I have more recently become primarily the project manager so I can work on other issues I have. His method of programming differs greatly from what I was taught in school. The only time he uses classes is basically in the form of a sort of dataset (not an actual dataset, as I learned how to use in school). As an example, there's the cEmployee class, where he creates a class for an Employee, and in that he defines all the fields an employee has.
All functions are put in Modules. So if he has several functions to populate a combo box, they all go in the combo box module. My understanding on this though is that when the program is run, the modules are treated as global functions and included regardless of whether or not they are actually used on a form. To me this sounds like it would increase the resource requirements to run such a program, since the large amount of module code has to be included for every form.
The way I learned was to put functions with specific purposes in namespaces and classes, then import the appropriate namespace and class when needed. Then only the necessary code to run a form is loaded, and the extra code for functions that are not needed isn't loaded until imported on a form. I never used modules myself, but I can see their utility, I just think he is severely mis-using modules in this case. Am I correct?
From your description of the situation, it appears your programmer has VB6 backgrounds and has not completely migrated to VB.NET; he does not use OOP if he can avoid it.
To answer your questions, his code style would make a hell for a pure VB.NET OOP programmer. However, it wouldn't cause much overhead.
A VB module does basically define "global" functions - if this were C# it'd be a static class with static functions. However, this won't make any difference to the resource requirements of your application: all methods are defined once, no matter where they're called from, and being in a module or a class doesn't change that. If you have 20 forms that all use the combobox code, the combobox code still only exists once - it's not duplicated 20 times, either in the application or in memory when you run.
It does sound like your contractor may have some unusual coding styles if he's using a lot of module code, but without more concrete examples it's hard to say for sure.
It's hard to answer without seeing the code. From the information in your question it seemed that your contractor was writing procedural structured code, which is old-fashioned, but not necessarily a huge problem, although many programmers who are used to OO won't enjoy looking at the code.
From your last comment on Dan's answer it sounds like he is writing a module for each functional area, with routines that can act on any object. The routines accept Object or Variant arguments, detect the type of object passed with case/if statements, then branch to the appropriate code for that object. Is that right? That is quite eccentric and hard to maintain. Usually, a better way is to declare interfaces for the functional areas, and have the classes implement the interfaces.
I've seen code like this from self-taught programmers. To be fair to them, they are bright people who were stumbling towards inventing OO programming from scratch! It can be a slow process though, and it's better to learn about other people's conclusions first! I might recommend a course on OO programming, or if he is a reader a book like Head First Design Patterns or even Code Complete 2, which has some good chapters on design. If you can get him hooked on Code Complete, that would be a good thing.
By traditional OOP approach, we learned at school that class methods are bound to their objects and while modules are used to carry global functions, and I guess your project partner wants to use those functions independently, irrelevant of associated objects. If those methods are processing only on Combo boxes, than they must be encapsulated with dedicated class for the purpose.
Well, as you said that loading all the functions at the same time will increase overhead, so here's how things will work; since, execution deals with functions only when they are needed, & not when execution starts, so no matter you include hundreds of functions with your code, compiler will execute them only when you call it, (until then compiler doesn't knows what you've wrote in it) along with allocating variables within the functions. But, this is not the case if variables are shared by all the functions, as when they are shared by all of the functions, they are global for them, and hence, they will sit in memory since from the beginning.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm reasonably familiar with the various forms of VB that existed prior to .NET (VB6, VBA, VBScript...), but have yet to delve into The Sweet New Flavor that is VB.NET.
So I would very much appreciate it if someone would provide a quick summary of the major differences in the language brought about by VB.NET.
Assuming when you say vb you mean vb 6.
Pretty big. The original visual basic does not use the .net runtime environment, and although they have similar names, they are pretty much too different languages. Visual Basic is not fully object oriented, but VB.net is. Error handling is vastly different between the two. VB.Net has try catch blocks where traditional vb uses On Error GOTO statements. These are just a few differences. The list goes on and on.
Here is a link describing the "Visual Fred" Name.
Oh the horror.
Sorry, but all existing answers are wrong in some way or another. Joel’s is actually the best of the bunch but its poor wording encourages misunderstanding (sorry, Joel – but just look at your comments!):
contrasting VB.Net with VB is not possible, because they are the same thing.
That’s exactly like saying that “contrasting apples with fruits is not possible because they are the same thing,” and as such not very helpful; especially since many people (still) use “VB” synonymously with “VB6.”
So, to clear things up a bit: both VB6 and VB.NET are dialects of the Visual Basic language family (let’s call it that). Their resemblance is superficial at best; someone who has actually used them both (and not only looked at some source codes) will have noticed that apart from a cursory syntactic similarity, they are completely different beasts. Using them are fundamentally different experiences.
The only aspect in which they actually resemble each other (apart from said syntax similarity) is that they both are very well suited for rapid application development (RAD) … at least until you’ve tried dynamic languages such as Python or Ruby in combination with GUI agile frameworks such as Shoes. But even as RAD environments go there’s a huge difference.
VB6 was basically developed to do RAD, nothing else. And in its time, VB6 was the best thing on the marked to do RAD, by a large margin. VB.NET, on the other hand, was not singled out for RAD development – any more than C#. Both are high-end languages backed by a general-purpose framework, much like Java but with the aspiration to improve on some of Java’s faults, such as its over verboseness by cutting a lot of boilerplate code (introduction of delegates, events, properties, operator overloading, autoboxing to name but a few such features).
And while VB.NET is to a large degree backwards compatible, this is very misleading. First off, no sane person would say that C and C++ are the same languages just because a lot of C programs compile fine on C++ compilers. The differences between VB and VB.NET are even bigger by some metrics because no complete VB6 code is valid VB.NET. It needs an automated “upgrade assistant” to produce valid .NET code, and experience has shown that this upgrade assistant is unsuitable even for medium-sized projects, mainly because its literal translation breaks many guidelines and assumptions of the .NET world.
Saying, like Kibbee, that the compilers of VB6 and VB.NET are “basically the same” is flat out wrong. Likewise, claiming that “the .Net runtime is not a change to the language” misses the point completely. Of course it’s a change in the language. VB.NET was completely build around the .NET framework, it’s not just any other library.
He claims that
If VB.Net was meant to be a new language, and not just a new version of an old language, they would have got rid of "On Error Goto" which they didn't.
– which is likewise misleading. “On Error Goto” was included solely for backwards compatibility (the upgrade assistant cannot convert old-style error handling into exception-based error handling).
Let me sum up the main point of this rather long posting so it doesn’t get lost: Just like Java and JavaScript, VB6 and VB.NET have very similar names (and for very much the same reason, too: marketing) but this is entirely misleading. There are a few syntactic similarities. Apart from that, superficially as well as under the hood, they are completely different languages.
VB.Net is just the version of Visual Basic intended to work with the .Net framework. It also makes other changes and additions to the language, but contrasting VB.Net with VB is not possible, because they are the same thing.
What you can do is contrast with VB.Net with VBA, or VB6, or VBScript, or some other variant of Visual Basic. But VB.Net still IS one possible variant of VB. In fact, if you look at the language part of the product by itself, they're now calling the latest version VB9, with VB10 due out later this year.
In the same way, you can't contrast "Pespi" and cola, because Pepsi is a cola, but you can contrast Pepsi and Coke.
That said, the VB.Net dialect of VB brings a significant number of changes and improvements to the language, including true support for object oriented and functional paradigms, to the point where idiomatic VB.Net code is often very different from VB6-era code.
There are quite a few - too many to list I think. You could almost consider VB.Net a completely different language that shares some similar syntax to VB. The biggest change is becoming familiar with the .NET classes.
VB.Net is a newer version that uses the Dot Net Framework / managed code.
VB is the old version.
VB compiles to p-code or native code, VB.net compiles to MSIL. Also the syntax differs a bit. As VB.net is the upgrade path for VB users and programs, there are a bunch of helper objects and functions that makes moving code from VB to VB.net easier, these objects and functions aren't normally used in programs written in other .net languages.
I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. What is "My" used for?
The purpose of My, as I understand it, is to be an easy shortcut to certain API tasks that are common but hard-to-find or hard-to-use. You probably shouldn't completely subsume your framework under My. (For one thing, C# people using your framework may get grouchy.)
Instead, you should design it as a normal framework. When you're finished, make a list of some common tasks that people might want to use your framework for. See whether any of those could be useful to have under My, especially where there are classes or methods that can be used in a number of ways, but they have one or two really common usages that can be abbreviated with My.
This article shows how to extend My, and it has a section at the end that describes a few design guidelines to follow: Simplify Common Tasks by Customizing the My Namespace
As to your main question, when coding in VB .NET, I use My as often as I can. It reduces a number of operations to one line of code.
I really like the "My" Namespace in VB.NET and I always use it in my WindowsForms applications, because it is very intuitive.
I use primarily these categories:
My.Computer: primarily for file system and network purposes
My.Application: Version number, current directory
My.Resources: Access to resources used by the application residing in resource files in a strongly typed manner.
My.Settings: very handy
I think, if your extensions for My of your framework fit well, then many VB.NET programmers would appreciate them.
I've used My in my VB.NET projects, and I don't feel guilty about it. I am primarily a C# guy, but until I transitioned my company to C#, we were a VB shop. In my mind, the My namespace is a nice piece of syntactic sugar. Just as I'm not embarrassed to use C#'s coalesce operator and other sugar, I'm not embarrassed to use VB's sugar, either. (To an extent; I won't use the classic VB functions that .NET still exposes.)
That said, never put anything in that namespace. It's Microsoft's namespace, and just as you wouldn't put anything under System nor Microsoft, don't put anything under My. It will cause confusion later on -- if not for you, then for others who maintain your code. Create your own namespace for your own code.
We do use it in some code, but hesitantly so. It's true that My often helps make code more readable. For example, the Environment.SpecialFolder enumeration curiously lacks a Temp member, whereas My.Computer.FileSystem.SpecialDirectories has one (Path.GetTempPath() will do as well, but is hardly intuitive compared to other special folders).
But My is only beneficial in such cases because the existing APIs are badly-designed, not because My is inherently better. Like JAGregory, I strongly suggest one avoids extending My — or any other kind of global namespace, variable, etc. — whenever possible. The idea just doesn't fit a clean OOP architecture.
I never use the My namespace (I'm a C# developer), but my VB co-worker doesn't as well. I found the My members not necessary, because in many cases, they're counter-intuitive for me, e.g. in my opinion opening a file has something to do with IO (hence System.IO.File) and not with my computer (My.Computer.FileSystem). They always seem so scattered and bunched together.
It's just some re-roll of functionality that is already available otherwise, from all languages. And I don't like depending on Microsoft.VisualBasic.dll when I'm developing for .NET - I always prefer System.*.
And then, it's always kind of limited. I see VB developers struggle with their app when they can't find something in the My namespace, because they can't imagine that you can use something in the System namespace. That of course is not a problem of the My namespace itself.
I mainly use C# and Boo, but when I do use VB.NET I use My namespace quite often. I dont see any reason to not simplify coding. It still retains its readability.
I've only used it from a user perspective, I've never plugged anything into it. I consider the My namespace to be some highly reliable, platform-provided, global helper mechanisms. Officially sanctioned shortcuts, really. I might be surprised to see external user or third-party code in there.
As such, I'd encourage a vb framework to define its own appropriately-named namespace instead of latching on to the existing My namespace. Such a framework shouldn't have that "global" feel to it.
Never used it so far, although I've never actually looked into it either.
I wouldn't advise putting anything into the My namespace yourself, it's much more clear just to lay it out like you would if it were a non-VB framework.
Love the My! Anything that helps me get the job done faster, and provides code for solutions that I don't have to write, the better!
I use My.Settings and My.Computer often while programming in VB.NET. I particularly enjoy My.Settings as an alternative to using ConfigurationManager.AppSettings when it is appropriate.
I agree with John Rudy about the use of My. It is syntactic sugar that makes life a little more readable.
I don't use it a lot.
I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. Is it?
If it fits, by all means, use it. Since you didn't offer any further information about your framework it's hard to say. I wouldn't put general-purpose stuff into the My namespace (such as the My.Computer stuff) because there isn't really any advantage to putting it there. However, application-centered helpers fit in well.