Latest / DevQuestions with Tim Corey / 007 Is It Better to Write Optimized Code or Readable Code? What is Good Code?

Transcript

007 Is It Better to Write Optimized Code or Readable Code? What is Good Code? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_00: Now here's your host, expert developer and online educator, Tim Corey.
• 0:25
  SPEAKER_01: Is it better to write optimized code or readable code?
• 0:29
  SPEAKER_01: Should I make all my code kind of boiled down to one really compact, cool line of code?
• 0:36
  SPEAKER_01: Or should I write 10, 15 lines of code to replace that one line?
• 0:40
  SPEAKER_01: Which is better and why?
• 0:42
  SPEAKER_01: These are some of the questions that come up around writing good code and what does that look like?
• 0:47
  SPEAKER_01: So in this video, we're going to address those questions.
• 0:50
  SPEAKER_01: Now, if you don't know me, my name is Tim Corey and my goal is to make learning C sharp easier.
• 0:55
  SPEAKER_01: One of the ways I do that is by sitting down, taking some time out to talk about these questions that come up as you learn to become a developer or a better developer.
• 1:05
  SPEAKER_01: So in this video, let's talk about how do you write good code.
• 1:11
  SPEAKER_01: Now, one of the things that I heard early on that really stuck with me is that code is meant to be read by humans.
• 1:21
  SPEAKER_01: That kind of stunned me because that's not what I had anticipated.
• 1:27
  SPEAKER_01: I anticipated that code was meant to be read by computers.
• 1:31
  SPEAKER_01: But it's not.
• 1:33
  SPEAKER_01: Our code is meant to be read by humans.
• 1:36
  SPEAKER_01: If it was meant to be read by computers, then we'd have a much different style.
• 1:42
  SPEAKER_01: We would have assembly language or binary, because that's what computers really want, but that's not what we're writing.
• 1:48
  SPEAKER_01: We're writing code that's meant to be maintained by humans, that's meant to be improved by humans, that's meant to be reviewed by humans.
• 2:00
  SPEAKER_01: And a lot of times those humans are us.
• 2:03
  SPEAKER_01: Okay?
• 2:04
  SPEAKER_01: So I've come back six months down the road and looked at an application I wrote and went, who's the idiot who wrote this software?
• 2:12
  SPEAKER_01: And then realized it was me.
• 2:15
  SPEAKER_01: Because I didn't write it real well.
• 2:17
  SPEAKER_01: Now, that's actually a good thing.
• 2:18
  SPEAKER_01: And if you look at my video on uh a previous video on the topics, I talked about how if you're learning and growing, that's what you're gonna say a lot.
• 2:30
  SPEAKER_01: You're gonna say, you know what, my code from six months ago is horrible.
• 2:35
  SPEAKER_01: That's okay.
• 2:35
  SPEAKER_01: That's actually a good thing.
• 2:36
  SPEAKER_01: You're learning and growing.
• 2:38
  SPEAKER_01: So check out the imposter video to learn more about that.
• 2:42
  SPEAKER_01: But as I'm reading through this code, I realize it's not readable.
• 2:47
  SPEAKER_01: I don't know what I'm doing.
• 2:49
  SPEAKER_01: I don't know why I thought that this statement over here was important.
• 2:54
  SPEAKER_01: What's this section even about?
• 2:57
  SPEAKER_01: Why is it in like is this non-functional code that doesn't do anything?
• 3:02
  SPEAKER_01: Why is it doing this?
• 3:04
  SPEAKER_01: And so what I've learned over time is that statement is really true, that code is meant to be read by humans.
• 3:11
  SPEAKER_01: And if I want to make my life easier, or the next person comes along, I'm gonna write code that's very easily readable.
• 3:22
  SPEAKER_01: And that means I often skip, avoid, or don't do, don't even learn those more advanced one-liner techniques.
• 3:33
  SPEAKER_01: I typically avoid practically everything to do with those things.
• 3:37
  SPEAKER_01: For example, a really simple one.
• 3:39
  SPEAKER_01: In if statement, if you want to say not something, let's say you have a Boolean value, um, is alive, and you want to say if is not alive, then you'd say exclamation point is alive.
• 3:52
  SPEAKER_01: The problem is that exclamation point kind of blends in with the is alive statement.
• 3:59
  SPEAKER_01: It looks like one more character associated with that word.
• 4:02
  SPEAKER_01: If you're scanning down through the code, it's often easy to miss that statement, and it looks like it says if is alive, then do this.
• 4:12
  SPEAKER_01: So what I typically do is I don't use the exclamation point.
• 4:17
  SPEAKER_01: I use equals equals false.
• 4:20
  SPEAKER_01: Is alive equals false.
• 4:23
  SPEAKER_01: And the reason why is because it's very easy to see that as you're scanning through the code.
• 4:29
  SPEAKER_01: You go, oh, is alive is false or is dead.
• 4:32
  SPEAKER_01: Um that's what's going to happen down there.
• 4:35
  SPEAKER_01: So it's easier for the next person coming along to quickly scan through the code and understand what's going on.
• 4:44
  SPEAKER_01: So I'm a big proponent of making code readable.
• 4:48
  SPEAKER_01: That's also why I love SRP or single responsibility principle.
• 4:53
  SPEAKER_01: You've heard it talk about it before.
• 4:54
  SPEAKER_01: I actually have a video on a single responsibility principle.
• 4:57
  SPEAKER_01: It's the first video in the SOLID series.
• 5:01
  SPEAKER_01: That's the S in SOLID.
• 5:03
  SPEAKER_01: And SRP says that a method or a class should have one thing, one reason to exist, one thing that it does.
• 5:13
  SPEAKER_01: And so if you have that and you name them well, then your code, especially that what I call a quarterback method, the method that calls all the other methods, that the project coordinator of your application that says, okay, do this, then do that, then do this, and so on.
• 5:30
  SPEAKER_01: That method, especially, is very easy to read.
• 5:33
  SPEAKER_01: Because it says print hello, then it says ask for first name, ask for last name, uh, say hello, full name, say goodbye, or something like that.
• 5:47
  SPEAKER_01: I mean, that's a very simplistic view, but that's kind of what you'd read through because those are all method names, and that's what they're doing.
• 5:54
  SPEAKER_01: The method name says what it does.
• 5:56
  SPEAKER_01: And so by having that really easily readable structure, you can almost read your code like a book.
• 6:03
  SPEAKER_01: Well, if you have a whole bunch of one-liners, it makes it harder.
• 6:08
  SPEAKER_01: What happens is you start scanning through and get to this dense section, and you go, okay, pause.
• 6:16
  SPEAKER_01: I need about five minutes to figure out what all this does.
• 6:20
  SPEAKER_01: And so you just sit there and you scan it and you read it and you think about it, and you waste a whole lot of brain cycles trying to figure out what's going on in this section, only to find it's a for loop and if statement, kind of wrapped together.
• 6:35
  SPEAKER_01: That's all it is.
• 6:36
  SPEAKER_01: But it's a little more complex because it's all crunched down into one line.
• 6:41
  SPEAKER_01: So I really avoid those things because it makes it harder to read my code.
• 6:47
  SPEAKER_01: And here's the other trick to that.
• 6:49
  SPEAKER_01: I like vacations.
• 6:52
  SPEAKER_01: I like the beach.
• 6:53
  SPEAKER_01: I like being on the beach or in the ocean and hanging out.
• 6:57
  SPEAKER_01: What does it have to do with this subject?
• 6:59
  SPEAKER_01: Well, if I'm on the beach, if I'm in the ocean and I have written code that is compact, hard to read, but really powerful, guess what happens?
• 7:12
  SPEAKER_01: If it breaks, I'm getting a phone call.
• 7:15
  SPEAKER_01: Because I need to fix it, because no one else understands it.
• 7:19
  SPEAKER_01: Maybe you don't have another senior developer on the team.
• 7:23
  SPEAKER_01: The junior developers can't fix it.
• 7:26
  SPEAKER_01: The intern can't fix it.
• 7:28
  SPEAKER_01: That's a problem.
• 7:29
  SPEAKER_01: I don't want that.
• 7:31
  SPEAKER_01: When I go on vacation, I want my code to be in a format where even the intern can fix it.
• 7:40
  SPEAKER_01: And that's no knock on interns.
• 7:43
  SPEAKER_01: What that is, is saying my code is so advanced that it's simple.
• 7:49
  SPEAKER_01: That's what I want.
• 7:50
  SPEAKER_01: That's I want my code to be simple and easily readable.
• 7:55
  SPEAKER_01: Because then anybody can fix it.
• 7:59
  SPEAKER_01: I don't want to have job security by saying my code's so complex.
• 8:03
  SPEAKER_01: Because here's the deal.
• 8:04
  SPEAKER_01: My memory isn't that good.
• 8:06
  SPEAKER_01: I'll forget what I did, and then I have to be the one to diagnose this stuff, and I don't want to be there.
• 8:13
  SPEAKER_01: I don't want to do that.
• 8:14
  SPEAKER_01: I don't want to waste a whole day trying to figure out what my application even does and how it works.
• 8:20
  SPEAKER_01: If you've worked in the industry at all, you've probably seen applications like that.
• 8:24
  SPEAKER_01: Where you read through and say, I just don't understand what's going on here.
• 8:28
  SPEAKER_01: And it takes you a while to get up to speed.
• 8:31
  SPEAKER_01: And that's the other thing too.
• 8:33
  SPEAKER_01: If you work for a company and they want to hire new developers, the better your code is at being readable, the faster those new developers get up to speed.
• 8:45
  SPEAKER_01: The faster they get up to speed, the faster they start helping you.
• 8:50
  SPEAKER_01: That's a good thing.
• 8:51
  SPEAKER_01: So I really highly encourage readable code.
• 8:56
  SPEAKER_01: That doesn't mean you can't implement some advanced stuff.
• 9:00
  SPEAKER_01: There may be parts of my code that an intern wouldn't necessarily get because they haven't understood that piece of it.
• 9:08
  SPEAKER_01: But really, I try not to.
• 9:11
  SPEAKER_01: I truly really try hard to make my code a little dumber, and that again, not a knock, but a little less than super senior developer complex stuff.
• 9:23
  SPEAKER_01: I try and make it into simple enough that it can be easily maintained.
• 9:30
  SPEAKER_01: So that's my focus.
• 9:32
  SPEAKER_01: In some ways, it's lazy.
• 9:34
  SPEAKER_01: I don't want to have to be the person always on call.
• 9:37
  SPEAKER_01: I don't want to have to be the person that has to carry a phone around and a laptop on vacation because I want to be the person in shorts and a t-shirt hanging out on the beach, goofing off with my boys, because I don't have to worry about people calling me.
• 9:54
  SPEAKER_01: Okay, so that's my focus.
• 9:56
  SPEAKER_01: That's what I would encourage you to be your focus.
• 9:59
  SPEAKER_01: Yes, there's some really cool stuff you can do with one-liners and code.
• 10:03
  SPEAKER_01: Yes, there's some stuff you can do to really compact your code and make it better better.
• 10:09
  SPEAKER_01: Um, but is it worth it?
• 10:12
  SPEAKER_01: What's the what's the benefit you get?
• 10:14
  SPEAKER_01: At the end of the day, your compiler is going to take your code and my code, so your code and my code, and it's gonna put it into the same code.
• 10:26
  SPEAKER_01: Okay, there's not gonna be a performance benefit if you write a one-liner.
• 10:31
  SPEAKER_01: If I write 15 lines to your one, there's no performance benefit here.
• 10:37
  SPEAKER_01: So it really comes down to are you just showing off?
• 10:43
  SPEAKER_01: Yes, it it makes it faster to write that one line, but faster to write once, slower to read how many times?
• 10:53
  SPEAKER_01: I don't see that as a benefit.
• 10:55
  SPEAKER_01: Okay, so I prefer to optimize for the number of reads it will have for the one time I have to write it.
• 11:04
  SPEAKER_01: Alright?
• 11:04
  SPEAKER_01: And that one time will save me time on the beach.
• 11:08
  SPEAKER_01: Okay, so that's my thoughts on writing good versus optimized versus simple code.
• 11:15
  SPEAKER_01: Okay?
• 11:16
  SPEAKER_01: If you have any thoughts, I'd love to hear them down below.
• 11:18
  SPEAKER_01: Also, if you have more questions that you want to answer in this dev question series, leave them down below.
• 11:23
  SPEAKER_01: Also, if you have questions about code that you want to see, ask me.
• 11:28
  SPEAKER_01: I will put it on the suggestion list and get to it as soon as possible.
• 11:32
  SPEAKER_01: Okay?
• 11:32
  SPEAKER_01: Thanks for watching.
• 11:33
  SPEAKER_01: As always, I am Tim Corey.
• 11:35
  SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
• 11:38
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 11:42
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions.
• 11:49
  SPEAKER_00: You can also send your questions to questions at IamTimcorey.com.
• 11:54
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 12:01
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.