fsprojects / fsprojects/FSharpLint

Should favour names in DU members (and maybe pattern matching?)

Open
#525 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
F#
Stars
327
Forks
74
PR merge metrics
No merged PRs in 30d

Description

There are two ways to write things, named or unnamed.

Unnamed (types):

type Data =
    | TwoParts of string * string
    | OnePart of string

Named (types):

type Data =
    | TwoParts of part1: string * part2: string
    | OnePart of part1: string

We could have a rule that warns about the former and prefers the latter. This would be enough to make a v1 of a rule.

For a 2nd version of the rule, we could also examine match blocks:

Unnamed (match blocks):

let examineData x =
    match data with
    | OnePart p1 -> p1
    | TwoPart (p1, p2) -> p1 + p2

Named (match blocks):

let examineData x =
    match data with
    | OnePartData(part1=p1) -> p1
    | TwoPartData(part1=p1; part2=p2) -> p1 + p2

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue does not name files, tests, or entry points. Start by locating how existing FSharpLint rules detect and report union-case declarations, then define completion as warnings for unnamed DU fields; pattern matching is described as a possible second version.

Written by the indexing model from the issue text.

Assessment

Tech stack
fsharp
Domain
tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.