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'?
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.
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?" )
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.
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.
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
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
Option Strict Off and Option Explicit Off are False Economies in production code.
You will spend more time chasing strange bugs than it takes to write your code error and warning free in the first place. My experience has taught me this.
The only exceptions is when I need to use late binding in which case I have to switch it off.
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.
Related
Since MariaDB 10.2.4 defaults is:
sql_mode = STRICT_TRANS_TABLES
and
innodb_strict_mode = ON
System requirements on https://get.typo3.org and in Installation guide do not explicitly mention it, but I know the restriction about not supporting strict mode got removed from the readme quite some time ago. I am not sure about innodb_strict_mode though.
Is there anything else to consider? What about third party extensions?
Resources:
Since MariaDB 10.2.4 defaults is:
sql_mode = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
https://mariadb.com/kb/en/sql-mode/
When this manual refers to “strict mode,” it means a mode with either or both STRICT_TRANS_TABLES or STRICT_ALL_TABLES enabled.
https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html
Since MariaDB 10.2.2
innodb_strict_mode = ON
InnoDB strict mode is similar to SQL strict mode. When it is enabled, certain InnoDB warnings become errors instead.
https://mariadb.com/kb/en/innodb-strict-mode/
This isn't intended as a full answer, but too long for a comment.
Had a lot of 3rd party EXT going haywire. It is often manageable if you install the extension anew, but upgrading an old install into an STRICT db resulted e.g. in just some views/subpages throwing exceptions while the rest of the system seemed to work.
You might spot a problematic extension due to the SQL definition making problems already (e.g. wrong default values), but that isn't a guarantee.
However sometimes specific queries cause problems as mentioned above. Most of the times however it is hacky SQL or using implicit type casts (especially date fields).
Checking an extension if its sql file would work and if it is using Doctrine throughout is a good indicator IMHO. But even for the rest nothing an acceptance regression test suite can't find, but some of the errors were such a PITA we disabled STRICT mode again.
Nevertheless: there is no reason not all extensions should allow strict mode.
First, thank you for taking pity on me and reading this issue. I CANNOT for the life of me figure out what extension I might have installed that is causing this issue, but it is EXTREMELY cumbersome.
Whenever I begin to type code (VB I think it also occurs in C#), for example "For Each" once I hit the F it forces a set of parentheses. Which would look like F(), but because I keep typing it looks like F(or). This only occurs when coding inside code blocks like a function or a sub, but when I'm creating the function it does not occur. I've disabled any and all power tools and the like, or at least I'm 90% sure I've done this for all of them, and yet it still occurs.
I'm usually pretty proficient at digging about the net and finding the answer, but for this one I'm at a loss. There is just too many keywords involved, so all I see is non-related topics, or how to make the parentheses occur, not get rid of them.
If anyone can provide some steps to resolve this, I'm happy and eager to try them. It's just such a hassle to live with for right now.
If you think it is a Visual Studio extension, then start by disabling all of them and adding them back one at a time.
You can also run VS with the command line switched to disable features.
Devenv switches
The simple answer to the cause is the Codealike VS Extension. I logged a bug with them and hopefully they'll fix it soon
Context: a program written in VB.NET, developed/maintained in VisualStudio2012, targeting framework v3.5.
A few years ago, the program was in VB(6) and we "translated" it to VB.NET. As a result of the transformation, which was mostly automated, we still have quite a few places in the code where formatting of doubles (and dates/...) for textual presentation is processed as in:
Dim sValue As String = Microsoft.VisualBasic.Compatibility.VB6.Format(dblValue, "0.00")
Conversely, when we need to extract a Double value from such a string, we use
Dim dblValue As Double = CDbl(sValue)
CDbl "listens to" the System.Globalization.CultureInfo.CurrentCulture of the applications Thread, and this does NOT change when - during the run of the code - you change the Regional Settings through the Control Panel.
However, the VB6.Format as executed in the code starts out conforming to the currentCulture of the application (as you might expect), BUT apparently (I didn't know this, but accidentally found out) listens to CHANGES in the Regional Settings and responds immediately to any changes you make there during the program execution. This implies that the CDbl() and VB6.Format() become mutually inconsistent.
Of course, changing the Regional Settings during program execution is awkward, and moreover, if you wish to support it, you can manage it by catching the SystemEvents.UserPreferenceChanged (and -Changing) events and act upon their occurrences.
However, the "different behaviour" of VB6.FORMAT versus "normal" casts as CDbl(someString) regarding changes in the Culture/Regional Settings, strikes me as undesirable. Preferably you would have VB6.Format to comply ALWAYS with the application/thread-CurrentCulture, and you may THEN choose how you want your code to respond to userpreference changes. Furthermore, I'd like to gain some more insight in the issue.
My question, therefore, is:
Is there a way to compile/arrange/... things such that the (Microsoft.VisualBasic.Compatibility.)VB6.Format listens to the application-CurrentCulture and NOT respond - without "our consent" - to changes in Regional Settings?
Additional information:
The program is compiled with - for the visualbasic stuff - a reference in the project (VisualStudio2012) to:
C:\Windows\Microsoft.Net\Framework\V2.0.50727\Microsoft.VisualBasic.Compatibility.dll (and ...Data.dll).
Any "educational" information or suggestion is welcome. The issue is not causing any real problems in our program, but I feel that we should/might have a better understanding and maybe even methods to make things more robust.
The VB6 Format() function is actually an operating system function under the hood. VarFormat(), a function exported by oleaut32.dll. Backgrounder answer is here. The MSDN library article is here.
As you can tell from the MSDN article, the function doesn't permit specifying a culture or culture specific settings, other than the day-of-week rules. This function dates from 1996, life was much simpler back then. So what you see is now easy to explain, it cannot know anything about the .NET Thread.CurrentCulture setting.
I have recently switched from a c# team to a vb.net team. One of the things I have not been able to find an answer to is the differences in compile error / options. Let me explain.
In C# i will, using default settings, get a compile time error when trying to pass in an invalid type to a templated class like below. Here I create an Animal with a string type and afterwards I pass in a datetime which results in an compile error.
IAnimal<string> animal = new Animal<string>();
animal.SetTrainer(DateTime.Now);
I know I will get the same compile time error in vb.net with "Option Strict". There is, however, a lot of legacy (VB) code in the same file that will not compile with "Option Strict". What options do I have. Im thinking this:
Switch to "Option Strict" and fix all errors. Will take some time and may break working code.
Maybe there is an alternate that will ensure compile time check of generics. After all generics are rather new so maybe there is a way of always enforcing this.
?
Thanks in advance
Double click your Project -> My Project.
Goto Compile and look for Warningconfiguration
Now you can change some settings.
Implicit cast
Late Binding
don't make them errors but warnings.
That won't make compile time errors but you can at least see some warnings.
Another solution would be to make your class a partial class and move your code to a new file. You can set Option Strict / Option Explicit on a per file basis.
Switch to "Option Strict" and fix all errors. Will take some time and may break working code.
Yes, do that. It will help you remain sanity.
Most errors that will pop up are probably simple casting issues, which are easy to fix (a CInt here, a ToString() there...).
You don't have to fix your whole solution or project at once, since you can enable Option Strict On at file level. Make it a good habbit to fix every file as you have to touch it.
This will not always be possibly, but you can also just move code that heavily relies on Option Strict On (e.g. COM stuff) to another file without breaking changes.
I have a whole list of validation rules that are either warnings (can continue) or fatal (cannot continue).
The fatals are easy, but the warnings are stumping me as far as a succinct way to set them up. I can handle the warnings easily enough, but it is messy.
Is there a declarative way to handle 'warnings'?
No, there isn't. I ended up adding a flag 'ValidateAll' to my entities and use that to force the warnings to become errors depending on state.