ErikSchierboom
commented
2 years ago Awesome list! Just in case you didn't know, we support different types of analyzer comments (see the docs):
essential: We will soft-block students until they have addressed this commentactionable: Any comment that gives a specific instruction to a user to improve their solutioninformative: Comments that give information, but do not necessarily expect students to use it. For example, in Ruby, if > someone uses String Concatenation in TwoFer, we also tell them about String Formatting, but don't suggest that it is a better option.celebratory: Comments that tell users they've done something right, either as a general comment on the solution, or on a technique.
With these different types, one can have some comments be more like suggestions, whereas others are considered (soft-)blocking.
On the other hand, you wouldn't want to ban <| even though |> is the preferred standard.
Indeed. What you could do though is to have this be an informative command. Something that the student should be aware of, but doesn't necessarily need to change (BTW F# has this same guidance).
Looking at the above list, here are some thoughts:
Provides elm-review rules to keep record fields and constructors sorted
Is this something elm-format will/can do automatically?
Provide an elm-review rule to measure the cognitive complexity of a function.
I think I'd not implement this rule. Many students won't understand what this means I think. While it is good to know about cognitive complexity, I'm not sure this provides much benefit for the average student.
Provides common linting rules for elm-review
There are probably some rules that are fairly well-known and that could be of use to the student.
Provides elm-review rules to help with the quality of the documentation
I wouldn't implement this. Documentation quality is not really about language fluency (improving that is our goal at exercism) I feel.
Provides elm-review rules to report performance problems in your Elm project
I agree that this could be useful for some harder or some performance-oriented exercises (e.g. nth-prime or palindrome-products require a fairly efficient implementation).
elm-review rule to forbid certain words in comments.
According to your comment, you'd want to comment if you find a comment that starts with -- TODO?
elm-review rule enforce consistent import aliases.
What does this mean?
jiegillet
Analyzer checks can be very useful for learning exercises, when you want to guide the student towards a recommended solution, but they can also be very useful for teaching about idiomatic code, community standards and that sort of things, across all exercises.
Here, I would like to discuss which checks would be worth implementing, and which checks would be too preachy. For example, the use of
camelCaseis so prevalent in Elm, that any other style should be commented on. On the other hand, you wouldn't want to ban<|even though|>is the preferred standard.The standard analyzer tool in Elm is
elm-reviewand people are encouraged to shared their rules as packages, so I searched for those and came up with this list. I already removed some that are too domain specific for Exercism (ports, JSON, HTML...) or too strict (forbid type alias constructors, banalways...) or some duplicates.I don't know yet how these would get implemented, I just want to talk about which kind of checks we would like. For now, all of these are my opinion, I look forward to discussions to narrow the options down or add new ideas.
Legend: ✅ yes, 🚫 no, ❓ maybe, 🔍 investigate further.
not True-->False[Added in #29 ]-- TODOcommentsNoSimpleLetBody)())elm-formatelm-review --fixNoInconsistentAliasesnot relevant,NoModuleOnExposedNamesmaybeNoExposingEverything...) some no (NoMissingTypeAnnotationInLetIn...)nth-prime,palindrome-products)elm/regexis available++::