Coding Blocks - Clean Code – How to Write Classes the Right Way

Episode Date: February 5, 2017

This week Allen is troubled by circles, Michael talks like a game show host, and Joe announces it's twins as we continue our deep dive into the classic Clean Code book by Robert C. Martin.

you're listening to coding blocks episode 55 subscribe to us and leave us a review on itunes stitcher and more using your favorite podcast app visit us at coding blocks the net where you can try and show notes examples discussion and more send your feedback questions and rants to comments at codingblocks.net follow us on twitter at coding blocks or head to www.codingblocks.net and find all our social links there at the top of the page with that i'm alan underwood i'm joe zach and i'm michael outlaw all right we got some news uh coming up here um first off beyonce is having twins i know that's uh big news for for everybody especially me because of my nickname right i'm glad you brought it up because i i definitely

thought we needed to have a discussion about this yes i guess we can skip on to the reviews then yeah who's reading itunes and who's doing stitcher itunes all right i'll do stitcher all right we got brian d bonnie jambaluni jazzman 9000 john moss crop and aaron's iphone you know what i don't know if you did that one the way it's written it It says brain D. Um, yeah. Brain D. Yeah. I like that. Okay. Oh, that might've been, that might've been a mistake. Wait, I don't know. You're right. No, it is brain D. Let's see. There it is. All right. JD 2017, Dr. Arts, Mr. Bailey, Wes Lex tech, carndog 19 and man with camera fantastic guys thank you everybody that took the time to write those seriously thank you very much appreciated enjoyed reading every single one of them i wonder if brain d is supposed to be a joke on like brain dead or something like that

like maybe that's why the d was possibly either that or he made an unfortunate typo but i did find that uh one of them was by Aaron's iPhone. Did you happen to notice the title of his? No, what was it? This is so great. Make commutes great again. Oh, I did see that. Oh, I love that.

And as always, for the full show notes of this episode, you can head up to www.codingblocks.net slash episode 55. And there you'll be able to find everything amazing. All right. So there was a discussion that I, that I had with a few people on Slack this week. And I think I even brought it up to you guys, maybe in a chat window. And let's say that you have a circle in the database you named a table circle and starting starting off everything that went into this table was a circle and then over time this thing evolved and all of a sudden people started shoving squares into it and the next thing you know they started shoving rectangles into it and then and then and then triangles i rename my circle table to shapes

you can't rename the table it's impossible like. Like it's, it's literally nearly impossible to do. It's, it's not even technically impossible, but not worth the time it would take to do it. Logistically, it would be more effort than it's right. But, but now you've got to create a class in your application. Oh, what do you name this table? Do you name it circle? Because it's going to map to that database table? So,

or do you name it shape because all of a sudden this thing has evolved into containing all kinds of shapes, right? In other words, do you carry the bad pattern forward just so that it's consistent? Yes. Or do you give it a more meaningful name and lie to yourself that at some point you will refactor circles to the name of the circles table to be shapes? Maybe, maybe you don't even lie to yourself that at some point you will refactor circles to the name of the circles table to be shapes. Maybe you don't even lie to yourself. Maybe you just say it doesn't matter. This is how it's going to be. There's going to be a shape in my application and in my database, there's going to be a circle. And as discussed on Slack, this is the one time we're putting a comment is perfectly legit, right? Like this maps to this table currently, but I'm just curious.

So the problem is, is either way you're creating confusion. The whole, the whole point of this clean code series is to try and avoid confusion, right? Make readability better and all that kind of stuff. And unfortunately this, there's no great answer here. Like it's really not logistically possible to rename the table so do you just keep the same name or do you make it what it truly is what would say you this is a bad pattern forward would you really consistency is bad is is more more important. That's not the route I went. I actually made it shape because I mean, and I hear you, this is actually, this is one of those real world problems.

Now for anyone who's listening in and like, what kind of table do you have this named circle? I mean, this is just an abstraction, like illustrate the problem the real table is not circle circle and right it's not really a table of shapes right but but yeah i totally went with the whole shape for the class because i wanted it to at least be clear when you're programming that you're working with a shape because it's misleading enough in the database right now and carrying that pattern over to the application, I feel like just furthers that, that, that problem. So that's the way I went in and people could argue that it's right or wrong either, which way, like this is seriously one of those things where you just kind of have to pick a side

and go with it. Yeah, I'm, I'm really torn about it. I mean, like in the specific example, in the real world example that I know that you did, I'm with you on the rename, but the way phrased it with the circle is like, Oh God. Yeah. It totally would make more sense to just keep it consistent and like carry the bad pattern forward for consistency sake. Of course, this is like real world situations where you want to make things easier on everyone in the future so they can follow along with what's going on versus uh start mixing paradigms right and and i mean ultimately what you'd really want to do is name it properly when you're writing your app and then potentially go

back and rename it later if the opportunity arose, right? But that's just not going to happen in this case. Yeah, it's a good question. I'm just afraid that someone down the line is going to come and not realize that there's a renamed thing here and they're just going to add a new one. So you're going to have it both ways. So that's my favorite consistency a little bit,

but either way, really, it's just kind of a bad situation. And it's the kind of situation that we end up in all day, every day, right? Yeah. In a real programmer's life, this is the kind of, this is the kind of thing that you end up spending way more time thinking about what should you name this thing than typing the keys, right? Like I probably thought about this for 15 minutes for, I was like, you know what, I'm just going to do it. So, so, so speaking of comments,

you know, last episode, we were talking about unit testing, right? A topic near and dear to our hearts. And you mentioned comments, right? And I said, like, one of the few times I might do a comment is in this like double assert situation where like one assert isn't something that I really care about, but you know, and so I'm calling it out like, Hey, I'm only doing this because if this situation isn't true, then you know the rest of this unit test isn't really worth testing. Um, and Marizio, does that sound right? Mario, he was just on developer podcast. No, really? Okay, well, there's a Z in there that threw me off. So Mario,

oh, oh my God, I'm wrong. I'm sorry. Yeah, continue. Ignore me. That's what I thought wrong. Yeah, I'm so wrong. So he called out to use assume dot that in the in unit API. I'd never never heard of never knew about that one. And I'm like, oh my God, that's amazing. That's beautiful. So instead I could remove all my comments and I can just say like assume dot that. And then whatever condition that I want. And then my code can be that much. You got one assert.

You know, well, yeah. Back to, back to a single assert. And I get rid of my comments that, you know, somebody else might not mean might not maintain. So that's cool. Yeah. I thought that was great. Nice tip.

Yeah. I wanted to mention his name is Danielle. He actually mentioned in a podcast who's recently on the cynical developers episode 10. He made a joke about sounding like Mario and I kind of clinged on to that. But you should check that episode out and you should join Slack because you get to hang out with cool people like him.'re right totally yeah and there was there was another question about um i want to say it was like a couple episodes ago remember we got tripped up on the question mark dot operator and we were trying to remember like

what we were referring to that when we were talking way back now about new c-sharp features that were coming in there was a specific term for it at the time that was going around and we couldn't remember what it was. And I, I forget what, what we ended on in that episode is like the Elvis operator or something, but then there was another name for it, but the actual name that we were trying to, uh, well, it's now called the null conditional operator, but at the time the name for it was the safe navigation operator. Oh, that's right. Yeah. You remember that?

I do. Yep. Coolness. All right. You got something to share there? Yeah, always. So I released another video, mini code adventure this time generating mazes with JavaScript.

And so if you didn't know, we're working on creating more videos these days. And so you should check it out. Let me know what you think. I'm trying to kind of make videos that kind of remind me of when I first was learning programming and everything kind of seemed possible and fun

and I would just do weird stuff. And so I've been trying to bring a little bit of that back and keeping things short. So you should check that out and let me know what you think. Also worked on a video with Paul Seal from codeshare.uk.

He walked me through setting up Umbreka, which is really awesome. As I've used WordPress for years, I've been a.NET developer for years. So I always kind of felt bad about it. And now I know of a better option. So you should watch that video and let us know what you think. Hey, you also did one on, it was a Markov chain, right? That one was also pretty excellent yep that was another mini code adventure and i'm kind of working these things um uh to a point

where i can kind of use some of the libraries together to do some cooler stuff but it's kind of fun working on because it's the total opposite of what i want to do in a way um like as a program like i always want to do everything scratch but like i want to you know bring in libraries i want to test it all i want to you know basically i want to program it and, but I want to bring in libraries. I want to test it all. I want to basically program it. In these videos, I've been doing the opposite, really focusing on the output, using as many libraries as I can to shave code and time off. And so it's been just kind of a fun juxtaposition.

Yeah, because you've been starting with Yeoman, right, for a lot of these things. So it's all there, and he can just start working, which, by the way, for most people, that's probably one of the biggest barriers to getting started on anything is just all the tooling and hookup around getting something up and running.

So I highly recommend checking out some of Joe's videos because he really does. He shows you real quick how to get up and running with Yeoman and literally writing code within a couple minutes. So good stuff. As a programmer i hate that there's all these libraries i don't know what they're doing and there's all this code there's all this stuff going on there's all these config files and i don't i have no clue so it's

hard for me to let go of that control but it's also very freeing to just focus on the the done line so it's been it's been really fun and kind of eye-opening to to just work on a like a very results driven approach now i will warn this approach is amazing for being able to just work on a very results-driven approach. Now, I will warn, this approach is amazing for being able to just start putting your hands on the keyboard. Never, ever just take that approach when you're pushing something to production because we mentioned on the last podcast, people setting up MongoDB and just, you know, they crank it out there. They've still got the admin and default password in, and you don't know about this, and that's a big problem, right?

So this is an excellent way to get up and rolling, but before you start pushing your stuff out to production, you really need to understand all those bits that are tied together. Yeah. Now, how many times have you started a project and you start looking into different configurations, and then by the time you're researching,

like how you want to set up the build process, you've lost interest for the project completely. Every time. It's not some percentage. It's every time. I was waiting on you to comment on that. I know you've mentioned that in the past, that being a big rub for you.

By the time you figure out how you want this problem to scale out to a billion concurrent users, you're like, okay, well, it's late. I'm tired. I'm done. Yeah. I'll never pick it up again. All right. Well, uh, we have stickers and we would like you to have them instead of us. So if you send us a self-addressed stamped envelope, we will gladly send you some stickers. So you can find all the information you need at www.codingblocks.net slash swag. And we look forward to sending you some stickers. Absolutely. And we have a winner for clean code on episode 53. Thank you for all those who commented and we apologize for all those that didn't win. But Cagnus Kabuku, you are the proud new owner of your own copy of Clean Code.

So we'll reach out to you and get that thing sent out. So congratulations. All right. And now it's time to jump into our episode here. We're on chapter 10 of Clean Code, working our way through the book, and this one is on classes. So here we go. What is a class? It's like a big function. It kind of is, really.

Kind of. In JavaScript, it's the same thing. They're all the same. So really, this is more about organizing your classes and how to make sure that you make them to where people can read through them and get through them. So what they start off with is classes should always begin with a list of variables. And they had their own preferred order which I mostly agree with I don't know that I've always followed it this strictly but like their public static constants or in c-sharp your read-onlys should be at the top then and then your private static variable should follow it then by your private instance variables now there was one thing that they said in here that I think this is probably because of

the way of doing things in Java that jumped out at me is they say it's seldom, there's seldom a good reason to have a public variable, right? And it's because in Java, everything is backed by a private variable. And so you have your getters and setters typically in a Java class. I mean, you could have in Java, you could just make those variables public if you wanted to, but. Right. But then you wouldn't have your getter setter paradigm, right? In.NET, you've got your public fields that, you know,

are basically backed by. Yeah, the properties. So this one I didn't totally agree with. I don't know. You guys. I do. I don't know. You guys. I do. I don't like to have the public. I don't like to have the variables directly exposed.

I like to be able to have some layer of abstraction away from that so that if I want to change the implementation of like how I, you know, work with whatever the input is or if I'm returning something, you know, just in case if I need to change that, I like that. So tell me this then. So I get what you're saying, but let's say, let's say that in a lot of cases, and I don't want to say a Poco or a simple plain old C C sharp object or something, but let's say that it's literally just something that holds data, right? Like there's no massaging going in or coming out. If you made that a public property, you could always later, if you needed to come back in and, and change, you know, the getter feature of it or the setter. Right. So that's what I'm saying. I would do a public, I would do an

auto property, right? So an auto property is exactly what you do initially, right? And make it public. But that's what I'm saying. Like, but keep in mind though, that behind the scenes that, okay, so an auto property is just sugar in the IDE. What's happening at compile time is a private instance. Uh, you know, variable is being created to actually store that data and getter and setter methods are actually being created and included when it actually gets

compiled. It's just for us visually, when we look at it, there's that sugary syntax, when we look at it, there's that sugary syntax of, we only see it as an auto property. But here's, here's the weird part though. In Java, it's very explicit, right? So let's say that you have- Only by practice though, it's not like it had to be. Right, right. But it's convention, I guess, is really what it is. So if you have a private variable and you called it like a width, right? Okay.

In Java, typically you're going to create a method called get width and set width. Sure. In.NET, you don't. You just say.width equal. And behind the scenes, it's going to call your getter or setter. Yeah. But again, that's because Java doesn't have that sugary goodness of the auto property to where it would have that width property and then automatically create the get and setter.

Agreed. Cause cause cause cause what I'm trying to say is that like at the end of the day, when it's compiled, both the Java and the C sharp are doing the exact same thing. C sharp is creating the getter and setter, but the way you're private member behind it, but wouldn't so tell me this though, wouldn't it be the same thing? Let's say that, let's say that you have a person class that has first name and

last name. And let's say that you do the same thing in Java and same thing in C sharp in Java. If you just made first name and last name public instance variables, then you could say person dot first name equal Michael person dot last name equal outlaw, right? That's really no different than if you just had public properties in dot net that were first name and last name. And you said person dot first name equal Michael and outlaw. So what I'm versus the invocation of like dot set dot get name dot set name.

And that's what I'm getting at is, is really, if you, I mean, I guess what I'm, yeah, I understand what you're saying, but where I'm going with that though, is that the compiler is going to, the C sharp compiler is going to make that what, what you would have in Java. If you did the get and set method,

but it's equivalent. Yes. And that's what I'm getting at is syntactically it's identical. And so when you say that you can't have a public variable, if you're really doing nothing to that, they're saying that really you should never even have a public variable, but no, no, no. But here's the difference. Here's the very key difference though. If you in Java, if you have a width variable and you leave that width variable, uh, public, okay. And then you later decide, oh, hey, you know what?

Based off of what value you try to assign to it, maybe I want to check something or maybe the get, maybe I don't even want you to be able to set that. I want the get to be calculated. So now I need to change that. Now you need to go back and refactor all the uses of that to use a method rather than this public, um, um, variable. Whereas in C sharp, because it has the auto property feature and behind the scenes, it's creating methods for you that you don't even have

to look at. Um, you have that ability without doing the refactor, that large refactoring to where you can just say, Hey, you know what? i want to change the git to actually do uh some special operation right yep so so that's a key difference there though oh it's a huge difference i'm just saying like this whole i guess that was the thing that i brought this up for is not having a public variable and c sharp means a very different thing than in Java. Yeah, but I don't consider a property. You're equating property to variable. It's behind the way that it's interacted with.

And behind the C, you're still creating a private variable. Doesn't matter. You're never looking at the IL code. What I'm saying is the way that you interact with it is different, right? So to your point, it's a very valid point. In Java, if you wanted that layer of business stuff on top of it, then you've got to change code everywhere where that was accessed and dot net. You don't basically what you're saying is if you were to like, look at two classes where

Java had a, a Java class that had a, uh, a public, uh, variable and a C sharp class that had a public property, that if you looked at those two classes, they would look the same character for character. You could write them to look the same, right? It's just that in C sharp, if you wanted to change the get and set operations, because it's a property, then you could without having to refactor every use of that variable, potentially. Whereas in Java, if you wanted to change that to a method, then it would create more problems. So I get that. But after it's compiled, though, you're not getting it.

So yeah, I mean. It's how you write the code, though. And that's what I wanted to pull out here is it's different, right? The two languages have syntactic differences and so in clean code where they say it's seldom a good reason to have a public variable i get it but in dot net it acts completely differently and it is syntactic sugar properties to variables but yeah yeah but uh i will say though the one thing about this section that that did get me was that if I am going to use a property,

sometimes I like to have the, if I am going to have a backing field for it, a backing instance member for it, a variable for it, I like to have it near that property. Oh, I do the same thing. Which would break this structure. Yeah, absolutely. Yeah, it does. i do the same thing like if if it was underscore width as the private then i would have the public width right after it yeah so i i don't know i mean i guess that's a style preference that seems how it's done a lot in dot net though isn't it i mean joe that's i i think a lot of your code i've seen the same way

yeah i always do it right next to it. That's something I got out of CodeComplete. But yeah, in Java, when you think about the getters and setters, I think I have seen kind of rows of those and then the variables underneath. But I don't know if that's necessarily a Java thing or just kind of a preference thing. But I prefer to keep stuff together. Yeah. Cool.

And then after the public variables, if you have any, then the public functions and it says follow closely. So going to that newspaper metaphor, if you have a public function that's using a private function, that private function should show up right after it. So not like a block of public functions and then your block of private, it would literally be a, you know, know public function whatever private function it's using then the next public function and so on so that was that was their layout for their clean class oh and uh go ahead oh sorry i was just going to mention the next point that we got here um so you can go ahead and mention your point before i take no no go go you're good i was just going to mention that they do mention we got here um so you can go ahead and mention your point before i take no no go go you're good i was just going to mention that they do mention changing

variables to protect it in order to be able to make it testable which is something that we've talked about a few times and it's kind of good for them to say it's okay it makes me feel a little bit better about some things that i've done and i understand um why they why they say that and i'm glad that they give it a thumbs up well yeah, yeah, so they say that, or he says that because test rule was literally what he said. Yeah. But he also says that's a last resort. Yeah, I mean, for the most part, you shouldn't want to know what the implementation of that private ish variable is. Right.

So you shouldn't need to test it. So I think that you should almost if you do need to test it, you should almost expose some some other method that can check the state of something. Right. I don't know. Just just a thought. But no reason to go too crazy on it. Yeah, I actually get torn sometimes about testing even protected methods within a class

because, like you said, you really shouldn't care too much about the implementation details. You should focus more on whatever the public interface is because that's the contract you know the contract of what that class is supposed to do right yep um and maybe if you're writing unit tests that do focus in on like private and protected methods then you're getting like a little too granular because those are the areas that might change more than you know some of the other areas but

yeah i've definitely written some unit tests around my protected. So the next point that they bring up that we've talked about in the past, maybe even in the solid episode, is classes should be small. And I like this. So when we talked about methods,

we talked about line counts, right? When he was talking about classes in this particular chapter, it was count responsibilities. I loved that designation for like how to measure a class. Totally. I wonder actually how long they sat there and thought about it before they finally came up with that. Because that's like an epiphany, right? Like I know exactly what this should be, right? It was because of when I read it, I was like, oh, that's beautiful. That really is beautiful. Yeah. And I mean, he, he gives like a, a beautiful example too, of, you know, by, uh, of where the difference between lines in your class versus responsibilities, um, you know, why that matters. And he expands upon that as the chapter goes on. But, um, I don't remember the exact name of the class or the,

you know, the method, but there was like one main method to it. And then something, um, it was like, like get last focused component. Right. And then there was, uh, some other methods that were related to the version of it. And, and he goes on to describe how, like, you know, those are two different responsibilities that the class is, uh, you know, providing, right? And even though it might seem like a small number of methods and a small number, you know, in terms of line count, the reality is that, you know, if you counted out the responsibilities,

that's where it started to go awry. Yeah, but I will say in this example, the class was like a model for a dashboard. And so I kind of do like the idea of having a class that acts as a facade for a bunch of other unrelated things. And so you've got like one basically interface for dealing with other things

that are normally disparate. So I don't really mind it too much in this case, as long as that class isn't heavy and it's truly just bringing in other behavior. I like simple facades for complicated behavior. So this particular example, though, like he took a massive class that had all kinds of garbage in it and then broke it down to five methods. Right. And this is where he was talking about. It had the mixture of get version information versus get focused.

And so they really are different responsibilities, right? And so I get it. I'm with you. Like sometimes it feels like making a class to make one method seems kind of silly. But I get where they're going with it. And it starts to make sense here in a minute too when they're going with it. And it starts to make sense here in a minute too, when they, when they start going through it. So like, um, this very next thing that we have, he says, just be, uh, not, not that one. If you can't derive a good class name, it's probably too large in scope. And I thought that was really interesting, right? Cause dashboard is really generic, right? So, so what all can a dashboard do? Like what, what all, I mean,

depending on how complicated your dashboard is, it could do a hundred things, right? I just named it dashboard info or dashboard manager. And that brings us to the next thing that they say, there are weasel words, manager, processor, super, anything that basically ends in ER or OR is probably an issue. I did like that term, the weasel words. That's one for your next code review. Right?

And it's interesting though, because we've all seen them, right? Like you'll see something like string manager or string utility or something like that. And a lot of times it's literally just gobs of random little things that, you know, you just kind of comb through to try and find anything useful. Yeah. And this was all part of an effort or going back to the responsibility, you know, and making sure, you know, you don't have, you don't have too many responsibilities. It was around responsibility driven design, which isn't a phrase that you hear a lot about. Yeah. That's not DDD, right? Huh? You hear that one a lot. No one's taking DDD, BDD, TDD,dd but then rdd and you're like um i think you just mean r and d

yeah i that i i honestly think it's a really nice way to think about things and and we get to it a little bit later so i'll say i'll save that part but i did i really did it resonated with me i i think I try to do things like that. A lot of times you get hung up on it, but, but yeah, I really liked it. Things tend to leak in. Like it might originally start out nice and clean and solid. And then over time it just becomes a wasteland of, you know, everything got piled into that one class. Like, wait, what happened? It started as a circle. Yeah. There was another statement in here, and I feel like we've talked about this before related to methods, but he was saying that you should be able to describe

your class in 25 words without using the words if, and, or, and lastly, but. If you have to use any one of those four words to describe your class, then you already know that it's doing too much. And therefore, it has too many responsibilities. So my class gets components and it tells the version. Oh, that's too much. I was just thinking like every comment I write write it pretty much is one of these four words like it does this one thing unless some other thing and that's why i'm writing the comment

because it's kind of funky so yeah that's a good point that kind of goes that ties into the whole trying not to write comments thing yep and that brings us to the next one which joe i think you talked about a lot in our solid episode so You want to lead us in on that one? Sure. And this kind of ties into the responsibility driven development we were talking about. It's the SRP, the single responsibility program per principle. And basically the idea that there's only one reason why a class or a module should have to change. And it's also, I think, the hardest letter of solid to actually accomplish.

And I recommend everyone tries to program something with total strictness on, on SRP, just cause it's really hard to do, but you will end up with really small classes and really small functions that do one thing if you really try to stick to it, but it's tough. I'm surprised that you say that it was the hardest of, of the solid letters to follow because in this chapter,

he specifically calls it out. It's like, this is one of the easiest things to do, but I totally disagree there. Well, he says it's the easiest to do, but it's also the most abused, right?

Right. Yeah. He followed up directly with that. So I think it's the easiest to abuse because you're always trying to make something, right? Like when you're trying to build something, you're not thinking about every, every single method you make. You're not constantly like, Oh, because you never get anything done, right? Like you can easily overthink the program and then you just find yourself in a rut. So I think that's why it's abused the most i still have a hard time with it and maybe

i'm just doing something wrong but that that's the one that always ends up driving me nuts because i'll start programming and i start thinking oh crap i'm doing too much let me split this up and then split it up again and now how do i even tie this stuff together without making one thing that he just three dependencies on this other stuff and so that's the one that I end up thinking about the most. The O, the L, the I and D I think are the easiest by far. But that's just me. Do you want to recap what those are supposed to be? Because you just went through all of solid. They're the other letters in solid.

I just summarized that for you. Episode seven. The O-lids are easy. O-lid. I think that's a new tv coming out it is yeah i practice uh i practice toled which is two or three uh responsibilities and then the rest of all it you know uh oh is the open close principle which is something should be uh was it uh open for extension closed for modification um and i feel like i can set that with just kind of privacy levels and just letting my stuff be extended.

I'm definitely oversimplifying that, but that one just doesn't seem that hard to me. I think I kind of do that one naturally. And then there's the Liskov Substitute Principle, which is, I should probably pull this up while I'm talking rather than making stuff up. But it basically has to do with being able to swap classes in and out for their uh their interfaces or um uh higher abstractions which i think is also another one that just kind of happens as long as you're not doing like i don't even do a lot of inheritance usually so that one hasn't been too big of a deal for me either and the i is inversion of control which goes along to me with testing

and same with D for dependency injection. So once I start bringing in the testing, the I and the D, they have to happen or else I'm not going to be able to test. And so, um, you know, it's one thing or the other. So if I'm trying to actually do a project, uh, in a solid way, and I also very rarely do that, but it's always the S that really hangs me up because it's so different to how I normally think about things. Okay. Thank you for the recap. When you, when you rolled through the letters, I was like, man, there's going to be a lot of people are like, uh, yeah, I don't know what we're talking about. I didn't want to, hopefully I didn't get them all wrong. Well, yeah, I did want to correct you on one though, because you said I was...

Inversion of control. Inversion of control. It's interface segregation principle. Oh, yeah. Well, I don't even know what that is anymore. But it's easy. Well, I can tell you how we summarized it in episode seven, and that is that no client should be forced to depend upon

methods it does not use okay so yeah you want to pass in the minimum amount of information and only take in the minute minimum as well as only acting upon the minimum amount of stuff okay cool so we've recapped episode seven you should go back and listen to it anyways. All right. So here was one thing that I thought was interesting and you touched on it a minute ago, Joe, was as you start doing things like, oh, I'm doing too much. I need to refactor. Well, that's one of the things they say here is identifying the responsibilities in that class can help us to refactor into more concise classes. So it's actually not a bad thing. Like going through writing it and then being aware when you do it, Oh, you know what? I could probably

pull this out. So that's exactly how you should go about doing those things. Write it and refactor afterwards. Yeah. But the reality is that we write it and then we're like, okay, that's done. Oh, I want to refactor this thing. Oh wait, I got to go off and do this other thing that is completely unrelated. Okay. I promise I'm going to come back to this tomorrow. Let me just do this one real quick thing to make the boss happy. And then a year goes by and you're like, oh man, I still haven't cleaned this up. This is embarrassing that this even looks like this. Why did I write it to begin with? I should just, let me delete it. I can erase this permanently from the git history. Hold on one second, man. I suck.

Let me just replace this whole thing with one comment that says, I'm sorry. Yep. So there's that. And that's real. And here was one that came up in, and I don't even think this one really matters unless so the concern of a ballooning number of files, right? Because as you create your classes, you have a ton of files that show up, but you see people that do that and it drives me nuts. You'll see people, you'll see code where you'll have like, um, an interface defined in it. And then there'll be a couple of classes that might implement that interface, or there'll be like a couple classes that aren't related they're in the same file and i'm like why why didn't you just split this stuff out right make files and you'll talk to

me like oh no i just thought it would be easier if there was just the one file that had all that and i'm like no i i'm looking for these things these uh classes by class i'm looking for the file by class name right and when you hide it like that so here's the thing and i and i've actually seen this argument over in our slack channels at one point where you know people like well if you're not using an ide then it's not that easy and my argument is look man if you're writing any kind of big application, use an IDE, right? I get it that there are some great text editors out there. Vim's one, Notepad++ is probably good, Sublime's good. But dude, if you cannot get from one file to another and you can't browse from classes to other classes, then get a different tool set, right? Like don't let that be your crutch,

that there's a bunch of files and it's hard to get to them. I don't, I don't think that's a legitimate excuse personally, my opinion. And don't use JavaScript for large projects. Whatever, man, you should know JS all the things. What? All right. So what about organization, right?

There was a, there was a statement in here where he was talking about organizing your toolbox. And would you rather have a bunch of individual, nicely labeled and organized drawers? These are where my metric wrenches are. These are where my imperial wrenches are. Here's all the screwdrivers. Here's the sockets. Or do you just want one big drawer with all your tools, you know, your hammers and saws in there and every time you like reach in to get a screwdriver, you get cut by the saw. Let me tell you, that's actually a simple view.

It is nice, but I like you got a wrench. I'm sure both of you have a wrench that's imperial on one side and metric on the other. Now that's the one is it just throw that one away? No, but I will say I strive for that neatness in my toolboxes and it never happens that way. Oh God. And then you get back in there and you're like, man, I'm so mad at myself for not having put this back where it should have been. Yeah. I'm so mad at myself for not having put this back where it should have been.

Because 15 minutes later, you're like, babe, I'm going to Home Depot and I'm buying another one of these because I can't look anymore. Which is why this episode is brought to you by Craftsman. So no, I mean, it's totally legit. It's a perfect example. You put it in a huge file with a lot of other garbage, you're never going to find it, and it's impossible to follow. The smaller classes make sense to me. Yeah, I really liked where he summarized this, though, and he said that if you have large multipurpose classes, it forces you to scroll through and read code that you don't

need to know right now. Whatever you're trying to fix or whatever you're trying to do or new functionality you're trying to provide, that other code is just getting in your way. Yep, totally agree. So I think that means that the correct size for a class, we said that the correct size for a method would be one line. So I guess a class then would have to be two lines. No,

no. Well, yeah, at least cause it's going to have one instance variable and one method. That's it. Oh, okay. I don't mix methods and instance variables.

I, I either have a class or a data structure. Oh God. Yeah. See, I was just thinking you had like your, your, your class statement with the name of the class

and then you had the method name. And the method we already said was one line. We've helped everybody now. I think that's as clean as it's going to get. It is. So with that, you're probably thinking like, oh my God, these guys are awesome.

How could I help them out? Well, let me tell you, dear listener, what you could do for us that we would super duper appreciate is if you were to head to www.codingblocks.net slash review, you can find links to Stitcher and iTunes there where you could go and leave us a review and we will be forever grateful to you for doing so. And with that, let's get into my favorite portion of the show. Survey says, all right. I always love just saying that. All right. So, uh, last episode we talked about unit tests, which you know how much we love. Uh, and the survey was how much of your code is covered by unit tests. Now here are your choices. What unit test? Oh, um, zero or those old things. Uh, it's probably like 25% or less. Or we try, but we're somewhere between 25 to 50% depending on the project. And another choice is we're on top of things. Our tests cover 75% of our code or we're amazing. Our code is covered a hundred percent by unit

tests and sprinkled with the glittery dust of a unicorn's breath. And lastly, wait, work or personal work? Um, not so much, but personal you'd be proud. So let's see. Let's start with Joe this time. I think Alan went first last time. So Joe, what would you say among those choices would be your pick that you think was the most popular one among our audience? Oh, man, that's a, it's really tough. Um, I'm, I think that it's going to be, I think it's going to be what unit test. Oh,

I'm zero. And I think it's going to win by C or five, no faith, uh, 19%. 19%. You said it was going to win by 19 is 19. What you think the, the overall vote was for this one?

No, I think he was doing some quick math there among how many questions there were. Yeah, what's the minimum? Let's say 17%. So, unfortunately, I also picked that one. Oh, really? Yeah, I'm pretty sure that most everybody's like, yeah, unit test, we don't have them.

It's going to come down to price is right rules. Unless Will's crew is listening over there at Pivotal. That's all they do is unit test. They probably skewed this a little bit if any of them did it. But I'm going to say this one won and it was 30%. Wow. Big difference there. So we have a difference between 17% and 30%. Wow, big difference there. So we have a difference between 17% and 30%,

both of you saying that our listeners just don't write unit tests. Yeah, pretty much. Yeah. And remember, this is Price is Right rules, and for those not familiar with the Price is Right, that means that if they went over, they lost, even if they are absolute closest. So what was the winning answer?

Well, I will tell you this much. You guys, I don't know if you cheated, but you got it. Really? That was surprising to me, the highest vote. You were surprised. Really? I really expected zero unit tests. Yeah. I'm at a loss for words. Yes. I did not expect that zero unit tests would be the most popular vote vote. All right. It was a percentage, but you lost Alan. I'm sorry. I caught it. Yeah. 25% or something. Oh my God. Where did you pull that? You cheated. Was it 25? It was 25%. I totally didn't cheat because I would have picked it. Yeah. 25% or something. Oh my God. Where did you pull that? You cheated. Was it 25?

It was 25%. I totally didn't cheat. Cause I would have picked it. Bad. Oh yeah. No, it was absolutely, it was 25% of the vote for zero unit test.

So that's not as bad as what I thought it was. I thought it would have been higher. Honestly. I really did. Yeah. There, there were some, you know,

the next, so this is where I really did. Yeah, there were some, you know, the next. So this is where I started to feel good about the world again because, you know, there were, you know, the next one was in the 25 to 50%. So, you know, between somewhere between 25% to 75%, I mean, those three together were definitely the majority of the... So people are trying. That's the good thing, right? Yeah.

Like, more or less. Now, here's the funny one, though. So there was one in here, and I don't know if, dear listener, if you happened to catch on to which one was a joke, but there was one in here about we're amazing our tester covered a hundred percent with unit tests and sprinkled with the glittery dust of a unicorn's breath like i didn't think anybody would actually pick that one and they did it got three percent oh nice very nice hey i was really surprised about that. This is 100% random, but well, I mean, maybe 80% random. You know how you like doing the surveys.

Yeah, okay. Man, I was flipping through the channels last night because it was the first time I sat down to watch TV in quite a while. And the new LeBron James game show, The Wall, was on. Oh, right. Dude, it's fun. Have you guys seen it or seen anything about it it's like I've seen I've seen the commercials for it yeah dude it's like new age plinko I've seen

the commercials for it and I'm like that's a show that's a thing really dude I'm telling you like they've done a really good job of making it a an anxiety-ridden plinko game it's amazing it really is so go check it out I'm sorry I had to derail this conversation, but when you did that, I was like, oh, totally. This is amazing. I love game shows, by the way. When I used to sit there and work at home, I would have my TV on the old game show network.

Game shows from the past 40 years, right? Right. And I've always loved to – I don't know. I have. Reminds me of sick days at home with a, you know, grandma. We were watching Price is Right or whatever. Dude, Price is Right. Bob Barker, amazing times.

Come on down. Yeah, man. You're the next contestant. All right. So, well, this is kind of random, but maybe not quite as random because at least this is on the topic of programming. But for some reason, this particular Stack Overflow came to mind today. And it's one of my favorite answers that I've ever read on Stack Overflow. And it's old. It's not by any means new. And surprisingly, it's not even the approved answer, but I definitely think it's hilarious, but, uh, and

I'll include a link for it, but there's a question on stack overflow from several years back. What is a callback and how is it implemented in C sharp? And so my favorite answer is this. I just met you and this is crazy, but here's my number. That's the delegate. So if something happens, that's the event. Call me maybe

and that's the callback. Do you want to say that for us? No, no, I think I think we've done enough singing in past episodes joe you do it no one has complained about her singing yet joe joe do it you're correct technically we they haven't crazy so call me maybe there we are awesome i love that i love that answer and I don't know why that came back into my

mind today, but I was like, Oh, you know what? We should share that in case of, uh, no one else is, if they haven't heard of that, then they deserve to have some humor in their day. That's good stuff. All right. So let's get into this episode survey, which is what type of overall development floats your boat? So do you prefer gaming? I want to make something people play with or business apps. I want to create apps that solve real business problems or machine learning. Data science gets my brain moving. Or DevOps. I want to make software delivery smooth as silk. Or big data. I want to pour through all the bits. Or maybe it's hacking.

Reverse engineering is how I butter my bread. And lastly, frameworks. I want to build the next great tool for developers. So I look forward to seeing those results. I do too. I'm really curious about this one. Don't, don't. I won't cheat.

I haven't ever cheated. I really haven't. No, no, no. I was going to say like, don't, don't, don't hamper the witness pool. All right. I won't. I won't. All right.

So let's get into cohesion. Let's do that. Well, it's not all jumping at one time. So I didn't read this chapter. Well, there's something to be said about honesty. Hanging up. All right. How do we got notes in the sides from the last time I read it years ago.

But no, I'm out of date today. So I vote for someone else. All right. So classes should have a small number of instance variables. And the methods, the way that it read in the book, and I'm wondering if I read it somewhat wrong. I'm curious. Is methods should affect as many of these variables in the class as possible.

And this meant like per method. So is what it sounded like. So if you have a method and you have three instance variables in your class, then if your one method, if one of your methods uses all three of those instance variables, then you have what's called high cohesion, right?

Like it's very, that class is doing a lot with everything that it needs to do. If you have, you know, 10 instance variables and you have a method and it's only touching one of them, then you have low cohesion. And that might be a thing to think about potentially refactoring. Well, let's say that if each of those, let's say in your 10 you have five methods that only touch two variables each, right? That's where you would have low

cohesion, right? If you have a method that's only touching a single that if you have a private variable that's only touched by one method, then why is it an instance variable? Why not just make it in line to the, or bring it into that method?

So that was interesting. And basically what they got at is, I kind of mentioned a second ago, is if for some reason you start noticing that you don't have high cohesion, then maybe that means you can refactor those things out into a new class. Or like you said, you could just bring the variable into it, or maybe, or maybe if you have to bring the variable into it, then it's not really doing anything that it needs to do there. So it basically means that it's time to start looking at potentially refactoring that, that class. Yeah. And what I really loved about this though, is it got my, it's time to start looking at potentially refactoring that, that class.

Yeah. And what I really loved about this though, is it got my, it got me thinking about, um, I wonder if, and there might be, and I just haven't noticed it, but I would love to know if there's some tools out there, whether it be a static code analysis type of tool or a tool that could run in, in real time as you're, as you're writing the code that could measure the cohesion level. That way, as you're looking at the class, you're like, oh, you know what? The cohesion's low on this. I've done something here that I probably shouldn't have. Or everything's okay,

but this is an opportunity to split things apart. So if anyone knows of a tool like that, I would love to hear about it i was actually just googling around and depends i know a new version just came out and i know a lot of the tools and graphs and static analysis stuff that it does a lot of it really relates strongly to finding code that belongs together and finding code that's kind of too bloated but i don't know if it has like a single score for cohesion. I don't, I don't know of anything like that. Yeah. I haven't seen that. Time to play with it.

We should write him an email. Right. Actually. Yeah, we totally can. So, yep. One of the, uh, so the next part of this was organizing change and this is where a lot of a lot of the whole the whole reason why you break classes down in smaller pieces it all sort of comes together here so when you break them into smaller simpler functions you reduce the event that when you modify one function it'll break another because you've now got a smaller set of changes to work with, right? Like you don't have all these crazy interdependencies. So it makes it a little bit safer to do things.

And something that Joe brought up earlier when he was talking about one of his solid letters is the way that you fix things to where you're not touching an existing method or a function is you allow for subclassing. So you open it for extension. And that's a huge way to be able to do things safely. Yeah, this made me really think too about, at least in my own classes that I've written, we've talked about the template pattern before. And I know I've done this multiple times where I'll have classes that'll have, I'll define some structure of like how the calling order is going to be done, but all the methods are protected and virtual

so that if some other subclass wanted to override that functionality or provide new functionality or whatever, then I'm giving them injection points into that, right? So I kind of looked at that as like, you know, like as I was reading this, I was questioning like, I'm pretty sure that that would fit in with, in line with what he's describing in this section. Yeah, totally. But there was a, there was a really great quote that I liked though. Um, and the quote was that if you have, um, private method behavior that applies only to a small subset of a class can be a useful heuristic for spotting potential areas for improvement. And when I read that, I was like, you know, that's actually really cool.

I haven't actually thought of it in that way when I'm trying to figure out like, okay, you know, should I break this apart? What parts should be broken apart? So I like that. And this going back to my previous question about the cohesion, right? If there was some tool that was measuring that, that maybe it could like point some of these out like hey this method is only implementing uh or only uh manipulating a small subset of private variables and you could really just move that whole thing out right um so i really liked that quote I see the ROCP is up there too, the open close principle. Yep. What you mentioned, open for extension, but close for modification. Basically, you should never touch that base class, right?

Or whatever that subclass is. You can always add as many subclasses of it as you want, but you should never be touching that original one. Which using that template pattern as an example, right? Like the structure is defined there, the methods are protected, you know, virtual so that you can override them if you need to, but there's no real need. You shouldn't have a real need to go and mess with that, but you could add on as many subclasses as you want.

So therefore it's open for extension. extension yep totally isn't that a cool way of thinking about things like you just kind of keep adding new features and then you reorganize those features in different ways to make things happen and i feel like that's what like you know management or whoever shareholders whatever that that's how they kind of imagine the word feature they say i want this thing and you give them that thing and now they can take it and rearrange it and, or get the old thing back or whatever. I know it doesn't really work that way in practice, but that's kind of the dream, isn't it? Well, I mean here, like he sums up the dream when he says that ideally we want to be able to add new functionality by extending the system, not modifying the existing code. Now let's go back to reality for a moment.

How in, in all of your career, right? How many times have you not had to modify the existing code? Yeah. I mean, it happens a lot. So, so it's a great ideal and something to strive for definitely you know up there in the realm of of seems nearly impossible and if i ever do get to that situation i'm probably sitting next to a unicorn well this i as i'm writing that code you know what though i think that you know there's been a lot of buzz in the past couple years about composition over inheritance and this is one of those cases where I think composition actually does help with something like that because if you're if you're building on functionality to a class instead of having a class that does too much or or you know has various different pieces of functionality

if you just build on pieces to that class, you know, you add it as a property of that class, then, then it might be easier to follow something like that because you're not, you're not working through inheritance as much as, as much as you're just building up pieces of the class that you need. It's, it's easier said than done though. I tried to do that recently with an existing class, and I ended up scrapping it because it was literally just, it was going to be so much refactoring and rework that. Yeah, but I mean, I like the idea of composition, though,

as a way to get to this ideal. So I think you're right there, that it can definitely help set you on that path. Don't repeat yourself too extreme. You can start one code base and just keep adding little things and configure it differently. And 30, 40 years later, you might have written all possible code, and now it's just a matter of arranging and composing things to do useful things. There might come a day when we run out of code to write.

It's already done. Now we just got to pipe things together like Bash. You can put a workflow engine in place, right? So all code will come down to a series of piped together Bash commands is what you're saying. That's awesome. Yeah, and is that better or worse than JavaScript? Worse.

Well, is Bash going to implement a virtual shell then? I don't know how to answer that. They've already thought about it. So before we derail this train any further, let's go into isolating change. So a client class, depending on concrete details is at risk when those details change. And this kind of goes back to that whole don't have public instance variables, right? Like you shouldn't be knowing about a lot of those internal details and that's why you want to be calling methods. If you're relying on the inner little bits of a particular class, then you are,

you're setting yourself up for some hurt in the future. Well, I also kind of read that. I mean, yeah, maybe that's part of it too, but I also was thinking at the time that I was reading it about like using interfaces versus using a concrete class. Oh yeah. Good point.

So that was like, as I'm reading this chapter, the kind of scenario that was playing in my head, right? So if I had some method that took in a concrete class versus a method that would take in an interface, then with the interface method, I'm probably, or version, then I know less about the class. I only know the contractive, you know, it offers these few things and I can do what I need to do. Yeah, that's a great point. And one of the things that they bring up, like the next one was a good base or abstract class can make testing easier because you can create these repeatable tests. And an example they used that I really liked was if you've got the Tokyo stock market and you call a method to get the value of, I don't know,

whatever stock you're looking at, it's going to change every time you call it, right? Like every second that thing's fluctuating. So that's not a good use case. Now, if you had a stock base class to where you could just say, okay, you know, get the value and it just returns a hundred every single time, then that you can test against that because you now have a repeatable test. So I really, I like their example of that. Yeah. And then there is this statement about making code more testable makes it more reusable in effect. So kind of going back to some of what we talked about in the previous episode, now carrying

forward into this, which kind of goes along with what you were talking about with the stock example, is that if you are making those tests available, then you're already kind of recognizing where you've introduced these dependencies that maybe you didn't mean to introduce, but because they're there, you can't test with those dependencies. So if you figure out a way to remove that dependency so that it can be injected as you need it, now you can test it and it can be used. The code is more reusable because it's not relying on the single dependency that you were using at the time that you originally wrote it. It is interesting when you think about it, a lot of, a lot of what you do, if you end up writing better code, you can find out if you've done it right.

If you can write a unit test, like I was thinking about this the other day, like a personal thing that I did is I had to add something to an application. And I separated it out pretty decent, like there was a there was an API call and that API called into, you know, some sort of class library. And that class library did something. And I realized after the fact, really, the way I should have done this is in that class library, I had to interact directly with the database and go do something, right? What I should have done is I should have abstracted that away one more step and said, okay, make this thing something testable so that I could call this method. And then I could have also had the next step be something like, you know, Hey, go do the

database transaction. But it's just interesting, like when you start thinking through these things, as opposed to how you're always working, if you think, how can I write something that would allow me to test this feature, this functionality that I'm doing, then that almost forces you to break it into a way that is more reusable in the future anyways. So this takes us into yet again, another letter from Solid, which is the dependency as a parameter to your class, instead of going to something like a singleton, or maybe just kind of newing up an object and doing it that way. And that makes your code more testable, which is awesome. But it also just makes it easier to configure outside of the code. So you can change things either at runtime or compile time or for different environments or in a bunch of different ways that you may have even thought about doing.

And you don't have to change any code to do it because you pulled those dependencies out and now they're being injected in and just kind of reverses the relationship and makes for cleaner code. And what I like about this, I like to mention is that dependency inversion doesn't mean you have to use a framework. You can start by just pulling those guys out into parameters at first and passing that stuff in by from some sort of other place, like a parent class. And then you're set up to do the testing. You can test away. And if you want to add in some sort of fancy framework later in the line, that's fine, but you don't have to make that decision upfront. You can start pulling those, those things out right now. Well, it's also important to say too, though, that, so yeah, you're right. It's not dependency inversion is not dependency injection.

But it is important to point out that with dependency inversion, that you want abstractions and not concrete details. So by that, what I mean is that you do want to have, allow your caller to be able to pass in those, those details, but you don't necessarily want to know that it's a list. You just want it to be innumerable, right?

And that's what they're referring to here is that you want to depend on something that's innumerable, not something that is specifically a list object. Yep, right. So that example I gave, rather than pulling out the database manager, also terrible name like we discussed, why don't you call it,

have the same methods, but just name it a little bit differently. Think about it a little differently and maybe call it like a data provider or something that gives you some flexibility. Because if you want this stuff to be able to be reusable, reusable ways that you hadn't imagined, then that's the way to go about it. And by going with your interface example, then that means that if somebody introduced a new data provider, I think it's what you called it, a new data provider, then it might be to something that you hadn't even considered yet. But yet now your code could still be usable for that new implementation. So I do want to back up real quick because you made a very important distinction in the dependency inversion and dependency injection. Dependency injection uses dependency inversion. And the big key is, so if you're in a method, so like what he said, pulling them out into parameters,

I think walking through a small little simple example might help illustrate this because I've gotten lots of questions on this in our Slack channel and other places as well. When you're talking about dependency inversion, think about if you call a method that says, you know, save person, right? Typically, in the way a lot of people do things, they just pass a person to that save method. And then inside that method, you're going to have something like using connection, you're going to instantiate a new connection to the database, then you're going to pass that person information either to a SQL query or to a proc, right? Now, if you back up and do what Joe was saying, where you take that and you make it into a parameter now, instead of newing up a connection in that thing, you might pass I connection or, or in, in my case, I really like repositories. I like the

whole repository pattern thing because you could have a person and say, save, right? So now what you do when you call that method, you pass in the person and you'd also pass in an I repository, we'd say, right? And then that way it could be a fake repository. It doesn't even matter, or it could be your real connection information so that it could save it. But that's where the inversion is because what you're doing now, instead of knowing it up inside that method, you have to knew it up somewhere outside of it in the collar. And that's why it's called dependency inversion, because now you're passing it what it needs to do to act upon that data that you were trying to use. So I think a lot of people get confused about that. It's actually

a pretty simple thing. You knew it up before you actually get into the method. And so you pass it along to the method. Yeah, very good point. So anyways. So with that, that's going to wrap up this chapter. And clearly, Clean Code is a resource that we like. So we will have an episode. We will have a link in this episode, uh, which you might find surprising, but it will be there. It will no doubt. And if you didn't win it, you can buy it. If you keep commenting, you always have the hope of potentially winning it in the future. Uh, but if, if you're

tired of waiting and you, did we forget to mention that at the beginning of the show? Oh, we did. We did. Yeah. I think we totally forgot. So if you would like to have a copy of Clean Code, be sure to go to this episode at www.codingblocks.net slash episode 55 and leave a comment, and we will be pulling from that list to see who is the next lucky winner. Yep, totally. So comment on this episode.

And you know, one thing I don't think we ever mentioned about the actual physical book is that it's got a bibliography for each section. So there's actually further reading and all the sources that are mentioned in the book are actually findable there, which is really cool. Yep, killer point. Yeah, which is kind of unusual. You don't really see that in a lot of books. So yeah, great point. And another thing too, I know I mentioned this before we talked through this stuff, but they really do have excellent visual examples throughout the book. Like, I mean, several of these chapters, you know, they're really only a few pages long after you

take out all the code pieces, but those code pieces really do help illustrate what, what we're talking about and what we're sharing from the book. So it's definitely worth a read. So yeah, I think in fact, in the beginning of the book, like maybe in, um, like an introduction chapter or something like that, it's like, yeah, you're going to have to read the code. You can't skip over the code, or otherwise concepts might get lost. Yep. So with that, let's head into Alan's favorite portion of the show. It's the tip of the week. Yeah, come on.

And I'm going first. I got another one here, thanks to Juggernaut, with sixes instead of Gs. And he pointed out today that you can trade in your old tech books or actually video games music lots of other stuff on amazon and not only will amazon pay for shipping but they'll tell you the value of the items before you even send it to them so i actually just looked up clean code if i were to sell my my copy has notes in the margins but if my copy were in better condition, they would give me 10 bucks for it.

So if you dear listener, when the book and want to make some money, you could just turn around and sell it for $10 and 70 cents. Come on, dude. But the reason this came up is because juggernaut recently sold a bunch of his tech books. So he took a,

you know, old like C plus plus 95 or whatever, an Amazon game, something for it. So he took, you know, old like C++95 or whatever, and Amazon gave him something for it. So rather than dropping it off at like Goodwill to, you know, gather moss or, you know, throwing it away or trying to pawn it off on the library, you could actually go and sell it, and Amazon would give you real money for it

that you can use to buy other Amazon things. And it'll keep you off the show hoarders in the future as well. So there's that added benefit. Yes. All right. So, oh, I guess it's my turn. Right. And we'll have a link in the show notes there. I'm not going to read that. All right. So, so mine is indexing and SQL server. If so, one of the things in SQL server or any database system really that can become problematic is if you need to sync data between environments and you're using surrogate keys that are just numbers, right? Like one, two, three, four, five. All of a sudden you need to move something into production from dev or to dev from production. What are you going to do? You have key conflicts now,

like your number fives don't match. What's number five in production is not number five in development. So one of the ways around this is you typically use like a unique identifier or GUID or UUID. They're called different things in different languages. But one of the problems with using GUIDs for a key or a unique identifier as a key in SQL Server is it's big. And they are also random. And one of the ways that SQL can get to data fast in SQL Server is it orders the data on the disk. And then that way, when you go search for something, it uses an index or a seek or a way to get to

that record fast. Well, if you're using a true unique identifier, they're random, they're all over the place. So you literally get performance problems because you get page splits. Things are always trying to be reorganized. It's ugly. Well, I came across something interesting today that I thought was a nice thing to know about. You can create a GUID as your primary key on a table, but do not use that to create your clustered index on the table. So it's interesting because typically when you create a primary key, it will also create a unique clustered index for you, which means that it's going to try and use that same column. Well, if you define the table yourself, or if you go into the properties or write your DDL yourself, what you can do is you can set the GUID as your non-clustered primary key, which means it's not going to try and sort that thing. And then what

you could do is you could create another column on that same table, make it an int, give it an identity seed so that it counts up and make that your clustered index. Now, it brings up an interesting point in that, you know, now what are you joining on in your application, you'll probably join on that ID on the identity column, because it's smaller, and it's faster. However, the you the unique identifier will be truly unique. And it's not going to add to your clustered index. So it's going to save you a ton of space. You're going to be able to search faster and everything kind of comes along for the ride. And I believe you can even use this in replication. So I thought that was interesting. If you break out your primary key into a non-clustered and then you

create another column and you make that your cl index. You get the benefit of both. You get the speed, you get lower storage, and you get the uniqueness for the record. So you're kind of describing having two primary keys, sort of. So you really have one primary key, but then you have another one that's your accessor. That's really what it is. It's your way to be able to access things within your system. But if you need to sync that data to another system, you still have your unique identifier so that you can make sure the records are unique and then it'll get its own ID in that system as far as a number for doing your joins. So there's an ID that you don't care about. That's the

integer. Yep. Then there's the unique identifier that you do care about, but you don't want to create a clustered index on it. Yep. So it's a, it's a performance tip and it's, it's a pretty cool one. So, uh, I thought that was worth sharing. All right. So I'm kind of torn between, uh, which one I wanted to get. So I'm going to let you guys choose. Oh, I know they're all, they're all Git related. See. So I don't know how you wouldn't have guessed that. I choose the tip mentioned by Brantley Blanchard and Mad Viking God to use the exclamation point to access the shell scripting when you're doing things like Git aliases.

Oh, yeah. Okay. Sorry for hijacking your tip. Yeah, no, that's fine um thanks could you please repeat what he just said oh go ahead joe so uh a couple episodes back i mentioned uh not being sure how to uh do shell type stuff and like get aliases because sometimes i'll do some good stuff and mix it with some bash stuff. And we had a couple of people write in notably Brantley and mad Viking God.

And they mentioned that you can do with the exclamation point, which I haven't tried this yet, but a couple of people did mention it. So I'm sure it's awesome. So sorry. All right. So what's your tip Ella? All right.

No worries. So do we want right, so what's your tip, Ella? All right, no worries. So do we want to talk about shallow cloning? Do we want to talk about copying archive without actually getting your.get directory and therefore it being an actual repository? Or do we want to talk about extra commands that are very helpful in order to see information on your, on your repository?

Let's go with two. I like the whole, you know, you're talking about basically getting a clean set of your code out of get without all the good stuff. Okay. Two it is. I like that one. All right. So I will include a link to a stack overflow answer on this but

basically here's here's what um where this came from here's the background on this story so uh i had some code that was using bauer to do a uh an install from a get repo of a specific tag. Okay. And basically all that Bauer was really buying me was the fact that it was, uh, checking out this cloning, this repository, checking out that tag, and then making a copy of that repository minus the get repo and get ignore and get attribute files, anything like that. Right. Minus all of that repository minus the Git repo and Git ignore and Git attribute files, anything like that, right? Minus all of that stuff. And it was just a clean version of what the files were, right? In the repository. But the problem that I ran into is that there is a known open bug in Bower that if you need to do that syntax for a private Git repo where you have to pass in credentials, then Bower will choke on the credentials and throw up an error and you're

left looking for alternatives to Bower, right? So I was hunting around and everything and I'm like, you know, surely really all this thing is buying me is it's just doing a copy of my repository, right? So turns out there is a command in Git called archive that you can use. And even in the documentation, the very first example they provide is using the archive command in Git to take a repository and compress it and then extract it out into some other directory. Now, by default, the archive command assumes that you're in a repository directory, but you can pass in a remote so that you could use a repository that you don't yet have, right? And then clone that

repository and then get it. And so what the archive command will do is then create one of two compressed files, either a zip file or a tar file, uh, you know, depending on your preference, but then, you know, going back to Joe's desire for everything being, uh, bash commands that are, or together or pipes together, you can then pipe that into other commands to, uh, CD and, uh, to some other directory and extract that tarball into that directory. So I will include links to both the get documentation as well as the stack overflow answer that started leading me down that direction. But it's definitely interesting and worth taking a look at. Very cool. All right.

Yeah. So that's it for the tips and you're really not going to tell us the other two. No, man, you really want to know the other two. I really didn't think you would. We got to do it for a,

yeah, I don't want to muddy the waters. No, you got to say that. Yeah, no, we'll do that. So,

uh, that that's it for chapter 10 on classes. So with that, be sure to subscribe to us on iTunes, Stitcher, and more using your favorite podcast app just in case if a friend happened to loan you their device so that you could hear this show or if they pointed you to this website,

in which case they are a great friend and you should thank them. And be sure to leave us a review by heading to www.codingblocks.net slash review where you can find links for iTunes and Stitcher where you can leave us a review and like I said earlier

we will be forever grateful for you doing so yep and I think you did say that you can find your show notes but you can also find discussion examples more social links all that kind of stuff there on our site And I think you did say that you can find your show notes, but you can also find discussion examples, more social links, all that kind of stuff there on our site and all the new videos and content that mostly Joe's been putting out here recently. So definitely head up there.

And you should join our Slack by going to codingbox.net slash Slack. Or if you would like some stickers, you can send a self-addressed stamp envelope to codingbox.net slash swag sweet and follow us on twitter at codingbox yeah totally and facebook we have one of those