|
|
|
|
|
|
by famousactress
5117 days ago
|
|
|
You either mean that it implies that you can become a good programmer while writing VB6, or that you can become someone good at writing VB6 programs, or that you can become someone who writes VB6 programs that are good. Regardless of which of those meanings were intended, I disagree. I find denying any of the three to be dismissive and just plain wrong. I should be clear: I hate VB6. I really do. But I'd stop far short of the arrogant suggestion that it's not possible to do good work in it, or that it's not possible to learn an enormous amount about what it takes to make great software while writing it. |
|
|
I started off in VBA hacking recorded macros. I would then write hundreds of lines of code into a single function (usually named "DoSomething" or something equally vague) and then I would live and die by the VBA debugger, tweaking the function when it broke. Over time, I learned the value of encapsulation and how much easier it was to debug my code if used smaller, well-named, functions.
When I started a different job and ended up doing a lot of VB6 programming, I ended up reading a lot of others' code. I would stare at functions that were literally 1000+ lines of code an painfully difficult to debug. The purpose of the VB6 code was to print barcoded shipping labels in a specified format, but the ZPL print instructions were heavily mixed with business logic. It was a nasty mess. The single greatest thing that would have helped me would have been encapsulation. Even if the developer hadn't separated the business logic from the ZPL code (which would have been very nice), small, well-named functions would have made the program so much easier to follow.
The reason I mention encapsulation specifically is because of how much you gain as a developer. If you learn nothing more than basic encapsulation as a VBA/VB6 developer, you'll do wonders for the readability and maintainability of your code.