geo_data_proc refactor: readability and a small bug fix #1331
Conversation
| jhu_df = ( | ||
| pd.read_csv(JHU_FIPS_URL, dtype={"UID": str, "FIPS": str}) | ||
| .query("Country_Region == 'US'")[["UID", "FIPS"]] | ||
| .rename(columns={"UID": "jhu_uid", "FIPS": "fips"}) | ||
| .dropna(subset=["fips"]) | ||
| ) | ||
| jhu_df = pd.read_csv(JHU_FIPS_URL, dtype={"UID": str, "FIPS": str}).query("Country_Region == 'US'")[["UID", "FIPS"]].rename(columns={"UID": "jhu_uid", "FIPS": "fips"}).dropna(subset=["fips"]) |
There was a problem hiding this comment.
Is this actually easier to read? I find the multiline a bit easier, though could be convinced otherwise. Also it would keep linting standards consistent across the codebase even though this isnt linted.
There was a problem hiding this comment.
Yea, it's def a personal preference I've developed while working with the delphi-epidata rewrite. Roughly put, I think it's easier to get an overview of a function when its code lines are lines and not code chunks. I spend less mental overhead on parsing indentation and code chunks and get more vertical space economy.
The pandas functions are code highlighted even in GH, so if you need the details of all the data munging you scan to the right, otherwise the read_csv is all you need to get a first approximation of what jhu_df contains. And then there's no need for the extra parentheses bloat on top and bottom.
But yea, it's mixing code styles across the codebase, so that's not great. At least it's consistent in a file? 🙃
There was a problem hiding this comment.
Split longer lines like this one in two steps.
* type hinting for language server * function docstrings * split really long pandas chains in two
Description
geo_data_proc.py(producing crosswalk files for geomapper) is a little bloated, so a few refactors to make it easier to read (on a widescreen monitor), a bug fix, and a minor change.Changelog