I hope you like those tips! If you want to install the Refactoring Extension in VS Code or PyCharm, you can check it out here: sourcery.ai/? * ---------------------------------------------------------------------------------------------------------- * This is an affiliate link. By clicking on it you will not have any additional costs, instead you will support me and my project. Thank you! 🙏
Good tips, thanks! Personally, I don't like returning an expression directly without assigning to a variable. When you use a variable, it is easy to add a breakpoint without refactoring if you need to see the value before it is returned.
It is as easy to add a breakpoint to a return statement even without a variable and evaluate the expression in a debugger, at least in a decent IDE. I don't think adding variables just for that is approved. Readability, on the other hand, is discussable.
Thanks a lot! Tips about "any" statement, assigning variables closer to their usage and guard statements to remove excessive indentation were very nice.
3:50 you can also inline the current_fashion local variable and rename the getter method, as well as getting rid of the else statement as the second if statement can also serve as a quasi-guard clause
I'm trying to become a data engineer and Python is my first coding language. My goal is to improve my programming skills and this video is super helpful to me.
Thanks for those tips, they are great! I have been refactoring a lot of my code lately, guess it shows I am progressing 😀 So refactoring tips: YES PLEASE! Great vid format as well 👍
3:57 I actually disagree with this one. Just checking the truthy-ness of a list is not always what you want. None is also falsy and is also recommended to be checked like this. What if you have a list that might be None? You now can't tell apart None and the empty list. Or, what if you have a list that shouldn't be None? If a None value makes it into your function somehow, it will be treated as if it were an empty list. It should just throw an exception instead, being given an invalid value. I always use "is None" and "len(x) == 0" checks to make it clear what exactly I am checking.
@@patloeber Yeah I gotta jump in here with Random... To you and Yndostrul, from a newb, when will I have a list that is None? A little lost, even a simple example would help if you have a moment...
@@TheJacklwilliams random's argument is not very pythonic. more often than not we would want to default a list variable to None instead of [] bc how python evaluates its default arguments (e.g. def func(a_list=None)). It's very common to have a list that's None; and in this case, if we want to treat None and [] the same in a single condition, it's perfectly fine to write "if a_list:"; but if None and [] deserves their own case we would wanna be more explicit about checking "len(a_list) == 0" for the [] value.
@@dl662 Thanks Derek. I’m a complete newb and doing all I can to start out with good habits. Being pythonic and doing things in an optimum fashion are top of mind for me. I appreciate the explanation. Thank you.
Update: any(generator) --> Stops at the first true result of the generator, without processing the rest. Which is very useful and something I'm glad I now know Original comment: Can someone run that any( check I believe the whole generator is first evaluated then any checks the result. If so this is not what you want on most large datasets
I prefer to only have return per function, it's much cleaner and easier to debug. Returning results as the var IMO is best practice. It allows you to easily debug and read the code output = 'hello' * 2 return output #> 'hellohello' That advice is only true when dealing with large numpy arrays where creating the variable is time consuming.
For number 5 (if expressions), then I think the if expressions can simplify code assuming that the code is not too long. For your example, I think that the shortening does not make it less readable. However, for if-else statements with longer assignments and conditions, the shorthand if expression can make the readability go way down (this is the same problem that long list comprehensions have). There is also the disadvantage that programmers from other languages can find the syntax a bit weird (although ternary operators still exist in e.g. JavaScript). I've purposefully avoided using the if expressions in my videos since I am not sure that everything knows about them. However, I think it would be good if more people knew :)
I have no idea why but I have always been doing these 8 things. I'm not even a good programmer but I guess a lot of trial & error gives you a bit of intuition about what seems more readable.
I write nested if expressions and have written a nested list comprehension which was 3-4 levels deep, can't even debug it anymore, it just works and no one knows why now.
Why would you want to touch it, if it works? Unless you need to change it to accommodate new functionality, in which case it's better to rewrite it from scratch, leave it alone. Only amateurs mess with working systems.
For #6 since you aren't computing anything inside the if statements, you can also just do return weather.is_raining or is_stylish Does this make sense to others?
For me the first variable would be my 'default' condition, then the subsidiary conditions would be tested against. I.e. you are taking in a multi-line file and depending on the data you output it into different files. The default setting for a line of data would be "unknown record type", then I see if the record fits into a condition. If the record never fits any of the conditions, that record gets tossed into an "unknown format" file for the user to figure out, and if needed add more conditions to the program
These are all style fixes that do not affect readability or function. Are you changing working code just to satisfy your subjective sense of beauty? Please don't work for me.
I hope you like those tips! If you want to install the Refactoring Extension in VS Code or PyCharm, you can check it out here: sourcery.ai/? *
----------------------------------------------------------------------------------------------------------
* This is an affiliate link. By clicking on it you will not have any additional costs, instead you will support me and my project. Thank you! 🙏
Really high information density on these vids. Very nice and not often seen.
thank you :)
3:35 Tip #5 can be applied one more time. You can avoid the "else:" and corresponding indentation as you just returned in the previous if section.
yep thanks for the hint!
Good tips, thanks! Personally, I don't like returning an expression directly without assigning to a variable. When you use a variable, it is easy to add a breakpoint without refactoring if you need to see the value before it is returned.
Good point! Yes this point is debatable, too :) I also like to use the variable in certain cases
It is as easy to add a breakpoint to a return statement even without a variable and evaluate the expression in a debugger, at least in a decent IDE. I don't think adding variables just for that is approved. Readability, on the other hand, is discussable.
I can to make the same comment. It's easier for debugging
Thanks a lot! Tips about "any" statement, assigning variables closer to their usage and guard statements to remove excessive indentation were very nice.
Thanks for these helpful tips. I'll start using them asap
3:50 you can also inline the current_fashion local variable and rename the getter method, as well as getting rid of the else statement as the second if statement can also serve as a quasi-guard clause
Great advice, did not know "any" . Thanks a lot
Nice! I didn't think of some of these, good tips.
#4: `var=something; return var` has its place: debugging.
Thirst for learning . This channel is a good one to quench
I'm trying to become a data engineer and Python is my first coding language. My goal is to improve my programming skills and this video is super helpful to me.
Hi Patrick,
Great video as always! Thanks for sharing your knowledge!
Also, your new Website design is outstanding. 👍
Beste Gruesse,
Sven
Thank you! Just noticed you have a channel, too. Great work :)
Thanks for those tips, they are great! I have been refactoring a lot of my code lately, guess it shows I am progressing 😀 So refactoring tips: YES PLEASE! Great vid format as well 👍
3:57 I actually disagree with this one.
Just checking the truthy-ness of a list is not always what you want. None is also falsy and is also recommended to be checked like this. What if you have a list that might be None? You now can't tell apart None and the empty list.
Or, what if you have a list that shouldn't be None? If a None value makes it into your function somehow, it will be treated as if it were an empty list. It should just throw an exception instead, being given an invalid value.
I always use "is None" and "len(x) == 0" checks to make it clear what exactly I am checking.
fair point! Checking for None and falsy can indeed be a pitfall in certain cases. I should have pointed this out...
if you have a list thats "None" then you dont have a list, why would you design your code like that?
@@patloeber Yeah I gotta jump in here with Random... To you and Yndostrul, from a newb, when will I have a list that is None? A little lost, even a simple example would help if you have a moment...
@@TheJacklwilliams random's argument is not very pythonic. more often than not we would want to default a list variable to None instead of [] bc how python evaluates its default arguments (e.g. def func(a_list=None)). It's very common to have a list that's None; and in this case, if we want to treat None and [] the same in a single condition, it's perfectly fine to write "if a_list:"; but if None and [] deserves their own case we would wanna be more explicit about checking "len(a_list) == 0" for the [] value.
@@dl662 Thanks Derek. I’m a complete newb and doing all I can to start out with good habits. Being pythonic and doing things in an optimum fashion are top of mind for me. I appreciate the explanation. Thank you.
Python Engineer, you are amazing!
Update: any(generator) --> Stops at the first true result of the generator, without processing the rest. Which is very useful and something I'm glad I now know
Original comment:
Can someone run that any( check
I believe the whole generator is first evaluated then any checks the result.
If so this is not what you want on most large datasets
I prefer to only have return per function, it's much cleaner and easier to debug.
Returning results as the var IMO is best practice. It allows you to easily debug and read the code
output = 'hello' * 2
return output #> 'hellohello'
That advice is only true when dealing with large numpy arrays where creating the variable is time consuming.
Great tips. Thanks
Well balanced information. Concise. Thanks.
Glad you like it!
Excellent video. Thanks!
thanks for watching :)
Thanks for the 8th tip, it is useful.
Actually, your all tips are great and useful, Nice tips
Glad it was helpful!
Definitely prefer a simple if-expression over an if statement for a simple assignment.
For number 5 (if expressions), then I think the if expressions can simplify code assuming that the code is not too long. For your example, I think that the shortening does not make it less readable. However, for if-else statements with longer assignments and conditions, the shorthand if expression can make the readability go way down (this is the same problem that long list comprehensions have). There is also the disadvantage that programmers from other languages can find the syntax a bit weird (although ternary operators still exist in e.g. JavaScript).
I've purposefully avoided using the if expressions in my videos since I am not sure that everything knows about them. However, I think it would be good if more people knew :)
Love the new video! 🔥
Glad to hear that!
I have no idea why but I have always been doing these 8 things. I'm not even a good programmer but I guess a lot of trial & error gives you a bit of intuition about what seems more readable.
Nice. Subscribed!
thank you :)
Patrick, just subscribed too your channel. Love your work. I waa trying to find out where you're from. You sound Canadian ie Letterkenney vibe.
Haha thank you so much! I am German ;)
these are true for any language, but good tips indeed
I write nested if expressions and have written a nested list comprehension which was 3-4 levels deep, can't even debug it anymore, it just works and no one knows why now.
Why would you want to touch it, if it works? Unless you need to change it to accommodate new functionality, in which case it's better to rewrite it from scratch, leave it alone. Only amateurs mess with working systems.
python is beautiful than javascript but ilove them both xD nice video!
1:35 that's what type annotations and docstrings are for...
I have always found the "pythonic" version of code to be non intuitive. I like the traditional if statements.
Why not use python black directly?
Is sourcery and such extensions as copilot, recommended for a junior developer with 4 months experience?
I don't even use Python but I am a simple man, If you upload I watch 😎
Haha thank you Robert, I don't use Flutter but I also watch a lot of your videos :D I can learn a lot from your video style!
You should definitely do more code refactorings
thanks for the suggestion :)
thank your tips, your code font is also beautiful, i like it, Can you tell me which one font?
For #6 since you aren't computing anything inside the if statements, you can also just do
return weather.is_raining or is_stylish
Does this make sense to others?
what theme do you use for the ide?
Material theme
Which VS Code Theme you are using Sir?
Dracula!
@@patloeber Thanks for Quck Reply!
Quick Python Refactoring Tips (30 Second videos): ruclips.net/video/D4xLPfetZRY/видео.html
Sir, Please bring a series of #pywebio with best web app examples.
#5 How about:
x = 1
if !(condition):
x = 2
#7: last else is unnecessary.
yep that's another good option 👍
For me the first variable would be my 'default' condition, then the subsidiary conditions would be tested against. I.e. you are taking in a multi-line file and depending on the data you output it into different files. The default setting for a line of data would be "unknown record type", then I see if the record fits into a condition. If the record never fits any of the conditions, that record gets tossed into an "unknown format" file for the user to figure out, and if needed add more conditions to the program
Nice.
thanks!
more pls.
I try to come up with some more :)
I follow every tips except the inline condition due to readability and any(list) because I forget 😂
Nah, just right click on random code and click your IDE's "refactor" button and trust that your code is better. I'm a profession programmer.
Huh, I refactore my code alike.
When You're First So You Don't Know Wut To Comment 🤔...
haha :D
@@patloeber Omg Thx Soo Much For REPLYING!! I'm a Big Fan Of U And Uve REALLY Helped Me With PyTorch!!
TYSM
@@SamrudhSwaminathan Thank you! Glad you like it :)
First don't use classes in python and all is fixed.
These are all style fixes that do not affect readability or function. Are you changing working code just to satisfy your subjective sense of beauty? Please don't work for me.
Yep. You can tell that it's amateur hour. Worse, it's amateurs with OCD.
One line if statements should be forbidden.. it is so unreadable, ugly.. nah no thanks man.
why u gotta sound like that bro