When is it better to add more code when you're refactoring? We've heard that deleting code is the best kind of refactoring, the best kind of code reviews end with more negatives than positives on the Git diff. But when does it make more sense? When is it going to improve your code to add more to it? When does adding more code actually simplify the code? That's what we're talking about in today's episode of Developer Tea. My name is Jonathan Cutrell. Today is an episode where we're talking about practices, really practical stuff that you can take and use in your practice today, in your job today, or if you're a aspiring developer. This is something you can take into the future as you learn more about coding. So I'm really excited to get into this topic because it's not intuitive. We run by these heuristics that we have built into our brains that eliminating duplication, for example. We've talked about this on the show before. I encourage you to go back and listen to previous episodes where things keep it simple stupid. This is something that we have in our brain as a heuristic and don't repeat yourself dry. There's plenty of these heuristics that we have built in. And usually they lead to a good outcome, usually they give us a positive way of thinking about good practice, good rules to follow. But unfortunately, sometimes these heuristics can lead us down the wrong path. So that's what we're talking about today. And first I want to kind of prime the way you're thinking about this by reminding you about what code isn't intended for. What is code? Why does it matter to not repeat yourself? Let's discuss this very quickly. And then we're going to talk about three specific situations when adding more code makes the most sense for a given refactoring session. So let's take this specific concept, the dry concept. Don't repeat yourself. Why does dry make sense? Well, for a few reasons. The first reason is if you have the same thing happening in your code multiple times, then it's very possible, if not likely, that changing that thing in one place would mean needing to change it in another place. So not repeating yourself would mean taking that particular concept and only writing it once. How does that happen? How can we actually protect ourselves in this way? How can we make sure that we're not repeating ourselves? Well, that's actually part of one of our three ways of adding more code to make it more clear. We're going to talk about that right after we talk about today's awesome sponsor, WooCommerce. Today's episode is sponsored by WooCommerce. WooCommerce is an open source eCommerce solution. It's built on WordPress and nearly 30% of all online stores on the web are powered by WooCommerce. WooCommerce is fully customizable. You can build a unique store to suit your specific needs and you can keep full control and flexibility of that store. Now, you always get to keep your data. This is very important about WooCommerce. If you ever decide to leave for whatever reason, WooCommerce is not going to hold your data hostage. They're going to let you take it with you. But on top of that, you can always customize WooCommerce because it's built on an open source platform, you can customize it yourself. You can write extra code, your own custom code to integrate any kind of thing that you can imagine wanting to integrate. Now, most of the time, this kind of integration has already been done by somebody. And more importantly, it's available to you. There's over 140 extensions available in the official WooCommerce.com marketplace. And subscribing for a year gets you support and updates on all those extensions. There's a ton of reasons to use WooCommerce. We're going to be going through these over this quarter, the first quarter of 2018. But this is kind of the introduction here. It is one of the most important things for commerce on the internet, right? Because 30% of all online stores. This means basically every third online store that you use probably was built with WooCommerce right around that. So I encourage you, if you are looking for an eCommerce solution, I encourage you to check out WooCommerce. Head over to WooCommerce.com slash Developer Tea. And if you use the code, the promo code Developer Tea, you'll get 20% off. This is only good until the end of March 2018. So head over to WooCommerce.com slash Developer Tea. Thank you again to WooCommerce for sponsoring today's episode of Developer Tea. So when does it make sense to add code rather than removing it when you're in the process of refactoring? Well, I'm going to give you three practical times when adding more code. These are actually refactoring patterns when adding more code makes more sense. The first time is when you're replacing a variable, a temp variable with a query. Now, what does this look like? Well, let's say you're inside of a method and you set a variable for the price of a given item and you're evaluating something about that item to determine the price. I would say for whatever reason it's not saved. And you have to actually do some work to figure out what the price is going to be. Maybe you do it based on the person who's visiting based on their location because you want to factor in sales tax or something. All of this is procedural code that you're having to write. And so any time that you need to figure out the price, you have to write that procedural code. Now, going back to our discussion about dry, we don't want to repeat ourselves in this situation, right? We don't want to set price multiple times and multiple methods across the file because the likelihood that we're going to forget to update one when we update another one is pretty high. We're going to end up having a mismatch between different price concepts. So what we want to do to avoid this is we want to extract that work out of the variable, we want to extract it away and put it into a method. We want to put the price procedural code into its own method. So now instead of creating a variable called price and saying price equals and then a bunch of code after that, instead create a method called price. And for that given item, you can define the price based on whatever is inside of that method. So now anytime you call price, you're going to get the same thing no matter where you are in the code. This technically will end up with a little bit more code. You're adding a new method, but overall that code is going to be much more maintainable. Similarly, another time when you add more code to create cleaner code, when you're creating a conditional, let's say you have a branching conditional, you have one condition, you want to do something if that condition is true and then you have another condition, your else condition maybe. And so you have these multiple conditions and inside of your parentheses or however your particular language is working for that condition, you're creating multiple statements to check against. Maybe you have ors or you have combining ends, you have multiple nested conditionals, maybe even have turnaries inside of your conditionals. That kind of conditional statement is incredibly difficult to read and incredibly difficult to maintain. So instead of putting all of that inside of the conditional itself in a similar way that we previously were extracting a temp variable out to a query, now we're going to create a method for your conditional. This is going to consolidate your conditional into a concept. Most of the time when you have a condition, that condition has a name. Whether that name has been identified yet or not is determined by how you've written your code so far. So if you have a name for this concept, go ahead and pull it out of the conditional and create a new method that wraps up that conditional. Now inside of your conditional statement, all you have is a single method call. And if you want to change that condition in the future, you can. Most of the time you're going to need to use that named condition in other places anyway. The third and final place that we're going to talk about adding code as a way of making your code more readable is quite simply lengthening your variable names. If you've ever written Swift or you've written a an iPhone app, you know that the built-in methods in Xcode typically have very long names. Now you would think that with very long names, you would end up not being as productive, but the opposite seems to be true. The longer these variable names are, the more clear they are. And as it turns out, it's a little bit easier to read long variable names than we initially may have expected. Many of us were trained to use short variable names, especially if we went through something like an algorithm course using variable names that are one or two letters long to describe a much more complicated concept underlying. So the problem with this, there's multiple problems with using short variable names. First of all, the benefits that we think we're gaining, we actually are not gaining in most cases, especially if your code is compiling and stuff is getting compressed out anyway. So it doesn't really matter how long your variable names are because your compiler is going to handle that for you. So you're probably not getting any good benefit out of shortening those names. The second problem is most of the time when we shorten, we either are using some convention is defined by the common way of doing that particular algorithm or we're using a shortened name like an acronym that we understand for a limited period of time. In other words, if you were to lay this project down and come back in three months and try to understand what that algorithm was doing, you wouldn't remember what that acronym was. Those variable names that you've created, the acronym variables that you've created, they no longer have meaning to use. So now, not only are they not following the convention, but they're also very confusing. They're confusing to look at because you don't remember what they mean. Anyone else coming to the project who didn't create that acronym likely won't remember what they mean either. So there are sometimes when this doesn't apply, for example, when it's an acronym that is widely known, that may be a time when an acronym is okay to use, but by and large, if you expand your variable names to be more descriptive, your code is going to become more readable. And this is, again, it's not intuitive because we want our code to be pretty and small. We want it to be visually appealing and we want it to be easy to scan our eyes across it. We don't want it to take a long time to read it. The problem is that most of the time, even when it doesn't take a long time to read it, it takes a long time to parse it for our brains to understand what's going on. So I recommend that you write descriptive variable names. Don't worry about how long they are to begin with. And if you find that they seem laboriously long, then later you can go and figure out maybe a more concise but still complete way of naming that variable in the future. Thank you so much for listening to today's episode of Developer Tea. Thank you again to WooCommerce for sponsoring today's episode. You can get 20% off by using the code Developer Tea, head over to WooCommerce.com, slash Developer Teato get started today. Thank you again for listening. If you enjoyed today's episode, I recommend that you subscribe in whatever podcasting app you use so that you don't miss out on future episodes of Developer Tea. We're focusing on practices, principles, and purpose this year. Today was a practices episode. I hope that you can take it and start using it right away. Thank you so much for listening and until next time, enjoy your tea.