Closed klauer closed 4 years ago
Merging #136 into master will decrease coverage by
0.1%
. The diff coverage isn/a
.
@@ Coverage Diff @@
## master #136 +/- ##
==========================================
- Coverage 78.79% 78.68% -0.11%
==========================================
Files 16 16
Lines 1820 1820
==========================================
- Hits 1434 1432 -2
- Misses 386 388 +2
Impacted Files | Coverage Δ | |
---|---|---|
pytmc/linter.py | 68.25% <0%> (-3.18%) |
:arrow_down: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 1ce15be...a6226e9. Read the comment docs.
We definitely need the fields to be written in a deterministic order. I'm already running into fields that get ordered differently at different times in ways that I'm unable to diagnose.
Alphabetical has the disadvantages you've noted but is clearly the easiest to implement (you've achieved this in a 5 character diff).
Unless there's an easy way to categorize fields and have a "natural-feeling" grouping without going through one-by-one and defining a static order, I think this should be merged.
Without doing it manually, my only other thought is that we could use something like softIoc.dbd
to generate per-record field ordering for us. Then the jinja filter would use that as the sort(key=...)
This would work as long as the dbd
files are always built with consistent ordering and if there's an easy way to extract it
I've created #143 which sorts recognized entries in a coherent way and alphabetizes the rest.
This doesn't have to be merged - but we should decide sooner rather than later if we are going this route.
Closes #109
Pluses:
Minus:
ZNAM
andONAM
, or some of the ugly mbbi/mbbo ones for 1-15)If we think the plus outweighs the minus, then let's go with it. If not, we can close this.
Example before:
After: