Transcript from the "Even More strict" Lesson
[00:00:00]
>> So now I'm gonna talk about some additional flags that we've turned on, beyond the regular strictmode stuff, so unused locals and parameters and implicit returns. So this just makes sure that I'm not leaving any unused code around, or at least brought to my attention, implicit returns, would be if I were to say, look, I'm returning a number here, A minus B, I'm returning a number.
[00:00:32] So this doesn't seem that harmful, all right? Like we know we're returning a number here. TypeScript can understand it. Here's where it gets tricky. You can make a change like this. And it's just way too easy, To change the nature of the function. I love explicit specification of return types, because when I'm designing a function, I make it a guarantee.
[00:01:07] You give me two numbers, I will return you the difference. It's just way too easy to sort of change the nature of a method here, and to fundamentally change what it's gonna return. So I'm either gonna run into this problem here, or I'm gonna run into it wherever subtract is being used, and I want my errors to pop up closest to the side of the defect.
[00:01:33] So here, I want to say number. I am returning a number. And now it's gonna tell me all right, like you're returning, it's some path in here, is returning undefined, or not returning at all explicitly. And then I have to resolve this. I would rather deal with it at the site of the function, then where are the functions being used.
[00:01:57] Where someone's consuming subtract, and they said, I thought I would get a number, but now it says I'm getting a number or undefined. That might be much more cryptic problems attract down, falter cases and switch. So some people enable this, this makes sure that you have a break in every case clause.
[00:02:13] I still have habits from my c++ days. I have no problem with falling through case clauses. I leave this, I'm willing to allow those falters. But this is how you would have TypeScript responsible for making sure you can't do that. Personally, this I would say is like more of a matter of taste.
[00:02:36] We already talked about types, this is what we use to make sure that just couldn't be used in our source folder, only the test folder. And then finally strip internal we talked about as well. This is something that's not part of the standard boilerplate here. This takes export and private functions, they may be exploited strictly for the purpose of testing them.
[00:03:00] And it makes sure they never appear and type information. So that your users will not get that autocomplete, with a bunch of underscore stuff that says please, don't use this. Like let's just make it, so never as in the autocomplete to begin with