You may have noticed that the code for
getButtonClicked() ends with a return
None statement on line 247. This might seem like an odd thing to type out, since all functions return
None if they don’t have any
return statement at all. We could have left line 47 out entirely and the program would have worked the exact same way. So why bother writing it in?
Normally when a function reaches the end and returns the
None value implicitly (that is, there is no
return statement outright saying that it is returning
None) the code that calls it doesn’t care about the return value. All function calls have to return a value (so that they can evaluate to something and be part of expressions), but our code doesn’t always make use of the return value.
For example, think about the
print() function. Technically, this function returns the
None value, but we never care about it:
>>> spam = print('Hello') Hello >>> spam == None True >>>
None, it means that the coordinates that were passed to it were not over any of the four buttons. To make it clear that in this case the value
None is returned from
getButtonClicked(), we have the
return None line at the end of the function.
To make your code more readable, it is better to have your code be explicit (that is, clearly state something even if it might be obvious) rather than implicit (that is, leaving it up to the person reading code to know how it works without outright telling them). In fact, "explicit is better than implicit" is one of the Python Koans.
The koans are a group of little sayings about how to write good code. There’s an Easter egg (that is, a little hidden surprise) in the Python interactive shell where if you try to import a module named
this, then it will display "The Zen of Python" koans. Try it out in the interactive shell:
>>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
If you’d like to know more about what these individual koans mean, visit http://invpy.com/zen.