One thing you might want to consider, depending on your needs: the way you have this coded, values over 100 will only snap back to 100 when the player actually visits the stats screen. This is fine if all you care about is creating the illusion that you’ve bounded the stat values, but in reality, there’s a very real possibility that the stats will go out-of-bounds and only reset when the player actively goes to check on them.
Unless your game is particularly mechanics-heavy, this probably won’t be a discernible issue for the player—so long as you never try to mix regular arithmetic with fairmath. Then things get really messy, because fairmath categorically does not work on values over 100 or below 0—in fact, I’m reasonably sure you’ll throw an error if you try.
Now, like I said, if you only ever do regular addition and subtraction with your stat values, you can stick with what you’ve got now, and it should work. (Though, your more code-savvy readers might cringe a little if try peeking behind the curtain.) However, if you anticipate even the slightest chance that you’ll ever try to implement fairmath (or want to make your code more efficient in general), I’d recommend saving yourself the headache and making adjustments now.
The obvious solution, of course, is to just exclusively use fairmath, which I believe is what most authors do. But if you don’t want to do this, the other method would be to create a subroutine that snaps out-of-bound values back and *gosub it every time you change a stat value, instead of waiting to correct it until the player visits the stat screen. There’s a tutorial on how to do this here. This is a little more bothersome than other methods, but it’s the most surefire way to mix normal arithmetic and fairmath while avoiding errors.
That all being said: if you decide to commit to exclusively using one method or the other, you can just ignore everything I said and carry on with what you’ve got. Either way, good luck with whatever it is you’re working on!