Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rule request: Prefer enums for convenience types #1871

Closed
2 tasks done
marcelofabri opened this issue Oct 1, 2017 · 0 comments
Closed
2 tasks done

Rule request: Prefer enums for convenience types #1871

marcelofabri opened this issue Oct 1, 2017 · 0 comments
Labels
rule-request Requests for a new rules.

Comments

@marcelofabri
Copy link
Collaborator

marcelofabri commented Oct 1, 2017

New Issue Checklist

Rule Request

If a type only exists to group global (static) functions and variables, it should be an enum to avoid being instantiated.

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

From Erica Sadun's Swift Style book:

When creating new types to host global constants and functions, prefer caseless enumerations to using structs. Enums are the conventional approach used by the Swift core team. Unlike caseless enumerations, structs can be instantiated by an API client.

  1. Provide several examples of what would and wouldn't trigger violations.
// should trigger
struct Math { 
  public static let pi = 3.14
}

class Math { 
  public static let pi = 3.14
}

struct Math {
  public static let pi = 3.14 
  @available(*, unavailable) init() {}
}

// shouldn't trigger

// enum
enum Math {
  public static let pi = 3.14
}

// class visible to Objective-C
class Math: NSObject {
  public static let pi = 3.14
}

// type with non-static declarations
struct Math {
  public static let pi = 3.14
  public let randomNumber = 2
}
  1. Should the rule be configurable, if so what parameters should be configurable?

Just on the severity.

  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.

Enabled by default.

@marcelofabri marcelofabri added the rule-request Requests for a new rules. label Oct 1, 2017
dirtydanee pushed a commit to dirtydanee/SwiftLint that referenced this issue Jun 25, 2018
dirtydanee pushed a commit to dirtydanee/SwiftLint that referenced this issue Aug 14, 2018
sjavora pushed a commit to sjavora/SwiftLint that referenced this issue Mar 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule-request Requests for a new rules.
Projects
None yet
Development

No branches or pull requests

1 participant