Umm... I have just started programming with Visual C++ from Visual Basic. And i want to know what in VB gives you bad programming habits like you all say. So far i have found no disadvantage of starting with Visual Basic.

Visual Basic doesn't let you easily do things that are bad programming practice.

Avoid goto's and breaks though this isn't vital and comment you code lots.

If your using C++ you should make use of OOP, header files and placing unrelated code in seperate files.

Old Basics like GWBasic taught bad programming practice because of the heavy use of GOTOs and line numbers which made programs cryptic and hard to read.

There are a numbers of things that you can do in Visual Basic (like gotos, and not using Option Explicit) that are bad programmings habits but not alot of well-informed people use this.

Visual Basic also have a large set of high-level features that save alot of time but may fool the newbie programmer into thinking those things are very simple. Using the VB IDE, you can create a window using a simple click but the created window will leave no trace in the code. That's a bad thing for VB programmers that learns real GUI programming when they realize that window that magically appear using a text editor.

VB5 and VB6 have some REALLY BAD OOP features that gives a wrong idea of what OO programming should be. I think it's the worse things from old VB.

... but VB.NET fixes much of those problems!

ya .net is good in that respect. Its what I really hated about the old VBs

Everyone badmouths goto's but guess what? Whether you use them or not you are still using them. Assembly language relies heavely on goto's, they are not evil when used properly, you're all just narrow minded.

Oh well of course we are narrow minded because we DIDN'T THINK that somebody would come out and say assembly language was full of GOTO.

The fact is, in any well designed programs, GOTO are never required. Procedures/Functions are a cleaner and safer way to wrap up GOTOs in the generated machine code.

You also seem to forget that lots a programmers are simply lazy and careless... Spagetthi coding won't die and GOTOs make that unbearable.

The idea is that a program is well structured therefore it is easier to read and understand.

As an assembly user you have to realise that its harder to keep trying to figure out where the goto, goes to than simply skiping to a function or looking at a loop.

Functions are actually called by "special" goto's; instead of just jmp'ing to a specific location, you store the current position of execution (eip or whatever) on the stack before jmp'ing there. When leaving a function through 'ret', it pops of that position from the stack ... and jmp's there.

Also "if()" and all program flow control relies on jmp's/contitional jmp's, so whatever way you design an application, in assembly/machine code you always end up with goto's (alias jmp's/bra's/whatever)

Amen!
(the word is required in any religiouse discussion. And goto or not goto is definitly a religiouse thing :-)

For good programming habits find a library and get "Code complete" (Steve McConnel, Microsoft Press, ISBN 1-55615-484-4). It's not the all-in-one solution, but it covers enough the fill a few days.

And when writing code, remember that what you write is supposed to be read by a human reader (and preferably without you having to explain what that variable is for or what that function does).

I posted an example of a situation where using goto's made the code more readable and better structured than the equivalent looping implementation. I'll try to find it. And assembly does use gotos whether you like it or not, they just arent called that. You label a line, then you call that line label, same thing.

This is pointless...

We were talking about high-level languages here. The fact that the underlying machine code uses GOTO is pointless in that topic.

Goto is nothing but a tool. (just like a chainsaw) Use it wisely and it can provide great power (like a chainsaw). Use it foolish and suffer greatly (do I need to say more?)