This code base is the gift that just keeps giving
-
Yes, I'm back with yet another gem from the the VB hell I'm porting:
' RJG: Best name ever.
Private Sub LoadGrid()
Dim SQL As String
Dim x As Long
Dim rst As New ADODB.RecordsettxtMode.Text = mode txtPID.Text = PID txtPolTypeID.Text = policytypeid x = Val("" & txtPID.Text)End Sub
That comment wasn't there, that was my contribution! This is fairly typical of the code quality - note that.. 1. The name is unrelated to the procedure. 2. There are two local variables that are dead. 3. It loads a text box from an integer field (PID is an Integer), but still feels in necessary to prepend "" in the last line, just in case! They're wondering why it's taking me a long time to port. Can't imagine. <Edit>And of course I forgot to mention that both txtPID and txtPolTypeID are hidden fields, with OnChange event handlers that carry out further processing - flow-of-control in this application is fractal-like.</Edit>
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Yes, I'm back with yet another gem from the the VB hell I'm porting:
' RJG: Best name ever.
Private Sub LoadGrid()
Dim SQL As String
Dim x As Long
Dim rst As New ADODB.RecordsettxtMode.Text = mode txtPID.Text = PID txtPolTypeID.Text = policytypeid x = Val("" & txtPID.Text)End Sub
That comment wasn't there, that was my contribution! This is fairly typical of the code quality - note that.. 1. The name is unrelated to the procedure. 2. There are two local variables that are dead. 3. It loads a text box from an integer field (PID is an Integer), but still feels in necessary to prepend "" in the last line, just in case! They're wondering why it's taking me a long time to port. Can't imagine. <Edit>And of course I forgot to mention that both txtPID and txtPolTypeID are hidden fields, with OnChange event handlers that carry out further processing - flow-of-control in this application is fractal-like.</Edit>
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
I feel your pain. That codebase must be like :(( :doh: :omg: :wtf: :mad::confused: X| :~ :sigh: at times.
What do you get when you cross a joke with a rhetorical question?
-
Yes, I'm back with yet another gem from the the VB hell I'm porting:
' RJG: Best name ever.
Private Sub LoadGrid()
Dim SQL As String
Dim x As Long
Dim rst As New ADODB.RecordsettxtMode.Text = mode txtPID.Text = PID txtPolTypeID.Text = policytypeid x = Val("" & txtPID.Text)End Sub
That comment wasn't there, that was my contribution! This is fairly typical of the code quality - note that.. 1. The name is unrelated to the procedure. 2. There are two local variables that are dead. 3. It loads a text box from an integer field (PID is an Integer), but still feels in necessary to prepend "" in the last line, just in case! They're wondering why it's taking me a long time to port. Can't imagine. <Edit>And of course I forgot to mention that both txtPID and txtPolTypeID are hidden fields, with OnChange event handlers that carry out further processing - flow-of-control in this application is fractal-like.</Edit>
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
VB hell
Why VB. It's a hell of non-programming, but not because of VB but because of the men wrote it...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
-
Rob Grainger wrote:
VB hell
Why VB. It's a hell of non-programming, but not because of VB but because of the men wrote it...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
Because this particular hell was constructed in VB. I've seen plenty of JavaScript hell too (and many others), but VB seems to particularly attract the infernal.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Because this particular hell was constructed in VB. I've seen plenty of JavaScript hell too (and many others), but VB seems to particularly attract the infernal.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
I done VB development of very large scale application (Microsoft sold us that VB is the language of the future). We done it in VB6 using every dirty trick we found - still the code was well written and readable...The application went off at 1999 and still working...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
-
Yes, I'm back with yet another gem from the the VB hell I'm porting:
' RJG: Best name ever.
Private Sub LoadGrid()
Dim SQL As String
Dim x As Long
Dim rst As New ADODB.RecordsettxtMode.Text = mode txtPID.Text = PID txtPolTypeID.Text = policytypeid x = Val("" & txtPID.Text)End Sub
That comment wasn't there, that was my contribution! This is fairly typical of the code quality - note that.. 1. The name is unrelated to the procedure. 2. There are two local variables that are dead. 3. It loads a text box from an integer field (PID is an Integer), but still feels in necessary to prepend "" in the last line, just in case! They're wondering why it's taking me a long time to port. Can't imagine. <Edit>And of course I forgot to mention that both txtPID and txtPolTypeID are hidden fields, with OnChange event handlers that carry out further processing - flow-of-control in this application is fractal-like.</Edit>
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
I feel your pain Rob. I've spent the last three weeks on a refactoring job that was supposed to last two days at most. The guy who wrote the original code was pretty sharp, with a deep background in embedded development in C. Unfortunately, the code in question is for a Windows service written in C++. Unsafe pointer casts everywhere, no attempt to follow the group naming convention, class member variables that were unused, lots of pointer arithmetic rather than straightforward array indexing, locals that were initialized and never referenced, the list goes on. The worst was the mix of MFC and STL collection classes. I spent four days alone getting the thing to shutdown without throwing exceptions or locking up due to threading issues.
Software Zen:
delete this; -
I feel your pain Rob. I've spent the last three weeks on a refactoring job that was supposed to last two days at most. The guy who wrote the original code was pretty sharp, with a deep background in embedded development in C. Unfortunately, the code in question is for a Windows service written in C++. Unsafe pointer casts everywhere, no attempt to follow the group naming convention, class member variables that were unused, lots of pointer arithmetic rather than straightforward array indexing, locals that were initialized and never referenced, the list goes on. The worst was the mix of MFC and STL collection classes. I spent four days alone getting the thing to shutdown without throwing exceptions or locking up due to threading issues.
Software Zen:
delete this;In many ways I suspect that's worse - at least VB doesn't tend to just bomb when an error occurs (at least while debugging) - in C/C++ unhandled exceptions tend to be, well, fatal. I don't envy you.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
In many ways I suspect that's worse - at least VB doesn't tend to just bomb when an error occurs (at least while debugging) - in C/C++ unhandled exceptions tend to be, well, fatal. I don't envy you.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Agreed, porting someone else's c++ can be one step closer to the insanity abyss (compared to VB). When i did a port/rewrite, it felt like peeking into that other fellow's brain, wondering how he could function with that strange wiring of his brain. I remember he used to start for example an event loop with a delete xxx call (except if it's the first time) followed by a new xxx call...
