|
True object-oriented programming allows it because they are all objects. It doesn't care.
|
|
|
|
|
Using a string as a boolean has nothing to do with object-oriented programming. If the code were directly comparing the boolean and the string, that might be considered something near valid (what with operator overloading), but that was not the case here. This code is basically like doing this:
If "Dragons" Then
Else
End If
It doesn't make any sense.
|
|
|
|
|
You are right, the code did not make any sense. That you are right about.
|
|
|
|
|
Someone doesn't use PHP.
Don't forget to rate my post if it helped!
"He has no enemies, but is intensely disliked by his friends."
"His mother should have thrown him away, and kept the stork."
"There's nothing wrong with you that reincarnation won't cure."
"He loves nature, in spite of what it did to him."
|
|
|
|
|
That's because somebody read a PHP book, puked in his mouth, and is still trying to wash away the filth.
|
|
|
|
|
God I really...REALLY hope that you're just trolling.
|
|
|
|
|
AspDotNetDev wrote: The bad part is that the OrElse is between a string and a boolean, which is
returning a boolean, which then gets passed as a parameter to
String.IsNullOrEmpty.
Uh, that's WHY there is an Option Strict: to allow relaxed type checking on certain operations. Though here it is certainly annoying, and one of the reasons I tend to use Option Strict pretty consistently.
|
|
|
|
|
I have never programmed in VB without Option Strict and Option Explicit turned on. That is the only way that VB doesn't turn into an absolute nightmare.
|
|
|
|
|
I agree. (VB is a nightmare anyways, but point well taken)
|
|
|
|
|
Slight disagreement. The real horror is that the developer has to specify, "Yes, please use short-circuit boolean logic" by using OrElse instead of that being the default behavior.
|
|
|
|
|
You mean like it is in every other language? The way it should be?
|
|
|
|
|
And the IIf function doesn't even have a short-circuit version! If you're used to writing code like this in C#:
int count = list == null ? 0 : list.Count;
and you try to translate to VB:
dim count as integer = iif(list is nothing, 0, list.Count)
you will wind up with a NullReferenceException when list is null/nothing!
|
|
|
|
|
Actually, since VB 2008, that's no longer true.
The If Operator (without the extra I)
The 3 parameter form act like the C# ternary operator ? : , while the 2 parameter form would be the C# coalesce ?? .
But yes, TRWTF is VB.
|
|
|
|
|
Wow, you learn something new every day
Funny how the documentation lists the 2-parameter form's arguments as argument2 and argument3, though...
|
|
|
|
|
Computers should be used for what they are good at: systematic consistency checks. Because this is where they can help preventing bugs early. Static analysis.
If I were God, I would make the Strict mode compulsory. And enhance the programming languages to help computers help us. For instance by introducing dimensional analysis on the data.
Dim Meters as Unit
Dim Side As Integer in Meters, Area As Integer in Meters^2, Count(0 To 5) As Integer
Area = 3 * Side
Count(Side) = Count(Side) + 1
|
|
|
|
|
|
Thanks for pointing at this article: a pure delight !
As is turns out, little of Hoare's hints have been followed, I guess
|
|
|
|
|
The paper doesn't seem to mention anything about implicit conversion on two incompatible types.
And even so, implicit conversion can be implemented on a type so two incompatible types become compatible, but the conversion is implemented by a custom algorithm.
I still think that should never be allowed.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
I think F# has something similar to this... in other languages you have to mess with funky generic type constraints or templates or whatever you have available
|
|
|
|
|
I feel your pain! Our company has a product where turning Option Strict On results in probably 1000's of errors... Stuff like:
Dim i As Integer = someStringThatSupposedlyCanOnlyHoldAnInteger The worst part is that code like this goes wrong on regular basis. Our users will never know though... Errors are caught and logged (preferably at the lowerst level, some 10 functions deep) and the software goes on like nothing ever happened
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
Naerling wrote: Our company has a product where turning Option Strict On results in probably
1000's of errors
Then you need to start fixing now.
Enable it on file level and fix the files one by one.
If it's not the highest priority your company has problems.
|
|
|
|
|
In the old VB days, I worked on a project and we mandated Option Explicit for all files. One dev kept removing it as his code wouldn't build when it was switched on...
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
|
It was a long process of giving him a roll kick to the nadgers every time he checked in a file without Option Explicit . We needed to have a rota.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Jörgen Andersson wrote: If it's not the highest priority your company has problems. If we make it our highest priority we'll be fixing software that 'works' as far as the customer is concerned. We won't be able to make new software anytime soon. We won't have any revenues for the coming months, just fixes that might not fix all they were supposed to fix. And lots of angry customers.
No, if we made it our top priority THEN we have a problem... I might not be happy with it, my boss might not be happy with it, but that's just the way it is.
Luckily, any new software we built is built with option strict on
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|