Choose a language; I'd recommend C# or Python normally, but in this case you should probably choose the same one your classes are going to teach you. Learn basic programming. This will likely involve making programs in a console-based, text IO format for some time. The simplest game you are likely to be making early on is a "guess the number" game in a text console environment, which can be done with a few simple programming constructs and iterated on fairly well.
ok. Changing to new stuff just because it may reduce the time spent coding isn't worth it for projects with significant amount of code because while it may provide the same functionality with less code, it still requires several tests to make sure it works right, and why change when you have code with the same functionality that has been tested over and over again. Is that what you meant?
Basically, yes. Sometimes it is worth it, but not always.
I read something about an automatic tool for vb that changes old code to the new code.
Such tools exist for most higher-level languages; C++'s complexity has made it traditionally very hard to provide them with any kind of guarantee of successful transformations, which is critical (more modern compilers like clang help make this more possible, but it's still not nearly as prevalent a thing as with other languages). That said, most such tools ("refactoring" tools) can only perform certain kinds of simple transformations such as renaming types or variables and moving code about. They're helpful but can't perform very complex widespread changes, and on their own cannot always guarantee that the change will be 100% functionally equivalent (even if they can guarantee that the change will be legal compilable code). You'd usually want unit tests, et cetera, to help with that.
Legacy code isn't always bad. It's just old. Changing old just because it's old isn't a good idea, especially on shipping products. For example, the code base of Guild Wars (and Guild Wars 2) doesn't use the standard C++ library for containers, et cetera. All the containers are hand-rolled. This was done (among other reasons) because in the formative years of the code base, the standard library wasn't very well implemented. The modern standard library is much better, and quite powerful, and while sure it would be nice to rip out all that old code and replace it with standard stuff... why? The existing code works and is tested, and introducing a change (especially on that scale, but not just on that scale) has a risk of breaking the functionality.
Why take such a risk for no demonstrable benefit? Until there is a demonstrable benefit (and again, being "new" isn't one), taking that risk is usually a poor business and engineering decision.
Even legacy code that is bad carries that change risk. Bugs are routinely discovered in code that we've shipped; sometimes we don't fix them immediately because the ramifications of the change need analysis even if the change makes the code better from an engineering standpoint.
When you work on large projects with serious business implications, not every decision can be based on pure engineering.
Somebody mentioned Halo earlier on; Bungie still uses that very same code base in Destiny, and it's in the new Halo games as well. Much of has evolved over time but there are definitely files that retain much of the original code or comments from, for example, Aleph One's code (though you may need to go back a fair few years since the project has diverged).
There's little point (and lots of cost) to rewriting everything from scratch every time a studio starts a new game. It already takes man-decades of work to ship a AAA commercial title these days. We cannot afford to increase that.