It's not that simple. Like most design decisions, it's not "good or bad", it is that you have different things for different purposes.
Depends on your goals. A lot of situations having something keep working with typing errors would be a bad thing. Strict typing makes it a lot easier to catch your mistakes instead of letting them get into production code.
By and large, most people feel that strict typing is normally the better choice. But not all. But that you feel that non-strict is better across the board, is certainly the rare opinion.
lol that is because i hate to see errors pop up here and there
hhhhh maybe, i have to check
JaredBusch last edited by
I personally hate opening a project and seeing that it doe snot have strict enabled.
The first thing I will do it change that, fix all the warnings, and recommit.
Prior to doing anything else I am supposed to do on that project.
tonyshowoff last edited by tonyshowoff
Weak typing is easier for beginners, but it can make things difficult for larger, more complex projects; this is something we kept bumping up against in PHP, which is why PHP 7's strict typing is great and we've saved a lot of debugging headaches and dealing with other problems by making everything strictly typed.
1 == "1" True 1 === "1" False
0 == 0.00000000001 True
Languages like C++ and Java always have type strict comparison, so it's as if you're typing === every single time.
Do it right the first time.
As @JaredBusch said above, when I don't see it enabled, it's just a sign of the horrors to come. Even well written JS code will have errors typically in it when people don't use strict.
In other words, if you feel as though you should be able to suppress syntax and type errors knowingly, you should not program; get someone else to do it. I sometimes hurt feelings saying this, but if you approach any other job in a similarly lazy manner, you'd be fired or in some cases imprisoned when your building collapsed or killed someone.
In actuality, programming errors have killed people, maybe yours won't, but that's no excuse to intentionally do a bad job because you're lazy. It's bad for your customers, bad for your environment, bad for your users, and bad for you when things fail and break and you don't know what went wrong because instead of logging properly and completely, you suppressed everything.
In addition to returning to projects much later, laziness with typing and also syntax causes people to write bad code initially so later on they have a much harder time reading their own code or debugging. Some people say this doesn't happen to them, perhaps with tiny scripts that's true, but beyond that they're just lying, or they're stupid.
So no, it's not awesome, and I've personally had to fix cases where ignored notices from PHP created failed database queries and data loss, as well as incomplete data states, and there's the recent example of a similar declaration problem leading to a guy deleting all of his customer data, that is also an example of why you don't program in production, another massive problem out there.
Either turn on all warnings and notices, enable strict everywhere you can or stop programming, no matter what it is you're working on. There's enough bad code out there, fix your approach before you get too old to do it and you're that old programmer everyone hates or that old IT guy who writes bad scripts which break things everyone else has to fix.
So I agree with @scottalanmiller, it depends on what your goals are, either to write something that works and is easier to maintain later on, or to write garbage to create a hell for yourself and other people which may or may not destroy data and lose things with no further information as to what went wrong.
Now that you know the importance of it, any decision otherwise beyond this point is being intentionally stupid and reckless.