Our next technique relates to magic numbers. So take a look at this. We have a test that asserts that a User can be awarded experience. Let's go through it really quick. Given I have a User, and that User earns experience two times, well, if we fetch their experience relationship there should be two items in that collection, and further, the total number of points they should have is 2100, or the sum of these two. Now if I give that a run, it does pass. However, I do want to point your attention to these numbers here, 2100. What are they?

And worse, what if they are repeated in multiple areas of your application? You may know that 2000 refers to upgrading an account. Maybe those are the points you earn when the User upgrades. You may know that, but somebody else on your team may not know that, or you six months from now may not remember that. So this is what we refer to as magic numbers. Numbers that have some kind of significance that isn't made clear in the code. Assuming these are important numbers, what if instead we signed a name? I'm going to go to my Experience model, and let's set up a constant. So what are the significant actions that generate experience?

I'm going to go to my Experience model, and let's set up a constant. So what are the significant actions that generate experience? One might be upgradeAccount. And like we said, it sounds like that is worth 2,000 points. Okay, so before we had a magic number, after we've given it a name. Okay, so now all I have to do is reference that constant. experience, upgradeAccount. And I will import that. Okay, so if I give the test a run again, I'm still going to get green, but this, in my opinion, is a win.

All right, let's come back, and we'll update it. All right, give our test a run again, and we still get green. You get the basic idea. So you'll encounter things like this all over the place. In our example, we're using experience points, but another use case would be even response codes. So if we take a look at Symfony's Response class, you likely know if you're returning a Response of some kind that a 200 is okay. We're all set to go. You'll know about a 400 or a 404.

We're all set to go. You'll know about a 400 or a 404. The more you work with these things, the more they commit themselves to memory. But it doesn't change the fact that they're still effectively magic numbers. How many times have you had to refresh your memory as to what a 422 is? So again, when providing a response, maybe in your controller, while yes, you could hard code 403, nobody's going to kill you, but instead consider using the named version. So this is irrelevant for this test, but yeah, you would pull in your response and then reference the constant, HTTP_FORBIDDEN. Now somebody else or yourself six months from now doesn't have to look up what a 403 is.

the constant, HTTP_FORBIDDEN. Now somebody else or yourself six months from now doesn't have to look up what a 403 is if they forget. Instead, they instantly know, oh, that's a 403 forbidden. It's the same approach. We replace a magic number with a name, and that name is typically stored as a constant, like you see here or even on our Experience model. So there you have it. Anytime you have a magic number in your system that's not immediately clear, instead consider giving it a name.

Anytime you have a magic number in your system that's not immediately clear, instead consider giving it a name.