Another gem from the VB6 code I'm "porting"
-
In one function, the following is used to call
SomeFunc(names changed to protect the guilty):If UCase(SomeFunc("" & int_var, bool_var)) = "YES" Then
F.chkBox.Value = 1
Else
F.chkBox.Value = 0
End If(with two more calls to the same function further down). Where
Fis a form variable (becausefrmwould be too hard to type) Looking at the definition...Private Function SomeFunc(Result As Long, Optional cond As Boolean) As String
If cond = True Then
Select Case (Result)
Case Is < 3
SomeFunc = "No"
Case Is > 2
SomeFunc = "Yes"
End SelectElse Select Case (Result) Case 1 SomeFunc = "No" Case Is >= 2 SomeFunc = "Yes" End Select End IfEnd Function
Why use a
Booleanwhen a string comparison, case conversion and check for null string will do? Why is thatBooleanargument optional, when it is always supplied? (before someone says, predictably, that the real WTF is VB, I'd like to point out I've seen code just as horrible in most languages. The real real WTF is that people who produce such garbage are still employed."If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
(before someone says, predictably, that the real WTF is VB, I'd like to point out I've seen code just as horrible in most languages.
But VB seems to bring out the best in bad programming.
Software Kinetics - Dependable Software news
-
Rob Grainger wrote:
(before someone says, predictably, that the real WTF is VB, I'd like to point out I've seen code just as horrible in most languages.
But VB seems to bring out the best in bad programming.
Software Kinetics - Dependable Software news
You need to try "View Source" on a few web pages then ;-) I think it applies generally to many "high-level"/scripting languages, unless (like Dart, Smalltalk) they were well-designed in the first place.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
In one function, the following is used to call
SomeFunc(names changed to protect the guilty):If UCase(SomeFunc("" & int_var, bool_var)) = "YES" Then
F.chkBox.Value = 1
Else
F.chkBox.Value = 0
End If(with two more calls to the same function further down). Where
Fis a form variable (becausefrmwould be too hard to type) Looking at the definition...Private Function SomeFunc(Result As Long, Optional cond As Boolean) As String
If cond = True Then
Select Case (Result)
Case Is < 3
SomeFunc = "No"
Case Is > 2
SomeFunc = "Yes"
End SelectElse Select Case (Result) Case 1 SomeFunc = "No" Case Is >= 2 SomeFunc = "Yes" End Select End IfEnd Function
Why use a
Booleanwhen a string comparison, case conversion and check for null string will do? Why is thatBooleanargument optional, when it is always supplied? (before someone says, predictably, that the real WTF is VB, I'd like to point out I've seen code just as horrible in most languages. The real real WTF is that people who produce such garbage are still employed."If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
You missed one: it converts
int_var(which is presumably aLong) to aString, and then relies on VB's implicit conversion to convert it back to aLong. :doh:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
You missed one: it converts
int_var(which is presumably aLong) to aString, and then relies on VB's implicit conversion to convert it back to aLong. :doh:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Well spotted - I left that one deliberately to ensure folk are paying attention ;-) Actually, most of the real horrors in this particular code base are more subtle and hard to illustrate in short snippets and more to do with putting too much business logic in event handlers for controls. When a form loads, info from the database is written to a control, which fires an event handler, which writes to another control, which fires an event handler, which... I think you get the picture. Business logic is totally interspersed with UI logic - often broken out into separate modules the contents of which have no logical relation. Global variables are used for all sorts of purposes. "Option Strict" has not been used, and frequently variables are not declared anywhere at all... GoTo's and even GoSub's are used liberally. I'm just glad I'm tasked with rewriting it rather than maintaining it, but it can be software archaeology trying to determine what the heck the original logic was intended to accomplish.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Rob Grainger wrote:
(before someone says, predictably, that the real WTF is VB, I'd like to point out I've seen code just as horrible in most languages.
But VB seems to bring out the best in bad programming.
Software Kinetics - Dependable Software news
As I always say, it ain't the tool that is used, it's the tool that uses it that's the problem.
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
-
As I always say, it ain't the tool that is used, it's the tool that uses it that's the problem.
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
Spot on!
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Well spotted - I left that one deliberately to ensure folk are paying attention ;-) Actually, most of the real horrors in this particular code base are more subtle and hard to illustrate in short snippets and more to do with putting too much business logic in event handlers for controls. When a form loads, info from the database is written to a control, which fires an event handler, which writes to another control, which fires an event handler, which... I think you get the picture. Business logic is totally interspersed with UI logic - often broken out into separate modules the contents of which have no logical relation. Global variables are used for all sorts of purposes. "Option Strict" has not been used, and frequently variables are not declared anywhere at all... GoTo's and even GoSub's are used liberally. I'm just glad I'm tasked with rewriting it rather than maintaining it, but it can be software archaeology trying to determine what the heck the original logic was intended to accomplish.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
"Option Strict" has not been used
I didn't think VB6 had
Option Strict? From my hazy memory, it only hadOption Explicit,Option CompareandOption Base. MSDN also listsOption Private[^], but I don't think I ever saw that used.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Well spotted - I left that one deliberately to ensure folk are paying attention ;-) Actually, most of the real horrors in this particular code base are more subtle and hard to illustrate in short snippets and more to do with putting too much business logic in event handlers for controls. When a form loads, info from the database is written to a control, which fires an event handler, which writes to another control, which fires an event handler, which... I think you get the picture. Business logic is totally interspersed with UI logic - often broken out into separate modules the contents of which have no logical relation. Global variables are used for all sorts of purposes. "Option Strict" has not been used, and frequently variables are not declared anywhere at all... GoTo's and even GoSub's are used liberally. I'm just glad I'm tasked with rewriting it rather than maintaining it, but it can be software archaeology trying to determine what the heck the original logic was intended to accomplish.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
In one function, the following is used to call
SomeFunc(names changed to protect the guilty):If UCase(SomeFunc("" & int_var, bool_var)) = "YES" Then
F.chkBox.Value = 1
Else
F.chkBox.Value = 0
End If(with two more calls to the same function further down). Where
Fis a form variable (becausefrmwould be too hard to type) Looking at the definition...Private Function SomeFunc(Result As Long, Optional cond As Boolean) As String
If cond = True Then
Select Case (Result)
Case Is < 3
SomeFunc = "No"
Case Is > 2
SomeFunc = "Yes"
End SelectElse Select Case (Result) Case 1 SomeFunc = "No" Case Is >= 2 SomeFunc = "Yes" End Select End IfEnd Function
Why use a
Booleanwhen a string comparison, case conversion and check for null string will do? Why is thatBooleanargument optional, when it is always supplied? (before someone says, predictably, that the real WTF is VB, I'd like to point out I've seen code just as horrible in most languages. The real real WTF is that people who produce such garbage are still employed."If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
What happens, if you pass cond as False and Result as 0 (or anything < 1)? Does the function return a Null value and cause an Exception in the If?
The good thing about pessimism is, that you are always either right or pleasently surprised.
-
In one function, the following is used to call
SomeFunc(names changed to protect the guilty):If UCase(SomeFunc("" & int_var, bool_var)) = "YES" Then
F.chkBox.Value = 1
Else
F.chkBox.Value = 0
End If(with two more calls to the same function further down). Where
Fis a form variable (becausefrmwould be too hard to type) Looking at the definition...Private Function SomeFunc(Result As Long, Optional cond As Boolean) As String
If cond = True Then
Select Case (Result)
Case Is < 3
SomeFunc = "No"
Case Is > 2
SomeFunc = "Yes"
End SelectElse Select Case (Result) Case 1 SomeFunc = "No" Case Is >= 2 SomeFunc = "Yes" End Select End IfEnd Function
Why use a
Booleanwhen a string comparison, case conversion and check for null string will do? Why is thatBooleanargument optional, when it is always supplied? (before someone says, predictably, that the real WTF is VB, I'd like to point out I've seen code just as horrible in most languages. The real real WTF is that people who produce such garbage are still employed."If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
The real real WTF is that people who produce such garbage are still employed.
And quite possibly one of the 23 million surveyed![^] Say it's not true! Marc
