search

jeffreykegler / yahc

Yet Another Hoon Compiler
MIT License
0 stars 1 forks source link

More 1-jogging anomalies #15

Closed jeffreykegler closed 5 years ago

jeffreykegler commented 5 years ago

1jogging.lint.txt

jeffreykegler commented 5 years ago

Working on the 2-joggings, I tightened up the standards for comments in gaps, and retro-ported them to the 1-joggings. I also improved the placement of the ZAPs in the context output, which came out rather nicely if I say so myself. :-) These are problems in gaps, mostly comments aligned with the jog when they should be aligned with the rune.

jeffreykegler commented 5 years ago

@ohAitch: I believe all of these should be added to anomaly.suppressions. Let me know if you agree before I proceed.

ohAitch commented 5 years ago

"missing comment" is a cute way to put it - this is a "blank line instead of empty line" lint right?

Provisionally add them to anomalies yeah, though there being 14 examples(+ some earlier) is definitely making me less confident in this being the right rule. How heavily are these outnumbered by non-blank comments that are in the fully-outdented "gutter"? (perhaps discounting any that precede an outdented empty comment, since the competing rule is "aligned to next line")

In particular, something like half of the examples are commented code, which definitely is more clear to put on the indentation it would be if uncommented than artificially outdent. And in the zuse case it isn't even stale commented code, it's serving as documentation / type system wishlist

jeffreykegler commented 5 years ago

I have added the anomalies and am marking this "Ready to be closed". The phrasing is "missing comment" because this policy is about indentation, and so the message explains why the gap is not allowed -- there needs to be a comment on that line. I expect to do a "No blank lines allowed" warning in the context of something like a Basic::Layout policy which will ban blank lines, tabs, and other layout matters which do not require parsing in the sense of finding the structure of the document. IIRC correctly rune-aligned ("gutter") comments heavily outnumber head-aligned comments -- in particular there are lots of empty comments which almost always are rune-aligned. I expect when we look back treating head-alignment as an error will seem very reasonable. In a corpus the size of the arvo/ one, a dozen anomalies is not really a lot.

ohAitch commented 5 years ago

Yeah that's why I specified non-blank(non-empty?): using an empty comment as a vertical list separator possibly describes most standalone arvo comment lines, and any immediately preceding header comments would similarly need to be rune-aligned(i.e. to the empty comment) and not head-aligned.

Definitely not going for "rune-aligned comments are disallowed", since I believe there are plenty non-empty comments that are rune aligned without a following empty comment; the question is whether "both allowed" would be a reasonable policy, and if not what are good ways to reindent the anomalies caught.

jeffreykegler commented 5 years ago

Closed as per the above.