2.6. Functions¶
Writing your own functions is important for improving the clarity of your code because it
separates different strands of logic (Rule 5.B)
allows you to reuse code (Rule 5.A)
prevents copy/paste errors (Rule 5.A)
The “Code and Data” reference has a short but very nice illustration justifying and explaining those rules. Do yourself a favor and read it!
I’ll simply add that while a “wet jumpshot” is good in basketball, “wet code” is bad. You’ve Wasted Everyone’s Time by Writing Everything Twice, which is bad even though We Enjoy Typing.
Nah, you want your code to be DRY. It’s very simple: Don’t Repeat Yourself.
So if you’re repeating the same block of code multiple times, turn it into a short function.
Our textbook has a section on how to build functions and we will cover many examples in class. Additionally, our resources page has a section on python, which will point you to some good explainers on writing them.
A few more points:
Don’t write functions for the sake of it! Writing functions can be a time-consuming waste of time that eats up time. (Lots of redundancy in that sentence was a waste of time to the reader, but at least it was short. Similarly, bad code is less problematic when it is short.)
Rule 5.D: If you are going to reuse your code, write a “unit test”, which is a script that tests out the behavior of the function you’ve written to make sure it works as intended. It should run your function with a few different inputs, possibly inputs with deliberate errors, test the function’s output against answers you know in advance are correct.
Using “toy” or “small” datasets is essential to developing functions and code more broadly. Create a small fake dataset because you can compute the answers by hand. You can also sample a small part of a large dataset.
Corollary: Don’t unit test for the sake of it. You don’t need to check what
round_a_number()does when you use a string as input.