|
1. Option Explicit Off
2. On Error Goto Label37
3.
With Object.Its.So.Nested
(...)
abc = .Some.Property
(...)
End With
4. Global myVar As String = "magic"
5. someInteger = CInt(int1/int2) (divide operator on two ints gives... a double).
6. Non-zero based arrays -- a fantastic source of confusion
7. Propagating null value in nullable boolean logic -- three-state logic? uhm? I won't be suprised if the next VB version would have a fuzzy logic implemented.
Not a problem with a language? I don't think so...
Greetings - Jacek
|
|
|
|
|
Jacek Gajek wrote: 1. Option Explicit Off
Yes this is horrible, almost as bad as JavaScript doing exactly the same, but with (until ECMAScript5) no equivalent of Option Explicit On.
Jacek Gajek wrote: 2. On Error Goto Label37
Quite horrible, but to blame VB for a fault in BASIC since the year dot is a bit unfair.
3. With/End With - OK, this is truly a mistake.
4. I don't like globals either, but most languages, particularly of that era, support them.
5. someInteger = CInt(int1/int2) (divide operator on two ints gives... a double).
Actually - thats pretty correct. Last time I checked 1/2 in mathematics was 0.5, not 0 or 1.
Ideally, a language can distinguish integer division and floating-point division, maybe with different operators, but this doesn't seem too horrible to me.
6. Yes, a terrible decision, and Option Base 0 just made things worse, as code in different modules can have different bases. I don't mind base 0 or 1, consistency is really important.
7. Not sure what you're referring to here, but if you mean null-propagation where nulls occur in boolean expressions (where null is an allowable result), that's the only option. Check the literature on Relational DB's (Codd et al.) for the justification.
Actually, Codd proposes 4-state logic (Yes,No,Maybe and Inapplicable, Maybe and Applicable).
These are not really boolean logic though, but VB, with typed variables (As Boolean) behaves correctly AFAIK.
It's not a great language, but most languages have points that are plain bad (JavaScript springs to mind heavily). Programmer's should be able to avoid features that cause problems - that's what they're paid for.
I've seen plenty of bad Javascript too - for basically the same reasons as VB.
Maybe we should just ban high-level languages 
|
|
|
|
|
Rob,
You should consider more two VB features:
8. Automatic type conversions like:
Dim a As Integer = "1"
9. Not assigment or type checking at compile type:
Dim c As Object
Select Case c
Case 1
Case "horror"
Case Color.Green
End Select
This code generates a warning for use of c before its assignment, a incredible error, because it will never run. And it happens in modern VB.Net versions.
---
We could assume that you like VB and we could accept it. Every programmer have your "perfect" language and consider it best as no one other.
I know VB since version 5.0 and even today I use this language in a lot of legacy projects, but never in a new project.
I know a lot of other languages (C, C++, C#, Python, Perl, PHP, Javascript, Bash, Java, Delphi) and each time I will start a new project, I never consider VB, because its problems.
Fact is Basic and VB are extremely easy to start programming but they "easiness" are really complicated for the real programmer. A real programmer should be able to run a program and it need to be deterministic. Same input, same output.
Some time a go, a friend mine was asking why a simple sum operation became wrong. She was using ASP 3.0, which uses VBScript, and 1 + 1 are equal to 11. As I saw that, I told her, perfect normal, what was you expecting? I told her simple to type her variables Dim a As Integer = 1, problem solved.
As me, and probably you, use VB along time both of us know that its evolution is really impressive. In version 5 and 6 its is a really poor in resource for type checking and compile time checking. Today it is more impressive, today 1 + 1 is really 2.
The easiness of VB 1, 2, 3, 4, 5 and we can consider version 6 to create and deploy windows applications are amazing, because your RAD and "good" (for the time) IDE.
Even with creation of Delphi, VB had evangelized his people.
But again, today, we can consider VB a good choice in real big and important projects. Project which requires use of good patterns, use o interfaces, a lot of modules, etc. VB can't handle this.
But again, it's my opinion. I consider VB a easy language not a good one.
|
|
|
|
|
Sergio,
Fair points - actually, I have to use VB at work but would much prefer use C#, or even better a true OO language like Smalltalk, but there seems little call for that in this neck of the woods. I've used VB in one form or another intermittently since VB 1.0 - at that stage, even though primitive by todays standards, the IDE was mind-blowing, the first time I was able to draw a GUI, and add event-handling code so easily.
I agree re. auto type conversion - in a typed language that's horrible, although many modern languages seem to do this sort of stuff (particularly in the Scripting arena, and I'd guess VB's kind of midway between there and a typical statically-typed language). Like you I have experience with a wide range of languages (slightly different selection, but generally similar).
Many languages have these kinds of faults - JavaScript has a whole set of them, but it seems to get nothing like the volume of criticism directed at VB. C has a whole different set, that tend to lead to more catastrophic run-time errors. The basic fact remains that whatever language you use, you need to learn its strengths and, particularly, its weaknesses, so you can exploit one and avoid the other.
Regards,
Rob
|
|
|
|
|
|
Any language which contains code to deliberately hide errors and pretend they didn't happen should not be released into the wild. Particularly if innocent and impressionable children (read: students) can be contaminated by it.
"On Error Resume Next" 
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Try with an empty catch does just the same. Does this statement apply to all these languages, including C# and Java?
|
|
|
|
|
No, it doesn't! Try with an empty catch would only work the same if you surrounded each and every single line of code with it's own, independent, try...empty catch block. Not even the laziest programmer on the planet would do that...
Having said that, it is possible a very thick student might. But he wouldn't get a passing grade for it.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
That's true. My point was that a swallowed exception leaves the program in an invalid state. Even if the magnitude is smaller, no language can protect us from bad practice.
|
|
|
|
|
I agree - but a language that has that designed in to make it easy? 
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
OriginalGriff wrote: No, it doesn't! Try with an empty catch would only work the same if you surrounded each and every single line of code with it's own, independent, try...empty catch block. Not even the laziest programmer on the planet would do that...
All you need is a try with an empty catch above the top level code, e.g. in a Button Click event, and all lower level code is covered.
So...asking again...
Should every language that has a mechanism for swallowing exceptions be pulled from the market?
I don't use classic VB any more except where maintenance is needed and that is needed less and less.
I do use VB.Net although I prefer C#.
Both C# and Java have their share of "features" that could attract every bit as much criticism as the features that people obsess over with VB.
And yet, I rarely hear those languages called into question to the same extent.
There's something about that word 'Basic' that just brings out the religious zealots on both sides of the debate.
To me VB has always been a tool, like a Hammer. I might feel a little sentimental from time to time, like a carpenter would about his first hammer, but it's just a tool. It has good and bad.
It revolutionised Software Development and it deserves a bit more respect for that than it gets.
More importantly, while it included features that allowed bad programmers to create complex code, it also included enough features to allow good programmers to write good code.
Very few of the features that people are critical of were absolutely needed. Create and enforce a few coding standards and VB could be used quite well for even complex systems.
The most important point to remember is that right now, out there in the wild there is code written in C# and Java that is 100 times more complex and difficult to read and maintain than anything that was produced in VB.
As a profession we should have enough self respect and pride to realise that code quality is predominantly a function of the developer not the tool.
Prior to college my only experience of programming was Basic. On my induction day for college back in the 90's I asked one of hte students showing us around if they used Basic at all.
"Basic? That's a baby language. We use C or COBOL"
When I started college I started messing with VB2.0.
A few weeks later that same guy approached me and asked me if I could show him VB, he wanted to use it for one of his assignments.
When I started work I used VB3.0. After a year or two I got a new manager who wanted us to start building Prototypes using an early version of Visual C++/MFC. He had VB programmers, but wanted use to only use VC++ (even for prototyping).
I quit, because think what you like about languages, some tools are just better for some things, and if you let ideology lead you into making bad decisions then I don't want to work with you.
No more excuses people.
It's not the tools....that are to blame for 'bad' code.
At some point we as a profession have to accept that for perhaps 15 years now there have been exceptionally good high level languages that can be used to build good quality maintainable code.
Let's stop wondering about which languages have dodgy features and start asking why we as a profession still produce so many coding horrors.
-Rd
|
|
|
|
|
Richard A. Dalton wrote: All you need is a try with an empty catch above the top level code, e.g. in a Button Click event, and all lower level code is covered.
It's not the same: On Error Resume Next causes execution to continue from the statement after the one that cased the error. An empty catch block will continue from the statement following the catch.
On error resume next
x = 3
x = x / 0
x = x + 1 would give an x of 4
try
{
x = 3;
x = x / 0;
x = x + 1;
}
catch {}would give an x of 3.
To duplicate the VB:
try { x = 3; } catch{}
try { x = x / 0; } catch{}
try { x = x + 1; } catch{}
I could argue that empty catch blocks are bad, but they can be justified under some circumstances (if they are documented sufficiently)
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
OriginalGriff wrote: It's not the same: On Error Resume Next causes execution to continue from the statement after the one that cased the error. An empty catch block will continue from the statement following the catch.
The empty try..catch is infinitely worse than On Error Resume Next.
On Error Resume Next leaves the flow of the code relatively untouched. If the Resume next is a bad idea the program flow will continue and will blow up some time later, but you can have some idea where the problem originated.
Of you swallow an exception at a high level and that exception originated at a low level, you are at a complete loss. Not to mention the fact that there could be any number of Empty try catch swallows in between.
But like you said the empty catch clause can be justified and so we don't slam an entire language because you can do it.
Guess what, classic VB didn't have Try..Catch. It had what it had. And like empty Catch blocks if you abused what it had you could write horrible code.
VB.Net and C# have better error handling mechanisms than classic VB....SHOCKER!!!!
If you worked with what you had you could use things like On Error Resume Next to write good code that could be understood.
There are many credible criticisms of classic VB, most of which seem to completely miss the point that VB was what it was and came from where it came.
It's like blaming your 1980 Toyota for you constantly getting lost because your 1980 Toyota didn't come with built in Sat Nav.
-Rd
|
|
|
|
|
3. VB has an integer division operator: 9 \ 4 returns 2, not 2.25.
4. Propagating the null value in expressions is correct. Technically, there is a difference between
Dim a As Variant
a = long_expression_possibly_returning_null
If a = True Then
some_code
Else
more_code
End If
and
Dim a As Variant
a = long_expression_possibly_returning_null
If a = True Then
some_code
ElseIf a = False Then
more_code
End If
And the difference consists on how the program handles the case in which a Is Null.
Still, I agree that VB is a very horrible language:
1. Default ByRef parameters? What were VB designers smoking?
2. No support for object-oriented programming would have been better than the weak support VB offers.
3. Weak support for value data types, which does not include operator overloading. (Java is guilty of this as well.)
4. Fairly common data structures such as collections and dictionaries are a mess.
5. Even more common Generic data structures such as stacks, queues and trees are simply not supported. And there is no clean, efficient way to implement them.
6. The only way to take full advantage of the power of the Win32 API is use gross hacks à la Bruce McKinney's Hardcore Visual Basic, aka, C (not even C++!) programming in VB.
|
|
|
|
|
Interesting line of conversation. A number of years ago I lead a team of programmers to build and deploy an enterprise scale, COM based VB6 app. In the end we had thousands of classes with a few hundred dlls and exes. All told our code base was estimated at well over a million lines of hand written code. Our first deployment was in 2001 and the application is still in service and recieves yearly updates.
Wouldn't choose to that again but...
All that being said, I no longer use VB6 for any new projects and I agree with all of the concerns raised here over the loose and sometimes illogical behavior of VB as a language. It can be used as a powerful development tool, as we proved, but only with skilled and experienced programmers to reign-in the language. Its a shame when the language makes you work harder to be a good programmer. In twenty years of programming I think the programmer and his/her skill is more important than language.
|
|
|
|
|
I worked on VB6 for some three years, and while I did see a lot of ugly code, I never found the language itself (or its IDE for that matter) to be particularly at fault. Sure it missed a decent array initialization mechanism, and its concept of "object-orientation" was laughable when compared to Java - but between a couple good practices (such as always using Option Explicit to enforce variable declaration) and a bit of boilerplate code to abstract away the worst idiosyncrasies, it wasn't bad at all to program; I for one didn't find it any more hard to program modular, loosely-coupled, highly-cohesive classes in VB than in Pascal.
Perhaps VB's ugly code base was more a consequence of the target public it was aimed at? Microsoft marketed it as a tool for novice programmers to write simple applications with, so it's no wonder we find a lot of bad code written in VB.
|
|
|
|
|
I remember my early days in programming. I started with VB5 at the age of 15. Oh my...
The fact that I didn't need to declare a variable simply knocks me out today. I remember when I realized that this was really bad, I remembered to always use "Option Explicit". The more I got skilled in programming the farther I got away from VB. It was like a calling to code horrors.
Soon enough though, I abandoned VB two to three years later in favor of C++.
The fact is that VB draws many people who either are not born to code or suck at coding because they are just starting.
|
|
|
|
|
My first language was C/C++. With my knowledge of this language, starting program in C# was really easy for me.
But my biggest mistake in my live...
...One day, i asked my boss how to do something in vb6, because i only wanted to see how another language works. This question was unfortunately the start of a big chaotic long-live and important project written in vb6 by my boss and other programmer, that have been left the firm long time ago. So my job was to step back from a modern language to a frumpish language.
My fun to program has been decreased a lot since that day, it's not mainly the difficult to work with vb6 in relation to C#. The syntax is okay, because at my young days i played with BlitzBasic. The hardest thing was the predominant bad-formed code in this project that has been written by unexperienced programmers (yes my boss included).
I said to my boss, that i don't like vb6 and instead of upgrade this old long-live project with new important features, we should create new projects with this features in a newer language instead of increasing the longevity of a old vb6 project. He answer with sentences like: "I don't give a sh*t, you get paid for this work.", or: "The customer needs this tool for work." etc.
There are some approaches in this projects, some features for this project has been developed in .NET, but because of the missing downward-compatibility and some problems to access them from vb6, this modern solutions had to be developed in vb6 to make the access easier. Because my boss dont have the time for this and i'm the only one who can do this, i had to destroy the .NET approaches and develop it in vb6. Its hardly imaginable how reluctant i'm with this, develop a done and working .NET feature with an older language, because the boss want to have it.
|
|
|
|
|
I feel really sorry for you. Bosses usually really don't care about the details, maintainability, etc. All they want is what the client wants.
And I often see they miss many opportunities because they are reluctant to improve things that are already working. With this kind of mentality, that companies like Microsoft gets owned by companies like Google.
Improve always, think before the client.
|
|
|
|
|
VB should just be put out of it's misery !
|
|
|
|
|
Beautiful! Just absolutely beautiful...
bwa
|
|
|
|
|
This is a response to all the posts in this topic before mine... you might know what I'm referring to if you read this thread up until this post...
I've written miles of VB5,6 code and folks can knock it all they like but I think it was one of the best products Microsoft has made alongside forcefeedback joysticks, access 2003, excel 2003 and DirectX in my opinion.
It is one of first totally RAD programming languages in my opinion: True Binary, tons of widget addons, ADO, ODBC, RDO .. tons of ways to communicate with databases and whip up applications quickly with integrated set up and deployment tools - all wrapped into one seamless package if you wen corporate - not to mention it supports various client/server (two tier/three tier systems easily.
On error resume next? You can test the error result after that command - SO? what's the problem? How is that different then try catch? You can do the same thing... and frankly - there is a time and place for any code construct - even GOTO.
I love when folks get indignant about GOTO and other coding philosophy. I truly believe users just want software that works - less flash and more "DO" ... and
* If you write beautiful code that is easy to read and performs great: AWESOME!
* If you write ugly code that works.. well.. I wouldn't recommend it but before I chastise ya: How much time did you have to get it done? Boss breathing down your neck? Simply didn't care? All valid reasons to write crap and "Git-R-Dun" in my opinion... Example: Coder: I need two days to do this right! Boss: I need it NOW.. an Hour! Worker: Sure thing boss!
VB6 is pretty darn sweet and I say if they had a vb7 by the same development team with better multi-tasking - I would chose it over .Net any day!
--Jason
Know way too many languages... master of none!
|
|
|
|
|
I concur.
We have a time & attendance system that was originally developed in VB6 that serves thousands of clients on a daily basis. (Some of these clients have > 10,000 employees). The current enterprise-level solution is now a mix of the VB6 stuff and .Net. Since 2005 the management kept saying "in 6 months we'll get rid of VB6 code". Now, years later, the ratio of the VB6 code to the .Net section is about the same. Why? The stuff just plain works, that's why.
Agreed, .Net is far more refined a product than VB6 is - it had better be, it's 12 years newer (in its latest version that is). However even now the VB6 code continues to ensure that paychecks are accurately produced and the system continues to hum along.
VB6 may wind up being the next COBOL. It will eventually fall off the radar but in the background will continue to get results for years to come.
One developer said that he'd never take another job where he would have to deal with VB6. That's all right son, just send that work my way. I won't turn my nose up - they pay me big bucks to fix systems that the kids don't want to bother with anymore.  I love .Net (absolutely crazy about C#) but, at the same time I find it a breath of fresh air sometimes to go back to VB6. Besides being a competent development environment it is just plain FUN.
-Max
|
|
|
|
|
true, that does hurt. but you should have seen some c code I had to take over when I first arived at the company I now work for.
something along the lines---
void _add{
int a,b,c,d,e,f,g,h,i,j,k,l,m,n;
int aa,bb,cc,iiii,iii,ii,i;
if {z==0}n=3; /*declared in globals*/
b=1
}
all of the code was like this, with vars never even refrenced in the code, except for one var that is assigned a variable, but never actually used. the names of the functions had no correlation to the body of code inside of them!
yes, most of it was scrubbed, as no one could follow the majority of the logic.
|
|
|
|
|
Maybe a programmer who wrote this was using a lot an early version of BASIC, where variables had to match a pattern ([A-Z][A-Z]) (identifiers not longer than two characters, not case sensitive, a-z letters can be accesed via an array A, e.g. A[3]=C as well as other "advantages").
BTW in your code i is declared twice.
Greetings - Jacek
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
