https://github.com/lue-bird/elm-review-variant-value-count

enforce that variants have at most one value
https://github.com/lue-bird/elm-review-variant-value-count

choice-type elm elm-review not-positional variant

Last synced: about 1 month ago
JSON representation

enforce that variants have at most one value

• Host: GitHub
• URL: https://github.com/lue-bird/elm-review-variant-value-count
• Owner: lue-bird
• License: mit
• Created: 2024-03-22T16:13:24.000Z (10 months ago)
• Default Branch: main
• Last Pushed: 2024-03-22T21:06:09.000Z (10 months ago)
• Last Synced: 2024-10-14T00:42:35.503Z (3 months ago)
• Topics: choice-type, elm, elm-review, not-positional, variant
• Language: Elm
• Homepage: https://dark.elm.dmy.fr/packages/lue-bird/elm-review-variant-value-count/latest
• Size: 61.5 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • Changelog: changes.md
  • License: LICENSE

Awesome Lists containing this project

README

        
Limit the number of allowed values on a variant to 1 at most

by using the [`elm-review`](https://package.elm-lang.org/packages/jfmengels/elm-review/latest/) rule

[`Review.VariantValueCount.zeroOrOne`](https://package.elm-lang.org/packages/lue-bird/elm-review-variant-value-count/1.0.2/Review-VariantValueCount/#zeroOrOne)

Below variant would be reported for example because it has two attached values:

```elm

type User

    = User String Time.Posix

```

## try it

```bash

elm-review --template lue-bird/elm-review-variant-value-count/example

```

## add it to your config

```elm

module ReviewConfig exposing (config)

import Review.VariantValueCount

import Review.Rule

config : List Review.Rule.Rule

config =

    [ Review.VariantValueCount.zeroOrOne

    ]

```

## why

A variant with multiple arguments is very similar to automatic record type alias constructor functions and arbitrary-size tuples

in that its parts can only be differentiated by position.

All three share the same problem: This position is usually neither obvious nor descriptive.

A missed chance to let the code be self-documenting!

Even when you think it's clear, there are likely implicit roles of the variant values:

```elm

type Msg

    = MessageReceived User Message

```

turns out in this case it was supposed to have been

```elm

type Msg

    = MessageReceived { recipient : User, message : Message }

```

One valid criticism is that `case` patterns now can't be nested

and so casing becomes more verbose.

And I will never disagree with you on that.

Pattern matching on records is just a missing feature in elm.