Vox

Leitura de 15 min

3 Times When More Code Means Better Code

Summary

This episode challenges the common heuristic that deleting code is always the best refactoring approach. Host Jonathan Cottrell argues that there are specific situations where adding code actually leads to better, more maintainable software.

The discussion begins by examining why principles like DRY (Don’t Repeat Yourself) exist and how they sometimes lead developers astray when applied too rigidly. The core premise is that while eliminating duplication is generally good, there are times when adding code serves important purposes like improving clarity and reducing future maintenance headaches.

Cottrell presents three practical refactoring patterns where adding code makes sense. First, replacing temporary variables with query methods centralizes logic that would otherwise be duplicated. Second, extracting complex conditional statements into named methods makes branching logic more readable and reusable. Third, using longer, more descriptive variable names improves code comprehension over time, especially when returning to code months later.

Throughout the episode, Cottrell emphasizes that these approaches counter intuitive programming instincts but ultimately lead to more maintainable code. The examples demonstrate how adding methods and using descriptive names, while increasing line count, actually simplifies understanding and reduces bugs in the long run.

The episode concludes with practical advice for developers to reconsider their assumptions about code brevity and focus instead on clarity and maintainability, even if it means writing more code initially.

Recommendations

Tools

  • WooCommerce — An open-source e-commerce solution built on WordPress, powering nearly 30% of online stores. Mentioned as the episode sponsor, with customization options and extensions available.

Topic Timeline

  • 00:00:00 — Introduction to counterintuitive refactoring principles — Jonathan introduces the episode’s premise: challenging the common belief that deleting code is always best during refactoring. He explains that while heuristics like DRY and KISS are generally helpful, they can sometimes lead developers astray. The episode will explore three specific situations where adding code actually improves code quality.
  • 00:02:02 — Examining the DRY principle and its purpose — Cottrell discusses why the DRY (Don’t Repeat Yourself) principle makes sense, focusing on maintainability. When the same logic appears in multiple places, changing it requires updates in all locations, increasing the risk of inconsistencies. This sets up the foundation for understanding when adding code might be beneficial despite seeming to contradict DRY.
  • 00:04:53 — First pattern: Replacing temp variables with queries — The first practical example involves extracting procedural logic from temporary variables into query methods. Instead of setting a price variable with complex calculations in multiple places, creating a price() method centralizes the logic. This adds code (a new method) but ensures consistency and reduces duplication risks.
  • 00:07:01 — Second pattern: Extracting conditionals into methods — Complex conditional statements with multiple branches, nested conditions, or ternaries become difficult to read and maintain. The solution is to extract the conditional logic into a named method. This adds code but creates a reusable concept with a clear name, making the original conditional much simpler to understand.
  • 00:08:44 — Third pattern: Using descriptive variable names — Cottrell argues against short variable names, especially acronyms or single-letter names common in algorithm courses. Longer, descriptive names improve readability over time. While counterintuitive to code aesthetics, descriptive names help developers understand code when returning to it months later. Compilers handle optimization, so name length doesn’t affect performance.
  • 00:11:30 — Practical recommendations and conclusion — The host recommends starting with descriptive variable names without worrying about length, then refining later if needed. He emphasizes that while code should be visually appealing, comprehension is more important. The episode concludes by encouraging developers to focus on clarity and maintainability over brevity, thanking the sponsor WooCommerce, and inviting listeners to subscribe for future episodes.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2018-01-26T10:00:00Z
  • Duration: 00:12:26

References

Podcast Info

Transcript

[00:00:00] When is it better to add more code when you’re refactoring? We’ve heard that deleting code is

[00:00:10] the best kind of refactoring. The best kind of code reviews end with more negatives than positives

[00:00:16] on the git diff. But when does it make more sense? When is it going to improve your code

[00:00:23] to add more to it? When does adding more code actually simplify the code? That’s what we’re

[00:00:29] talking about in today’s episode of Developer Tea. My name is Jonathan Cottrell. Today is an

[00:00:34] episode where we’re talking about practices, really practical stuff that you can take and use

[00:00:40] in your practice today, in your job today, or if you’re an aspiring developer, this is something

[00:00:47] you can take into the future as you learn more about coding. So I’m really excited to get into

[00:00:52] this topic because it’s not intuitive. We run by these heuristics that we have built

[00:00:59] in today. We run by these heuristics that we have built in today. We run by these heuristics

[00:00:59] that we have built in today. We run by these heuristics that we have built in today. We run by

[00:00:59] to our brains that, you know, eliminating duplication, for example. We’ve talked about

[00:01:03] this on the show before. I encourage you to go back and listen to previous episodes where things

[00:01:09] like keep it simple, stupid, right? This is something that we have in our brain as a heuristic

[00:01:13] and don’t repeat yourself dry. There’s plenty of these heuristics that we have built in

[00:01:19] and usually they lead to a good outcome. Usually they give us a positive way of thinking about

[00:01:26] good practice, good rules to follow. But unfortunately, sometimes these heuristics

[00:01:32] can lead us down the wrong path. So that’s what we’re talking about today. And first,

[00:01:38] I want to kind of prime the way you’re thinking about this by reminding you about what code is

[00:01:44] intended for. What is code? Why does it matter to not repeat yourself? Well, let’s discuss this

[00:01:51] very quickly. And then we’re going to talk about three specific situations when adding

[00:01:56] more code makes the most sense for a given refactoring session. So let’s take this specific

[00:02:02] concept, the dry concept. Don’t repeat yourself. Why does dry make sense? Well, for a few reasons.

[00:02:11] The first reason is if you have the same thing happening in your code multiple times, then it’s

[00:02:17] very possible, if not likely, that changing that thing in one place would mean needing to change

[00:02:25] it in another place, right?

[00:02:26] So not repeating yourself would mean taking that particular concept and only writing it once.

[00:02:34] How does that happen? How can we actually protect ourselves in this way? How can we make sure that

[00:02:41] we’re not repeating ourselves? Well, that’s actually part of one of our three ways of

[00:02:46] adding more code to make it more clear. We’re going to talk about that right after we talk

[00:02:50] about today’s awesome sponsor, WooCommerce. Today’s episode is sponsored by WooCommerce.

[00:02:55] WooCommerce is an open source, open source, open source, open source, open source, open source,

[00:02:56] e-commerce solution. It’s built on WordPress and nearly 30% of all online stores on the web

[00:03:02] are powered by WooCommerce. WooCommerce is fully customizable. You can build a unique store to

[00:03:08] suit your specific needs, and you can keep full control and flexibility of that store.

[00:03:13] Now, you always get to keep your data, right? This is very important about WooCommerce. If

[00:03:18] you ever decide to leave for whatever reason, WooCommerce is not going to hold your data hostage.

[00:03:22] They’re going to let you take it with you. But on top of that,

[00:03:25] you can always customize WooCommerce. Because it’s built on an open source platform,

[00:03:31] you can customize it yourself. You can write extra code, your own custom code to integrate

[00:03:36] any kind of thing that you can imagine wanting to integrate. Now, most of the time, this kind

[00:03:40] of integration has already been done by somebody. And more importantly, it’s available to you.

[00:03:45] There’s over 140 extensions available in the official WooCommerce.com marketplace,

[00:03:51] and subscribing for a year gets you support and updates on all of that.

[00:03:55] All those extensions. There’s a ton of reasons to use WooCommerce. We’re going to be going

[00:03:59] through these over this quarter, the first quarter of 2018. But this is kind of the

[00:04:04] introduction here. It is one of the most important things for commerce on the internet,

[00:04:11] right? Because 30% of all online stores, this means basically every third online store that

[00:04:18] you use probably was built with WooCommerce, right around that. So I encourage you, if you

[00:04:24] are looking for WooCommerce, if you’re looking for WooCommerce, if you’re looking for WooCommerce,

[00:04:25] or an e-commerce solution, I encourage you to check out WooCommerce. Head over to

[00:04:29] WooCommerce.com slash developer T. And if you use the code, the promo code developer T,

[00:04:35] you’ll get 20% off. This is only good until the end of March, 2018. So head over to

[00:04:41] WooCommerce.com slash developer T. Thank you again to WooCommerce for sponsoring today’s episode

[00:04:46] of developer T. So when does it make sense to add code rather than removing it when you’re

[00:04:53] in the process of refactoring?

[00:04:55] Well, I’m going to give you three practical times when adding more code. These are actually

[00:04:59] refactoring patterns. When adding more code makes more sense. The first time is when you’re

[00:05:04] replacing a variable, a temp variable, with a query. Now, what does this look like? Well,

[00:05:09] let’s say you’re inside of a method and you set a variable for the price of a given item. And

[00:05:15] you’re evaluating something about that item to determine the price. Let’s say for whatever

[00:05:20] reason it’s not saved. And you have to actually do some work to figure out what the price is

[00:05:25] going to be. Maybe you do it based on the person who’s visiting, based on their location because

[00:05:29] you want to factor in sales tax or something, right? All of this is a procedural code that

[00:05:35] you’re having to write. And so anytime that you need to figure out the price, you have to write

[00:05:40] that procedural code. Now, going back to our discussion about dry, we don’t want to repeat

[00:05:45] ourselves in this situation, right? We don’t want to set price multiple times and multiple methods

[00:05:50] across the file because the likelihood that we’re going to forget to update one when we update a

[00:05:55] another one is pretty high. We’re going to end up having a mismatch between different price

[00:06:01] concepts, okay? So what we want to do to avoid this is we want to extract that work out of the

[00:06:10] variable, right? We want to extract it away and put it into a method. We want to put the

[00:06:16] price procedural code into its own method. So now instead of creating a variable called price

[00:06:25] saying price equals and then a bunch of code after that, instead create a method called price.

[00:06:31] And for that given item, you can define the price based on whatever is inside of that method. So now

[00:06:39] anytime you call price, you’re going to get the same thing no matter where you are in the code.

[00:06:43] This technically will end up with a little bit more code. You’re adding a new method,

[00:06:48] but overall that code is going to be much more maintainable. Similarly, another time when you

[00:06:54] add more code, you’re going to get the same thing no matter where you are in the code.

[00:06:55] To create cleaner code, when you’re creating a conditional, let’s say you have a branching

[00:07:01] conditional, you have one condition, you want to do something if that condition is true, and then

[00:07:06] you have another condition, your else condition maybe. And so you have these multiple conditions

[00:07:12] and inside of your parentheses or however your particular language is working for that condition,

[00:07:18] you’re creating multiple statements to check against. Maybe you have ors or you have combining

[00:07:24] ands. You have,

[00:07:25] um, multiple nested conditionals. You maybe even have ternaries inside of your conditionals.

[00:07:31] That kind of conditional statement is incredibly difficult to read and incredibly difficult to

[00:07:36] maintain. So instead of putting all of that inside of the conditional itself in the similar way that

[00:07:44] we previously were extracting a temp variable out to a query, now we’re going to create a method

[00:07:51] for your conditional. This is going to consolidate,

[00:07:55] your conditional into a concept. Most of the time when you have a condition, that condition has a name.

[00:08:01] Whether that name has been identified yet or not is, you know, determined by how you’ve written

[00:08:08] your code so far. So if you have a name for this concept, go ahead and pull it out of the

[00:08:14] conditional and create a new method that wraps up that conditional. Now inside of your conditional

[00:08:19] statement, all you have is a single method call. And if you want to change that condition in the

[00:08:24] future,

[00:08:25] you can. Most of the time you’re going to need to use that named condition in other places anyway.

[00:08:32] The third and final place that we’re going to talk about adding code as a way of making your code more

[00:08:37] readable is quite simply lengthening your variable names. If you’ve ever written swift or you’ve written

[00:08:44] a, uh, an iPhone app, you know that the built in methods in Xcode typically have very long names. Now you

[00:08:54] would think that with

[00:08:55] very long names, you would end up not being as productive, but the opposite seems to be true. The longer these

[00:09:02] variable names are, the more clear they are. And as it turns out, it’s a little bit easier to read long variable names

[00:09:08] than we initially may have expected. Many of us were trained to use short variable names, especially if we went

[00:09:15] through something like an algorithm course, using variable names that are one or two letters long to describe a much

[00:09:22] more complicated concept.

[00:09:25] So the problem with this, and there’s multiple problems with using short variable names. First of all, the benefits that we think we’re

[00:09:32] gaining, we actually are not gaining in most cases, especially if your code is compiling and stuff is getting compressed out

[00:09:40] anyway. So it doesn’t really matter how long your variable names are, because your compiler is going to handle that for you. So

[00:09:46] you’re probably not getting any good benefit out of shortening those names. The second problem is most of the time when we

[00:09:53] shorten, we either are using

[00:09:55] some convention that is defined by the common way of doing that particular algorithm, or we’re using a shortened name, like an

[00:10:06] 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

[00:10:13] months and try to understand what that algorithm was doing, you wouldn’t remember what that acronym was. Those variable names that

[00:10:21] you’ve created, the acronym variables that you’ve created, you’re not going to be able to understand what that acronym was.

[00:10:25] They no longer have meaning to you. So now, not only are they not following a convention, but they’re also very confusing. They’re

[00:10:33] confusing to look at because you don’t remember what they mean. And anyone else coming into the project who didn’t create that acronym

[00:10:40] likely won’t remember what they mean either, right? So there are some times when this doesn’t apply. For example, when it’s an acronym that is

[00:10:50] widely known, that may be a time when an acronym is okay to use.

[00:10:55] but by and large if you expand your variable names to be more descriptive your code is going to

[00:11:01] become more readable and this is again it’s not intuitive because we want our code to be pretty

[00:11:07] and small we want it to be visually appealing and we want it to be easy to scan our eyes across it

[00:11:14] we don’t want it to take a long time to read it the problem is that most of the time even when

[00:11:19] it doesn’t take a long time to read it it takes a long time to parse it for our brains to understand

[00:11:25] what’s going on so i recommend that you write descriptive variable names don’t worry about how

[00:11:30] long they are to begin with and if you find that they seem laboriously long then later you can go

[00:11:37] and figure out maybe a more concise but still complete way of naming that variable in the future

[00:11:42] thank you so much for listening to today’s episode of developer t thank you again to

[00:11:47] woocommerce for sponsoring today’s episode

[00:11:49] you can get 20 off by using the code developer t head over to woocommerce.com

[00:11:54] slash developer t to get started today thank you again for listening if you enjoyed today’s episode

[00:11:59] i recommend that you subscribe in whatever podcasting app you use so that you don’t miss

[00:12:04] out on future episodes of developer t we’re focusing on practices principles and purpose

[00:12:09] this year today was a practices episode i hope that you can take it and start using it right

[00:12:15] away thank you so much for listening and until next time enjoy your tea

[00:12:19] you

Visão de gráfico