Closed dvbuntu closed 3 years ago
✅ Merging this PR will increase code quality in the affected files by 0.49%.
Quality metrics | Before | After | Change |
---|---|---|---|
Complexity | 5.88 ⭐ | 5.34 ⭐ | -0.54 👍 |
Method Length | 78.10 🙂 | 78.36 🙂 | 0.26 👎 |
Working memory | 10.00 😞 | 9.74 🙂 | -0.26 👍 |
Quality | 59.38% 🙂 | 59.87% 🙂 | 0.49% 👍 |
Other metrics | Before | After | Change |
---|---|---|---|
Lines | 205 | 226 | 21 |
Changed files | Quality Before | Quality After | Quality Change |
---|---|---|---|
src/python/preprocessing.py | 51.64% 🙂 | 51.91% 🙂 | 0.27% 👍 |
test/python/tests_preprocessing.py | 69.95% 🙂 | 68.59% 🙂 | -1.36% 👎 |
Here are some functions in these files that still need a tune-up:
File | Function | Complexity | Length | Working Memory | Quality | Recommendation |
---|---|---|---|---|---|---|
src/python/preprocessing.py | prune_graph | 16 🙂 | 247 ⛔ | 13 😞 | 35.36% 😞 | Try splitting into smaller methods. Extract out complex expressions |
src/python/preprocessing.py | prune_graph._check_resource | 3 ⭐ | 109 🙂 | 13 😞 | 59.60% 🙂 | Extract out complex expressions |
test/python/tests_preprocessing.py | TestsPreprocessing.setUp | 0 ⭐ | 239 ⛔ | 8 🙂 | 60.13% 🙂 | Try splitting into smaller methods |
test/python/tests_preprocessing.py | TestsPreprocessing.testFormatting | 0 ⭐ | 125 😞 | 9 🙂 | 67.82% 🙂 | Try splitting into smaller methods |
The emojis denote the absolute quality of the code:
The 👍 and 👎 indicate whether the quality has improved or gotten worse with this pull request.
Please see our documentation here for details on how these metrics are calculated.
We are actively working on this report - lots more documentation and extra metrics to come!
Let us know what you think of it by mentioning @sourcery-ai in a comment.
This PR fixes some of the logic with the Python
preprocessing.py
. Previously it looked for both maximum and minimum constraint violations, but based on this issue, I don't think we can actually check the minimum constraint this way.Another fix is ignoring the Source and Sink nodes when checking for violating nodes. Previously we might have hit them early and missed violating nodes.
I also changed which node get identified as offending. Given a shortest resource path from Source to A, if the cost is say 10 while our maximum allowed is 5, then A cannot possibly be on the shortest resource-constrained path from Source to Sink. So we mark node A for removal. Previously, the predecessor to node A was removed, think under logic that the final edge (i.e. B-A) was the problem. But that could remove a node needed for other paths (see Issue #72 ). Node identified changed from -2 to -1.
Finally, if the shortest path from Source to A consumes too many resources (i.e. node becomes a key in
nodes_source
), that is sufficient to remove that node. Whether it also consumes too many from A to Sink becomes irrelevant (and vice versa) as it cannot be part of the shortest path. If my logic is mixed up, I'd be happy to revert the changes I made.node in nodes_source and nodes_sink
changed tonode in nodes_source or node in nodes_sink
(note typo fix as well, was missing checking node innodes_sink
).