search

quantifiedcode / python-anti-patterns

An open collection of Python anti-patterns and worst practices.
https://quantifiedcode.github.io/python-anti-patterns
Other
1.71k stars 249 forks source link

Optional arguments #110

Open GatorQue opened 6 years ago

GatorQue commented 6 years ago

When a function/method has arguments with a default value assigned all other callers of the function/method should explicitly specify the optional argument name.

def foo(bar=None, zoo=None): pass

Bad: foo(1, "lion")

Good: foo(bar=1, zoo="lion")

Rationale: Additional optional arguments will likely be added to the function/method in the future and the callers won't need to be hunted down and updated to account for the new optional argument added.

Example: def foo(flag=True, bar=None, zoo=None): pass

Bad: foo(1, "lion") # unexpected result since flag is now assigned 1 and bar is now assigned "lion"

Good: foo(bar=1, zoo="lion") # No change necessary - behaves the same as before

adewes commented 6 years ago

I partially agree, as naming variables explicitly makes the code clearer for functions that have many optional arguments. Would you be able to write an anti-pattern for this? Could be a great addition to the "maintainability" section, you can use e.g. this file here as a template:

https://github.com/quantifiedcode/python-anti-patterns/blob/master/docs/maintainability/using_single_letter_as_variable_name.rst

Looking forward to reviewing that PR (and don't worry about grammar / presentation, we can fix that), thanks for contributing!

GatorQue commented 6 years ago

Sorry it took me so long to put this up. I hope it fits your anti-pattern format and explains the concept clearly enough.