-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Hi GeoDesign team,
after looking at some of our geoprocessing scripts, I tried to order the concepts below for their immediate usefulness and applicability. Over time I might (or might not - there is always the Internet - create related wiki pages).
Here are a few best practices for Python scripts:
-
Make them DRY: DRY stands for Don't repeat yourself, if you repeat two lines in a row, there is a lot of space for improvement (https://en.wikipedia.org/wiki/Don't_repeat_yourself)
-
Good code does NOT need documentation: Yes, that is the opposite from what you heard before, BUT coding languages are languages after all, if you are proficient in a language you do not need to write it in another language. Python is designed in support of that assumption. You should definitely get rid of inline comments (of course there are exceptions). You should still document on the module, class, method, or function level using docstrings (see below) and if you are fancy function annotations. Write what a particular thing does (but NOT how). If you need an inline comment that might be also an indicator that it is time to break this piece of code out into a function or method.
-
Follow PEP8 which is the Chicago style guide of Python https://www.python.org/dev/peps/pep-0008/ mostly ignored by ESRI examples.
-
Reduce the use of conditionals and (to a somewhat lower extent in Python) FOR loops. Try to use exceptions, arguments, iterators, and map() methods instead.
-
Methods and functions should do one single thing, as a rule of thumb, make them so short that you can see them in an editor without scrolling (30-40 lines). If they are longer than 100 lines then their is definitely potential for improvement.
Here is my list:
- docstrings (https://www.python.org/dev/peps/pep-0257/)
- functions
- os standard library
- context managers
- exceptions and exception handling
- scope and state (relatively easy in Python but still good to understand)
- variables vs. references
- mutable and immutable collections: list vs. tuple
- dictionaries
- list comprehension
- classes
- decorators
- modules
- virtual environments (I would put this on the top of the list but it is a hassle in the arcpy context)
- unit tests
- packages (for sharing work across the team)