fsprojects / fsprojects/FSharpLint
Should favour names in DU members (and maybe pattern matching?)
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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