chore: reformat codebase with longer line length #2362
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2362 +/- ##
========================================
Coverage 74.1% 74.2%
========================================
Files 292 292
Lines 59476 59622 +146
========================================
+ Hits 44127 44261 +134
- Misses 15349 15361 +12
|
|
I'd vote for the default 88. And there may be other commits in the history we might want to apply This triggered a lot of codacy warnings for some reason, maybe things that it missed before? A lot can be ignored but a few look like real issues |
|
I like the idea of switching to the default of 88. The resulting code is easier to read. Will need to update the create packages code, but that can be done separately as it is currently under development. |
|
I also like the line length limit of 88. While we’re on this topic, I think it could be beneficial (and in the same spirit of this PR) to review the other Ruff settings as well, particularly the linting rules that are currently set to be ignored. |
Agreed, we ignored several to make the initial move to ruff easier but imo it makes sense to aim for the defaults. Maybe we can add |
mwtoews
force-pushed
the
line-length-88
branch
from
d4e75c0
to
5307a9f
Compare
|
Agree that the default 88 char length looks ideal, so let's keep it. I've revised this PR to exclude As for enabling some other Ruff checks, agree this is a good idea, but I recommend to choose these carefully with individual PRs with specific aims/fixes. |
|
rebasing after #2363 should turn codacy green here |
Codacy began detecting a "severe" pylint E1126 invalid sequence index violation in #2362. The issue pre-existed that PR, I think the format changes just revealed it. We could just ignore it in the web UI but this is probably worth coming back to, to appease linters and type checkers and to make the code easier to reason about. Relatedly, there is work ongoing to make ruff work with codacy, so hopefully in future we can use ruff ignore syntax for things like this if/when needed
mwtoews
force-pushed
the
line-length-88
branch
from
5307a9f
to
3af2e20
Compare
This PR reformats Python code with a maximum line length of 88 characters to better represent the code. Note that a related repo MODFLOW-USGS/modflow6-examples already uses the default line length of 88. See modflowpy/flopy#2362 for a related PR with rational and discussion. This PR was automated using these Ruff commands (including quick fixes to ISC001): ruff format ruff check --select ISC001 --fix ruff format
This is a draft PR to investigate the utility of contributing and maintaining code with a longer line length limits.
The codebase currently has a line length limit of 79 (via #954) as suggested in PEP 8 (which is related to a 80 char limit of decades old IBM punch cards and terminals). However, longer line lengths are generally encouraged for modern Python development, which is a language that commonly has four-space indents needed to define logic structures, thus requiring more horizontal space than other programming languages.
Black has a default of 88, which is the same default for Ruff. Is this the ideal length for the flopy codebase? Not sure, but a quick scan of the suggested changes look much better.
Despite the size of this PR, it was quickly automated using these ruff commands (including quick fixes to ISC001):
There are no functional changes in this PR, thus the code "runs the same". As such,
.git-blame-ignore-revscan be amended to ignore these changes with (e.g.) GitHub's blame view (this would be a follow-up PR).Is Anyone in favor of increasing the line length? If so, does 88 seem reasonable, or some other length?