3 ms·
Huge TypeScript fan here - been using it since its 0.8x days. And I'm very interested in the new --strictNullChecks compiler flag. But I'm trying to implement t
by smithkl42 10y ago
Huge TypeScript fan here - been using it since its 0.8x days. And I'm very interested in the new --strictNullChecks compiler flag. But I'm trying to implement that on our current codebase, and I'm coming to the conclusion that it's still a bit premature. There are a lot of very common and harmless JS (and TS) patterns which this breaks, and for which it's been difficult (for me at least) to find a workaround.
Turning on --strictNullChecks flagged about 600+ compiler errors in our 10Kloc codebase. I've addressed about half of those so far, and I can't say that any of them have actually been a real bug that I'm glad got caught. On the contrary, because of the weird hoops it makes you jump through (e.g., encodeAsUriComponent(url || '')), I'd say that our codebase feels even less clean.
- evmar 10y agoOne counterintuitive observation about introducing stricter type checking into an existing codebase is that it rarely finds bugs. Why? Because the existing codebase typically "already works", in that issues that the type checker might have found were already discovered through automated (or manual!) testing. The real value of more strict type checking is when writing new code -- you won't need to spend as much time discovering bugs in development or writing tests for issues the compiler is catching.
- smithkl42 10y agoGood point. And I can see that I would have made different (and probably cleaner) design decisions in certain places if strict null checking had been a part of our code from the beginning.