Learn more and get started by visiting talk python FM, slash tie pie that's Tai PY. The links in your show notes. Thank you to tie pie for sponsoring the show. And it's right functions that are ten line ten, ten lines long, not a hundred lines long. Now, I like to hear your thoughts on this, but my feeling about all of this stuff is as a general rule this is what you should do. There will be situations where you might, you know, this is just, I can't think of something better or it's way over the top to try to adhere to all of these rules within the small context. I could tell you on the talk python training website, there's a couple of places where it's like 75, 80, 90, lines of code for a single function, just like this is so bad. I wish it wasn't like this, but it's just weirdly unique and but there's, you know, 19,000 other lines of code that are all three lines, 5 lines, type of thing, right? So it's for me, at least this isn't a 100% or you're doing it wrong. It's 98% or 95% of the time. You should be doing this that are maybe some weird case and how do you feel about that in general on these topics? Yeah, as I said before, sometimes you just don't get the resilience and design right from the start. So inevitably you're going to write some longer classes or functions. But then when you break them out and smaller units, the other thing you have to say about that is it gives you an opportunity to do better documents because in this example, if you break this lung function that's doing three things out into three separate functions, parse CSV, build up list, bad name, but you get the point. And print results, then all of a sudden we have three units now and every unit has a name. Hence when you go back after a year and look at that code, which always happens, and you always wonder. How about the heck was I thinking? Now you had a glance just by looking at the function numbers. You have just already a better idea dysfunction. You can give duck strings as well. So at a glance, you have just a much easier time figuring out what this was about. Yeah, I appreciate you actually gave a shout out to me in this first piece here, which I didn't expect, but one of my rules, I see in this article you referenced Martin Fowler's refactoring book. And one of the most important things that came out of that is not all the refactorings, but this idea of code smells, right? And maybe tell people real quick about code smells. Yeah, that's a funny name, right? Code smell. I hope that is smelling and analogy. I came up with. But yeah, basically, it's code that's not following these best practices. And it's just not maintainable, not easy to extend going back to these principles we mentioned. So yeah, not following these guidelines that code can be smelly. It can be as code smell. Well, the idea is it's not actually not working. It's just not nice. You know, you kind of turn your nose up at it when you see it, but you can't say it's broken because it is working. But it's a good point. It smells a little bit off, right? It's not quite broken code, but it's sour. I don't know. And so the reason I bring this up is one of my rules of thumb here that I love. And I think you're kind of hinting that with this little shout out that you gave me in this article is when we come across these code smells often, especially when you're earlier in your career, often the reaction or the first thought is, you know, this part is not nice. This part is complicated. This part is hard to maintain or hard to understand. So I need to put a nice comment. I've been told, comment your code, don't be a jerk, comment it. So I'm going to put a big comment that describes why it's really bad. And all that. And in the code smells sort of world. These code comments can be seen as deodorant for the smell. Like it doesn't remove the smell, but it kind of obscures it's not as bad if you saw the comments saying why the code that follows is bad, but maybe you could just make it not need a comment and a lot of times you just said that's, well, these 5 lines of code need an explanation because they're mixed in with all this. But if they had a function that had a name whose name was basically the comment, well then you don't need a comment because the name is the comet and it's now small and understandable, right? Like there's a lot of these little iterative things that go on. Exactly. Yeah, that's a great point and it's very easy to make that refactoring just turn the comment into a function and we have created another unit we can extend, we can test, et cetera. So yeah, it's interesting because there are kind of mixed feelings about commands. Some people say ferocious commander code but mostly in their literature literature I'm reading that commands are actually not that good and sometimes even labeled as a code smell in the sense that your code should be kind intuitive. I think it's going back to that half of the time when people are actually putting those comments. It's because there's something kind of messy and they're trying to help you get over that mess or deal with that mess. Right. Rather than just fixing the mess, you know? Yeah, it might be an indication of a bad design, right? Yes, exactly. You might even have to go back to the drawing board. Yeah. But that said, I definitely see a place for commands where sometimes you just want to remind yourself. And of course, you're a team members, not what to code is. They can read the code, obviously, but why you took that decision, but there might just be some extra context that you need to give. Yeah. And that's also different than Doc strings, potentially. Which is kind of a form of a comment, but it's meant to talk about the API and not cover up some weird thing you had to do in the middle. Exactly. Yeah, docstrings are basically your API documentation. Yeah. Exactly. All right, well, good stuff, I mean. Even GitHub co-pilot and those things are starting to use these comments as a way to say, well, I'll just make a function that kind of is named what the comment is.