What are the bad habits that it teaches?
Printable View
What are the bad habits that it teaches?
NONE! It depends on the teacher! :rolleyes:
So, what are some of the things that are considered "no-no's."
Using the "End" keyword.
With the exception of error trapping, never use GoTo.
Never use default control names such as Command1 or Text1. Always give your controls names that reflect their purpose like cmdClose or txtFirstName.
Often the greatest strength of a person or thing is also its greatest weakness. VB was originally designed to make it easy for the less technical folks to write code. It succeeded very well in that aim, thus it is hugely popular. The problem is that to make it easy to write code VB let a lot of things happen implicitly. This meant that the developer didn't have to worry about a lot of the detail and could get on with the fun parts of programming.
That's great, but it also means that if you aren't aware of what's happening you won't be aware if it's happening incorrectly and you won't know how to fix it if it breaks. The more that occurs implicitly the more likelihood there is that something will happen that is not exactly what you intend. It's possible to write excellent code with VB, just like it's possible to write terrible code in any language. The thing with VB is that because it isn't as strict as some other languages, and thus doesn't force you to consider the details as much as some other languages, it's easier to make mistakes, either through laziness or ignorance.
VB doesn't teach bad habits, but it doesn't try as hard as some other languages to prevent you getting into them. That can mean that those with lax attitudes may be more attracted to a language like VB that will let them get away with some things that other languages might not, and those things may cause issues at some point that would not appear with other languages. Like I said, VB doesn't teach bad habits. If you're conscientious then you'll write good code no matter the language. If you're not you won't. It's just that you're more likely to be unaware that you aren't doing things the best way with VB because it won't tell you. VB is by no means the only, or even worst language in terms of strictness. There are languages that basically have no boundaries at all when it comes to types, etc.
Now, there are times when this lack of strictness is a Godsend. You can throw something perfectly workable together in minutes in VB that might take hours in something like C++. By the same token, I've lost count of the number of people who've posted about errors in VB.NET that totally mystify them, only to have the whole thing become clear and cleared up when they turn Option Strict On and make all their casts and conversions explicit.
@jmcilhinney:
have you ever developed in any of the Pre.Dot.Net version of VB and for how long if you did?
I have to agree with JMC in some regards...
Implicit datatype coercion - the ability to use two different datatypes in an expression - is evil. The fact that VB6 allows this shocked me when I came into the PC world.
I've not done a lot of .Net coding yet - but what I have done has shown me that MS finally got around to understanding the importance of the "type" of an object - almost to the point of insanity since there are so many different "types" now!
I could care less if an occasional GOTO statement is used (personally) - I understand how spaghetti code is created with excessive use of GOTO - but GOTO is not any different then EXIT SUB or EXIT FUNCTION really. And if you were coding in ASSEMBLER you only have GOTO (branch) statements to jump around with!
I think that learning good habits really comes from understanding what's under the hood. That means really knowing what a line of code does internally.
Coming from the 80's means that I've done a lot of coding in lower level languages and that helps take the mystery away.
Some of the coders I have had work for me never got past the mystery and in reality wrote poor code because of that fact alone. I often find myself teaching the "internal" of a concept so that the coder can get past the poor practice...
Agree in what? Someone needs to know the product and have practical experience to be able to judge. I'm sorry but that doesn't apply to Jim I'm afraid unless he prooves otherwise (my upfront appologies if that's the case).Quote:
Originally Posted by szlamany
Having said, I think there is no reason to wright a whole article... :rolleyes:
And the GOTOs are not VB specific only - many other languages have it and they do work pretty darn good. It is upto programmer to how to use it...
However, as I said there are bad teachers - not students...
Never in anger, and I've only played with it a bit.Quote:
Originally Posted by RhinoBull
I believe that absolutely everyone should work in VB.NET with Option Strict turned On for the very same reasons. Declaring variables without a type is something that a lot of beginners will do without realising that there's a better option, and that can quite easily lead to issues. VB doesn't "teach" people to do that, but it does allow them to where other languages might not. That's just one example of how VB makes things easier, but in doing so also makes it easier to write less sound code. As I said, this can be a good thing or a bad thing, depending on the circumstances. It also doesn't mean that VB developers will automatically write less sound code. A good developer will write good code no matter their language of choice.
Pardon my ignorance but what whould that mean? This expression here in the States means something entirely different. It must be British/Australian...Quote:
Originally Posted by jmcilhinney
I shouldn't use that expression as this same question has been asked before. In fact when I posted that my girlfriend noted that it may not be understood in some places. Proof that she knows best. ;) Anyway, to use something in anger means to use it properly, as opposed to just messing about with it. I've used VB6 to mess about with and get a feel for it, but never built anything useful with it. I was working in a C++ shop at the time.Quote:
Originally Posted by RhinoBull
I know we've had our differences and I've provoked my share of them, but I'm not specifically criticising VB here. I would think that any objective assessment of VB would have to admit that it does let you get away with sloppy habits more so than many other common languages. This was specifically by design too, to encourage and enable those who found languages like C/C++ to intimidating, difficult and restrictive. VB's greatest strength is its simplicity, but that simplicity also enables sloppy programmers to create bad code more easily than some other languages might. Having said that, I don't deny that it's quite possible to write sloppy code in any language, but the reasons may be slightly different. All languages have their strengths and weaknesses, VB as many on both sides as any other langauge.
Thanks for the British English lesson. :)
Anyway, I am not against any criticisism at all nor I am afraid of it.
However, over the past decade or so I've read many articles mostly written by hardcore C++ people which was btw my primary dev language for about 10 years until VB4 32 bit. They've always blamed VB for being a loose language and not being able to "teach good habits" new commers...
I agree with the "loose language" part and there is nothing really wrong with that but I did and still am disagreeing with the "habits" part... I will repeate myself but will say it again: "it depends on a teacher". Vast majority of "teachers" carried over their QBasic mentality into 75% object oriented VB6 environment without even bothering to introduce new (and very rich btw) features. What can you expect after that? You tell me.
BTW, VB.Net is still a bit of a loose language compare to C#.
I agree, and some C# programmers do look down on VB.NET in a similar fashion. I always recommend having Option Strict On in VB.NET to avoid the things that prompt those jibes. I guess we're both right, mainly because we're both saying essentially the same thing. I just managed to do it in more words. One of my special skills you appreciate, I think. ;)
Bad programmers develop bad habits through complacency.
Good programmers develop good habits through learning.
The best programmers don't develop habits, and are always receptive to new ideas.
Yes, yes indeed. :wave:Quote:
Originally Posted by jmcilhinney
Amen to that! :afrog:Quote:
Originally Posted by penagate
I cant believe that no one has mentioned how VB 6 is missing the enforcement of OOP which in turn produces better designed apps, theoretically at least. I'm sure there is some way that it could be avoided partially but C# enforces OOP very strictly while VB.NET is less, VB 6 is almost nonexistant.
One other thing that is not very language specific but is mentioned earlier is how a developer could bypass the learning and understanding of what goes on behind the scenes when using simplification techniques like wizards for setting up connections to databases for example. If they dont understand how to code it manually in pure code then when they to make some kind of modification that is not supported in the wizard you will find they create a thread like "How to change my connection to a database at runtime" :rolleyes: Wizards are present in 2005 more and sure they are a timesaver to a point but should be used where appropriate and never be fully dependant upon.
I've been programming professionally since prior to 1980 - decades on mini-computers called VAX's (Digital Equipment products).
We produced enterprise applications on this box using BASIC.
We were always looked down upon by piers for using BASIC - since COBOL was available. COBOL being such a strictly enforced typed languages it was superior to BASIC (so they would say) - this is the same argument you get from PC C# coders over PC VB programmers.
This is all a load of garbage.
T-SQL is one of the weakest languages I have used as far a type-casting - but you can still be "careful" and "strict" in your own use.
As far as habits - which is the thread topic...
I think conventions are one of the most important aspects of creating maintainable and easily enhancible code. Whether you are a single developer or a shop full of developers having conventions that are always followed is in my opinion of of the most important rules of coding. Conventions lead to a consistent product for the users to see also.
In VB6 we use the same template for every sub and function - with consistent error trapping in every sub/func. Naming conventions are important - but less so, in my opinion, then coding and structural conventions.
So if you want to learn good habits understand what is happening in each line of code you write. Avoid using wizards - they might be helpful for quick production of code - but to a novice they are a crutch that should be avoided.
When I code a program I usually step through lines of code and examine progress in the various debugging windows supplied by the IDE. I've done this since my VAX-11 BASIC days 25 years ago. I consider this a great habit. I've had partners and coders work for me that did not do this - instead they would code pages and pages of logic - and hope that the final result was what they expected. If it wasn't then uncovering the bad logic was extremely difficult. Imagine developing a PENSION calculation in this fashion - I've recently needed to convert a routine like this from VAX BASIC and could not believe the mess of code that was created (all without comments as well!).
After you code for a few decades you simply know how to code a piece of logic - having probably done something similar in dozens and dozens of places in the past.
OOP is great - but in my opinion that's really an organizational tool for putting functionality together in a program. This is good stuff - because the language is "forcing" a consistent approach (if you follow it) to organization - but hardly a requirement to putting a program together. Following OOP practices is a good habit to learn - but there are many other more foundational habits that should be built as well.
I would say that the major problem with VB6 (aside from the IDE, which was decidedly inferior in code management to .NET), was the very ease of use. Most people never need to know what an object is in VB6. They don't need to know why a string isn't an integer. In fact, you barely need to know what those two words MEAN to write in VB6. This was a great strength....until you tried to move into a new language.
If you start in VB6, with no experience in a lower level language, you will have a harder time moving to other languages. For example, there is the keyword New in VB6, but you don't actually NEED it. Most people who write in that langauge don't know what that word does, or why it would be used. I wrote dozens of programs in VB6, and I STILL don't know what that word is for in that language. Loads of questions about that in .NET, however.
@RobDog888:
original question was not about missing fuctionality.
@szlamany:
I totally agree with you about the OOP and of course about the COBOL/BASIC sentiments...
@Shaggy Hiker:
original question was not about any particular feature of a language.
And btw, the New key work is quite important - it how you use it that makes the difference.
If you feel like this, it's time to start learning...
http://infohost.nmt.edu/~jaredc/programming.gif
@RhinoBull, Its not about missing functionality but more of that if its not enforced like it is in C# then they learn bad habbits of non-oop structure, design and logic. That surely would qualify as learning a bad habbit.
I will disagree as far as disagreement goes in this case: lack of functionality does not create any bad habbits what so ever.
OOP does not teach any good habits as well. OOP is just another way of writing program which isn't necessary is best way all arround.
In fact using too much of OOP may lead you to develop bad habbit...
But let's get back directly on the topic:
What are the bad habits that it (VB6) teaches? - I said it before and will say it again (and again if necessary) - NONE !!!
Rob, by that logic you could say C++ teaches bad habits as it does not enforce any particular architectural paradigm.
Which is better is subjective and not really valid; there are people that prefer procedural programming to OO and that's fine as each has its place.
As I implied previously, it's up to the programmer to make what they can of the language. No languages 'teaches' anything-- it's the language user that develops their own habits.
That having been said: if you are complacent about it, you can easily develop habits in VB6 that won't help you if you need to use .NET. The same goes for any two languages which enforce markedly different architecture styles. And if you intend to use one language all your life then there's nothing wrong with that; but on the other hand, if you are making a career of programming, then you must be versatile and always know the limits of each language, so that you can use what is appropriate for the job.
@penagate - that was truly well said!
All I have to say about it that if programmers rely upon the ease of use of VB 6 then when they make a change to another language they will get thrown for a loop as more advanced languages allow you to use and apply better practices. Now for ex, in VB.NET 2003 VB 6 programmers are lost when they make the switch nd not even understand how to show a freaking form. Now if they understood what was happening and had any kind of exposure to OOP in VB 6 they then they might have a leg up on the other but those that didnt cant understand how a form is an object and how to show it or navigate between forms. They think it should be "easy" and only have to do like they did in VB 6 with a .Show and they are done. This is part of the reason why VB 6 users either hate or find it really hard to make the change to .NET. ME changed this in 2005 as they were more forced to make some kind of change to make it "easier" to show a form like it was in VB 6.
VB 6 teaches programmers that everything should be easy and so easy that they dont have to do a logical thinking.
Again: VB6 teaches nothing. And who said VB6 is easy? Perhaps its syntax that makes it easy to read and understand. But again - it's beyond the original question.Quote:
Originally Posted by RobDog888
Ok, maybe you're taking "teaches" technically from the OP post as no programming language teaches anyone anything but I dont think thats the context its being used in here. ;)
I guess you could deduce that VB 6 implicitly guides users into thinking and creating a consunses that programming with VB 6 is easy and there is very limited programming knowledge/skill needed, if any at all. this in itself is a bad habbit to have - being lazy, not learning and not understanding anything about programming logic and design.
I'm sorry Rob but I'm afraid you're still missing few very major points:
- there is no language that "guides" anyone anywhere
- there is no language that "teaches" anyone anything
- OOP is not an advantage of one language over another
- we are not trying to discuss why should one migrate to .Net
- we are not trying to discuss why learnig .Net could be difficult for those stubborn "old timers"
If you want my opinion on the last then VB.Net is a Java with VB-like syntax (so is C# with C-like syntax). That's one of the biggest reason that real pros that really hated java for a long time don't want to be bothered with moving to .Net. And it's not because of a complexity and a brand new language as you may think. Anyway, that was a bit of an off topic...
Exactly. And furthermore, you can be complacent when using any language, and you'll end up somewhere different. A lot of people being complacent when using VB doesn't imply VB is a bad language; as the plethora of badly written free snippets for Javascript doesn't mean JS itself is bad. It's all about how you use the language yourself.Quote:
Originally Posted by RobDog888
I think Rhino and Rob are basically saying this same thing, just in their different ways.
I was on board until this part of this post. Every language guides people somewhere, whether spoken, written, or logical. We can only communicate ideas that we can put words to, and no language has a complete set. This is as true for programming languages as it is for spoken languages.Quote:
Originally Posted by RhinoBull
A few examples would be:
1) Memory usage. If you program in C/C++, you have your faced rubbed in it constantly. There are many many books written for these languages on the use of pointers, memory management, footprints, etc. How many have of the same have been written for VB: 0! Why? Because you really don't need to know that stuff for the vast majority of VB apps. Conversly, you can't do much of anything in C/C++ without that, so you had better learn or else. Does this mean the language teaches? No, it just sits there. But that's a trite and silly answer. The fact that the language forces you to learn the subject is the same as the school system we all grew up in. If the latter is for teaching, then so is the former.
2)OO. Yes, OO! It isn't exactly something that everybody comes by naturally. I started with MASM, then C....then I picked up a book on C++. You pretty darn well better be learning the concept behind OO if you ever wanted to work with any of the frameworks that showed up with C++. To learn OO without such a language would be virtually impossible, as you would have no frame of reference to be able to conceptualize the problem. Of course, there are other languages which would suffice (.NET, SmallTalk, etc), but that's the point OO languages teach OO, and you won't learn it without them.
3)STL and generic programming. A whole different kind of learning, but the same argument as I have already made, so I'll leave just that comment.
Does VB6 teach any bad habits? I don't think it really teaches anything particularly bad, but I don't really know. I came from C++ to VB, and found that the understanding of the one made the other much more comprehensible. I have no experience moving from a higher level like VB down to a lower level like C++, but I would think that it could be more difficult than going the other way.
You know I've spent fair amount of years developing in C++ and I don't miss pointers at all after moving toward VB.
Also, I think that you're mixing developing "bad habbits" and higher education - those two have nothing in common.
And last - addiction to OOP could (under sircumstances) be considered as a bad habbit as well.
It's not about what's offered - it's what you do that matters.
Best regards to all.
I really dont think you are reading my posts? I did post that VB 6 nor any language "teaches" you.Quote:
Originally Posted by RhinoBull
As far as a language that guides you, well I'm sure you will argue the point more but each language can guide you with intellisense and other tools that come with each IDE. so then the question arises: language guiding you - no, no language guides much less teaches you; but if you are taking into account the IDE that comes with the language development software then yes, which is where intellisense, for ex. , comes in.Quote:
Originally Posted by RobDog888
OOP can be and advantage and a disadvantage, depends on how its applied or not. If you go back to the days of BASIC then there were no Objects. That made the language very limiting and forced you to create workarounds to compensate. No if it did have Objects then you could learn how to take advantage of it for better design and programs logic overall. So with VB 6 if the programmer can write some easy code without using a good design then it will be a poor program. If you dont take advantage of the tools provided in a language then how the heck could you expect to have a good application?
Who said anything about that "you should switch to .NET"? :sick: Dont put words in my post :p :D
Just like any of the examples of other languages posted in this thread, C++, VB.NET, C# etc. We are not saying why its hard for VB 6'ers to learn .NET but rather some of the pitfalls that occur when they try to apply their learned bad habbits in other languages.
Piece out!