Do you use 'strict off' option, 'explicit off'? Or may be 'strict custom' and some other options like 'Implicit type. Object assumed', 'Late binding', 'Implicit conversion'?
+9
A:
Never. OPTIONS STRICT OFF is the same as OPTIONS BADPROGRAMMING ON.
OPTIONS STRICT OFF relaxes some of the checks that VB.NET makes. It relaxes language rules. Those rules are there to save you from yourself. Don't ever prevent the language from saving you from yourself. This is especially true if you're coming from a more releaxed environment, in which case chances are that you need saving.
Another thing to note is that most programming languages don't have a switch to say: please allow me to shoot myself in the foot.
John Saunders
2009-06-30 12:34:12
+1 Because you are right and made me laugh. That being said perhaps you could explain a little bit why "strict off" is a bad thing :)
Andrew Hare
2009-06-30 12:36:42
So what you're saying is Ruby = Bad Programming?
JaredPar
2009-06-30 12:40:41
@JaredPar: does Ruby have an OPTIONS STRICT OFF command, or is it always off? That's different.
John Saunders
2009-06-30 12:41:13
I always thought pointer arithmetic in c was an implicit invitation to shoot yourself in the foot. Then fall down a black hole :-)
Dan F
2009-06-30 12:44:54
@John, AFAIK ruby is always dynamic / option strict off. Turning option strict off essentially turns VB.Net into a dynamic language of sorts. So saying option strict off equals bad programming is essentially saying the same for dynamic languages in general
JaredPar
2009-06-30 12:46:01
@JaredPar: Ruby was designed to be dynamic, and seems to have the culture of a dynamic language. In my experience, most of the abouse of OPTIONS STRICT OFF does not come from good intentions, but from people not trained as programmers, or who are being lazy. That's the difference in my mind. I would favor ON being the default for all new projects and source files. If someone wants to turn it off for late binding, great. But I'd rather not encourage bad practice absent a culture that actively supports successful dynamic language dev in VB.
John Saunders
2009-06-30 14:18:41
@John, VB.net was also very much designed to work with Option Strict Off. It's been in the language for decades and every feature that comes into VB.Net is considered in the context of Option Strict Off. You keep saying it's bad practice but that Ruby is fine. I can't see any distinction between operating VB.Net in "dynamic" mode and using a dynamic language, they are equivalent.
JaredPar
2009-06-30 22:13:21
@JaredPar: Perhaps it's my feeling that most of the VB.NET developers who still use OPTIONS STRICT OFF do so either because the code was that way before they started, or because they started off in a lax development environment; possibly one that did not use OO. Jared, my first BASIC was Dartmouth; my first PC Basic was Quick; my first Visual Basic was 3. I have worked with one high-quality, sophisticated application using VB6. Only one.
John Saunders
2009-07-01 00:16:05
New VB.NET developers should use OPTIONS STRICT ON except where late binding is required. That way, we won't be having this discussion ten years from now. Otherwise, the sins of past omission will be visited on the subsequent developers who think this is just the right way to code in VB.NET. OBTW, Ban Modules!
John Saunders
2009-07-01 00:17:32
@JaredPar: 1 more: its not a question of whether VB.net was designed to work with OPTION STRICT OFF. The question is why developers are using that option today. My perception (and it may be a false one) is that these habits are coming from developers who came up when the OO features of VB were not widely used. Some are developers accustomed to VBScript, possibly from Classic ASP. My perception is that most are not using this because they have a specific need for late binding or other dynamic features. They're using it because they don't know better, or don't know how to be better.
John Saunders
2009-07-01 00:25:21
+1
A:
I like to use Strict=On, so my code fails at compile time rather than when it's gone live, and Explicit=On because in a static language it would be kind of weird not to declare your variables.
Iain Hoult
2009-06-30 12:37:13
+2
A:
Generally I leave Option Strict On at the project level because in general I want strict semantic checking. In the cases where I do want to use late binding I will turn Option Strict Off at the file level.
JaredPar
2009-06-30 12:39:49
A:
I always turn Strict ON when I start a new project or when I receive an active project
I will never provide support on a project with that OFF, ever
Fredou
2009-06-30 12:42:07
+2
A:
Always develop in any language with full warnings and restrictions on. No exceptions, ever.
To do otherwise is a false economy, sure it may seem to work, but sure as hell it'll come back to bite you later
(currently debugging a series of PHP web applications where the original 'coder' had suppressed all errors and which, literally, display several hundred errors per page when enabled. "Make sure variables are defined before using them in tests? Why would I do that when i can just suppress the error and not have to think?" )
Cruachan
2009-06-30 12:42:25
A:
I have done it both ways. Always have it on. I did not have it on when was doing some quick and dirty vbscripts and it cost me debugging time. Turn it on, keep it on
Anthony
2009-06-30 12:45:18
A:
I usually have Strict OFF if I'm doing some quick-and-dirty prototype or spike where I know I won't have to maintain the code in future.
The word "know" is key here though, if there's any chance the code will migrate into something you need to support then set Strict ON and deal with any errors before they come back to bite you.
John Donoghue
2009-06-30 13:29:39