#100DaysOfCode in Python Transcripts
Chapter: Days 34-36: Refactoring / Pythonic code
Lecture: Refactoring 10: quality code best practices

Login or purchase this course to watch this video and the rest of the course contents.
0:00 Alright number 10, bonus, the last refactoring item. I'm just going to talk over some general coding best practices
0:08 because of course Pythonic code is important and pleasant to read but it's often also a matter of sticking to the best of role coding practices.
0:17 For example, make sure your units of code are short. Typically, a function or method should be around like 10, 15 lines max.
0:27 It can be very Pythonic but if you start to write functions of hundreds of lines of code, it's not good. It's not easy to maintain.
0:34 So this is your 10 guidelines to make your code more maintainable. Some other ones I want to highlight here, write code once duplication is a monster.
0:43 You really want to prevent having the same code defined in multiple places. Keep unit interfaces small, so that
0:50 means when you have functions the number of arguments to get if you keep that to a reasonable level, it's easier to maintain.
0:57 For example, if you have a function that takes 10 arguments, not easy to maintain. You could consider passing around a
1:04 class or refactoring to a class modules. Again, that's the part of name spaces of the Zen. It's good to have similar behaviors
1:13 or similar objects grouped together in files. To not have one file holding 10 classes, split those out in files, right?
1:21 Which makes it easier to reuse them in other programs. Testing of course, you want to automate your testing
1:28 that when you make changes you have this regression suite that you can just run in seconds and highlight if you introduced a new failure.
1:36 Which, if your system becomes more complex, might happen. This is an automatic way to catch that and keep the quality of your software high.
1:44 In day 10 you learned about pytest and how to write tests so that's really important here. There's also a lot of habit around this
1:51 so if you get into the habit of writing clean code, keeping to high standards, it means that when you go into your code base, you leave
1:59 the campground cleaner than you found it, right? I love the anology in the pragmatic programmer book about having a small crack in
2:09 a window if I remember correctly? Leaving that unattended leads to broken windows and the same is true for your code base.
2:17 If you let small bad habits creep in it might actually lead to a lot of damage in the long term. It's really about having good habits
2:25 around writing clean code, run the PEP8 checker on your codes, see if it's formatted properly, the right conventions are used, etc.

Talk Python's Mastodon Michael Kennedy's Mastodon