Rule Request: Acronyms Camel Case
Open
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
- Updated SwiftLint to the latest version
- I searched for existing GitHub issues
Rule Request
- Why should this rule be added? Share links to existing discussion about what
the community thinks about this.
https://google.github.io/styleguide/javaguide.html#s5.3-camel-case
https://stackoverflow.com/a/27172000
- Provide several examples of what would and wouldn't trigger violations.
would:
let userID = 1
let greatAPI
wouldn't
let userId = 1
let greatApi
- Should the rule be configurable, if so what parameters should be configurable?
no, we need just enable/disable
- Should the rule be opt-in or enabled by default? Why?
no
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
Start by reviewing SwiftLint's existing naming rules and the linked Java style guide to understand the requested acronym behavior. Add coverage for the provided violating and non-violating Swift examples, and consider the work complete when the rule can be enabled or disabled and those examples are classified as specified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100