|
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(); }
}
|
|
|
|
|
Jörgen Andersson wrote:
Naerling wrote:
Our company has a product where turning Option Strict On results in probably 1000's of errors
Then you need to start fixring now.
...snip...
If it's not the highest priority your company has problems.
FTFY
|
|
|
|
|
The Law of Missing Parentheses: Keep adding closing parenthesis at the end till the compiler stops complaining about them.
|
|
|
|
|
This is why it's good to always explcitly define your intentions with the proper parenthesis.
It makes it easier to detect mistakes like that and for someone else to read and deduce your intent. You can easily produce similar errors in logical grouping in C# or other languages. Even if not with that particular syntax. 
|
|
|
|
|
Option strict FTW! Option strict all the way!
Option strict is the first thing I turn on when anyone hands me a VB.Net project. I'll say it a million times: I would rather get a compile time error than a runtime error. Option strict won't flag every possible runtime error, but it will flag most of the boneheaded ones.
|
|
|
|
|
I can develop in more than 10 language (actually, I don't know exactly how much languages I now, I always forgot some) and I have no preference for the best language.
Almost all the time I use C#, but I use others as needed if the moment needs and it pays my bills.
But, I really don't like VB at all. I know VB since VB 5.0 (or 3.0, I don't remember, the year was 98) and these syntax flaws are really annoying. The VB (also VB .net) rounding is also terribly, all languages that I know truncate integer division and VB round it.
The backwards compatibility of VB .net with VB 6 projects made VB .net a horrible language.
I'm really experienced with VB (and VB .net) and it's a pain to correct legacy code in this language, so good luck!
|
|
|
|
|
You Remind me my Old company. Joining them I started developing with VB6. In my Project I did the entire project keeping Option Explicit on. Then I gave that entire project to my Senior.
Then he complained: Hey I cannot program, its making error.
??????????????????
what ????
I know I am coward since the day I know that fortune favors the brave
|
|
|
|
|
Before people start... The horror is NOT that this is VB code... Now with that out of the way...
A bit of weird code a colleague found recently...
If code.Length < 5 Or code.Length = 6 Or code.Length = 7 Then
Throw New Exception("Code should be 5 characters long.")
End IfMy guess is that the programmer assumed it would be 5 characters long or less. Then it turned out it could be 6 too so the Or code.length = 6 part was added, then the code was 7 at some occurrence... The users weren't stupid enough to enter an 8 character code so that one hasn't been added (yet) 
Why not simply check if code.Length <> 5? 
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
At least the programmer added a comment stating what the code should do.
|
|
|
|
|
If only the code did what was commented... Perhaps requirements changed and the comment is wrong?
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
Maybe the comment and the error message should have been
' This code should always be 5 characters or more than 7 characters.
|
|
|
|
|
Then he should correct the exception too:
"Code should be 5 characters long OR longer than 7."
Giraffes are not real.
|
|
|
|
|
OMG ... I can't look at it. I'm feeling sick. Thank you for ruining my day! 
|
|
|
|
|
or simply set the max lenght of the textbox = 5
|
|
|
|
|
In order to write secure code... whatever how important is your input, do Not trust the client, validate input data even @ back-end
think about client Validation just like good interface, to ease user life, to reduce hits on the server... no more
Last Egyptian Physicist
www.ameen.rr.nu
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
