From the course: Refactoring with GitHub Copilot

Code smells - Github Copilot Tutorial

From the course: Refactoring with GitHub Copilot

Code smells

“

You are familiar with code smells, even if you don't know that phrase by name. Code smells are not bugs, but they are things that just don't seem right. This first function, process order, is 40 lines long. Long functions can be a code smell. It might be okay, but it's worth looking at. I'm going to walk through this function. The comments indicate that it has four responsibilities: validate order, calculate total price, apply shipping, and send notification. If I was going to refactor this function, I'd use those each as jumping-off points. This isn't, of course, about testing, but imagine having to write unit tests for this function, a nightmare. The next function, createUser, is an example of too many arguments. Just look at the signature, it has 11 or 12 parameters. I'm not sure I'd even remember if email or phone number comes first. And do I have to pass an empty string for args I don't intend to use? Imagine a use case where a business logic requires adding a title to the user. Then you'd have to update all calls to it. Okay, I'm going to jump over to PHP for a moment. There are three classes in here: checkout, invoice, and report. Now each one has some hard-coded logic about tax. Fixing this might require creating a new tax class or even some kind of global constant. This code smell is often called shotgun surgery, because updating the tax rate would require updating a value on line 37, on line 24, and on line 9. I sure hope we got them all. I'm going to show one more example. Imagine a blog system, there's a user or author object and a blog post object. This is arguably not a terrible code smell. The blog post is formatting the author details for use in the blog. But, since the blog author has been established, this is actually called feature envy. The author class should be responsible for generating the string, and then the blog class should call that method. There's also things to consider about property visibility here. All the properties on author are public, which means they could be changed. I didn't cover all code smells here, not even close. But I flagged some of the more common things that are worth looking for. Code smells can be strong or faint, and they don't always indicate a problem, but they might. This means they are worth looking into when considering refactoring.

Contents