After formatting, the biggest contributor to a code base feeling awkward or unkept is dead code. Dead code will rot your code base. As a good programmer, we should follow the scouts rule and leave the code base better than we found it. That means removing dead code. Now there are a few different types of dead code, so let's take a look. The first is commented code. We all know that commented code doesn't actually run,

The first is commented code. We all know that commented code doesn't actually run, but when we're first programming or we're trying out a new solution, everything's kind of a whip, right? That's fine, but what's not fine is leaving it in the code base. Doing so creates two problems. First, future programmers, even if that's you, are going to end up reading this code, even though it's commented out,

First, future programmers, even if that's you, are going to end up reading this code, even though it's commented out, we still see it as such, it leaves the code a little noisy. Second, we may not always know why this code is commented out, and as such, that's gonna prevent us from removing it, so we just leave these comments in here and if that cycle continues, our entire code base is gonna be littered with dead code. Again, this code is not executed. In fact, it's not even interpreted by php.

Again, this code is not executed. In fact, it's not even interpreted by php. It's immediately removed when parsed. As humans, we should do the same. Now, if you're not comfortable removing this code, remember you could always do so in an atomic commit, so I could add this specific change and commit it in a nice explicit commit message such as removing dead code. Another common form of dead code is unreachable code similar

as removing dead code. Another common form of dead code is unreachable code similar to commented code. This may be the result of WIP style programming. Unreachable code may also be related to unnecessary syntax or logic. Let's take a look at a couple more examples. Here we have a pretty obvious example of code that's after a return statement. In fact, PHPStorm is actually highlighting it.

after a return statement. In fact, php storm is actually highlighting it as an unreachable statement, but unreachable code could also be after other statements which end code execution. For example, we have the Laravel helper, abort. If this were higher up in the code, php storm no longer sees this block as unreachable, and there are other helpers in Laravel such as dd, which would end code execution.

and there are other helpers in Laravel such as dd, which would end code execution. If you come across code that's after a return statement, it's dead code and you should remove it. Other forms of unreachable code may be related to syntax or logic. Let's go back to the snippet from the intro video. Notice here that PHPStorm is actually graying out this break statement.

Notice here that PHPStorm is actually graying out this break statement. That's because it's actually unnecessary. As programmers, we are taught to end our case statements with a break, but just like the code we saw previously, if it comes after a return statement, it's actually unnecessary and so we could remove it. Taking this a bit farther, if you have a switch statement where all of the cases use return, you can actually refactor this into a match statement.

where all of the cases use return, you can actually refactor this into a php match statement. Again, this may not be readily visible because of the extra syntax, but if we take a second to collapse some of this logic, the dead code and the ultimate refactor will present itself. We see now that the break statement is grayed out as before and can be removed, and ultimately the return false at the bottom is now highlighted as unreachable.

and ultimately the return false at the bottom is now highlighted as unreachable. Removing that dead code now makes it much easier to see the refactor to a match statement. In fact, php now gives us the option, less obvious form of unreachable code is logic. A contrived example of this might be an if statement where its condition always evaluated to true or always evaluated to false, in which case the code inside of the if statement would never execute,

or always evaluated to false, in which case the code inside of the if statement would never execute, and again, we can see PHPStorm marking it as unreachable. Now this condition's pretty obvious, but if the condition were more complex, it may not be as easy to see. But in this case, what if mainDomain can never be example or it's always example. In either case, we would have dead code, dead code. That's much harder to spot.

In either case, we would have dead code, dead code. That's much harder to spot. If you come across this kind of unreachable code, remove it, save the future programmer from having to go down the same logical path you did. Final type of dead code is abandoned code, much like unreachable code due to logic. This one's pretty hard to spot. Let's take an example from the Laravel framework. This code builds the routes

Let's take an example from the Laravel framework. This code builds the routes for authentication using the route helper and it takes an options array, but what are the options as a php array? They could be anything, but if I highlight these, we see that there are only a few such as login, logout, register, reset, confirm, verify. Are there others? Is this code used anywhere else?

reset, confirm, verify. Are there others? Is this code used anywhere else in the Laravel framework? Those are pretty tough questions. I don't know the answer to that and it demonstrates the issue with dead code. I don't feel comfortable removing or refactoring this options array by leaving it. I'm allowing developers to pass anything even though it wouldn't have any effect on the code.

I'm allowing developers to pass anything even though it wouldn't have any effect on the code. Another example of abandoned code is code with temporal logic. Take for example, a Black Friday promotion. Once Black Friday has ended, the code related to that promotion is now dead. But this can take more complex forms such as code that is toggled on and off by configuration or maybe a user preference.

that is toggled on and off by configuration or maybe a user preference. What if the ability to send SMS is never available? What if no users have opted for that for a preference? This code is never executed and therefore it's dead. Much like before, if you encounter these, you need to determine if this is dead code or not. If it is, remove it. Clean up the code base, save that future developer from going down the same rabbit hole.

Clean up the code base, save that future developer from going down the same rabbit hole. That's the real issue with dead code. It hurts readability. Even if we can spot it as dead code immediately, we still end up reading it. Therefore, it makes the code noisy. If we can't spot it as dead code, we spend more time figuring out that it is dead code. Again, this matters to humans. It requires a human eye. As we've seen, an IDE may help spot some dead code.

Again, this matters to humans. It requires a human eye. As we've seen, an IDE may help spot some dead code. For example, in PhpStorm, we can run an unreachable code inspection on our code base to help find unreachable code. You may also use a static analysis tool such as php, stan to find more complex dead code. Either way, when you encounter instances of dead code, remove them. It'll make the code less noisy.

of dead code, remove them. It'll make the code less noisy and you'll be leaving it better than you found it.