realm / realm/SwiftLint

Rule Request: [ValidDocs] (bring it back)

Open
#2,650 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

rule-request
Dominant language
Swift
Stars
19.7k
Forks
2.3k
Avg merge
1d 1h
Merged PRs (30d)
11

Description

New Issue Checklist
New rule request

Please describe the rule idea, format
this issue's title as Rule Request: [Rule Name] and describe:

  1. Why should this rule be added? Share links to existing discussion about what
    the community thinks about this.

It would be possible to lint the documentation. This rule was added back in 2015 https://github.com/realm/SwiftLint/pull/225 and removed in 2017 https://github.com/realm/SwiftLint/pull/1455. Would it be possible to have it back?

  1. Provide several examples of what would and wouldn't trigger violations.

wouldn't:

    /// This is a function
    ///
    /// - Parameters:
    ///   - parameter1: this is parameter1
    ///   - parameter2: this is parameter2
    static func function(parameter1: String, parameter2: String) {
        print("Hello world")
    }

would:

  • Function with documentation, where the parameter names do not match the function parameter names:
    /// This is a function
    ///
    /// - Parameters:
    ///   - parameter1: this is parameter1
    ///   - parameter2: this is parameter2
    static func function(parameter1: String, otherParameterName: String) {
        print("Hello world")
    }
  • Function with documentation, where the documented parameters do not match the function parameters, or the order does not match:
    /// This is a function
    ///
    /// - Parameters:
    ///   - parameter1: this is parameter1
    ///   - parameter2: this is parameter2
    static func function(parameter1: String) {
        print("Hello world")
    }
  1. Should the rule be configurable, if so what parameters should be configurable?

I do not think so.

  1. Should the rule be opt-in or enabled by default? Why?
    See README.md for guidelines on when to mark a rule as opt-in.

Seems to me that it will be good to have it enabled by default.

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

Start by reviewing README.md's opt-in-rule guidance and the linked historical pull requests (#225 and #1455) to understand the previous implementation and removal. The work is done when documentation parameter names, sets, and ordering are checked against function parameters, with the examples in this issue covered by tests.

Written by the indexing model from the issue text.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.