exercism / exercism/elm-analyzer

Which common checks should be running on every solutions?

Open
#13 4 comments 1 reaction 0 assignees View on GitHub
Dominant language
Elm
Stars
1
Forks
5
PR merge metrics
No merged PRs in 30d

Description

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 `camelCase` is 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-review` and 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, ban `always`...) 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.

| Rule | Package | Add? | Comment |
|-------------------------------------------------------------------------------|-------------------------------------------------------------|:----:|---------------|
| Provides elm-review rules to detect debug code | jfmengels/elm-review-debug |✅|No Debug in prod [Added in #68 ]|
| Provides elm-review rules to simplify Elm code | jfmengels/elm-review-simplify |✅|Things like `not True` --> `False` [Added in #29 ]|
| Provides elm-review rules to detect unused elements in your Elm project | jfmengels/elm-review-unused |✅|Removes dead code [Added in #29 ]|
| elm-review rule to ensure your code uses camelCase. | sparksp/elm-review-camelcase |✅|Strong standard [Added in #71]|
| elm-review rule to forbid certain words in comments. | sparksp/elm-review-forbidden-words |✅|Can be used to comment on `-- TODO` comments|
| Provide elm-review rules to follow some of my personal code style preferences | jfmengels/elm-review-code-style |❓|Minor (`NoSimpleLetBody`)|
| elm-review rules for working with the Unit type | mthadley/elm-review-unit |❓|Minor (always matches `()`)|
| A rule for elm-review that discourages long one-line Imports. | r-k-b/no-long-import-lines |❓|Tedious without `elm-format`|
| elm-review rules to ensure sortable code is sorted in the "proper" order. | SiriusStarr/elm-review-no-unsorted |❓|Tedious without `elm-review --fix`|
| elm-review rule enforce consistent import aliases. | sparksp/elm-review-imports |❓|`NoInconsistentAliases` not relevant, `NoModuleOnExposedNames` maybe|
| Forbid division operations that produce unwanted values or runtime exceptions | vkfisher/elm-review-no-unsafe-division |❓|Too demanding?|
| Provide an elm-review rule to measure the cognitive complexity of a function. | jfmengels/elm-review-cognitive-complexity |🔍|Confusing for the average student. Only for the hardest exercises?|
| Provides common linting rules for elm-review | jfmengels/elm-review-common |🔍|Some maybe (`NoExposingEverything`...) some no (`NoMissingTypeAnnotationInLetIn`...)|
| Provides elm-review rules to report performance problems in your Elm project | jfmengels/elm-review-performance |🔍|For performance-oriented exercises only? (`nth-prime`, `palindrome-products`)|
| Customizable elm-review rules for allowable pipeline styles. | SiriusStarr/elm-review-pipeline-styles |🚫|Too opinionated|
| Provides elm-review rules to help with the quality of the documentation | jfmengels/elm-review-documentation |🚫|Documentation quality is not really about language fluency|
| elm-review rule to enforce documentation for every top level declaration | ContaSystemer/elm-review-no-missing-documentation |🚫|Documentation quality is not really about language fluency|
| "elm-review" rule to forbid Regex package usage in favour of Parser package | ContaSystemer/elm-review-no-regex |🚫|`elm/regex` is available|
| Provides elm-review rules to forbid the use of import aliases | fysiweb/elm-review-no-import-as |🚫|Too strict|
| Provides elm-review rules to keep record fields and constructors sorted | fysiweb/elm-review-sorted |🚫|Alphabetical is not always the best order|
| Provides an elm-review rule to prohibit redundant usage of `++` | truqu/elm-review-noredundantconcat |🚫|Covered by jfmengels/elm-review-simplify|
| Provides an elm-review rule to prohibit redundant usage of `::` | truqu/elm-review-noredundantcons |🚫|Covered by jfmengels/elm-review-simplify|
| Provides elm-review rules to disallow single-pattern case expressions. | SiriusStarr/elm-review-no-single-pattern-case |🚫|Covered by jfmengels/elm-review-simplify||

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.