realm / SwiftLint

A tool to enforce Swift style and conventions.
https://realm.github.io/SwiftLint
MIT License
18.45k stars 2.2k forks source link

Rule Request: Ignore CodingKey enums in Nesting #5641

Open braker1nine opened 1 week ago

braker1nine commented 1 week ago

New Issue Checklist

New rule request

This is more of an edit to an existing rule than a new rule, so apologies if this is the wrong format... Add a boolean option to the Nesting rule. When this option is enabled, enum's conforming to CodingKey won't count as violations of nesting.

My main argument for this is that CodingKey's are less of a nested "type" and more of an annotation of the current type for Codable If you have types that have custom CodingKey types, you basically lose a

Triggering

struct Wrapper: Codable {
    struct Inner: Codable {
        struct WayInner: Codable {
        }
    }
}
struct Wrapper: Codable {
    enum CodingKeys: String, CodingKey {
        case id = "identifier"

        struct TechnicallyOkayButBad {
            struct Violation {}
         }
    }
}

Non Triggering

struct Wrapper: Codable {
    struct Inner: Codable {
        let id: Int

        enum CodingKeys: String, CodingKey {
            case id = "identifier
        }
    }
}

I think I would propose this be an opt-in setting on the nesting rule.

Looking at the criteria in the README

A rule that can have many false positives

I think this change would actually reduce false positives

A rule that is too slow

I don't think this would be an issue

A rule that is not general consensus or is only useful in some cases

I'm not sure if there's consensus here. And it's a very specific case...

braker1nine commented 1 week ago

I've already spent some time on a rough version of implementation. So if this is something that feels worth adding, I'm happy to work in a PR for it

SimplyDanny commented 3 days ago

Sounds like a reasonable exclusion. However, I recommend adding this only as an option to the rule. So the default behavior of the rule doesn't change.

If you have worked on a PR already, please go ahead and propose it. I'll be glad to have a look at it.