The Ultimate Guide to Writing Functions
Vložit
- čas přidán 21. 07. 2024
- Over the years, I’ve seen a lot of code by different people, and my conclusion is that writing great, well-designed functions is difficult. So, I made this guide, which includes the 7 most important things you should do when writing functions.
👉🏻 The code I worked on in this video is available here: github.com/ArjanCodes/2022-fu...
🚀 Next-Level Python Skillshare Class: skl.sh/3ZQkUEN
👷 Join the FREE Code Diagnosis Workshop to help you review code more effectively using my 3-Factor Diagnosis Framework: www.arjancodes.com/diagnosis
💻 ArjanCodes Blog: www.arjancodes.com/blog
🛒 GEAR & RECOMMENDED BOOKS: kit.co/arjancodes.
👍 If you enjoyed this content, give this video a like. If you want to watch more of my upcoming videos, consider subscribing to my channel!
💬 Discord: discord.arjan.codes
🐦Twitter: / arjancodes
🌍LinkedIn: / arjancodes
🕵Facebook: / arjancodes
📱Instagram: / arjancodes
👀 Code reviewers:
- Yoriz
- Ryan Laursen
- James Dooley
- Dale Hagglund
🎥 Video edited by Mark Bacskai: / bacskaimark
🔖 Chapters:
0:00 Intro
1:11 Tip 1: Do one thing and do it well
5:17 Tip 2: Separate Commands from queries
6:53 Tip 3: Only request information you actually need
9:27 Tip 4: Keep the number of parameters minimal
14:55 Tip 5: Don’t create and use an object in the same place
17:24 Tip 6: Don’t use flag arguments
19:59 Tip 7: Remember that functions are objects
22:56 BONUS: Tips for naming functions and parameters
#arjancodes #softwaredesign #python
DISCLAIMER - The links in this description might be affiliate links. If you purchase a product or service through one of those links, I may receive a small commission. There is no additional charge to you. Thanks for supporting my channel so I can continue to provide you with free content each week!
👷 Join the FREE Code Diagnosis Workshop to help you review code more effectively using my 3-Factor Diagnosis Framework: www.arjancodes.com/diagnosis
If only I had this when I first started out. The amount of useful information you were able to so succinctly squeeze into a 25 minute video while keeping things clear and accessible is outstanding. Fantastic Job.
Agree
Agree x2
3*(agree)
After tulips and cheese, I really thought you were going for windmills, but nope 😂. Great video, as always!
Summary of this video:
== TIPS ==
- Functions should do one thing, and one thing only
- Side effects (commands) or computations (queries), not both
- Request only what you need
- Minimal parameters
- Separate creation and usage
- No flag parameters (split up functions instead)
- Use higher-order functions
== NAMING ==
- Split up functions with `and` in their name
- Shorten
- Names should be verbs, arguments should be nouns
- Always use the same vocabulary
- Use the languages preferred_naming_scheme and notTheWrongOne
(so never touch C#)
- No spelling or grammar mistakes (duh)
You forgot one key bit - Python should be called Prostitute.
You've forgotten one of the most important take-aways: Arjan thinks Python should have been called Prostitute.
"Prostitute 3.11 is up to 60% faster than Prostitute 3.10"😄
And? The function should do one thing only...
@kayakMike1000 a redundant and somewhat idiomatic but nonetheless correct formulation.
Guido Van Rossum initially named his language "stroopwafel", but it didn't take off because the name is too long.
While he was visiting a zoo and thinking ideas for a shorter name, a snake ate his stroopwafel.
Guess what type of snake it was. (I cannot give you any hints, because stroopwafel didn't support type hints).
Umm Cobra?
was it a coralillo ?
An Oroshimaru?
a pythong?
this is a nice story but I hope you aren't implying that's how he named the language because python is named after Monty Python not the snake python
Crazy value in less than 30 mins! Not only you know what you're talking about, you also know how to deliver it in simple terms. Thanks.
I appreciate that!
Glad you mentioned there should be a verb in a function name.
def verb(direct_object, indirect_object, ...): ...
Or for methods, subject.verb(objects).
Been trying my best to be consistent with using normal grammar to make my code make sense, like using plurals for collections to make loop variables easy to name.
I'm excited for this one! I've always wondered if I was going about functions in the most efficient/optimal way and I'm sure these tips will guide me to be better.
You could've added the cc_validation function as a method for the Card class, and even turn it into property, or validate it upon instantiation in the init, will make even more sense.
Great content, keep going ❤️
One of the best channels, and for free. Feels amazing.
Hi ArjanCodes, thanks for the video! I appreciate the way that you teach these coding concepts - you strike just the right balance, in my opinion, between conceptual and practical explanations.
Nice! You've taken some of the most fundamental clean code practices and distilled them down to a very coherent and concise 25 minutes with no hand waving or fluff. Uncle Bob would be proud =)
I have followed you for a couple of years and this is my favourite video. You are getting so clear and concrete with your points. Functions did deserve a video like this!
Thanks so much Hector - glad you liked the video!
Great video as always. I always learn something new watching your content! Thank you for sharing
Just to say, I've only dabbled in Python and don't know much more than the fundamentals of the language, but I still get A LOT out of watching your videos. I really appreciate how your presentations are so chill and straight to the point. Even when I can't quite tell what's going on with the language, I can get the idea you're trying to teach. Good stuff!
Thanks for the great video again Arjan! It was really informative and helpful🙏
Hello Arjan. I have been following your tips for a while now. It’s completely changed the way I write code and I have received accolades at my work for the significant improvement in code style. I want to thank you very much for it. Please make more videos like these.
Same here, thank you Arjan!
Same
Thanks a lot for these videos! Can't stop watching them!
It's great to see Uncle Bob's Clean Code lessons apply still to this day! Thanks for the video :)
Another great watch! I am so glad there are so many great videos on your channel! Thank you so much for all the valuable information.
I'm glad you're enjoying the content!
My favourite Dutch things so far: Frikandeln, Vla and Pasta Choca. Now I can add Python. Thank you!
Really gooood video!!!!
To @GrammarNazi, at work we happen to have a Django model named “Custom”. Because classes should be singular names in Python... and someone thought Customs was a plural 🤦♂. We still can not safely refactor that.
The Dutch guy said order salad instead of fries Holly crap haha.
The first time I visited Holland my culture shock was how much fries is consumed. I did not connect the Irish historical famine with the current reality.
Love your style and had a blast in Amsterdam. Keep up the good work and thank you for putting these together!
Thanks for the great video.Especially I liked the trick to force keyword arguments. And the closed open principle.
Glad you enjoyed it!
Python should have been called Stroopwafel.
That's a funny name, I'd've called 'em Shaswazzas!
@@lachlanstanding7386 I see you've played "knifey spoony" before
how in the hell, you have so much tasty food in netherlands :D
It's a windmill.
why?
Bonus Tip: Don't nest conditionals. While two simple, nested conditionals might be acceptable but I would already try and think of a better way. When you have three levels in your decision tree it might be time for a truth table. It may seem cumbersome to adhere to this rule but in my experience it always leads to better structure in the code.
Nice. Very good advice about separation of concerns. Thank you.
Glad it was helpful!
Didn't know those partial functions!!! Sooooo gooooood
I'm glad you learned something new!
New to the channel since yesterday's CZcams recommended your video on Classes. Subscribed and liking the tutorials. I am learning and also seeing new things that I don't know what they are for. Decorators perhaps? protocol, hmm Going to look it all up and become better knowledged
Thank you so much!
wow I really like this video. What a clarity and clear explanation with real examples. Thanks for this wonderful video. 👏👏👏👏👏👏
Thanks so much Aby, glad the content is helpful!
Love this kind of videos. Thanks. This is something to return to...
Thanks so much Dror, glad the content is helpful!
Ur explanation is very clear n concise.
I learned something new today. Thanks
Thanks so much GShan, glad the content is helpful!
These videos are very necessary, thanks!
Glad you like them!
Very juicy video, and at the same time funny, especially the joke about PyQt 😂. Thanks!
I'm happy you enjoyed the video!
I learnt so much from this one video
Your channel is brilliant, keep up the great vids!
Thanks a ton!
Awsome video, a lot of very usefull info for me. Thanks a lot!
Thanks so much Ivan, glad the content is helpful!
This man's content is a gift, thank you Arjan
Amazing content as always. Thank you Arjan
Thanks so much, glad the content is helpful!
This video is heavily underrated!
Great as always.
The only thing I just want to say is, since I found your channel and has watched some videos, I never look Python is easy anymore.
And every time I look at my current Python code, it's looks like a dumb code. 😂
Thanks for the content. 👏🏻
that was a good one at 5:50 🤣
Eiffel was used in some classes back in the day at my uni, it really helped me on understanding OO, it was so much nicer than Java (which didn't even have generics back then).
Bertrand Meyer named an engineer's language on a great French engineer: Gustave Eiffel. By this rule, Python might have been called "Tideman" or "Lely"
The sound of your keyboard is so soothing.
Thanks for the inspiration
Enjoyed the video!
Glad to hear it!
Excellent video! There is one thing that I didn't understand. In order to not pass all the user information you made a CardInfo protocol and said that it then would only pass on the information in the protocol. I tested this, but I can still access name from the User dataclass in this way. So the protocol doesn't extract only the variables it contains, but I guess only checks that those needed are there? So in effect you send over as much data in this way as with simply passing the User without the protocol. The protocol approach is nicer than sending the User, but having a Card class is even better.
Hi Arjan! Great video as always, I feel like I've learned more about python programming from you than I have during my astronomy studies. At 16:45 in the video you create a PaymentHandler baseclass using a Protocal. Howcome you don't use an AbstractBaseClass for this? Using a protocal like this seems to ignore the "better explicit than implicit" principle. Is there some advantage to using a protocal like this?
The humor quality is increasing with each video. Not only did I learn, I chuckled a few times !
Glad you like them!
thanks a lot. great content
It's very interesting for me to step into the mainstream Python developer world on CZcams. I'm a scientist and I write tons of "complicated" Python (and Cython and C++) code but the complexity is very different in scientific code - it's in the math and the algorithms rather than the stack of code that manages other code as seems to be common in mainstream codebases. We use abstractions like classes of course but our hierarchy of abstractions is much less branched than here, more like a stack than a web. We like our input files with dozens of parameters (🙂), which flows into some main, which calls some objects and functions, that kind of thing. This comment in itself is not a criticism of common design patterns - I don't feel qualified to criticize them, but I do note how difficult it is often to find the code that actually _does_ something in "professional" codebases. There is so much fluff that is supposed to manage the complexity that it becomes quite complex in itself. That has always frustrated me. Good abstractions are hard to come by, and mainstream code is full of bad abstractions for the sake of abstraction. Sometimes it's better just to _do_ the thing you want to do, rather than erect an entire class of middle managers, usually classes, with abstract-sounding names. If your core algorithm is ten lines or so (as is amazingly often the case by the way), there is no justification for writing 5000 lines across 14 source files to "manage the complexity", but that's often what you see. Bottom line is when you manage complexity you introduce complexity, and that has to be controlled if you're going to make the code friendlier to the developer and user. As you may have guessed, I'm a big fan of Brian Will's diatribe on OOP, not that I think classes are bad (he doesn't either) but that I think most abstractions are bad, and cementing them in with further bad abstraction is a bad idea. Just some thoughts from a scientific programmer - I live in a very different world from all of you, but maybe I have some useful insights because of that. I don't know. You decide.
*Very helpful, Arjan! Thank you!* 👍
Thanks so much, glad the content is helpful!
Awesome content. Keep going !
Thanks so much Mithun, glad the content is helpful!
I just realized Arjan has 10% the subcribers I just assumed the channel had from watching for so long. I honestly believed for years this was a 1 million+ channel and only just now realized it wasn't.
I need to comment and share more, this is my fault.
Thank you so much for your support Kristopher!
loved this
Thanks so much, glad you liked it!
Arjan, I have one question not related to this video: working with an ORM (like Django's), how do you use the SOLID principles? If you ever talk about this it would be so cool 😜
Thank for the video!
I also seek how to use functions within the dataframes, namely in Polars, and how to incorporate it in DuckDB (using SQL in Polars dataframes).
Working with alot of data is a bit frustrating, and I seek ways to use real-case data analyses.
Also wonder how to use the Python Class system in the above case... Don't want to overload the system with too many variables.
Quicktip: you can select cc and then hit ctrl/cmd + d to select next occurance of cc. With this u can change selected same words.
Thank you!
Thanks so much, glad you liked it!
5:45 - 😂
Arjan is spot on here!
Another tip: put your 17:00 Put PaymentHandler and StripPaymentHandler, related subclasses/polymorphisms next to each other.
PRICES is particular constants (which are akin to arguments) as opposed to PaymenteHandler and StripePaymentHandler class definitions (which are akin to function definitions).
So in sum, separate arguments from parameters, or templates from values.
thanks it worked
Thanks so much Kristian, glad the content is helpful!
Great video. Have you considered creating a video covering partial applications for functions?
Great suggestion Richard, thank you!
Hey Arjan / youtube community. every time i watch those videos, i have a feeling that applying this knowledge into my data engineering python tools would be an overkill. Can you recommend something like levels of complexity in python code, where one could judge design quality of code based on those levels? As an example, how long one should stay in single module project, what is the moment when design should consider dataclasses etc.
Very good video, thanks a lot, instant abo
Glad you liked it!
"Im looking at you pyqt !", love your joke. Thank you for this amazing channel
Thanks for watching!
what is the diff btw 'def validate_card(card: CardInfo)' and writing 'def validate_card(card: Card)' Is it syntactic sugar? It do not to scope down number of props passed the validate_card() when executing, property 'valid' still there.
Serious question: How can you stick to the default vscode theme for so long? It doesn't not even highlight function arguments in the function body. Is it for video recording only or you do actually use it on a daily basis?
BTW. Love your content.
Thank you!
Thank you Arjan. I'm just wondering if you swapped ABC with Protocal libraries.
Great video as always! I also love partial functions in Python. One issue I have with them though, is that the type checker in Pycharm doesn't really know what to do with them. For e.g.
def sum(a: int, b: int) -> int:
....
sum_2 = partial(sum, b=2)
The type checker shows and error when it checks whether sum_2 is of type Callable[[int], int].
Does anybody else have this issue? What do you all do about it?
What error does it show?
How would you proceed in creating functions for dataframes?
thanks Arjan, very nice and based
Thanks so much, glad the content is helpful!
What's the advantage of using partials over lambdas? Is it just about readability?
One question not related to this video:
How to solve the relational impedance mismatch?
If I use the solid principles to design a payment system (like you did in a different video), an employee object, contrast object, commission object.
You use interfaces, composition and inheritance.
But how to reconcile this with the database???
I’m quite confused.
Thanks.
Come on Arjan! Every python dev knows Guido loves Monty Python and that's where the language got it's name. There are ton's of Monty Python jokes in the source code and docs.
Hi, i love your Videos, but please use a zoom on you screen when u show and work with Code. Thx a lot for your work!
In my work I work on a codebase that someone else wrote with massive amount of typos, the typo point hits near and dear, it is infuriating to try to find functions with typo'ed names... Also, how you would approach making clean code with a dominant package that you need inherent a lot from its classes, like Pytorch and Pytorch Lightning for example?
First video that made my laugh :) good jokes, you def not a junior YT anymore :)
Thank you, glad you liked the video!
What is the name of the code smell where an object is created and used in the same place?
@12:05 you seem to indicate we're running validate_card on the CardInfo type but you pass the Customer?
What is the benefit of creating the "digits_of" internal function within "luhn_checksum"? Why not just digits = [int(d) for d in card_number]?
In other videos, I recall you've advised against including types in variable names. Maybe it doesn't apply here because it's a type variable, but when you called the type HandlePaymentFn I wondered about the naming scheme.
When I name function types, I usually put "er" at the end of the name. In this case the function type would have the same name as the class it replaced, "PaymentHandler." I probably would have called the param "handle_payment" rather than "payment_handler" though. e.g.:
PaymentHandler = Callable[[int], None]
def order_food(items: List[str], handle_payment: PaymentHandler) -> None:
...
What are your thoughts? How does everyone here name their Callable type variables?
I wanted to ask a question about holidays.py line 26 code. What does the 'f' do in: raise ValueError( f"you don't have enough holidays left......\ I'm struggling to understand that...
Is the protocol class cardinfo still relevant after creating a separate data class for the card ?
1. SRP from the S of SOLID + some good refactor examples
Why do you use validate_card(card) and not validate_card(alice.card) in tip 4 (at around 14:00)?
The mind of the coder - they think they are creative but they are not they are just master organisers ! and no you dont need to be creative to be organised - its just a matter of finding the optimum for the goal ( within constraints of course ). Choose your focus.
As a self taught, these design principles are really that one thing that I felt is missing to pull of brilliant code.
Thanks so much Gukzilla, glad the content is helpful!
at minute 5, for this piece of code: for digit in even_digits:
checksum += sum(digits_of(str(digit * 2))) , I feel like we could write: checksum += sum(even_digits) * 2, thus we don't need to enumerate each even_digit, times 2 , convert to string ten convert back to an int list, then sum up.
I don't understand the card info protocol... Was that left as an incomplete example, or is the class declared completely, for use as a protocol?
Thanks for the video. One question: in the protocol class, is it required to mark as properties the class’ attributes or it can be declared as attributes?
Marking the attributes as properties is the only way to declare them as immutable (useful for NamedTuple instances, or just a `const` like declaration); but they can be declared as attributes too.
Could you do a deep dive on building your own modules
Please 🙏
Noted!
For data related code, how do you deal with passing dataframes to functions? Should you select only the colums which are needed or pass the whole thing?
I would pass the whole thing, as objects are passed by reference instead of pass by value. If you only pass the bits you need, you're likely to copy a bunch of data unnecessary.
Flags argument seen to be stretched:
N flags represent 2^N functions.
Flags might be written in configuration file, so using them in some form or another might be necessary.
Splitting one function into many just to remove flag might lead to code repetition.
I like how you grumbled random stuffs like the paypal and naming of Python. That just makes the video so much entertaining and fun to watch, while still being extremely informative.
Thank you!
function creation reminds me very much of database normalization
23:56 "I'm looking at you PyQt" 😂😂😂 fr tho
Great video! At 23:14 and 23:29 did you mean to say "Parameter" rather than "Argument"? 😱
So on the first example, the luhn checksum one, it is ok to leave the functions all inline IF AND ONLY IF you know that the requirements wont change and you will just use it in that one place.
Other than that it is a bad practice as it leads to less code coherence and more coupling, which makes thing hard to change.
The few advantages to inline are efficiency and faster to write, but in a large software in prod, the drawbacks outweight the trivial advantages.
In general, nearly always extract out to make your code more modular and easier to read, it is just common sense.