VB 6
-
Just for your pleasure, I have opened a random VB 6 program from my archive to post some horror. This is from a program which purpose was to teach user doing simple math tasks, that is multipying, dividing, adding and subtracting. Well it worked, but I still don't know a multiplication table by heart. I suppose Command1 was a "Start" button. Of course, the same code was copied to a "Next task" button.
Private Sub Command1_Click()
x = InputBox("Enter a name or a nick:", "Name?!", nz)
If x = "" Then Exit Sub
nz = x
kon = False
Command3.Enabled = True
Command4.Enabled = True
dzial.Interval = Text4 * 1000 // adjustable time restrictions, cool
odp.Interval = Text5 * 1000
Label1 = ""
Label8 = ""
Label1.Visible = True
il = 0
oc = 6
' Combo2.AddItem "0 - First component (denary)"
' Combo2.AddItem "1 - Both components (denary)"
' Combo2.AddItem "2 - First component (hundredth)"
' Combo2.AddItem "3 - Both components (hundredth)" <== whatever that means... ;)
If Check1 = 1 Then
ul = Combo2.ListIndex
Else
ul = 124
End If
1:
Randomize
d1 = Int((Text2 + 1) * Rnd)
Randomize // randomize every time -- that time I though that it would give "more random" numbers...
d2 = Int((Text3 + 1) * Rnd)
Randomize
If Check2 = 1 Then
rd = Int((4) * Rnd + 1)
Else
rd = Int((2) * Rnd + 1)
End If
If d1 = 0 Or d2 = 0 Or rd < 1 Or d1 = d2 Or d1 = 1 Or d2 = 1 Or rd > 4 Then GoTo 1
Randomize
If ul = 0 Or ul = 1 Then
a = Int((9 + 1) * Rnd)
a = Left(a, 1)
c = Str(d1)
c = c & "." & Str(a) //Whoa...
d1 = CDbl(c)
End If
If ul = 1 Then
a = Int((9 + 1) * Rnd)
a = Left(a, 1)
c = Str(d2)
c = c & "." & Str(a)
d2 = CDbl(c)
End If
If ul = 2 Or ul = 3 Then
a = Int((99 + 1) * Rnd)
a = Left(a, 2)
c = Str(d1)
c = c & "." & Str(a)
d1 = CDbl(c)
End If
If ul = 3 Then
a = Int((99 + 1) * Rnd)
a = Left(a, 2)
c = Str(d2)
c = c & "." & Str(a)
d2 = CDbl(c)
End If
If rd = 1 Then
w = d1 * d2
Label1 = d1 & " times " & d2 & " =?"
ElseIf rd = 2 Then
w = d2
Label1 = d1 * d2 & " divided by " & d1 & " =?"
ElseIf rd = 3 Then
w = d1 + d2
Label1 = d1 & " add " & d2 & " =?"
ElseIf rd = 4 Then
w = d1 - d2
Label1 = d1 & " minus " & d2 & " =?"
End If
dzial.Enabled = True
odp.Enabled = True
Command4.Enabled = False
Frame1.Enabled = False
Text1.SetFocus
Text1.SelStart = 0
Text1.SelLength = Len(Text1)
Command2.Enabled = False
End SubA correct answer was stored in a global vari
-
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" X|
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?
-
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.
-
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.
-
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? :wtf:
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
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.
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
-
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
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 + 1would 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.
-
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 + 1would 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
-
oh fat cannon! :omg: Yes, this confirms my oppinion. VB6 is the language with the most chaotic code i have ever seen. It's really a language for small short-life stuff. For those who never where in that situation: Imagine if you have a project with code like this in this language, but with 100000 source code lines...
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 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 shit, 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.
-
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 shit, 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.
