Rule Request: Properly formatted TODO comments

[sindresorhus]

New Issue Checklist

• [x] Updated SwiftLint to the latest version
• [x] I searched for existing GitHub issues

New rule request

I would like to ensure TODO comments are formatted properly.

It should also apply to FIXME comments. It could be useful for MARK comments to, but then the rule needs a more generic name I think.

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

It's important to format TODOs correctly for readability and for Xcode to parse it correctly.

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

• Colon after TODO. If this is left out, Xcode will not be able to parse it.
  • // TODO Something => // TODO: Something
  • /* TODO Something */ => /* TODO: Something */
• No triple-slash or double-star comment. I often incorrectly use triple-slash comments for TODOs.
  • /// TODO: Something => // TODO: Something
  • /** TODO: Something */ => /* TODO: Something */
• Spacing. For // comment, one space after the // and one space after the colon. For /* */ comment, one space after /* and before */ if it's inline.
  • //TODO:Something => // TODO: Something
  • /*TODO:Something*/ => /* TODO: Something */
• Ability to enforce only using // for TODO comments and not /* */.

3. Should the rule be configurable, if so what parameters should be configurable?

You should be able to opt into only allowing // for TODO comments.

4. 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.

Enabled by default. I can't imagine anyone wanting //TODO:Something.

[marcelofabri]

PS: we already have a rule for MARK

[iliaskarim]

@marcelofabri Should markrule be expanded to also account for todo's and renamed? That seems to make more sense than having a todorule, markrule, and todoformatting rule, for instance.

[marcelofabri]

I personally think that having another rule is easier for users as it gives them more choices (which rule to enable/disable, allow them to disable locally, etc)