Coding Blocks - Clean Code – Comments Are Lies

Episode Date: November 7, 2016

This week, Michael fails geography, Allen introduces us to Croom, and Joe has to potty as we head into our third installment of the Clean Code series. Want to be part of our Slack community? Sign up @ http://www.codingblocks.net/slack and say “hi”! Join the Slack Link to Episode 49’s Full Show Notes http://www.codingblocks.net/episode49 Survey News […]

you're listening to coding blocks episode 49 subscribe to us and leave us a review on itunes stitcher and more using your favorite podcast app visit us at coding most of everything find show notes example discussion and other stuff. Send your feedback, questions, and rants to comments at CodingBlocks.net Follow us on Twitter at CodingBlocks or head to www.codingblocks.net www.codingblocks.net

and find all our social links there at the top of the page. What? What? What? And with that, welcome to CodingBlocks. I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. Alrighty, so as always is the tradition here, we like to start off with saying thanks to the people that took the time to leave us a review. And I really don't want to say some of these names. I think I will, though.

Some of them aren't so bad. I think I'm going to take iTunes. I'll let one of you guys take the Stitcher one. All right. Well, first, I want to know which of you guys beat Wizard of Oz in arm wrestling in order to get him to write a review. Oh, that was totally me. You just ask Will. Will is scared of me, man.

Oh, is that who that was? Yeah, I beat him in a race already. Just ask him. If you're on our Slack channel, just go over there and hit Will Madison and be like, yo, I heard Alan smoked you. And then that should do it right there. You know, I read that review

and I was like, wait a minute. Who is that? Mom? Oh, that's amazing. All right. All right. So, from iTunes, we have Clive Scott from Zimbabwe. From Zimbabwe. Yeah, I thought that was awesome.

Dave Lowe, 85. Ali Hamadi, Wizard of Oz, 8. I guess the first seven parts were not as good as the eighth. Matt P. Caswell. I feel like H0317 is supposed to mean something. Maybe if I were to translate those to letters. H-O, like hollow, I don't know. Gin RK.

Trix. Help me out here, Alan. Ideal? Okay. I'll take that. Well, now what? I like that one. Jamie WST and Aduli. Yes.

Yes. You want Stitcher or you want me to attack this one, Joe? Uh, I got it. Go ahead. We got Ajit, Decoded the Gir the giraffe and i didn't say go raff c stick oh my god wild true return null lavin dylan rib holly joe c and mantra polo love it guys thank you very much yeah they there were some really good ones all all of them were excellent and thank you i mean there were some really heartfelt ones. All of them were excellent, and thank you. I mean, there were some really heartfelt ones in there,

and they all put smiles on our faces. Yep. Yeah, we can't say it enough how much we really do appreciate you guys taking the time. And some of you guys have actually taken the time to do it on both Stitcher and iTunes, which is like a double extra thank you. So we super appreciate that. Yeah, I might have even somewhat twisted Andrew K.'s arm

into doing the other one because I helped him out with something. Well, you know what? Maybe I'll go ahead and interject this in here. I was going to bring it up later. But as our way of saying thank you back to you guys, hey, guess what? We mentioned last time that coding block stickers are a thing. So if you would like one, we'd love to give you one. So

if you send us a self-addressed stamped envelope, we'll send you a coding block or two sticker. Totally. Totally forgot to remember what our address was. Do you want to put it in the show notes or do you want to... How do you want to do that? I'm not sure. We'll figure that out. I think the show notes Or how do you want to do that I'm not sure we'll figure that out

I think the show notes is probably the best place We'll stick it up there Rather than randomly saying an address Here write this down dear listener Nobody's going to remember that But you know what related to that real quick I should mention that we will totally do favors For reviews

Or hey even better Do you want to just do you want to uh just ask them to email or dm us for the that's what i was gonna say like if you so regardless if you contact us either on twitter or in slack or let's just do that yeah just do that we'll send you the address to send it to and and we'll get them out yeah Yeah. So, yeah, because we'd love to have you to have a sticker. Yeah, and I wanted to also mention we got an email from somebody, and I appreciated the email because the guy's like, you know, I tried out your podcast, and it really didn't do it for me. Oh, right.

And it kind of hurts. I mean, honestly, as much as we really like to get the reviews that tell us, you know, how we're changing people or improving things or whatever, we also like to get the feedback. It kind of hurt. This guy, he wrote, and I'm not going to say who it was. You can't please them all. You can't.

That's really hard sometimes. Even when you see the thumbs down on the video or something like that, you might have a thousand thumbs up, but that one thumbs down is like a dagger in your side but we appreciate it i mean i think he was looking more for like a lecture type thing and that's not what we are yeah so you know again we do appreciate all feedback that comes in you know we're not gonna be able to make everybody happy it's impossible but you know thank you for taking the time to do that those that do so i feel like joe's had some more face time in front of a camera i i think he might be addicted to it or something now because it's becoming a

bit of a problem i can't have a normal conversation with joe without him recording his end of the conversation on camera and then posting it to youtube to be like, hey, look what I did. Yep. Hang on, man. This is gold. Hold that thought one second. Yeah, I did make some more Code Warriors videos, and then the next one coming up, I actually walked through a problem that I created and kind of showed a little behind-the-scenes look. Wait, you made the problem?

There was a problem that didn't exist, and you're like, you know what? This is now a problem. Yeah, this one was actually an intentional problem. So I did make a problem that didn't exist, and you're like, you know what? This is now a problem. Yeah, this one was actually an intentional problem. So I did make a problem, and I'm pretty happy with it. But I'll give you a little vaccine sewer. But I would love some feedback because the videos are long. They've been kind of long, so I'd love to hear if that's a problem

or if that's about right or I don't know if there's any other ideas. I'm still kind of experimenting, so let me know. Yeah, totally. Very cool. You can leave comments on the videos, too. We'll have links in the show notes for those. i don't see where you guys are finding the time yeah man it sometimes it's hard but like when you get excited about something you're just like all right i gotta do this now otherwise i'm never gonna get the thing is though is like i know what you guys like workload is like and that's the part that's killing me because i'm like well i don't

have time to do that i can't do that right now and And yet you guys are like, oh yeah, here's a, here's a video I did. And I'm like, what? It was 10 o'clock at night. That's all I can say, man. Yeah. Um, so yeah, I don't edit either. Oh, I do a little bit of editing, not a lot. So I also put together a video that was fortunately, Andrew K had a problem that he shared in Slack and it was awesome because he was like, look, man, I'm debugging this problem and I can't get it to work. And he was awesome because he was like, look, man, I'm debugging this problem and I can't get it to work. And he was pasting snippets of code and, and we weren't really getting very far because it's really hard to take just little portions of something and really make much out of it. And he was kind enough to just zip up the entire thing and send it and be like,

Hey, yeah, totally. Will you help me out? And I was like, cool. Could I record this? And he was like, yeah, go ahead. So I have a real live debugging, like debugging a real application that's basically creating your ultimate Overwatch team, which I think Joe Zack got a little bit excited about when he saw. Yeah. I didn't know it was Overwatch related.

I need to get back to it. I haven't played in a long time. Man, I never bought it. I need to. Oh my God, that game's awesome. It's so fun, man. Yeah, it's probably more fun than making videos it's like but yeah so that's up there we'll have all those links in the show notes and also

um if you just go to codingblocks.net and go to the top of the page there's a link to our youtube page so you can see all that new stuff oh and by the way we don't have it in our show notes joe actually took the time to upload all our episodes to YouTube. Oh, right. So now our entire back catalog is on YouTube. So if you don't have something you can list to and you just want to put it on the background while you're at work. Hey, you want to relive the past? There you go.

There you go. So that's excellent. And he even put the code that he used to do that up on our GitHub. Joe is trying to make my life more difficult by letting me track the statistics for the metrics here by having it on multiple sources. So thank you for the extra work, Jeff. Now I definitely have less time to record my own videos. We'll see. That script is pretty ugly.

But I was thinking about cleaning it up and maybe trying to get a few other podcast hosts to give it a shot and see if it works for them. Maybe some podcasts that we'll mention here in a few minutes. Yeah, totally. All right. So it was conference time since the last time we spoke. So we have here in the Atlanta area, we had two great conferences one week after the next, and they were both amazing. So first up was the Atlanta Code Camp.

Alan and I were both at that one, met some listeners there. That was awesome, as always. I got to stop saying uh, I guess. But where was I going with that? There were some great talks at that one. Oh, yeah. That's where I was going with. Okay, so listen to this.

So before he answers, so I'm going to give you a list of the sessions that I went to, okay? Docker for the win. A developer's guide. No, I'm sorry. A developer's introduction to Azure machine learning. Put the test before the code. Let's see. This will be the fourth one.

Building websites using ASP.NET Core, Docker, and Azure. And I think the last one was automate design patterns with PostSharp and aspect-oriented programming. So what did I list off? Five, those were the five sessions that I went to that day.

And they each, it might, this might be the most crowded one I've been to either, either. Here's the, here's the thing. I either lucked up and went to the popular sessions for each block for the entire day, or there were just more people here this year than in previous years because a lot of these were like beyond standing room only to to see the session yeah i didn't go to all the same ones i don't have a list of them but i noticed the same thing every room was packed the only one that wasn't packed and it's a shame was microsoft was putting on a particular room where they had iot iot devices and they would go over different ones during

different blocks but literally they had like six or seven tables set up with basically a raspberry pi starter kit for iot type stuff well specifically there's a windows 10 i IoT starter kit that uses the Raspberry Pi with a stripped down Windows 10 on it. And it's amazing because I think the kit's like 115 bucks. Yep. But they showed a lot of really cool stuff in there. So that was the only one I went to during the day that wasn't crowded,

but that was more like a lab type thing. And so people were kind of really more interested in the talks, I think. Yeah. Well, there were some great talks. There were a lot of talks. Okay, so I listed the five that I went to, right? Because there's only one of me

and I haven't figured out how to make more of me yet, you know, as clones. But at least not where we could share, you know, the same brain. There were other ones, though, like on HoloLens, for example, that I didn't even get to. There were topics that I was like, man, these, this sounds really interesting.

Would love to know more about, but you know, these other topics, I just felt like I could put to work sooner. And, uh, you know, they were, they were really interesting to me. So, so on our favorite though, I think we're both agree on what our absolute favorite was. And you'll probably get into that here in a second um but the one that i really enjoyed and i got a decent amount out of and it actually made me want to go play with it more was docker for the win like there were there were some really cool things that i found in there and if you haven't messed with docker and you don't know why you should mess with docker then uh you know maybe you should just go up to docker whatever it is

dot com and and start looking at it or whatever it is dot com yeah i mean i've definitely got the link right there in my head so um but i mean it's really really cool stuff and it's a shame that it doesn't work on windows in terms of how... Wait, but it does. And it is docker.com. It's getting there. It's getting there. It doesn't. So only for a 2016 Windows server... Oh, sorry.

...does it exist. There is specific requirements. And it has to be Hyper-V and all kinds of stuff. So, I mean, I wish, though, I wish that you could run the Linux-y type stuff on Windows. It'd be amazing because then you could just port everything everywhere. But in any which way, it was really cool. But our favorite of the day was... But that's what the previous versions

of Docker were, though, on Windows. There was the... Shoot. Hold on. Let me find it. The Docker Toolbox, and then the Docker for Windows, and then the Docker Engine for Windows. And if I recall, Docker Toolbox is the... We're going historically, right? So Docker Toolbox is the oldest, then Docker for Windows, and then the Docker Engine for Windows. And if I recall, Docker Toolbox is the,

you know, we're going historically, right? So Docker Toolbox is the oldest, then Docker for Windows. And then the new thing is Docker Engine for Windows. That's the one that you're talking about that would allow you to run Windows instance, Docker instances on a Windows machine. The previous two though,

if I'm correct, if I recall were linux on it if i remember right no that can't be right no i think it was a vm with linux on it oh yeah yeah yeah you had to have because because it reused um uh virtual box it has to use you had to use virtual box in order to have a linux vm right yeah yeah i, I wish there was a native way to cross it. And I mean, it sounds like it's getting there now, and especially with the Windows subsystem for Linux, maybe it'll be a possibility. They say they don't support it yet.

Yeah, not yet. But my guess is it's going to get popular enough to where it will happen. Have you tried it yet? Have you tried Windows subsystem for Linux? I haven't installed that version of it yet. Joe, wait. You don't have 1607 yet? Have you tried Windows Subsystem for Linux? I haven't installed that version of it yet. Joe, wait. You don't have 1607 yet? You should have it by now.

Not on a computer I use. You have it on a computer you don't use? Well, no. So, like, my wife's computer has the latest version and all that, but I don't know that I'd do it on this one. So, yeah, I don't know. I haven't been able to do it, but, man, that'll open up such a crazy world. What about you, Joe?

Have you tried it? My computer came with PowerShell, so no. I'm set. No, my work computer is not Windows 10, and most of the time I'm not working. I'm using my MacBook. Right. Although that may be going away with the escape key. Well, I guess where I was going with this, though, was that I've been playing around with it, and I want to use it more.

But I have found some frustrating things, not with the Windows subsystem itself, but with other tools sometimes giving me problems. And it's hard to track down because it's like these are tools that might work on a real Linux. And then I try to bring them onto Windows subsystem for Linux and they start giving me a problem. So, you know, I haven't found the root cause yet but, you know, because like I said, I want to use it for a lot more than I am. Cool. But what was our favorite

of the day? Okay. I think there's a consensus here. So, here's how this, and I'm going to totally butcher this name, even though I practiced it and you guys heard me try to practice this name i even listened to how someone else said this name just to make sure that i could try to say this name correctly and i'm still going to butcher it but here goes so what happens is we're going into the last um session of the day okay now we've talked about aspect oriented programming before i'm a fan i like it

it's cool right i don't know if you've ever done it but if you haven't you should totally try it and so the way the the way the session card worked out was like you didn't really see who the speakers were you just saw titles and descriptions and whatnot so i'm like so i saw this one on aspect oriented programming and it was specific to PostSharp and I thought, oh, that's cool. Maybe I'll pick up some new stuff with it, right? Pick up a new thing here or there that I didn't already realize about it. So this is the one I'm going to go to. And I don't know if it was coincidence that Alan was already going to go to that one or if maybe he heard me say that out loud and was like, oh yeah, you're probably right.

I don't know. I don't remember. um at any rate we ended up being there at the same time and coincidentally alan or not coincidentally but alan got there before i did and so i walk in and i sit down next to him and i'm kind of like you know looking up at the thing i'm like holy wait a minute do you realize who's giving this presentation alan this is the guy who created post sharp so here goes me butchering his name gail fratour fratour fratour fratour i you know what i i can't i can't i'm sorry i try it's kryptonite every time. But at any rate, so Gale was the one giving the presentation, and it was an amazing presentation. It was already on a topic that I really liked, but I was super stoked to see him giving the talk.

Yeah, the only problem with the presentation, the dude was super sharp. Post-sharp. Yeah, post-sharp. You know what I really liked? By the way, this is just some meta for anybody out there. If you ever go look at their logo, their logo looks like a skewed hashtag almost. Or sharp. It came out of the whole idea of cross-cutting concerns.

Right. And so that's why the logo looks like it does. When he went over that, I was like, that's really cool. I love that logo idea. But he was an excellent speaker, but the only problem was he knows his stuff. And he went super deep. And I'd venture to say two-thirds of the people in that room were like, I have no idea what I just heard.

So I'm with you there. There were a lot of people in that room that didn't know about PostSharp, didn't know about aspect-oriented programming. So as a result, they were asking some really basic questions. But for those of us that already had some of that knowledge under our belt, we're listening to this and we're like, oh, this is amazing. So here's the cool thing about this this talk and i had never ever considered using aspect oriented

programming to solve this problem we've talked in the past about the value of aspect oriented programming and uh i should just call it aop um and using it as a way to, like Alan said, get rid of your boilerplate cross-cutting concerns, right? So for those that aren't familiar with it, let's say you have some method that you write and maybe you do null checking a lot, right? And so rather than having that null checking as part of the method, instead you write

an aspect and you decorate the method to say like, hey, check for nulls. And that way you only have this null checking logic in one place. Or if you do any kind of logging logic, for example, instead of having your method with all the logging baked into it,, you have a logging aspect and all of your logging is done in that one place. Or another example might be maybe you want to have exception handling done in your method, but instead of doing it there, you do it in an aspect. And that way your method, the idea is that you leave your method to only contain the business logic that you're trying to solve and all of that boilerplate stuff, null checking, logging, exception handling, whatever, you know, retries or things like that. Let that be often some other method in an aspect whose one

job is to do that one thing like logging, for example, right? Well, this whole talk that Gail gave was on the idea of you could use aspects to do much more than just cut out the boilerplate. You could use aspects to enforce design patterns so that if you see that something isn't being done, then you could either wrap it into the correct design pattern, if you want, as an example. It was one of the things that he presented. Or you could throw compilation errors or warnings describing like, hey, you're not adhering to the standard. And so he gave this one example using the weak event pattern, which wasn't a pattern that I was familiar with, so I had to go read up on that. Super complex.

And he gave an example using the weak event pattern where you could, at compile time, determine whether or not someone else's code, if it wasn't adhering to the weak event pattern, that you could throw a compile time error so that the developer would know right then and there, oh yeah, sorry, I need to go and do this. And that was a concept that I hadn't considered. Yeah, it was pretty amazing. I think it went beyond just errors, right? Like it would even convert kind of at the compiler. It doesn't change your code, but the compiled code itself would have flipped that into a pattern that wouldn't have caused the memory leaks. And that was the part that was like, holy smoke. Yeah, like I said, you could either enforce the pattern to modify it, or you could just throw the compilation error to let the developer know that, hey, you need to implement this pattern.

So either you do it for them or you tell them that they should do it. So the idea was that, you know, you have your senior level developers, let them focus on writing aspects and enforcing these like more global concepts within your environment. And it was something that I never really thought about using using aspects for and so it was a really awesome talk and it really opened my mind up to a whole new idea of like how i could use aspects in my code yep so i really like that um yeah and and gail's from oh sorry oh sorry no go ahead what'd you say uh it's kind of odd right i was saying uh gail's from prague so it's pretty exciting you guys got to see him. Yeah.

Czech Republic, I believe, was what he said. Well, he lives in Prague. Okay. I don't remember. I'm pretty sure it was... Yeah, whatever. Is Prague in the Czech? Man, I'm sorry.

I'm American, but... No, he's in Czech Republic. They may be the same same place i don't know probably the capital of check there you go this is where prague 2016 best of prague oh my god public tourism trip advisor see this is this is america america america america so i'm not so not only do we not know stuff like that but but we're actually, we like get high fives for not knowing stuff. Yeah. Which is, I guess, going to be a nice segue into, hey, guess what the next conference was, was Connect Tech.

And so, you know, the previous week I have this great opportunity where I get to meet Gail, which, by the way, you know, we talked with him afterwards. He was super, super nice, super approachable guy. And as if that wasn't cool enough, then I meet Matt Groves at Connect Tech, who was giving a talk there called I Have a NoSQL Toaster. And sequel toaster and um for those not familiar matt groves is the author of aop in dot net which is a book we have referenced before so i really felt like back-to-back aop guys at conferences like my code is trying to tell me something so but that was super cool uh getting to meet both of those guys and then here was another cool thing that happened at Connect Tech. So sitting there, one of the sessions, one of our listeners comes up, James Majors. He was giving a talk at Connect Tech on functional programming in Swift.

So I got to see that session as well, and it was really awesome. One of my favorite quotes or concepts that he had said was, he was talking about the concept that as software developers, we tend to be very cyclic in that whatever the current thing is, that everything needs to be that way. Right. And so he said, you know, let's, let's take it into a different context. Let's say that you were a carpenter. Then the tools of your trade would be a hammer, a screwdriver and a saw.

And if you were a carpenter, you would never ever tell other other carpenters, hey, guys, you know what, man, saws are the thing. They are awesome. You know what, I'm not going to use hammers and screwdrivers anymore. It's saws from here on out, right? As a carpenter, you would not do that. But yet, as software developers, we get into these patterns where we'll say, oh, you know what, functional, all the things. Everything should be functional. That's all I'm going to write from now on. Or, you know what?

No, I don't like functional anymore. I'm going back to regular, normal, object-oriented programming, and we're going to go from there. Oh, man, that didn't work out too well. Too many inheritance problems. I'm going to just composition, composition all the way. And the point that he was making

is that sometimes we got to stop that. We can't say it's going to be all or nothing in one thing, right? And it was kind of to a, I guess a saying, I think this is a thing, I've definitely heard you say it recently, where if you have a hammer, think this is a thing um i've definitely heard you say it recently where

if you have a hammer everything looks like a nail yeah right and it's kind of you know that's kind of the same point that he was making is that you know people that some people get into functional programming as an example and they want to do it for everything and then that's not necessarily uh the right thing like in an example that he gave was like, okay, you could, you could get away. You could actually do some functional programming, UI programming. It would be horrible. Right. No state, recreate everything.

Yeah. It's not going to work. Like, like, well, because, because one of the whole tenants about functional programming though, right, is you're not modifying any, you're not mutating any external state, right? You're just giving, you're giving some inputs and you give an output, right? But in order to draw stuff on the screen, you're definitely mutating something, right? Yep. So that's kind of the point, you know.

But it was a really good talk, though. That's awesome. Yeah, I wish that I could have made Connect Tech. That was another two days. I had too much going on, but that would have been an awesome one to go to. So what do we got next? Oh, and then on episode 47,

there was that whole conversation that we got lost into, mostly because I'm going to blame this on Joe for him not being there to stop us, but there was that uh topic that i had brought up about you know ios and android and how they're all kind of the same and like you know everything that you could do on android you could do on ios so who cares right and um except press an escape key and now um but but i think that uh lynn Len McCray actually reworded what I was trying to say so much better than what I actually ended up saying. And he said that, you know, because I think the way I said it was that iOS was a better Android than Android is or something like that.

And he was saying that, well, maybe a better phrasing might be that the Google ecosystem is best on an iPhone. Because, you know, my discussion was focusing on the apps and Android alone offers more than just apps, which is a fair point. And I think his rewording of my point is a lot better than the way i said it although one of our friends just shared with us a link today on the news you owe me me mix oh yeah i saw this phone oh yeah oh man that was drool worthy that thing that is gorgeous it actually made me rethink this whole that whole topic because then I was thinking like, okay, fine. The ecosystem on iOS I like better. And I feel like the security is better on iOS.

The bug bounties are higher on iOS because the difficulty is so much higher. So that makes me feel like it's more secure. Now, whether that's a false sense of security, we'll never know, because the NSA will never tell. But from the hardware point of view that you're bringing up, the hardware options are so, there's so many more out there. And it's not that they're better necessarily. It's just that because there's more than one vendor iterating on ideas,

then you get a lot more spaghetti thrown against the wall to see what's going to stick. LG failed with their most recent one where it was pluggable components and stuff. It didn't really take off. There's ideas, right? I think there was a more noticeable recent fail than LG, but sure.

We won't mention blowing up phones. That was pretty cool stuff. Um, and we'll put that in the show notes. That's just for fun. Um, what else we got? Oh,

so, so we mentioned our Slack channel all the time and you should totally join. You took, you should. And where can you do that? Does anybody know? Codingblocks.net slash Slack. Totally.

And there is a channel in there that I know I'm definitely in it. I think you found out about it the last episode that I made this. Oh, yeah. And Joe, I know you're in there all the time. And it's one of those things where we're just kind of trying to pump people up to do things on their own, right? Like we've done the Coding Blocks thing. And I think we're going to make this a regular part of our show now, just bring up people that are doing some really cool stuff. And most recently, Zach Braddy, he has got the reactionary.net. Wouldn't it be Brady?

Braddy, B-R-A-D-D-Y, yep. And he does a lot of React things. And I've read a couple of his articles, and I really like his writing style. It's entertaining and informative. And Joe, you want to share a couple of his articles and I really like his writing style it's entertaining and informative um and Joe you want to share a couple of them yeah um James Studdart uh he's got cynicaldeveloper.com we mentioned his uh interview with Hello Tech Pros a while back um and now he's got his own podcast so we went out and bought a mic and did it and I'm really looking forward to hearing more of those I've got a little preview before it was released and so I'm looking forward to that and thanks to James oh sorry go a little preview before it was released, and so I'm looking forward to that. And thanks to James. Oh, sorry.

Go ahead. No, all good. Although I did want to mention before I forget the hashtag I made this. I didn't actually make the channel. I don't know who did, but I don't go there to inspire people. I go there to get inspired. So a little bit backwards there, but it's been really

good. Well, I wanted to say thanks to James. We now all know about Tiggers and Eeyores due to his Hello Tech podcast interview. So that's now a thing that we can all be aware of. Yep. And I must say that dude really knows his onions. That's awesome. Go ahead.

Go ahead. Well, we got Paul Seal also, and he's come in there, and the one that he hooked me on was the one about if you open up Chrome, if you open up Chrome, if there's no connection and you open up Chrome. I don't know why that's so funny. Man, I don't know. But if you're in offline mode and you open up Chrome and you hit, like, the arrow key, then you can play a game. And I watched his little video on that.

But he also happens to have more useful stuff that's, like, code related. And his is codeshare.co.uk. So apparently, like, every one of these guys, I think uh is paul or not is uh zach in the uk too uh he's in one of those countries yeah all three of those guys are um in that the other well we know how well we are at geography so i think let's see which part is in there somebody's in the uk somebody's in wales i think that's all close to Italy, right? I think Wales might be in Sicily, which is not in Italy. Something like that.

You can see where we're coming from. That's in Egypt, right? Well, what I'm getting at is all those folks across the pond there seem to be a little bit more motivated. So we need to get some folks in here and doing some I Made This. I feel like they probably know the geography

better than we do. Probably. So what else we got? Oh, we got some really cool news. Want to talk about the giveaway? Yeah, let's do that. So as you know, we are doing our Clean Code series, and so tonight will be the third part of that series.

And first two parts, we were having a drawing. So as we said last episode, tonight we will be announcing the winners from episode 47. And episode 48, you'll be announced next episode. And the idea is you go to the show notes, leave us a comment, and enter for your chance to win. So for episode 47, the winners are, drumroll please. You know what? I'm sorry I asked. I'm sorry. You just blew some speakers out and some cards. Binary Nexus wanted a joke, and he just got it.

That was hilarious. Nice. I am sorry. That wasn't really the joke I was going to give later, but it's actually not a bad one. Mike,

you're a winner. That's going to be fun. Congratulations. You already have the book. We're going to have to track him down. All of these, we're going to reach out to you via your Discuss credentials. So unfortunately, these weren't like the most identifiable names necessarily, but Mike was one of the winners, Hussein and Mr. SC.

Yep. So congratulations. Each one of you guys will Hussein and Mr. SC. Yep. So congratulations. Each one of you guys will get a copy of Clean Code. And when we reach out to you, we'll ask whether you want Kindle or paperback. And that's pretty much it. So, again, in the next one, we'll do another giveaway. There was something about a poem, though. Oh, yeah, totally.

So I wanted to call this out. I'm actually sad. I wish i could have like you know bent the rules and given this guy one so matthew watkins man he wrote us a poem up on there and it was absolutely fantastic it harkened back to the days of our initial giveaway i don't even remember what episode that was oh it wasn't in part of 47 then uh well no so it So it is. It is in episode 47. Let me see. Codingblocks.net. So prepared. So incredibly prepared. I like that Mr. SC, who was

one of the winners, in his comment he said, hello from Wales, UK. Delivery all the way here is going to cost quite a bit. Is it too late to undo that? Yeah, is it too late? Sorry. We're going to take a quick break here to redo the winners. Yeah.

All right. Well, while Alan is trying to find this poem that I would love to hear, I probably already read it. I just don't remember it. But I just want to go over the giveaway rules for this episode. So you will go to www.codingblocks.net slash episode 49. And at the bottom of the page there, you will see our comment section. You can leave us a comment and that will enter you in for the drawing. And this episode is going to be a little bit different than the previous episodes.

And here's why. Because remember when I mentioned Gale, whose last name I can't pronounce? Well, he happened to hook me up with some Post Sharp Ultimate licenses. So here's what we're going to do. We're going to spread those out across some of the episodes. But how many things are we giving away in this episode 49? One? Just one. Just one? Okay. So there's going to be one lucky winner for episode 49. I think that was the way it was for 48 too. One lucky winner for 48, one lucky winner for episode 49. But when you enter for 49, and if you should be the lucky winner we will contact you and ask you if you want your choice of a copy of clean code or a copy of or a license for post sharp ultimate

and it's your choice uh which one you want i believe post sharp ultimate it's a uh perpetual license but it comes with a year of support so any um if i recall any upgrades you know or fixes or whatnot that come out throughout that year then uh you get those as well and so i feel like that's really double clean code because post sharp can clean your code so you either get a copy of clean code or you get something that cleans your code. Yep. All right. And I did find, oh, and by the way, just for you guys that want to know, PostSharp Ultimate, if you want to take a stab at it, it's $669 per developer.

This is not a little tiny piece of software that you may never use. If you actually get it, it could be useful if you write some C-sharp code, and Visual Studio is your IDE of choice. So it is a pretty incredible value, and a huge thanks to Gail for providing those. I kind of feel like, when we read this poem, maybe each one of us should read a paragraph of it. We can do that. Or, I guess, more specifically, a verse.

All right. Well, that assumes that Joe has found it paragraph of it. We can do that. Or I guess more specifically a verse. Well that assumes that Joe has found it or sees it. I have not. I need the link. It's all in episode 47 and then just go down and you'll have to hit load more. That's ridiculous. Let's just

go back and forth because you and I are already there. No, I'm in this, man. Oh, you got it? All right, so. You already found it? You need to find it? All right, I will. I'm going to kick it off right here.

I'll go second. All right. There once was some code in great need. It was messy and so hard to read. To see such spaghetti would make you get sweaty so bad it made FX cop bleed. But Alan, Michael, and Joe announced last week on their show, you don't have to ditch it, you just have to fix it and start building afresh with clean code.

So I said to myself, that is that. This book must be where it's at. I'll submit to their site, and maybe they might just pull my name from their hat. Dude, that is absolutely fantastic. Somebody grew up on a whole lot of Dr. Seuss. I'm just saying. Can we just send them a book? I'm thinking about it.

I think that Alan should totally just come out of pocket here and drop a little bit of money here to send this guy a book. Because you took the time to do this, you get one too, man. That's it. That made my day when I read that. Anybody who can convince us to break out into verse on air, I feel like that's worthy. Yeah, that was killer.

So four copies given away this time. We can bend the rules. They're our own. So my kids do it all the time. So congratulations, guys. We hope that you find this book as interesting and useful in your life as Joe certainly has. Yes. All right.

So, with that, now it's time to get into the show. I mean, I know we're running a little bit long. There was a lot of news this time, but, you know. I'm done, man. You guys kidding me? All right. That's the end. Cue exit music.

No. So, in this one, as we've done in the previous, we're just going to do one chapter because apparently we're not slow or we're not fast at any one given thing. So in this one, we're going to talk about comments in clean code, which is chapter four? Yes. Yes, chapter four.

Yes. All right. Oh, I'm stuck. Joe, kick us off, man. All right. So I like how he starts off with a quote here talking about, at best, comments are a necessary evil. And I couldn't agree more.

They're often wrong. They never get updated, which contributes to them often being wrong. A lot of times they're just bad. And so I don't really trust them anyway. A lot of times it's just old code that I just get confused about. It's weird. You ever do one of those things where you're searching and replacing for some code and fixing stuff up, and you find commented out code, but you don't want to change it because you're not testing it, right?

So you don't want the next person to come along and uncomment it. But you also don't want to not change it because that's what you're doing right now. So the only solution is just snip it out, right? Well, yeah. I mean, there was actually a great quote in here that I wanted to say that starts it off where it was that nothing can clutter up a module more frivolous than dogmatic comments and nothing can be quite so damaging as an old, crufty comment that propagates lies and misinformation. Yeah, totally.

And you know what's funny you know who sort of sort of convinced me of this whole thing was my boy that i beat in the race will oh my god um you won't let him down will you how many years ago was that you think you could pull it off the second time absolutely oh my god oh so we had a conversation about some code one time because there was a method that i'll never forget that was there. And it was so complicated. And it was one of those things where I just had to learn what this thing was doing, right? And I had spent, you know, I don't know how many hours just trying to really internalize what it was doing.

And you didn't refactor it, did you? I didn't refactor it because I was scared to death of it, to be be honest with you because the code was so intertwined and nested with everything else we should have a conversation on tdd oh man yeah that would probably change things so it was one of those things where i was like you know what i'm going to put the notes at the top so that i can save somebody else two or three hours of their life right and he's like no totally we should never do that and i was like what like you're crazy and he's like no dude if it doesn't identify what it does by being able to read that method then you shouldn't put comments on it and i was like i i disagree i can't rewrite this code like not not and feel good about it right like i i would have been nervous you were scared i was scared yep and

i didn't i didn't want to do it. This is one of those few times where we can get Alan to actually admit he was scared about something. So we can't live this down, Joe. Alan was scared. I didn't want to do it. And he actually convinced me. He's like, look, dude, unless it's a public API, you really shouldn't be commenting those methods. Now, OK, we'll come back to the public API because I actually take issue with that. But I will say this, though,

and this is kind of going along the same lines of where he was thinking with this, which is a quote from the book. One of my favorites is that comments are always failures. Yeah, it's to compensate for our failure to express ourself in code. And that is true. I mean, it really is. If you name your method properly

and if your method reads well, you don't need to comment it. Like, that's it. It's simple, but what do you do with legacy code? You write some unit tests to verify that it works, and then you go with the factory. Yeah, right. Good luck writing unit tests with post-legacy code.

I mean, you brought it... I'm not saying they have some dependencies baked in there that make it a little difficult well you brought it up on the last episode Joe remember you were talking about the fact that you went to try and break something apart and because there were so many parameters and so many things that were nested like well I mean the three of us have worked have absolutely worked in frameworks in the past where well I say frameworks but I mean I mean like large code bases where it was dated patterns that were followed at the time that had dependencies so intertwined and baked in that to write a unit test for it was impossible. They were all integration tests.

Every one of them. You couldn't. Yeah. I mean, like new code that we were able to introduce, sure, we could write some unit tests for that, and they could be beautiful, and, you know, like angels would sing every time you'd open them. You know, they were beautiful. You know, little rays of sunshine would shine down on you

any time you even ran them. But the old code, yeah, no way. You stayed away from it. And that's the sad part. Yeah, I mean, one of the things I like that they said is comments should be updated as code is updated. But the better use of time would be to make the code better itself. So you don't even need the comments, right? Yeah, I'd say just delete the code.

I mean, the comment. Because the code changes and evolves. And the comments will get separated away from the code that it can often get separated away from the code they describe. So I'm not talking about you have some function, you know, some summary documentation at the top of your function to describe what the function does. I'm saying that, for example, in the body of the function, you have some kind of comment describing what's going to happen. Then it's quite possible that that comment can get, as someone else refactors or adds functionality. Now suddenly that comment isn't next to the block of code it's trying to describe. And then as that block of code evolves over time,

that comment might not even be relevant anymore. And so now it's just, it goes back to the previous quote from the beginning. It's misinformation. It's a lie. I hate comments and code which i like hey going back to uh as our as our friends on the other side of the pond would call it university um i mean i remember that being a big thing that that um professors would would comment on like not to use the word comment uh as pun tell you to comment your code right yeah i mean they they were actually i remember you know that being a thing that they wanted to see comments

in your code so they could see what you're trying to do and whatnot and you know here's uh here's a very well-known very well-respected book by some extremely well-respected authors that are saying like yeah no man don't don't even bother don't waste your time you're crap yeah i had a professor that would actually say um you know basically write the stuff out in like comments first like what you want to do the steps and then go in fill the code and leave the comments and then you're done you've already written the comments great right yeah that feels like the old way that you would write like a paper for you know your your lit class or something your intro your summary and your body type right go ahead and write your outline first and then that way you know once you write the

outline then you know what you're trying to write but yeah i mean we touched on a second ago the worst part is like he said so it might be bad that comments become irrelevant as the code changes but the worst is when it's not irrelevant it's misleading. So that comment that stayed there, instead of it actually providing something or really just being wasted space, it makes people think that something else is happening because you read that comment, and the code changed with that comment,

and now the people assume something that is incorrect. And that is probably the worst problem that can come about with that. Yeah, the book makes a point to say that the older the comment is, the more likely it will just be plain wrong. So if you have a comment that's in there for years... Yep.

Have you ever seen something where the comment's like... There's a comment on the function. The function's like 300 lines long, right? And so you make some little change in it, and then later someone says, hey, didn't you read the comment? It says you need to add you make some little change in it and then like later someone says hey didn't you read the comment it says you need to add it in

five more places you're like no I was down here on line number 200 horrible pattern already yeah you have a documentation or a comment in

your in your code saying hey if you add something here you got to add it other places but this is kind of to Alan's point though inaccurate comments are far worse than

no comment at all. Right. So that misinformation puts the developer in the wrong frame of mind. And it's worse than if they didn't have a comment at all and they were forced to read and interpret the code. Hey, I do have a question for you, Joe, though. So you just brought up a very, a very valid thing so first we know it's a bad pattern if you got to change something in one place you have to change it in five right because that just speaks of copy and paste and a nightmare what what do you do so if if you see that and they say hey you missed that comment what what tell me what what's the path there boy scout rule um and it's that's one of the things tough. I mean, if you can extract that out to a common class

that's used in multiple spots, then that's kind of, you know, one good first step. But a lot of times you can't. The reason that thing is copy pasted five times is because, you know, there's already some other problem that's kind of deeper going on. And so it's probably not an easy refactor. So you just got to do whatever little things you can

until, you know, until one day there's hope. So what's the alternative, though? So let's say that you refactor and you do what you can up to that point. Is a comment not good enough to say, hey, go check these files? Is it the wrong thing to do? No, because here's the thing. And this kind of goes back to your previous uh story that you were talking about with you and and i think it was will yeah where you know that because because

in your mindset you're saying like okay we know that this is a mess right i know that this is a mess and so because this is a mess i'm i my mindset is i should comment that so that others know. But instead, what you should really be saying to yourself is, oh, this is a meth, a mess, a meth. It could be. It could be. Kroom and meth. It could be. Yeah.

But instead, you should be saying to yourself, okay, I see that this is a mess. I should clean it up, right, and just take the hit. That's always one of those tough ones, too, because you've always got to balance what the customer needs or what your boss is saying time-wise that you've got to do something, right? And so the cleanup, literally, like if it took you two or three hours to figure out what was happening in a method,

which should not ever happen but does a lot, if it takes you that long to figure it out, how much more time can you spend doing that if you really were only trying to find a bug in the system right and so and so now a ticket that was supposed to be you know uh maybe a two-hour turnaround now you're talking about it could take a day or two after you start testing and making sure everything's fitting like it's it is one of those very difficult decisions, and you as a programmer need to know how to balance properly, and that's a really hard one.

Sometimes you just need to, at least from my own experience, when I've hit situations like this, and I know that because of deadlines, I can't do something about it right now. But what I can do right now is I can create a ticket so that myself or someone else can be assigned to come back to it. Yeah, that's a good point. And that way, you know, managers and whatnot, they can see, hey, here's some technical debt that needs to be, we already own it. We need to manage it, right? You got you gotta pay it off but do you comment

the code at that point because here's the thing if you walk away from it there's two things that are going to happen and i'm curious what you guys think about this right i don't comment it i'll go ahead and tell you well so here's here's the way i look at it if you so let's say you create the ticket i agree that's the right thing to do because that's saying we know there's a problem we need to address it but the problem is you go off and you work on some other stuff and a month later you come back you've got to relearn everything that you learned that last time right you're going to have to do that anyways and here's and here this is the reason why i say i don't comment it is and and this is another quote from the book is that programmers cannot realistically

maintain the comments okay so if i add a comment there and I don't come back to that piece of code for a month or two months or however long it is, how do I know that other changes haven't been introduced that totally undo whatever my comment was? My comment to myself could be totally irrelevant or wrong or misinformation or whatever. It could be a complete lie by the time I get back to it. So what's the point?

Well, sometimes you want to use misinformation to your advantage. Like a lot of times if I see some messy code, I'm not able to deal with it at the time, what I'll do is I'll put a to-do in there and I'll say, clean this crap up, period. And in parentheses, I'll say, by the way, don't bother looking this up in source control. It was written by Outlaw.

Yeah, and that's when I'll see a comment about like, oh, yeah, I cleaned up Outlaw stuff, and then I'm going to be like, wait, what? Yep, and hopefully Outlaw will come across it first and actually fix it because he's embarrassed about the thing he didn't do. So you just make sure you include people on the pull request is what you're saying.

Yep. Interesting. Tough crowd. people on the pull request is what you're saying yep uh interesting tough crowd um so yeah i mean i guess i get it i i'm i'm on the fence on whether whether it should be commented or not and i do agree that sometimes you have to come back you have to relearn it anyways because you don't know what changed but um yeah one of the other quotes in here that i really liked was the only good comment is the one you found a way not to write. Man, that sums it up. That's so valid. If you figure out and you think about how can I write this method name,

how can I write this class name, how can I write the body of the method in a way that people can just look at and understand. Well, it goes to the whole point of this chapter in this book is to be able to explain yourself in code. So if you can explain yourself in code and you don't need to write that comment, then it's easier for everyone to understand and maintain that code long term. Yep. Sometimes the comments that I write are for um like for reasons behind

things like i'll be doing a code wars problem or something and rather than doing like 4i equals 0 i'll do something weird like 4i equals 2 because there's some items in the list that i know i don't care about and so in that case you know i i guess the right answer would be to create a variable called you know array starting point and then for i equals array starting point or something like that or values that i care about starting index and some so some better way of saying um what i would say in common which is starting here because of this yeah that's interesting i like that take on it and you could even name your variables in a way that they're obvious right like you know skip x number of and then that's your starting point for

your loop you know that's that's interesting i did i did like one of the things that they say can either one of you tell me when there is a good time to have a comment yeah no yeah uh copyright and licensing no you're wrong oh man back in the day you used to see file after file and have the license at the top. Even sometimes you have the names of people who made the change and what they changed. Hey, Bob was here. I feel like this is no longer even the way it's done anymore.

Now the license is in a separate file that's just in the code base. And that's the better way. So don't have the license buried, the license header buried in every file. Because that was so like, we've all seen code where you had like skipped the first 25 lines because you know it's the apache license declaration you're like okay yeah i get it apache's really wants you to know about it well you guys

remember the subversion days where it would throw the last modify by comments at the top of the file and like that's right it would do it for you yeah yeah totally hate that and i think you know what though i honestly think that was a sign of the times where the tools weren't as good right like now you can go into like if you're using github for instance you can go in there and easily look at the history of everything right and so maybe maybe it was just a sign of the times. I don't know. Yeah. Most comments are going to be bad comments that are crutches or excuses for poor code or

justifications for insufficient decisions. Oh yeah, I do that one. I thought that one was a pretty good comment. I'm a justifier. You know where I do use comments? Can I answer for you? Sure.

I was going to say the mumbling. Yeah, because one of the topics was on mumbling, having comments that are plopping in a comment just because you feel that you should or because the process requires it or because it's a hack. And I've definitely ran across a couple times where I'm like, oh, Alan wrote that.

I don't know why this is here. Yeah, I definitely have some of those in there. And I usually do it for comic relief half the time. They're probably not useful at all. But no, where I actually do use comments is, and I'll go to SQL. When I write a stored proc, typically what I'll do at the top of it,

the comment isn't about the proc per se, but I'll have in comments like usage examples. So if you want to test the proc, you can just highlight this text right here and run it. Assuming that the proc doesn't change or the variables passed in don't change. If it does change, then it can break it. But the thing is, a lot of times you need to be able to have a use case that you can go up and test easily. And it's not like you have unit tests for SQL Server.

Or if there are, I'm not aware of it. Well, going back to Joe's point, though, with his for loop example of for i equals 2 where he wants to skip something, the book refers to that type of comment as an amplification comment. So they say a comment may be used to amplify the importance of something that may otherwise seem inconsequential. Okay, yeah. Oh, I actually did that today on a couple spots. There was a place where I was copying and pasting,

but it was a case where I was kind of doing... I wasn't copying and pasting code from one method to another. He tried to say it under his breath like we wouldn't catch it. No, it was a case where I was kind of doing... I wasn't copying and pasting code from one method to another. He tried to say it under his breath like we wouldn't catch it. No, it was actually SQL. Oh, that makes it better then. Yeah, there's no modularity in SQL. Give me a break. But it's very little and it's very poor.

But what I'm doing is basically doing a big case statement, right? And because there's no freaking dynamic sorting in the SQL server or any other SQL that I'm aware of for no good reason that I'm aware of. I was, you know, copying and pasting like 10, 15 lines and you kind of paste the column names in because you have to, there's no other way except for dynamic SQL, which I will shoot you if you, you know, do too much of that. You have to justify if I see dynamic SQL, there better be a comment up there telling me why you're doing it. But anyway, the point is, so I did some stuff and it was copy-paste, copy-paste, copy-paste.

Oh, but two of these were different for whatever reason. And so I put some comments off to the side saying, this is not a typo. This is intentional. Yeah, that makes sense. If somebody sees a pattern and all of a sudden there's a wrench in that pattern, that makes sense. But, again, if somebody goes in and updates that code later, then those might, you know, who knows what could happen. It's a frustrating thing, really. I don't actually see it in our show notes here. But so the API thing, before we kind of get towards the end of this public apis i actually feel like there should be oh that was coming up there should be some level of commenting on them if nothing else for tools like js doc

or not js doc java docs and that kind of stuff to where like even we work in the ext js framework for better or for worse but they auto auto-generate their documentation based off the comments and the code, which is an interesting way to create full-blown documentation for an API. Assuming it's valuable comments that aren't lying. Yeah, but I mean that's really important. The JavaScript, there's the slice and the splice, and the articles are, the arguments are almost the same for these guys. They operate

on arrays. And the only way you know what one does versus the other is basically because of comments. One says returns a copy of the array. The other says it returns a modified array. And that's important information. And I don't know any other way to get that without looking at the source code. And good luck finding that. Right. So there

is a section here in this book that I guess we're kind of already getting on, so I'll go ahead and bring it up, which was Java docs in non-public code, and they were saying, like, you shouldn't do it. It's just no value. I agree. I so disagree.

Really? Well, and here's the reason. Because what are we calling public? Okay? Because, okay, we're in a c-sharp world right and maybe uh you know i don't remember how it's been a while since i've worked in any with any java packaging so i don't remember how that works with the docs but in a c-sharp world if i package something up as a nuget package you don don't have the source, right? So your only ability

as a developer in the IDE, your only ability to see some of those things is to, when you dot and then a bunch of stuff comes up, that IntelliSense documentation that is presented to you while you're typing, or even if you were to hover over something and read like, okay, yeah, that's what that thing does. And that's just staying within the IDE, right? Those are, those are extremely valuable. And you're only going to get that documentation if you provide the XML feed with the XML document with your NuGet package. Now, you could say, well, Michael, you don't have to put that in the summary documentation of the class or method or property or whatever. And you're correct.

Technically, you could just manually write the XML if you wanted to. But the easy way to do it is to write your summary documentation in with your code and then use tools that can extract that, much like you were talking about with the JavaScript frameworks. You could use a tool to extract that XML at compilation time. Even Visual Studio, actually, if I remember right, will spit out the XML for you when it does the compilation if you have anything in your summary documentation.

So, you know, that's extremely valuable, right? And that doesn't have to be something that you publicly outside of your company or your user base distribute. So if you're drawing the line at public as, you know, people you don't know using your thing right like i take issue with that one but even um you know intel sense is great it'll show you the the javadoc stuck there for internals or something so if you're working it's nice

able to see like as you're typing the method like here's descriptions of what the arguments should be and here's what the return is. Only if you provide the summary documentation. Yep. So here's the thing. And I think, yeah, there is a distinction. So I guess when he was saying internal, and probably the same way I was following. Well, he said public.

I agree with what you're saying. So I don't necessarily think it's internal versus public. I think it's more what is a package that you use in your application versus your internal application. Well, that's what I'm saying. You have to define public. Yeah, and that's what I was going to say. If it's something, a package or some sort of component that you've bundled that people

are going to use, I do think you document those with comments or whatever. However, you can generate the documentation because that's not something internal to your application. That's something that you're interfacing with, right? It's almost like a third-party component, even though it's internal. Now, here's, okay, so basically, if I could restate what you're saying then, is that there are times when you should write that documentation and times that you shouldn't. But how do you differentiate between when you should and when you shouldn't?

And the reason why I say that is because there have been times where in code bases that even the three of us have worked in collectively where there's been some project and we're like, oh, you know what? This thing has kind of grown into its own thing and we'd like to be able to use it elsewhere. We should make it its own package. But dang, there's no summary documentation on it so if we do that you're not going to be able to like look at it and immediately know like oh this

is what this does and oh by the way the guy who originally authored it is no longer here so now we got to go and take the time to figure out what all this stuff is doing and then add the summary documentation in like that's a huge hassle whereas if it had been done at the time right yeah then that summary documentation could have easily uh been usable when it was put into a package so yeah i mean like i'm not i'm not a fan of inline comments with inside the method, but header documentation for methods, I am a fan of. Right? Like whatever you want to call that. Summary documentation for C Sharp. That's actually what Will and I had kind of had the debate on

was the header documentation. He was like, no. And I think I agree just from the fact that. Well, I'm not saying explain it because it's unreadable though right right i'm talking about it i'm talking about just giving a short description of it so that when you package it up in that he said yeah i disagree i disagree and so here's the thing i actually kind of do agree only if it's valuable though that's another thing too is that it has to be i'm sorry to interrupt but it but i'm talking about like you don't necessarily have

to go overboard and do it on every little thing, although I'm probably pretty bad about that. But, you know, you can definitely see, like, these are the times where it needs to be done. Like, if you have a two-string method on your class, for example, you don't need that, right? You can skip that. We all know what a two function that's going to be, you know, a little bit more, you know, even though you might have a great title on it, a great name on it, you know, you might want to have some summary documentation in there to just make it available. And then here's another great option, too. And I know I totally cut you off, and I'm sorry. But there's tools out there.

Okay, so, you know so GitHub is a big thing. A lot of people use it, right? And GitHub will do this, and so will some other code-based, code repository platforms, such as Visual Studio, Team Services will do this thing that I'm about to mention. And I'm pretty sure Bitbucket does it as well,

if I remember right. But the idea is that if you have a readme, like, I'm sorry, not even have readme, but just a markdown file, you know, so it could be readme.md, but it doesn't have to be. But if you have a markdown file in the root of your, of some folder, then GitHub and Visual Studio Team Services, you can actually view that as, it'll, it'll render that markdown for you so that you can see it. So where I'm going with this is if this is something that you're going to make as a package or offer as a package, and you have that summary documentation extracted out, you can, there are converters that can take that summary documentation, throw it into markdown, and now you include that

along with your code when you put it up into whatever repository and now you include that along with your code when you put it up into whatever repository of choice you're using. And now, not only can your users read that documentation through their editor, but you have your API documented that's, quote, publicly available, which may only be to your company or your team or whatever, but however you define public. And you know, um, we should say, uh, actually Andy's, sorry, Andy, uh, said in one of our comments on episode 48 that, um, we don't mention enough is that, um, what we're talking about is basically best practices and that's not always the right answer

for your situation. And so all this stuff needs to be to be you know thought about and you need to make situations make decisions that are right for you in your situation so um you know like even the stuff we talked about like the application like i've read the book i agree with 99 of it but i still do things that they say not to do um because i think it's right in my scenario so yeah i just wanted to mention that yeah so the one thing i was going to say though because the the original question was, so on the internal stuff, what if at some point you decide to break it out? I say you bite the bullet then.

Because I am still a fan of keep your code as clean and as expressive as possible. And then when you can, if you can break it out at that point, I know that it's more work at that point in time. But then at least you've probably gotten to a point where you're like, OK, we know that this part of our app is a core piece or something that can be reutilized. And it's probably already been shaped and formed over that period of time. So that now when you go to break it out, you got a pretty good idea that it's now going to sort of stay in that state.

And so I think that is probably the better time to comment it. I'm not saying that's always the case. Yeah. I mean, I'm just thinking back like that. There was this one specific example, though, where it was a library that was created. And it wasn't that the library wasn't expressive in what it did. It was, but there was a lot to it. And if you weren't working in it, if you didn't author it, you didn't know all the

things that it could do. Whereas had the documentation already, the summary documentation already been there, then you could have used tools to extract that documentation and not only make it to where, you know, it can be packaged along in the NuGet package and used in the IDE, but, you know, other places, you know, like I mentioned in the, you know, the repository, whatever your repository, your hosting server of choice for your repository could visualize that API documentation too to make it to where now your users can explore it a little bit

easier, right? So, yeah, I mean, like Joe said, there is no one, you know, you can't say this is the way it's always, the way you always do it, which kind of goes back to the point that James was making in that speech about Hammer or Saw, all the things. So one thing I did like is they did say a good use of comments is explain what a regular expression does. Oh, I've totally done that.

And it makes sense because it's not something most people understand. So when it's something kind of cryptic, and there's really no way to make it expressive because by its very nature, it's a bunch of... If you've ever ran across a regular expression with a comment like this, then you'll know it was mine because I'll start it off with something along the lines of, because humans can't read regular expressions.

And then I will break down each token of the regular expression and what i am trying to do yep oh man ain't nobody got time for that yeah i know right just show me a sample like this works yeah i know it's horrible i should never do that but this is one of those places where i break that uh this rule about the comments though because um in that one example though yeah i mean even i'll go back and look at regular expressions that i have written and i'm like wait what oh yeah totally what was i doing here and then it takes me a minute but yet if i go ahead and include that that little bit and and i'll always i'll put that in there you know because humans can't read regular expressions because then i know it's, oh, this is mine. I originally wrote this.

This is my explanation of it. As long as these tokens still match, then I know that this is pretty good. It's funny. If you ever do take the time to learn regex, doing replaces and text files, when you have lists

of things, man, they become amazing. It really does take a little bit. Nobody learns regular expressions. I did for that reason. No. It flees from the mind. We all learn simple regular expressions and we'll think that we're like the gods of programming

because we can do these simple things. And until you start getting into backtracking and replacements, and then you're like, whoa, wait a minute, things are going plaid here. They're getting so crazy. And yeah there there are regular expressions out there that uh mortal man cannot write it it took a it took iterations of resharper to say hey you should change this 100 hours of machine learning yeah oh you know i will say though um if there's ever been the perfect case for unit testing it's got to be regular expressions.

So if you're looking to get a start on your brownfield project and you want to start adding tests and you're not sure where to begin and you're a little bit scared, start with some regular expressions. It's a great place to kind of pop into function. And it's so easy to test. And then you can modify those guys without being too afraid. And you can put in all those weird edge cases that you worked around. But you say, my application doesn't have regular expressions. Well, this is your opportunity to add some. Yeah, that's right.

And then, so there was one last point that they hit on here that I thought was interesting. And I can completely see where this is valid. Is if you're interfacing with a third-party library that isn't very clear in how it works or it does things that are unexpected that might be a good place to put a comment because you can't change their code you can only use their code but then the problem is if they upgrade the code later and it changes how it works then now you have a comment that's no longer valid you know does anyone have an idea on how you could do this in code instead of comments? An aspect, maybe. Okay.

I got aspect. Joe? I wasn't paying attention. Okay. I wasn't paying attention. My answer was the facade pattern. Oh, yeah. You could.

You could write a facade pattern around that third-party library, you know, if it's applicable. Yeah, that could work. And then that way you could make your facade more expressive to your need. And then that way you don't need the comment. I've seen some comments. Sometimes it'll be like, you know, thirdparty.open. You know, open a connection, do some stuff. And then later it'll be like thirdparty.open.

And there'll be a comment there that says, I don't know why this closes. You know, reopen. And I appreciate having that comment there because otherwise I might think it was just a mistake. But then, you know, what would you do in that case? Would you create a new function called like reopen so it's more clear and then just do it open in there it seems kind of noisy yeah that's nasty yeah i don't know that's one of those things that if you come across you say um that was a good comment how about your your facade pattern could manage the state of the openness or not,

and if it's already closed, then it would just reopen it for your user. That's a great example, though, because that's the kind of garbage where people do feel like they need to put a comment there because they're like, you know, I tried to delete this and it broke everything, so apparently it's doing some crazy stuff behind the scenes that I don't know what it's doing. That's actually a comment that I've probably written before. It's crazy stuff behind the scenes. Sometimes it just closes itself.

Well, I think our favorite that we've definitely talked about on this show more than once is, like, I don't know how you could ever even get here. Yep. And then somebody finally got there after I left. That's amazing. Yeah. All right. And so what was the other one? Oh, to-dos.

Yeah, we already covered that, though. What do you feel? Do you like them? They're okay. I mean, I don't hate them, but I have definitely seen cases where myself or someone else adds a to-do, and then later myself or someone comes along and does what's in the to-do, but the to-do is left. And so then I later come back and I'm like, oh, hey, here's this to-do statement.

And I'll read the to-do statement and then I'll read the code below it. And I'm like, oh, wait, it already does that. I think I to-did it. Yeah, that's to-did. That's to-done. Yeah, I do see to-dos that I write all the time. I tend to write a lot of to-dos when I'm first starting to work on something and i'll kind of come back and search for and fix them but sometimes i get left in so i'll come back you know a few months later i see a to-do there i'm like

huh i don't think this is relevant anymore i think i can just delete the to-do but i'm not sure so i'll just leave it forever hey i gotta i gotta way to pose this question to you about comments in a way that you guys might not have considered that probably, I don't even know if the author has considered this way of thinking of it. But because this book, I believe later does get into a chat section on test driven development. And I know that Uncle Bob has definitely have, has some strong opinions about test driven development testing testing in general and one of the tenets of test-driven development is that you write your your test first that fails and then you write just enough code to make the test pass you write no more code than it takes to make it pass and no less, right? And then you refactor, right? Now, if you were to take that approach, right?

So you write your unit test first, your unit test fails, and then you write just enough code to make the unit test pass. So let's say you had an add function and you have a unit test that says like, hey, if I pass in two and three, does it return five?

So when you write your method the first time, you just simply return a hard-coded 5. That's how, like if you're truly following test-driven development, right, especially in the beginning, that's how you would do it, right? You would write just barely enough code to make it pass before you would refactor.

Now, the question is, the question is, the question is, since you can only write enough code to make it pass, you can't write the comment ever. Oh, that's a good point. Right? There is no comment. Yeah.

So, if you're following TDD, does that mean you never write comments? Except maybe when you're done, you're like, okay, fine, I've got to write some summary documentation because Outlaw is kind of particular about his NuGet packages. Nah, man, you do it while you're in there. Otherwise, it's not a question of mine.

If you're practicing pure TDD, then you're never going to leave the keyboard if you're doing an add function. It's like, if it's 3 plus 4, it turns 7. Well, no, no, no. That was just like the worst example that came to mind. I mean, first example that came to mind. But it illustrates the point.

But yeah, I mean, just for anyone who's not already familiar with TDD, I was just trying to illustrate what it is. But yeah, I mean, if you're following TDD, then you never really get, there's never an opportunity to write comments because if you're following TDD, it doesn't say like, write a failing test, write enough code to make it pass, refactor,

and then comment. No. It's those first three, and you just keep doing those first three. Yeah, I think that honestly, though, you've mentioned it in a previous episode. You name your methods crazy long, right? I name them crazy correct. I think it's what you mean to say. I don't think you need a comment.

I don't think you need one. If it says... Well, but that's the unit test, though, that we're talking about that are crazy long correct. Yeah, you're talking about starting with it. Yeah, I'm talking about the actual code, though, right? Okay, yeah. Okay, let's say, for example, you write that failing unit test, and then you go to write your method

that implements that failing... or not implements it, but makes that unit test pass, right? You can't technically write a comment first because you're only supposed to write just barely enough code to make the unit test pass. I guess you don't do it then. I guess you don't.

All right, well, this whole section is done then. Forget the book. Yep, we're done. And that took us, what, three minutes? We got through comments in three minutes, right? Something like that. I feel like Joe wants to say something. Yeah, we actually have some more stuff on comments.

But first, I wanted to mention a really great comment we got on episode 44 recently. In that way, we had talked a bit about basically putting up your school projects if you're in some sort of school or boot camp and posting those to your GitHub and using those to, uh, kind of show off your, your chops when you're looking for a job. And Darren Hona mentioned that, uh, that's probably not a good idea since a lot of schools,

um, will actually specifically prohibit you from doing that sort of thing because they don't want other students to just find your work and copy it, base it. And so said, uh, you know, you can do it.

Just make sure you check and ask permission or make sure that you're allowed to do it before you post your results. That said, you know, you can do it. Just make sure you check and ask permission or make sure that you're allowed to do it before you post your results. That said, you should still do side projects, but I just thought that was really good feedback. So, I mean, he's right. And he was like, oh, Michael, please don't tell people to do this. And, you know, yeah, so Darren's probably right. Yeah, shame on me for saying it. But I kind of feel like, oh, boo, schools would do that. And they do. But I think if it were me, I'd probably still go ahead,

maybe live up to my name here and put it into the repository. And, you know, along the lines of, uh, better to beg for permission than, or beg for forgiveness than ask for permission. I mean, even if I just put it in the repository and left it as a private repository, right? And so then no one else can see it. And then when I graduate, I'm like, oh, look, public all the things. You know, I mean... That sounds like terrible advice.

Yeah, it probably is. It really probably is. But yeah, I hate that that's true, though. So thanks, Darren, for making me feel bad. And thanks, Darren, for the excellent feedback. And we love getting feedback in and of all. We've got a lot of really great comments this time. And we've also gotten a lot of really great reviews, which are awesome because they give us feedback, make us feel good, feel good about ourselves.

And they also help new listeners find the show, which is really important to us. And the show's been doing really good, really, great lately and we really appreciate that and we desperately want more so we would really appreciate it if you haven't reviewed us already if you went to codingblocks.net slash reviews and hooked us up all right so now we're going to get into we're going to take a little moment here to get into my newly favorite portion of the show. It's the Survey Says section. Now, in our last episode, the survey was, what is your preferred work environment? All right.

Now, Alan, Joe, Alan especially. I haven't cheated, man. I'm pretty sure. I believe I'm telepathic. That doesn't happen. That doesn't happen. Don't cheat. All right. If it happens again, we'll totally know that you're lying.

All right. You guys haven't cheated. So here are your options. No. No, Joe. No. He openly admits to it. I publicly deny it.

All right. What is your preferred work environment? I guess if we were playing it truly like the Family Feud survey says, then you would have to tell me something and then I'd be like, survey says... But we know what's in the survey, so that doesn't work very well. Yeah, I guess you're right. Alright, so your options are love me some

cubicles or open floor plan equals collaboration. Yay! Or home office, pants optional or a work office with a door and lastly coffee slash tea shop so what's it gonna be let's see i think i think joe might have gone first last time so alan goes first this time i you know what i mean because i do get in and slack and i chat with people i really don't know what people are

going to do on this one because i i mean i've seen people that say that they work from home and they kind of hate it i've seen people to say that they work in an office and they kind of hate it yeah so i i think there's a lot of hate in the world is what you're getting at. Yeah. Thanks for being a Debbie Downer here. I don't think you can please anybody is basically what it boils down to. So out of those choices, I'm going to say that people would probably like an office with a door.

An office with a door. Not a view, but a door. Well, yeah. Which is kind of interesting because the way this question was phrased is it's with a door. So it could be in the basement of the building, but as long as you have an office with a door well yeah which is kind of interesting because because the way this question was phrased is it's with a door so it could be in the basement of the building but as long as you have an office with a door you're you're satisfied shut the world you don't need a window but you need a door all right joe i'm gonna say that was i'm gonna say that was 30 30 all right what have you got joe uh yeah i'm gonna say the same. I think that it's going to be really close between working from home and

home with our Office with a Door. I'm going to say Office with a Door at 33%. 33% Office with a Door. Price is right garbage. Alright, this is Price is Right. Yeah, here we go. So we're mixing two games, the Family

Feud and the Price is Right. So by Price is Right rules, that means that you have to pick the right one without going over on the percentage, and the closest one wins. And survey says you're both wrong. Home. Yeah. Home, office, pants optional is totally the winner. Why would you think anything less? Come on, man.

We live in Atlanta. Have you seen traffic around here? Oh, dude, it's insane. It's insane. So that might be part of it, but in Slack, a lot of people are like, yeah, I don't really like working from home.

I feel like I'm trapped sort of like in a cave. Yeah. I am trapped in a cave. Yeah. But I've also only worn gym shorts for like six months straight now. Right? It's amazing.

Stretchy pants. So wait, what was the percentage on this one? So home office won by 35%. Now, Joe cheated. He totally cheated. I am going to go ahead and bet that because by Price is Right rules, he did beat you on an office with a door because that was our second most popular choice at 33 and

a half percent oh my god oh wow that close hey so we were both pretty spot on with this one yeah you both you both are in that third range but he edged you out by price is right rules so i will say this if i didn't live in an area where the commute sucked just to drive to a coffee shop right like like well i don't know that's the thing right if you live like maybe if you lived in the city and you worked in the city it wouldn't be so bad right like if you could walk to the office or something no no no no no no no but if i can tell you i can tell you i can tell you having lived in quote the city and you know worked in quote the city that you could still have a 45 minute subway commute and it would still suck no no let's say that you can walk to your office and it's five minutes away i could yeah most people don't have that that live in the city

no they don't but i could see somebody saying you know i do like to go into the office because i like to be around some people right like i can I can totally see that because the only reason why I don't feel as trapped here is because we'll get together and go to lunch or we'll get on Skype or whatever the case may be. But there is FaceTime. And so that helps. But people that are truly isolated that maybe aren't in a good developer-centric type environment where they're just kind of working at home in isolation.

Like one of our listeners that was like 120 miles away. i mean i could totally see where that would be a problem right like you literally feel like you're the only person on planet earth you know and that's that's kind of i don't know i i get it well yeah so i think the answer there though is that you don't necessarily need to be around co-workers you just just need interaction with people, period. So if you're working from home and you're frustrated, just take a break to go to a coffee shop or go out and walk around a store or get something to eat or whatever. Just take a moment or be around other humans

to remind yourself like, oh yeah, this is why we do this. Did anyone vote for cubicles? Cubicles, yeah, totally. Really? Yeah, it was not one of the popular ones though it was it was uh fourth out of the five you get some privacy you know and you still get to go to lunch yeah i'm actually surprised because like um of those options if i wasn't going to pick home because cubicles i definitely am up there on the cubicles

i like it because you get just enough privacy uh you know when you want it right and if you want to put on some headphones to block people out you totally can um but like the open floor plan which was which rated higher than cubicles by like double almost. Okay. I can't stand that. I can't stand if I can just like look across, like, you know, I'm sitting there and we're trying to write some code and I got to like look across and like,

Oh, there's your face. Oh wait, sorry. Sorry. I wasn't trying to catch your eye or something. I wasn't trying to like flirt with you while I was, I just looked up from my monitor for a moment or,

you know, you know, if you're trying to talk to your spouse or significant other and you're like you know happened by just looking around and all of a sudden you catch your co-workers you're like whoa you know yeah i mean it just doesn't feel comfortable to me and yet it was a higher you know more popular choice yeah interesting so i will say though i think slot kind of keeps me saying like there's people i'm used to seeing you know most days like say like angry zoot or um mad viking god or something i'm just used to kind of keeps me sane. There's people I'm used to seeing most days, like say Angry Zoot or Mad Viking God or something. I'm just used to kind of talking with these people day in and day out.

I'm pretty isolated. I'm pretty far away from even any other developers out on my little island. So it's not really an island. Joe owns an island. You heard it here. Right, yeah. I'm pretty sure. I'm pretty sure that's what I heard.

Wow, man. You should Google it. Right, yeah. I'm pretty sure. I'm pretty sure that's what I heard. Wow, man. You should Google it and skip past the photos with the police tape, and you'll see some nice ones. Wow. Yeah, so it's nice to have developer connections there. So here's our survey for this episode. So in keeping kind of topical with some of the things we've already discussed here recently, hey, guess what?

We have coding block stickers. We'd like to give you one. Send us a self-addressed stamped envelope. You'll have to email us or DM us on Twitter, and we'll tell you where to go. So in keeping with that topic, Alan here is a little weird. He doesn't want to put a sticker on his laptop. So I'm not trying to taint the jury here. But the survey is, do you put stickers on your

laptop? So your choices are no. I've got class and I'm an adult. Stickers are for kids. I don't have a sticker book. I have a MacBook. Right on. Or your other option is stickers stickers all the things so one sticker what one sticker you can't just stop at one man these are like yeah if you do have something over the apple you know like iron man no man hey, how many stickers do you have on your laptop, Joe? Which laptop?

The one that's yours, not work. Your personal laptop. One of your personal laptops. Stop it, man. Your MacBook. MacBook Zero. Dell, like, I don't know, 10. And why?

Because your MacBook is pretty and you don't want to mess it up, right? Yeah. Yeah. I will admit, I had one on the Dell for many years. You had one on the Dell? And then when I retired it, and it basically became just like a shelf laptop, then I just started putting random stuff on there, because who cares? But the MacBook, not happening to me.

Yeah, man. Would you drop 3K on a machine, and it's all polished aluminum? Your logic is so backwards. It should be the exact opposite because on the MacBook, if you want to take it off, because it is just aluminum, it's the easiest one to clean any sticker residue off of

versus if it was a plastic one, like a plastic case one like your Dell, then taking the sticker off could actually damage the plastic on it or any finish on the plastic or anything that you might try to clean the sticker residue off could mess up the finish of it. Your logic is completely backwards here.

Hold on, I'm having a seizure right now seeing all the stickers flashing on Outlaw's back of his laptop. There might be like one or ten or thirty on there. I don't know. Oh my god, how many are there? I don't know. Who knows? I can't count that high. There's at least twenty. Alright, maybe I can't count that high. There's at least 20. Alright, maybe I can't

count that high. Oh, yeah, man. I definitely am the more I want it clean. I have two on mine right now only because I've got coating blocks and I've got the MVP thing I got. Man, look at how beautiful this looks. This is amazing. Oh, God. Hey, there's this lovely little coating block

sticker right here. The coating blocks one is nice. I will say, though, I did stick a coding block sticker. Got an MS Dev Show one right there. Look at that. Look at that beauty. I put it on the back of my phone case. So if I'm talking on the phone, people can see coding blocks sticking out of my ear. So that's nice.

I got a cool little robot. You like the robot. You like my Git Ninjas, too. No, man. You know what, though? I'm going to be surprised. I think that no matter what I guess on this next one, I'm really going to have a hard time understanding it one way or the other.

Right. Because I'm going to think it's about half and half. Some people are going to be like, no way am I sticking to that. I'm actually really excited to see. And I'm actually surprised that Joe wouldn't have any on his laptop, considering that he has an entire guitar that's held together by nothing but stickers. And if he ever took one sticker off, it totally changes the tuning

of it. Yep. So 15% of my guitars have 100% sticker coverage. Did you say 15%? Have 100% coverage. I feel like he's trying to tell me he has 15 guitars. I didn't actually do the math.

It might be 12.5%. Yeah, I didn't do the math. I have a lot of instruments. All right. So, you know, keeping with the humor here, Binary Nexus wanted some jokes. Let's do it. So, what's the object-oriented way to become wealthy? Inherit. Inher become wealthy? Inherit.

Inheritance. Inheritance. Yes. Very good. Very good. Yes. All right. And then there were a couple other things that I forgot to mention here.

What were they? Oh, just kind of like a recap, or not really a recap. But, you know, the the last episode it actually sparked some pretty serious conversations like a lot of them that um you know there was that whole conversation about the method order which we'll get into in more detail with the when we cover the next chapter chapter five which is uh formatting uh but yeah there was a lot of interesting conversation around that one and then the live pr that got there was it got some love and it got some hate but it was it was totally uh interesting you know it got a lot of talk let's put it that

way it did it definitely sparked a ton of conversation on slack which was interesting i mean it's funny after the fact like after i went back and actually looked at the code i was like okay i see what you're saying with the vars right like some of those things couldn't a bit they didn't need to be broken out and all it was for the record just one method that we were talking about yeah it was and and honestly i didn't even remember because i we had planned on recording that episode like i don't, a week or two prior. Yeah. And we had talked about doing the live PR a week or two before we actually got a chance to record it and then forgot.

And then I remembered it on air. Which, you know, I mean, so some people thought like, oh, great. Alan and Michael are arguing. This is amazing. And then some people thought, oh, great. Michael and Alan are arguing. This is horrible. So, yeah. I mean, it was totally – so that part was interesting.

But, you know, in fairness, I wish we had remembered it ahead of time so that we could have maybe prepared that segment a little bit better than what it ended up being. But because we were in that section at the time, I was like, well, okay, fine. Let's just go ahead and try this and see how this works. And it was interesting. So, yeah, it was the one method.

It was one method that went from 16 lines of code to 43 after the, quote, clean code approach. The method didn't go to that. The method plus all of the other methods that went along with it, I should say. Yes, yes, sorry for that. Yeah, so to clarify, the original method by itself was 16 lines of code,

but then after it was, quote, cleaned and additional methods were added on, it became 43 lines of code. And so that was where the interesting things came. But again, I don't know if we'll try it again. Maybe. Maybe. Other listeners are probably like, oh, dear God.

We don't know yet. I mean, if we do, we'll probably prepare for it a little bit better. Because like I said, I mean, it was code that was gone in my head. Yeah. So sorry about that, but we tried. Yep. Sometimes you don't know until you try. Yeah. So sorry about that, but we tried. Yep. Sometimes you don't know until you try. Yeah, totally.

What's going to work. And I didn't even realize we had more to talk about on comments here. Oh, yeah, man. I totally forgot we split this up. We are so totally not done talking about comments. So let's plow through this thing. So we've already hit on the APIs because I didn't realize this was down here. Yeah, and we've already said that most comments are just bad comments and

not needed and code should have been changed, blah, blah, blah, blah, blah. Oh, yeah. Joe, did you see this when you were reading that they said they took some shots at JavaDocs or they did take shots at JavaDocs because they said they were useless? This was hilarious.

Yeah, where they extracted or not extracted, but they were just pointing out like here here's a public library like you can go view the source code yourself here's the comments on the source and it's horrible because it would be like uh you know here's a variable date and they would have a comment above it this is the current date or whatever right like something like that ridiculous and we even talked about the log journals earlier like how subversion would add those things on top of the files.

We covered that. This is kind of going back to the log journals, as it's phrased here. Let's focus on SQL Server for a moment, which is Joe's favorite topic, which is why I picked it. So,

so you're welcome, Joe. Uh, if you were to use the tooling within Microsoft, uh, SQL server studio management studio to create a new stored procedure or function or whatever, it automatically puts in a,

uh, comment block right at the top that includes the author. Now, I'm fine with some description code in there, but it bugs me, especially when you see change logs that are added into any kind of code, whether it's SQL or not. But it bugs me because I'm like, well, it's already in the source control.

But the fact that the author is there and it's in this template for the documentation, I kind of hate that. That was the old days, too, if you'd go into your IDE and create a new file. Like, there'd be a comment at the top for the author. Oh, yeah, you're totally right. I mean, it's just... An at author declaration in your Java documentation. I think it was Ego stuff back in the day, right?

Like, they're like, wait, these developers need to feel like they own this or something. I don't really know. It's been a few years since I've used IntelliJ, but I feel like IntelliJ might still do that. It does, I believe. It does. It's been a while. I'm going to get slapped. Somebody's going to be like, oh, outlaw.

So, yeah, I mean, yeah, I'm not a fan of that. Yeah. We've already said that they're usually noise and useless. Oh, no, this is different. When you add a comment, it's literally just restating the exact, like you said with Tomcat. Yeah, I mean. The constructor. Oh, yeah, there's a constructor.

Oh, come on. And it puts that comment in there for you, right? Like, add constructor here. Right. Oh, yeah. There's a constructor. Oh, come on. And it puts that comment in there for you. Right? Like, add constructor here. Right. Oh, come on, man. What else? Comments that contain about things.

I do this. I put comments. I'm like, I don't know why this is like this. Or what's going on? Or I'm doing a hack. Hey, man. If you're going to complain, at least complain to where everybody can hear it. I guess that could be a thing. Sure.

Sure. Don't use a comment when you can use a function or a variable. And this goes back to what you were saying earlier, Joe, right? Like refactoring that thing so you didn't start it to name your variable and then it's obvious or just being expressive right yeah yeah and you know the thing I did to upload the videos to

YouTube I started out by just kind of putting in comments and I kind of pseudocoded it like old school style and then I started writing code and then later I went to this I was like okay everywhere I have a comment I'm going to take those three lines out and make it a method well I started doing that next thing you know the arguments start exploding because I And later I went to this, I was like, okay, everywhere I have a comment, I'm going to take those three lines out and make it a method. Well, I started doing that. And next thing you know, the arguments start exploding because I realized I had dependencies just kind of woven throughout.

And I realized I had written really crappy code and it's functional. And so you can see, if you want to look at some examples of how not to write code and examples of bad comments, then take a look at the scripts I wrote. How about this one? Do we have a link up on the site for our GitHub? I don't know if we do. I don't know. If not, we'll add it in the show notes and we'll make sure that we add it up at the top of the page along with our social links and the 5,000 other links that we have up there. I feel like we really need to add some additional links up at the top.

We do need more. I mean, we've got to make it look like the back of your laptop. We should probably comment that in the code. We should. What about this one? Have you ever seen this where someone will have closing braces and they'll have a comment at it like, this closes the if, or this closes the while,

or this closes the switch, or this closes the function? The author here, Uncle Bob, says that if you find yourself wanting to mark your closing braces you should try to shorten your functions instead that's a good point but you remember in html like back in the day you'd have templates and it would have start this library like uh macromedia tools were were crazy about that like anytime you drag component on there start this and this right okay Right. Okay. Alright. Those are legitimate. They're still HTML to date. I want to see stuff like that.

Here's column one, column one end. I want to be able to search that file. You can't really break those guys up modularly. But you could collapse the elements, right? Potentially. Yeah, if you're using a modern editor. Yeah, it depends on how good the code is too. Yeah, I can see that. modern editor. Yeah, it depends on how good the code is too. So, yeah, I could see that.

What else we got? Yeah. What about banners? You like the big to-do banners? I do in SQL. Like, this is the section that gets this crap. I'm trying to remember what they were referring to by the banners. It was that.

It was the big, big like titles type things that you put so they're instead of just having slash slash and then your comment it would be like slash slash slash and then a bunch a bunch of stars and then oh right right right to break it apart yeah i mean hmm uh i probably am bad about doing that i do it in SQL for print statements. Like you said, it's hard to modularize SQL code. Well, if you have functions and you have procs that call other procs, sometimes it's really hard to find out where you are when something's going on.

So I'll put print statements in there that will kind of have banners like start of this function, right? And then stuff that will happen in it. Well, I was thinking of examples like, because I'm pretty sure if you by default, like start of this function right and then stuff that happened in it and well I was thinking of examples like because I'm pretty sure if you by default I can't remember when you do your summary documentation doesn't it automatically put in some of that those banners for you or am I thinking that wrong I'm

thinking about the ones it's like 40 slashes on the right and it's like yeah I think some generators might. That's where I was thinking of as one, but then I'm also bad about, and I think Joe mentioned sequel, I'm pretty bad about there where for some reason I feel like I don't write my sequel

to the same cleanliness level as other stuff, so I'm bad about that. But I will have some gnarly comments in there that have the banners to break it apart. Well, the big problem, I think, and not to get too far on the side tangent of SQL, I think the reason why it's so hard to write,

you can write modular code with SQL. You can write functions. You can write all kinds of things. But then the thing that you run into the most with SQL is performance. So if you write it to where it's pluggable, then you're really taking a hit on the performance. And so usually that tradeoff is not allowed in your relational database.

And that's kind of what stinks is, you know. Yeah. Here is a big one that I absolutely hate is commented out code. Yeah. We've talked about this one before. In fact, I remember creating a meme about it, joking around about it because of a quote from, I think it was Roy, how do you pronounce his last name, Joe?

Osharov. Osharov. Something like that. The author of, what was that book? It wasn't the AOP. It was Unit Testing and C Sharp. The Art of Unit Testing. Yeah.

And because he had made a comment that was along the same lines about, you know, I absolutely hate it when I see someone comment out code and then commit it. Because why? I've denied pull requests. You have source control systems that can manage that. Why would you do that? You're not doing any favors. And here in this book, the author makes the point of saying that

if you do this, others who see that commented out code won't have the courage to delete it. They'll think it's there for a reason and that it's too important to delete. And so the commented out code gathers like dregs at the bottom of a bad bottle of wine. It does. And he's not lying at all. It is horrible. And it will stay there because you know there's times where when i when i have seen that if i

absolutely know that it is old then uh you know fine i'll delete it but sometimes you'll run across that commented out code you're like wait a minute was this something new that the author wanted to add and didn't or i think there was even a case here recently where there was some code where there was a method written that was like, hey, I think we're going to need this eventually, but I found out that we don't, so it was commented out,

and I think I came back to it later and was like, yeah, I'm deleting it. We'll add it when we need it, but for right now, who knows what that might look like i actually had somebody um because i will straight up deny a pull request if there's a bunch of commented out code because i'm like this is this is noise like it really bothers me but i did have somebody that i contacted one time about it and i was like yo dude why why do we have this in here and he said because i'm actually he was basically working in three different

branches type thing to where this stuff needed to go into other places and it was going to get pulled upstream and in the uh or further up and further up it was going to be uncommon and so basically he was saying this is going to this is going to happen in the next version i've already got it in here but we don't want it in this version. And so I was like, That seems horribly nasty. Okay, I guess. And so I kind of let that one go because I was like, okay, I get it. I understand why you're doing it.

I don't love it, but I don't really know a good alternative at this point. So, yeah. Yeah. Well, yeah. So, what else? What else can we say about comments? HTML comments? Joe loves HTML comments.

Those are his favorite things. He just said it. What do you think about them? What do you think about them, Joe? Me? Yeah, I hate them. What about XML comments in your code? Like what Microsoft does?

Now, wait a minute. Hold on. Let's be fair there. Because, you know, I was trying to make a joke and nobody bit it. But because Joe was saying that he didn't like or that he did like the HTML comments in HTML. But this was specifically saying putting HTML comments in java docs or in your summary documentation that that was the part that they didn't yeah yeah sorry yeah yeah that's the stuff i can't say and i see and you do see it like you'll see a little b tags or whatever to make stuff bold

and i just don't i hate seeing stuff like that it looks nice when it outputs but yeah no that is unacceptable unfortunately as it relates to like let's talk specifically the C Sharp world, right, with the summary documentation, unfortunately, there are some of those summary tags that if you want to use, guess what? You have to do things like, you know, you can't just do less than. You'll have to do

ampersand, LT, colon, or semicolon. Oh, you know what I do? That's the way that, that's the, quote quote Microsoft way to do that though, right? For some of those instances. Like, and I'm thinking of examples where you're trying to like say like see this other reference, right?

Or if you're trying to say that, see this other type that is a generic, right? And you want to include the uh the alligators right then you have sometimes you find yourself in a situation where yeah you got to do that nasty uh encoding manual encoding yeah but i will say um i i like markdown stuff even if you're not running a markdown generator like things like putting little asterisks beside something that you want to bold because i feel like that is meaningful when it's text only and if you turn it into formatted rich text later, then that's fine.

I have no problem with that. Well, I feel like it has become a thing that is meaningful, right? Yeah. Same with underscores. It's more readable than some sort of SGML type stuff, right? I think the one thing I hate and I see it a lot, so this HTML comments thing, it bugs me because it's not just in comments.

People will feed HTML out of their database. They'll feed, like, HTML has kind of become this thing that everybody shoves everything into. Not everything runs off HTML, right? Like, if you ever have some sort of mobile app that needs data, you've now got HTML all wrapped in there. And if it doesn't work with it, then now you've junked up your stuff. Well, I guess I should clarify, too, that manual encoding that I was referring to is actually for XML, not for HTML. The and ampersands and all that. Yeah, I don't know.

I think I like the idea if you're going to go one direction versus another, I like the markdown because it's just more readable, right? It's not tag-based. It's not some sort of other language base. It's just kind of, you know, like they say, markup, right? It's not terrible. Yeah. And there's certain words I like to bold.

Even when I'm writing an email, if I'm saying this and this and the and, I really want to stick out because I really want to emphasize that these two things have to be true or else it's false. Then I'll bold the and or I like bolding nots all the time. So I'll say this is not the case. I'll bold not because like when you kind of read over something, it's easy to kind of see what you want to see. And I feel like that kind of makes you focus on it. Yeah, I like that. One of the other things they say is only comment on the code that is right

next to the comment. Not underneath? Well, not away from it. Okay. Don't make some sort of comment that's all about the method way up here when there's things that are happening. You put it next to the code if you're going to do it. Yeah, right underneath it, right? So they say ideally, right? Wait, above it or underneath it or beside it? Yeah, definitely not underneath.

Hey, where do you like to put it? Do you hang it off to the right or do you put it above? I usually put it above. Say what? Right in front of it. Wait, what does that mean? To the left of my code. You can't do that. Sure you can.

You can if you do the slash, slash, slash, slash. I will deny that pull request. Block comment. Do not do that. I'm not saying I do. That's Joe's code. Yeah, I sneak stuff into the right of my banners. That's how I get stuff through in pull requests. Do not ever do that.

You hide all the code In your banner so that No one really sees the bad stuff that's happening That's horrible So don't put historical discussion Or relevant descriptions Or details in your comments Yeah

No problem there I might have done that once or twice I mean nobody's counting 43, but if we were. If you start punctuating your comments, then here's your sign. Here's your sign. All right. Don't write too much information in your comments. That's what I just said.

The comment should be easy to connect to the code it's describing. That's what we just said. Put it next to it. I feel like we've already covered these function headers. Yeah, we're there. Only use Java docs. A well-named function is better than a comment header, which, yeah, I mean, I want to agree with,

but going back to the packaging comment, that's the only place where it's like, who was it that wrote in that said that these are best practices and not necessarily the way you've got to do it all the time? Because if you're going to package this thing up, I do like to have the ability to export out that API documentation for others to consume. Yeah, I think the rule of thumb is just what you said. If somebody else is going to consume it, then you should probably have those comment headers.

If it's just code that's going to be used, it's never shared, nobody else is ever going to interface with it, fine, don't do it. But if it's going to be used... Well, I'd be careful about the interface because somebody else is always going to be helping you maintain it

or maintain it after you leave or whatever. Yeah, but it's not a pluggable feature, I guess, is kind of what I'm getting at. Packageable feature. Yeah, packageable. How about if we phrase it like that? Yeah. So we're down.

We're done. And by packaged, I mean that if it's going to be shared without the source code, it's only going to be distributed as a compiled package, then that's where I like to have some of that documentation. But again, in the places where it makes sense. If you have a two-ring, I get it. I know what that does. You don't really need to comment that to the nth degree

as to what it does and tell me about the history of string concatenation or toString functionality or whatever. Right, right. So we're down to the resources we like. Do we like clean code? Love it. Sweet. I did until we started doing this book.

It's in the description now. Now I'm done. I don't like it anymore. This will not be in the resources we like. I'm joking. So, yeah, we will totally have a link to that in our show notes. And now we enter into Alan's favorite portion of the show. It's the tip of the week.

Yes, sir. And I believe you're leading off this go around yeah buddy so i don't really know how to classify this one i'm gonna classify it as a tip of the week but it's also kind of like a a correction though because in the episode 48 last episode you gave a tip where it was something along the lines of hey if you ever wanted to see i forget how you phrased it if you ever wanted to see like the files that have changed uh that that are in your you know that are in your repo but you don't want to see maybe a bunch of other stuff because like in your example, some other third-party framework where, in that example, you're not just taking in a compiled DLL, one DLL. You're taking in their source.

So think of maybe some JavaScript framework and you're bringing in a bunch of their code. And you want it in your repository at the part of that commit just so that others can build it, whatever. Whatever your reason is, you have it in your repo, like it or not. And so you have this command that was something along the lines of, hey, do a git diff dash dash cached dash, I don't even remember all the parameters.

Name only. That was pretty much it, yep. Yeah. So I got a much easier way to accomplish that. And I apologize that this didn't even dawn on the parameters. Name only. That was pretty much it. Yeah. So I got a much easier way to accomplish that. And I apologize that this didn't even dawn on me when you said it. So I apologize for that. But yeah, dude, you could just totally do a git status. You could do a git status in the path that you care to see,

and it'll show you only those changed files. So yes, that would work. The problem I had, though, is I had files in multiple different directories at different levels. And so the issue I ran into is unless I wanted to do each one individually, I wanted to be able to run one. So I initially tried to do a get status. And the problem is all the files, basically, I deleted a bunch of files from a repo. And so they all showed up and they blew everything out of the cache now here's where every linux shell guy is going to be like wanting

to slap you around too because you could have just as well just done your normal get status without passing in a path and then pipe that to a grep minus v and then exclude whatever regular expression pattern you want interesting and still seeing your changed files right but the point is is that um you know you can just add the path to a lot of git commands to just see that portion of it so you know kind of going following on or adding on to your tip from last week if you do a git status in a particular directory path then you'll only see those changed files in that particular path that you pass in if if you are trying to narrow it down and similarly um you know other examples

where this could be used is you could do um some might you might normally just do a git status and no other commands you could also do the same for diff you could just say git diff and it'll show you a diff of everything that you've changed and if you've changed a lot like in your case that might be too much so you could say hey git diff and path and include a directory path and then you'll see only a diff of the file or files that have changed in that path and adding on to that suppose you want to just add the files in that path to stage them for your next commit you could say get add in that particular path and it'll add it'll stage them for your next commit now specific to the ad you can get a little fancy if you wanted to, and you could wildcard it,

right? Now, if you just do like, let's say, let's say that you had all of your SQL related, because Joe loves SQL. So let's say that you had all of your SQL sql related files in a directory called sprock and uh you were to do a git diff sprock slash and you're like oh okay yeah i want to add all those and you did a you could do uh a git add sprock and it would and it would just add all of the files that have changed uh they're in that directory to uh to your staged area, if you want to call it that. But you could also do things like sproc slash splat dot SQL if be aware be aware that git add will warn you if doing splat in that scenario would add files that are otherwise considered to be included like maybe in that sprock directory there's a dot folder that would typically be hidden and ignored by your git ignore file but because you try to do a git add splat on that

particular directory it will warn you hey i'm sorry we can't get add this because you are attempting to add things that are um that that are supposed to be ignored but you're so it will warn you with a dash a yeah you don't do that, man. You can totally do that. No, no, no. Well, you're thinking of just like a get add dash A. Yeah. Without a splat. Capital A.

And that's dangerous. It's not recommended. I'm a big fan of you should... I'm a big fan and believer and practitioner of when I do my commits, I specifically review the individual files and specifically stage them independently. You know, I don't just get add everything and then commit everything or, or even worse, I don't do like a commit dash ma where you are staging, where you're adding the commit message and adding everything at the same time. I don't do that either

just because of my own fear that I might commit something that I didn't mean to commit. Sweetness. Who's up next? That's you. You're going to give us another website that's not available, aren't you? I am. Did you see that?

I was joking, man. going to give us another website that's not available, aren't you? I am. Did you see that? Oh my gosh. I was joking, man. I think DynamicDNS is down again. Code Wars is down. Oh, really? Yeah. It looks like there's a DDoS thing going on. I was really just hitting this to make sure everything was cool.

It looks like we're recording at a time when sites are under attack again. You know what? I hate to say this, but this really kind of sucks. This is sort of what we're in now, right? People do these kind of – it drives me crazy. But we don't want them mad at us and taking us down. So if that's what you want to do in your free time, I mean, hey, it's not for me.

I don't think we'd be all that difficult to destroy, right? Oh, yeah wait wait wait no he's totally that's not at all the case right right so moving right along so all right so my tip was and this i i'm really kind of upset because you guys would really love to see this so we talked about docker a little while ago one of the cool things that this company did and it's i can't even remember who they're a subsidiary of or broke off of um but there's this site called hyperdev.com and we'd talked about you know how would you go about learning something or teaching your kids like this conversation's come up a lot in slack like uh people have asked, hey, what should I get started with? Dude, HyperDev.com is amazing. You don't have to worry about all the minutia

of setting up an environment like your server, your client stuff, all that. You go to HyperDev.com, and there is an online IDE, and when you hit run run it sets up your server runs it and you actually have a site that you can go back to so let me ask you a couple questions this isn't down they're just doing maintenance

on my for what I see so my next question is or actually my first question is so are you saying that this is like a docker container that would run locally on your system? On theirs. It's in the cloud.

So it might be Docker on theirs. It might be a virtual machine. I actually listened to a podcast where they were talking about it. Oh, okay. So it is using Docker in the background. Yep, it's Docker. And so the reason they did that is the very reason, I don't know if we've talked about it on this show, but one of the reasons to use Docker is unlike a VM where you have to provision, you know,

eight gigs of RAM and two virtual CPUs or whatever, like that's what that particular virtual machine is going to use. With Docker, you could have like 16 gigs available, but spin up, you know, 50 Docker containers and give them each a couple gigs. Well, if I could restate that, just maybe to make it more clear or not, if you wanted to spin up 100 VMs that each had one gig of RAM, and you wanted to spin those up concurrently,

as each virtual machine would come up, they would grab a lock on that RAM, meaning that your host OS would have to have a minimum of 100 gig plus whatever it needed in order to run those concurrent VMs. Whereas in Docker, if you had 100 Docker instances that you wanted to run concurrently that each needed a gig of RAM, because they're sharing the resources in the RAM, they wouldn't grab a lock on that one gig.

They would only use what they needed at the time. So in practice, you may find that you only needed, say, 60 gig available for all of those instances to run concurrently. Yep, totally. And that's just a weird example, assuming, you know, but it's one that everyone can like easily, it's easy to picture that example. It's kind of elastic resources, right?

Like it'll grow up to what it needs and then shrink back down to what it's using. So HyperDev is using, so you're saying that HyperDev is using Docker in the background, but you could say like, hey, I need to have a linux nginx uh server to play with they'll spin up a docker container no it's easier or instance for you easier than

that so it's basically like no js basically you have your ide up there you can just start coding javascript and then when you're so like in the browser editing like a js fiddle yes yes very similar except you can create an entire application and and when you're done, you hit play, and you now actually have a site on the web, and it's free up to so much RAM or whatever kind of usage, and then if at some point it starts getting popular, you can pay to have it scale out.

Oh, this thing actually stays around. Yes, dude, that's what's amazing. So they spin this Docker image up and leave it up, and it stays. Yep. Holy maintenance nightmare. I don't want to think about that. Well, the cool part is, right, if it's not using any resources, it's not really doing anything.

That's true. But I was thinking about it from the, like, they're in a maintenance window right now. They've got to know all the Docker instances that somebody wants up, somebody wants running. I wonder how they do that. Are they letting the instances die and then spinning them back up on the fly? This is also going back to Docker versus VM.

One of the big pros to Docker versus virtual machines is because there's not that virtualization of the hardware where you have to actually like put a lock on things to you to to have your dedicated resources um in the docker world because you're sharing all this it spins up in seconds compared to a vm might take a minute or so to actually boot up right you actually have that boot sequence yeah it's not even really spinning up right it's just sharing the resources yeah it starts a process it's just a process yeah it's it's really cool and it hurts me that this is not working right now because i mean it's again it's pretty amazing like their whole they're kind of going for the freemium thing like a lot of places

do now to where hey come in here and play get hooked on it you create something and now you need it to grow. All right, start paying us a fee, which is not terrible, right? At least you can get started. That's pretty neat. It's too bad that you gave a tip that we can't verify. It's so frustrating, man. I had actually clicked it when you were talking,

and I was like, why is it not working? Because I would totally do some OAuth with this thing because there was this other resource that was about OAuth. Oh, wait. Oh, man. That hurts, doesn't it? Sorry. So hopefully this thing will be up

whenever you guys get in here. But yeah, right now I'm a little... It's Joe's fault. I'm going to go with that. All right. Yeah, I got that Python book on penetration testing and I've been trying out a couple sites in the show notes.

Nicely done. Thanks for taking me out. You have no problem. My tip is an open source Visual Studio extension. If you're using Visual Studio, you should check this out. It's free. It doesn't just work for C Sharp. It also supports

C++, F Sharp, VB, PHP, a bunch of other stuff. Less SAS, it also supports C++, F sharp, VB, PHP, a bunch of other stuff, less SAS, stuff like that, JavaScript, TypeScript. And it's got a lot of really nice features, like code cleanup, comment formatting, which is a big no-no, according to this episode. There's just some other cool stuff,

just some really nice refactorings. And one of my favorite things is it actually adds a little progress bar down near the like the windows the Visual Studio, what do you call it? Like the button? You're doing a great job. Keep going.

I'm really enjoying your use of words. I'm sorry. When you click on Visual Studio, right, and you're in Windows, it puts a little icon down in the taskbar. What is that called? The icon down in the taskbar. Like is that called? The icon down in the taskbar. Like the app icon maybe? Something like that.

Okay, well, when it's building, you actually see the little green bar moving from left to right. And so it's nice because you can actually go browse around and do some stuff and you can still see the steps. Like from left to right,

like Knight Rider? Like it goes back and forth like Knight Rider? Not at all. A progress bar. Like a progress indicator. It shows the progress of your build. So you can see without actually going over visual studio that oh i've still got some time on my build or my build is done i can get back to work i thought there was like a michael knight option to this thing oh wait i follow you and i'm actually excited about it now

that i've i think understood what you said so right now like if you hit build a visual studio it's sometimes it just goes away and you don't even really know if it's doing anything right and you're like the bottom right you know it's like you have to have visual studio open so if you're like okay this build's going to take two minutes unless you're going to sit there and watch the thing you're you know you're going to go check email or whatever respond to some stuff but in this way uh in this case um it changed that icon in your taskbar so you can actually see the progress indicator right there so you don't have to go back to visual Studio just to see if your build's done.

I like it. Now I feel kind of bad for putting you on the spot like it does. That's all good. Those were some amazing words. I really enjoyed that. I want to relive that. You're welcome. That's what we do.

Just driving the bus. Yep, yep. This has been a long episode, guys. Well, the reason I mention this is it's got a code reorganization feature that lets you do stuff like automatically sort methods and members based on Microsoft Style Cup Convention or Alphabetical Order or Privates First, whatever. And so it's got some really nice features for doing that sort of thing and that's why someone recommended to me unfortunately i'm a jerk and i didn't get the name and so if you uh say something in slack or messages and let us know

that it was you then i will apologize to you personally and send you some stickers that's awesome yeah um free yeah i'm totally curious to see because, okay, so we've maybe talked once or twice about my love affair for ReSharper, and it shares a lot of functionality with this. So I'm curious to see a comparison of one versus the other. Does code made in terms of formatting beat it out because i'll tell you i have seen resharper do some cleanup that i'm like whoa i wouldn't have done that ever like i'm very selective about the some of the cleanup that i'll let resharper do i

i uh maybe once in my entire usage of resSharper have I dared to say, like, you know what, just go ahead and clean up this entire file. Right. But I have definitely not thrown it at entire solutions or projects and be like, you know what, just go wild. I trust you. Yeah. You know what's nice, though?

It's got a shortcut, too, for join lines. So if you've got, like, say, you know, a getter setter kind of thing going on and the get takes three lines and all those return a variable you just select all control m j and then it just smashes those guys into one line nice but what do you mean smashes into one line like one line that's like uh does this thing semicolon does that thing does semicolon then like what do you know it'll do that too but i'm talking about like talking about like a getter. So you've got get, bracket, return, my variable, bracket. You know, it's four lines and it's only doing one thing. So I want to, you know, control MJ, done.

Yeah, I like that. So does it have the feature to sort based off the use, which is what we talked about last time? Well, he said the StyleCop versus alphabetically. But StyleCop, that was what you were talking about, bringing the privates and the publics together and all

that. Is there the thing of, because what we talked about. The newspaper. Yeah, being able to, this uses this, this uses this. Does it do that? I'm still trying to figure that out. It's got some custom rules that you could set up for how to sort things. i'm not really sure if that's an option i'm not seeing that one specifically i haven't found it uh when i mess with it either so i don't know yet i'm curious about going back to your joining example though like um and again only because i have more

experience with resharper and none with codemade because resharper will do that automatically like there you don't need to do a keystroke for that uh like as you're typing it if you were to type it out as uh individual lines and you put in that last curly brace and it realized oh you're not really doing anything it'll just boom format it back up into one it'll collapse it so does does codemade do the same thing is it like watching as you're typing and like making formatting changes? I've only barely experimented a little bit and I did not notice that, but I might've just missed it. I'm,

you know, maybe I was just used to it though. But I will say, one thing I didn't mention is it's got like a little window that shows the methods, but you can actually rearrange them there too. So you can go ahead and drag this guy underneath that one, this one,

that one, that one, that one, and it actually will do it in the code, which is really nice. Ooh, that is nice. Wait, say that again. So in like a,

you know, like the dropdown, it sounds like in the dropdown, like where it shows you your methods and visual studio, he's saying there's a window there that will show you all the methods. And you can drag them around in the window itself and it'll rearrange your code in the file. Yep.

That sounds horrible. That's amazing. Because the window is and it'll rearrange your code in the file yep that sounds horrible that's amazing because the window is already alphabetical no no no i wasn't trying to make a joke i wasn't trying to be funny but it honestly is though right like are we talking about the existing like the solution explorer no the new one the code made window oh it's got so it so it has its own like solution explorer type view it's for the file so it shows you all the methods in the file and the – In whatever order they're in. Exactly. And you can go ahead and say, you know what?

I want all my publics at the top or you can say I want to rearrange these alphabetically. But you're saying you could do it manually and just drag them around in this code made Solution Explorer window and it would rearrange them? Yep. I like that. Okay, I might be installing this and playing with it. That's pretty nice. And it's on GitHub, so you can contribute. Sweetness.

All right, then. All right. Well, I guess somebody's going to have to add in the ability to do newspaper sorting. Oh, sorry. It sucks. No, you don't have to. We don't need it. All right.

So I think I've said all I need to say. So guess what? We've talked about chapter four, chapter whopping four of Clean Code. We're really progressing fast on this. And, you know, I hope you're able to keep up with this fast-paced topic and done by the year 2020 i'm pretty sure yeah well there's no way we are not going through this

entire book no way there's no way it'll take forever um if you hate this then we've only gotten good feedback about it so if you hate it you should leave us a five-star review and then email us to let us know why you hate it. Definitely email the hate and share the love. That should be a saying. Share the love, email the hate. That's going up at the top of our site. Right, right. Coding Box, share the love, email the hate.

Star the love, email the hate. Make sure you do leave us a comment at www.codingblocks.net slash episode 49 for your chance to win your choice of either a copy of Clean Code or a license to PostSharp Ultimate. And in case if you heard this episode because a friend let you borrow one of their devices to listen to it or they pointed you at our website and you heard it that way or you found it from some Reddit article or whatever, hey, now you've heard it. So be sure to go on to iTunes or Stitcher or whatever your favorite podcast app is and subscribe to us there. And leave us a

review. We like reviews. We have handy links for you at www.codingblocks.net slash review, where you can leave us a review for your favorite platform. Yep. And as you said, visit us at codingblocks.net. You'll find all our show notes for this episode and many others,

examples, discussions, and more. Yeah. And send your feedback questions and rants to our Slack channel. blocks.net you'll find all our show notes for this episode and many others examples discussions and more yeah and send your feedback questions and rants to our slack channel uh codingbox.slack.com and uh follow us on twitter at codingbox or head over to codingbox.net and you'll find all sorts of links including maybe one to github yeah we need to add that in there i'm sure that we'll get that done at some point in time. All right. Now, I got to go to the potty.

All right. Well, that was more than we needed, isn't it? Sweet. Yeah. Sorry, I've been a little testy for the last 45 minutes because I got to go to the potty. Is that what it was? You haven't been testy. I'd like to have a quick conversation with you real quick, sir. I'm surprised you didn't just go to the potty.

That's right. The benefits of working from home. You know what I want to discuss, though though is why is a grown man referring to it as the potty that just sounds wrong uh we're rated g