Vox

Leitura de 25 min

4 Code Smells (And How to Fix Them)

Summary

This episode of Developer Tea focuses on practical strategies for identifying and fixing common code smells in software development. Host Jonathan Cottrell explains that code smells aren’t about correctness but rather about maintainability—indicators that code might become difficult to change in the future. He emphasizes that most code is written to be changed, making these heuristics valuable for long-term project health.

The first code smell discussed is the “13-fingered monster,” characterized by multiple deep indentations in a single file that indicate a class or component taking on too many responsibilities. This pattern appears in HTML, templating languages, and JavaScript callbacks, and the solution involves flattening the code by extracting responsibilities into separate components, partials, or using promises.

Next, Cottrell covers the “long method” code smell, where functions or methods become too lengthy (typically over 10-20 lines) and difficult to reason about. He notes that developers often use whitespace or comments to separate sections within long methods, which signals an opportunity to extract those sections into separate functions. Both this and the previous smell share the same antidote: breaking things into smaller, more focused pieces.

The third smell is the “semantic battle,” which occurs when code needs frequent updates due to changing business terminology or interface labels. This happens when code uses jargon-heavy names that become outdated as business language evolves. The solution involves separating dynamic labeling from the underlying data structure, often through configuration fields or CMS settings, which also helps with internationalization.

Finally, Cottrell discusses “message chains,” where data or messages must pass through multiple intermediate objects to reach their destination. This creates fragile dependency chains, particularly problematic in React applications where props are passed through many components. Solutions include using state management libraries like Redux, dependency injection, or delegation patterns to reduce coupling between components.

Recommendations

Tools

  • Linode — A cloud hosting service that allows developers to quickly set up Linux servers with various distributions and configurations, offering SSD storage and Intel processors.
  • React — A JavaScript library mentioned as an example of component-based architecture that helps encapsulate responsibilities and avoid code smells like the 13-fingered monster.
  • Redux/Flux — State management libraries for React that help solve the message chains code smell by separating data from component hierarchy, allowing components to fetch data independently.

Topic Timeline

  • 00:00:00 — Introduction to code smells and maintainability — Jonathan introduces the episode’s focus on practical code smells. He explains that code smells aren’t about correctness but about maintainability—indicators that code might become difficult to change. Most code is written to be modified, so identifying these early helps prevent future problems. The term ‘smell’ comes from the gradual nature of these issues, starting as a ‘whiff’ and potentially becoming an overwhelming ‘stench’ if ignored.
  • 00:04:53 — The 13-fingered monster code smell — The first code smell is the ‘13-fingered monster,’ characterized by multiple deep indentations in a single file that look like fingers. This indicates a component taking on too many responsibilities, appearing in HTML, templating languages, and JavaScript callbacks. The solution involves flattening the code by extracting responsibilities into separate components, partials, or using promises. This makes code easier to reason about by reducing the mental context needed for deeply nested structures.
  • 00:11:11 — Long method code smell and breaking things down — The second smell is the ‘long method,’ where functions become too lengthy (typically 10-20+ lines) and difficult to reason about. Developers often use whitespace or comments to separate sections within long methods, which signals an opportunity to extract those sections into separate functions. Both this and the previous smell share the same solution: breaking code into smaller, more focused pieces. Refactoring often adds more lines of code as you create new methods and functions for better abstraction.
  • 00:14:23 — Semantic battle code smell and dynamic labeling — The third smell is the ‘semantic battle,’ which occurs when code needs frequent updates due to changing business terminology or interface labels. This happens when code uses jargon-heavy names that become outdated as business language evolves. The solution involves separating dynamic labeling from the underlying data structure, often through configuration fields or CMS settings. This approach also helps with internationalization by making text translation more manageable.
  • 00:18:07 — Message chains code smell and dependency management — The final smell is ‘message chains,’ where data must pass through multiple intermediate objects to reach its destination. This creates fragile dependency chains, particularly problematic in React applications where props are passed through many components. Solutions include using state management libraries like Redux, dependency injection, or delegation patterns to reduce coupling. The goal is to minimize the number of objects that must stay intact for information to flow properly.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2018-04-16T09:00:00Z
  • Duration: 00:22:22

References

Podcast Info

Transcript

[00:00:00] We’re going to get very practical this week on the show.

[00:00:07] My name is Jonathan Cottrell, and you’re listening to Developer Tea.

[00:00:09] And my goal on this show is to help driven developers connect to their career purpose

[00:00:13] so they can do better work and have a positive influence on the people around them.

[00:00:17] And in this week’s episodes, we’re talking about very practical things.

[00:00:21] For example, today, we’re talking about identifying code smells.

[00:00:24] We’re not going to talk about every code smell on the planet,

[00:00:27] but we’re going to talk about some very common ones.

[00:00:29] And then we’re going to give you some very simple ways of fixing these.

[00:00:33] Of course, we aren’t going to give you any code examples on this show.

[00:00:36] That’s not the goal of this podcast.

[00:00:38] Instead, we’re going to give you some heuristics and ways of applying these things

[00:00:42] and some terms that maybe you can Google in your own time to learn a little bit deeper

[00:00:47] if they resound specifically for your case.

[00:00:50] So I’m really excited about this because code smells are such a common way

[00:00:56] to become a better programmer.

[00:00:59] Being able to identify them is such a key skill that programmers have to develop.

[00:01:05] And the reason we call them code smells is because there’s nothing necessarily wrong with the code.

[00:01:12] In other words, there’s syntax that is all correct.

[00:01:17] And even algorithmically speaking or accuracy wise, things look fine.

[00:01:23] There’s nothing particularly bad about the outcome of the code.

[00:01:28] And so for all intents and purposes,

[00:01:29] if you left the code the way that it is today, it will work indefinitely.

[00:01:34] It will continue to work as you expect it to work.

[00:01:37] The problem is you’re very unlikely to leave the code as it is today.

[00:01:41] In fact, most code is written in order to be changed.

[00:01:47] If things go as planned, it’s very unlikely that you’re going to write a piece of code and then leave it.

[00:01:53] So we’re going to ignore cases where that might be true.

[00:01:56] For example, you may be writing scripts or macros or something.

[00:01:59] And you don’t necessarily need to refactor those.

[00:02:02] But there’s even a good case to be made for writing maintainable code, even in those scenarios.

[00:02:07] For example, if you want to publish that script or that macro as an open source tool for other people to use,

[00:02:14] or perhaps if you’ve found it extremely useful to you and you want to share it with your colleagues,

[00:02:20] with your coworkers, then writing code, even from the very beginning,

[00:02:23] with the idea of change in mind and flexibility and maintainability.

[00:02:28] We’ve talked about maintainability.

[00:02:29] Relatively recently on the show, the idea that code is written in order to be changeable,

[00:02:36] in order to be able to flex to new requirements, flex to new situations,

[00:02:42] and even the smallest of jobs, you can benefit from writing that code in a maintainable way.

[00:02:49] So we’re not talking about correctness in this episode because this episode assumes that your code is correct.

[00:02:58] Now,

[00:02:58] how do you determine if your code is correct?

[00:02:59] And if code is correct, well, it depends on the use case.

[00:03:01] But what we are talking about in today’s episode is taking correct code and making it maintainable code,

[00:03:08] identifying things that kind of point to what made down the road,

[00:03:13] made that code hard to maintain,

[00:03:15] and then using those kind of smells to give you a pointer to how to fix those smells,

[00:03:23] how to make that code more maintainable for future changes.

[00:03:27] So it’s called a smell because,

[00:03:29] it’s not going to be a black and white thing.

[00:03:32] It’s very unlikely that you’re going to be able to look at code and immediately recognize a code smell.

[00:03:37] It may be something that as you’re working with it,

[00:03:40] you start to recognize what may down the road cause issues,

[00:03:46] right?

[00:03:46] And that’s why it’s very difficult to grab a hold of.

[00:03:50] It’s not something that you can write a test for necessarily,

[00:03:52] although there are ways of making this more black and white.

[00:03:57] A code smell typically comes on,

[00:03:59] in terms of a gradient.

[00:04:01] In other words,

[00:04:01] it gets worse and worse and the smell gets worse and worse.

[00:04:05] So you may get a whiff at first,

[00:04:07] right?

[00:04:08] The sense that something might be able to be changed for the better.

[00:04:13] And then as you continue writing code and the smell gets worse,

[00:04:17] the code continues in the same bad direction.

[00:04:20] Then you have a very clear picture of what has gone wrong.

[00:04:24] And we’ve all worked on projects most likely where that smell has been ignored and eventually,

[00:04:28] it became an overwhelming stench rather than just a whiff.

[00:04:34] So the hope of this episode is to give you some heuristic tools to identify things in the early stages of that smell.

[00:04:41] So you can go ahead and refactor,

[00:04:44] go ahead and start pushing that code in the better direction so that you don’t end up in that really bad smelling code scenario.

[00:04:53] We’re going to actually cover four different code smells in today’s episode.

[00:04:56] It’s a lot of content.

[00:04:57] So I want to jump straight into it.

[00:04:58] And the first one is something that I actually have identified as a code smell for myself.

[00:05:04] And others have called it something different,

[00:05:06] but I’m going to call it the 13 fingered monster.

[00:05:09] The 13 fingered monster.

[00:05:11] If you look at your code,

[00:05:13] especially if you are developing in some kind of interface language,

[00:05:16] for example,

[00:05:17] an XML based like HTML or a JSX.

[00:05:21] If you look at your code and you see indention patterns that look like fingers.

[00:05:27] In other words,

[00:05:28] it goes deeply indented and then comes back out to more shallow than deeply indented again,

[00:05:33] and then back out more shallow.

[00:05:35] And this happens over and over and over in the same file.

[00:05:39] This is a code smell.

[00:05:41] Now,

[00:05:41] why is this?

[00:05:42] Why is it that deep indention and multiples of deep indentions can be a code smell?

[00:05:47] Well,

[00:05:47] most likely what is happening when you have these deep indentions is that you’ve created a collaborator,

[00:05:54] right?

[00:05:55] A collaborator takes multiple responsibilities.

[00:05:57] Right?

[00:05:58] And puts them into the same file in a class oriented language.

[00:06:04] You might call this a guide class,

[00:06:06] but the same thing could be true for interface languages.

[00:06:09] You very often see this in HTML where you put all of your,

[00:06:13] uh,

[00:06:14] your HTML code into a single file like an index dot HTML.

[00:06:19] And there’s nothing necessarily wrong with this until it becomes unmaintainable.

[00:06:24] Now,

[00:06:25] most of us are not writing static HTML files.

[00:06:27] We’re either generating them with some kind of static site generator or we’re using a template language or we’re using backing code to generate them using partials,

[00:06:39] using other templates that we compile into a single template,

[00:06:43] for example,

[00:06:43] PHP.

[00:06:45] And so what we can do instead of having this,

[00:06:47] like we said,

[00:06:48] this kind of God class or collaborator template,

[00:06:52] we can flatten those indentations out.

[00:06:56] So how do we do this?

[00:06:57] Well,

[00:06:57] we take the,

[00:06:58] the various fingers,

[00:07:00] the 13 finger monster.

[00:07:01] Remember we take each of those,

[00:07:04] those deep indentions and we try to recognize what is the job that this indention,

[00:07:09] this kind of spike in the code,

[00:07:11] what is it doing in JavaScript?

[00:07:14] You can also view this through the lens of callback functions.

[00:07:19] If you have multiple nested callback functions,

[00:07:21] then very often you can run into scenarios where you haven’t covered that particular,

[00:07:27] that state that callback isn’t running properly.

[00:07:30] You aren’t handling errors properly.

[00:07:32] Something is making it difficult to maintain that code and the callbacks are becoming nearly impossible to reason about,

[00:07:39] right?

[00:07:39] So that’s a deep indentation in JavaScript.

[00:07:44] And so what we need to do is find ways of flattening the code out again in HTML or in a templating language,

[00:07:52] you can abstract these various indentations into partials,

[00:07:57] that do the job that that particular code was,

[00:08:01] was performing in JavaScript.

[00:08:03] You may use promises,

[00:08:05] right?

[00:08:05] You can use promises and flatten the code out.

[00:08:08] So you have more reasonable functions to pass to those promises.

[00:08:12] Now here’s the interesting reality.

[00:08:14] The end point,

[00:08:15] the outcome of this may even be logically exactly the same,

[00:08:22] but the code has changed significantly more specifically,

[00:08:26] as it relates,

[00:08:27] relates to indentation.

[00:08:28] Most of the time indentation means new context,

[00:08:33] something inside of another div or something inside of a callback function,

[00:08:40] maintaining an understanding of what state this particular indentation is referencing can be very difficult for your brain to do.

[00:08:51] And so what you’re doing by switching this out and,

[00:08:55] and offloading it into,

[00:08:57] into functions or into partials or whatever it is that you use to wrap this code up,

[00:09:03] this allows you to reason much more clearly about that particular piece of code.

[00:09:08] And you can do it in one piece at a time.

[00:09:11] This is exactly the concept that we follow when we’re taking code and abstracting it to components.

[00:09:17] For example,

[00:09:18] using react,

[00:09:20] we’re encapsulating some kind of job,

[00:09:22] some kind of responsibility,

[00:09:24] some kind of data or information,

[00:09:27] even,

[00:09:27] even the semantics around that particular item,

[00:09:30] we’re encapsulating that into its own thing,

[00:09:33] its own thing that has its own responsibility.

[00:09:36] So the heuristic here is if you have multiple indentations,

[00:09:40] if you have that 13 fingered monster,

[00:09:42] then it’s very likely that you’re going to benefit from flattening that code out.

[00:09:47] Now we’re going to take a quick break and talk about today’s awesome sponsor.

[00:09:50] Then we’re going to come back and talk about the other three code smells very quickly.

[00:09:54] Today’s episode is sponsored by Linode with Linode.com.

[00:09:56] Linode.com.

[00:09:57] You can get up and running in just a few minutes.

[00:09:59] You can have a Linux server running in the cloud in Linode’s cloud in just a few clicks.

[00:10:05] You pick your node location,

[00:10:07] your resources,

[00:10:08] and of course your Linux distribution.

[00:10:11] Now there’s tons of shared starting distributions that other Linode users have created that you can use as well.

[00:10:18] This is one of the benefits of Linode that other developers just like you are the builders and the users of this platform.

[00:10:26] On top of that,

[00:10:27] Linode provides 24 seven customer support and you can get started with just $5 a month.

[00:10:34] Not only that,

[00:10:35] Linode is going to provide you with $20 worth of credit and that’s four months of free service on their introduction plan.

[00:10:42] That is a one gigabyte of Ram server.

[00:10:46] And by the way,

[00:10:46] all of their servers run on SSD storage and on Intel E five processors with a 40 gigabit internal network.

[00:10:54] Go and check out what Linode has to offer.

[00:10:56] Head over to spec.fm slash Linode to get started today.

[00:10:59] Use the code developer T 2018.

[00:11:01] That’s all one word developer T 2018 at checkout.

[00:11:05] Thank you again to Linode for sponsoring today’s episode of developer T.

[00:11:09] So we’re talking about code smells.

[00:11:11] We’ve talked about this one that I’ve dubbed the 13 fingered monster.

[00:11:15] Other versions of this are the God class,

[00:11:18] but it doesn’t just apply to object oriented programming.

[00:11:21] Pretty much any time you have a single file that is trying to describe,

[00:11:26] multiple things,

[00:11:28] multiple responsibilities articulately,

[00:11:31] there’s probably a better way to handle it.

[00:11:33] There’s probably a way that you can take those responsibilities,

[00:11:36] wrap them up so that you can interface with them more reasonably.

[00:11:40] You don’t have to keep all of that in your brain and you don’t have to have that file know everything about that responsibility.

[00:11:48] But an extension to the 13 fingered monster is the long method code smell.

[00:11:53] So this is what happens when,

[00:11:55] even when you have one of those things that has its own responsibility,

[00:12:00] when it is carrying too much of that responsibility.

[00:12:03] Now here we’re talking mostly about some kind of object oriented or method driven programming in JavaScript.

[00:12:11] You may consider these functions,

[00:12:13] but ultimately if you’re doing too much inside of a single function,

[00:12:17] then that function number one becomes less useful,

[00:12:20] less reusable,

[00:12:22] and number two,

[00:12:23] it becomes more difficult to reason.

[00:12:25] About a decent heuristic to use is somewhere between 10 and 20 lines of code.

[00:12:31] Everyone has their own threshold and in fact different languages have different thresholds.

[00:12:36] For example,

[00:12:36] you may set your threshold at a much lower number two or three or four lines of code.

[00:12:41] Maybe the most that you want to put into a single method,

[00:12:45] but certainly at the top of that range is probably around 20 lines of code,

[00:12:50] especially when you start taking up more than half of your editing space or something like that.

[00:12:55] Then it’s probably time to start breaking this up too.

[00:12:58] Now you’ll notice these first two anti-patterns,

[00:13:00] these first two code smells that we’re identifying,

[00:13:03] both of them have to do with trying to do too much within a single container,

[00:13:08] within a single component,

[00:13:09] within a single method.

[00:13:10] And the antidote to both of these is to break things down into smaller pieces.

[00:13:15] You’re going to see this over and over and over.

[00:13:17] And it’s why a lot of refactoring ultimately ends up adding more lines of code than it does taking away because a lot of the time,

[00:13:25] what,

[00:13:25] what this means is adding new methods,

[00:13:27] adding new functions to your code so that you can abstract away some of the logic that you’re doing within that single long method or that single long function,

[00:13:37] that single long component,

[00:13:39] a common habit that people have when they’re writing these long functions or these long components is to break them up using white space or comments.

[00:13:48] You’ve probably done this before.

[00:13:50] You have different sections of a function.

[00:13:53] You have different sections of a method or of a component.

[00:13:55] And you put a line break before each of these sections.

[00:13:59] And what you’ve done is you’ve kind of created this mental bucket.

[00:14:03] You’ve collected some,

[00:14:05] a few lines of code together that are doing something that is conceptually related.

[00:14:10] And when you find yourself doing this,

[00:14:11] that is a perfect signal of when to wrap that code up into its own function,

[00:14:16] into its own method,

[00:14:17] into its own component.

[00:14:19] All right,

[00:14:20] so let’s get moving on.

[00:14:21] We’ve got two more code smells to cover.

[00:14:23] The next code smell is called,

[00:14:24] the semantic battle.

[00:14:26] This is another one that I’ve named.

[00:14:28] Unfortunately,

[00:14:29] you’re not going to be able to Google this.

[00:14:31] It is similar to another code smell called alternative classes with different interfaces.

[00:14:36] In that code smell,

[00:14:37] you have two classes that perform essentially the same exact thing,

[00:14:41] but you’ve created semantic differences between the two.

[00:14:45] But in the semantic battle code smell,

[00:14:47] you find yourself changing your code only so that you get the naming right.

[00:14:54] Now,

[00:14:54] this,

[00:14:54] often happens,

[00:14:55] and this is really the code smell that you’re looking for.

[00:14:58] This happens when the naming of the business side changes and you want your end on the code side to reflect it.

[00:15:07] In other words,

[00:15:07] there is a semantic label in the business logic or in the business language that you need to apply in your code for some reason.

[00:15:16] For example,

[00:15:16] you may have a header and the business language wants to change that to hero,

[00:15:23] or maybe the business,

[00:15:24] logic changed the language from payment to transaction,

[00:15:28] and they want all of the language in your code changed to reflect this.

[00:15:33] And here’s the problem.

[00:15:34] One of the hardest things that you’ll ever do as a programmer is come up with the right name for something.

[00:15:40] And there are times when this particular code smell may unfortunately be necessary,

[00:15:45] but most of the time when you actually run into this code smell,

[00:15:49] it’s because you’ve named something that is more jargon oriented than it is.

[00:15:54] Described.

[00:15:54] Another example of this might be naming something mission statement rather than naming it paragraph.

[00:16:02] Now,

[00:16:02] how can you capture this information,

[00:16:05] this mission statement label while retaining the underlying reality that this is ultimately text,

[00:16:12] that it’s ultimately a paragraph?

[00:16:15] Well,

[00:16:15] what you can do is add this concept of a labeling,

[00:16:19] a kind of visual label to your code so that no matter what that label is,

[00:16:23] it’s not going to change.

[00:16:24] It’s not going to change.

[00:16:24] The underlying kind of data structure,

[00:16:27] the underlying reality of that code is that it’s dealing with text.

[00:16:31] And in fact,

[00:16:31] this is a very good refactoring solution because you’re also going to deal with a very similar problem when it comes to internationalization.

[00:16:41] So when you have a display to the end user that needs to be translated,

[00:16:47] right,

[00:16:47] this,

[00:16:47] this certainly becomes a problem if your code is reflecting only one language.

[00:16:52] And now you have to translate it.

[00:16:53] Translate that information to the end user.

[00:16:56] So adding this dynamic labeling on top of your code avoids this issue of the semantic battle.

[00:17:04] If your code continuously is having to be updated because of the business language,

[00:17:09] then it’s very likely that it’s time to make that update more sequestered to its own area of the code,

[00:17:15] more specifically a dynamic field.

[00:17:18] For example,

[00:17:18] if you’re working with a CMS,

[00:17:20] add that label field so that can be configured,

[00:17:23] on its own.

[00:17:25] Another flavor of the semantic battle happens when you try to name code based on where it shows up.

[00:17:33] For example,

[00:17:33] you may name a field in your CMS that’s going to show up in the interface in this particular iteration towards the top of the page.

[00:17:42] You may name that field with the word top.

[00:17:46] A few weeks later,

[00:17:47] a redesign pushes that field towards the bottom of the page.

[00:17:50] And now you have to deal with this,

[00:17:53] uh,

[00:17:53] mismatch in naming versus the outcome versus the design.

[00:17:57] So again,

[00:17:58] another way to avoid this is to separate that labeling from the underlying reality,

[00:18:04] the underlying structure of that information,

[00:18:06] that data.

[00:18:07] Another code smell that is perhaps more relevant today than it has been in a long time is the message chains code smell.

[00:18:14] This is when you have multiple objects that have to be jumped through in order to pass a message to another object.

[00:18:22] Another example,

[00:18:22] or another version,

[00:18:23] of this may be if you’re passing data through multiple objects just to get to that final object.

[00:18:30] This happens quite a bit in react.

[00:18:32] For example,

[00:18:32] when you’re passing down data through props and you’re only passing it between objects until it gets to the one that you need it in.

[00:18:40] And while most of the time,

[00:18:41] this kind of passing of information down to the next component is not necessarily an issue,

[00:18:47] especially if you’re only passing through one or two components,

[00:18:50] sometimes it does become an issue because managing that,

[00:18:53] that dependency chain means that all of those objects have to stay intact in order for that final object to receive the information that it needs to render or behave properly.

[00:19:04] Ultimately for react developers,

[00:19:06] this is the point of things like flux or redux.

[00:19:09] It helps to separate the information that you would pass to a given component that you could fetch for a given component and separates that from the structure from the hierarchical structure of your components.

[00:19:21] If you found this code,

[00:19:23] smelling an object oriented language,

[00:19:25] for example,

[00:19:26] like Ruby,

[00:19:27] then there’s a few things you can do to circumvent it.

[00:19:30] The first one is to identify why you are using the class in the first place.

[00:19:35] In other words,

[00:19:36] if class A is calling a method on an object that is an instance of class B,

[00:19:41] then why is it that that class is calling that method?

[00:19:45] Perhaps there is a way to delegate that method,

[00:19:49] right?

[00:19:49] So,

[00:19:49] basically what you’re doing is you’re hiding the middleman.

[00:19:52] You’re hiding the,

[00:19:53] the fact that there is a method that breaks down common effects of the environment,

[00:19:53] but now you know that you’re ruining the Arts misconception.

[00:19:53] So,

[00:19:53] that you’re calling that class and instead you’re delegating it to a different class.

[00:19:58] One way to handle this is to inject a dependency into the initialization of class A and then

[00:20:06] delegating that particular method call onto that injected dependency. Now you don’t necessarily

[00:20:11] have to call that dependency by name. Instead you can just call the method and then the receiver of

[00:20:17] the method is responsible for the implementation. What is perhaps more common is that the first

[00:20:22] class, class A, calling the method on class B shouldn’t be happening in the first place. In other

[00:20:28] words, whatever is making class A call that method on class B, perhaps that thing should call the

[00:20:34] method directly through class B. Now that’s a little bit confusing and a little bit more in

[00:20:39] depth than we usually go on the show in terms of technical discussion, but hopefully this makes

[00:20:45] sense. The ideas here are to find ways that your code seems a little bit weird, a little bit off,

[00:20:52] and to

[00:20:52] understand why and find ways of fixing it. And we’ve gone through four code smells in today’s

[00:20:58] episode. The first one is the 13-fingered monster. The second one is the long method code smell.

[00:21:04] The third one is the semantic battle. And finally, the fourth one is the message chain code smell.

[00:21:11] I hope you’ve enjoyed today’s episode of Developer Tea. It’s a little bit more practical than we

[00:21:15] usually do, but hopefully this has been a breath of fresh air and has kicked your week off to a

[00:21:20] good start. Thank you again to today’s excellent sponsors.

[00:21:22] Get started with $20 worth of free credit on linode.com. Head of respect.fm slash linode to get

[00:21:30] started today. Use the code DEVELOPERTEA2018 at checkout for the $20 worth of credit. Thank you

[00:21:36] again for listening. If this show is helping you out, and if you’re feeling a little bit generous

[00:21:41] today and you’d like to give back, I would love to request that you go and leave a rating and

[00:21:47] review for this show in iTunes. iTunes happens to be kind of the driver for the show. If you’re

[00:21:52] a discovery of pretty much every podcast platform out there, iTunes and Google Play make a huge

[00:21:58] difference. If you go and leave ratings and reviews on these types of platforms, then it

[00:22:02] helps us reach more developers. It helps other developers just like you find Developer Tea and

[00:22:08] get the same kind of value that you’re getting out of it. Thank you so much for listening to

[00:22:12] today’s episode. And until next time, enjoy your tea.

Visão de gráfico