AWS CloudFormation Linter

Unused setter value is likely a mistakeSW-W1004 Duplicate key in dictionary is likely a mistakeSW-E1000 Default parameters should always be positioned at the endSW-W1001 Duplicate conditions in branch instruction is likely a mistakeSW-W1005 Enum should always have unique casesSW-W1007 Use of an insecure version of TLS protocolSW-S1002 Use of an insecure block cipher modeSW-S1003 Use of an insecure cipher algorithmSW-S1004 Prefer using `min()` or `max()` over `sorted().first` or `sorted().last`SW-P1011 Prefer using `.first(where:)` over `.filter { }.first` in collectionsSW-P1007 Prefer `contains` over `range(of:) != nil` and `range(of:) == nil`SW-P1012 Force unwrapping should be avoidedSW-W1023 An object should only remove itself as an observer in `deinit`SW-W1028 Prefer `contains` over comparing `filter(where:).count` to zeroSW-P1001 Prefer `reduce(into:_:)` over `reduce(_:_:)` for copy-on-write typesSW-P1010 Prefer using `.allSatisfy()` or `.contains()` over `reduce(true)` or `reduce(false)`SW-P1000 Prefer `contains` over using `filter(where:).isEmpty`SW-P1002 Prefer `contains` over `first(where:) != nil` and `firstIndex(where:) != nil`SW-P1003 Prefer checking `isEmpty` over comparing collection to an empty array or dictionary literalSW-P1004 `@IBInspectable` should be applied to variables only, have its type explicit and be of a supported typeSW-W1006 `try!` statements should be avoidedSW-W1008 When the index or the item is not used, `.enumerated()` can be removedSW-W1002 The initializers declared in compiler protocols such as `ExpressibleByArrayLiteral` shouldn’t be called directlySW-W1027 Avoid using `dynamic` and `@inline(__always)` togetherSW-W1026 Subclasses of `NSObject` should implement `isEqual` instead of `==`SW-W1029 Passing `NSNumber.init` or `NSDecimalNumber.init` as a function reference is dangerous as it can cause the wrong initializer to be used, causing crashes; use `.init(value:)` insteadSW-W1030 Delegate protocols should be class-only so they can be weakly referencedSW-R1029 Prefer using `.last(where:)` over `.filter { }.last` in collectionsSW-P1009 TODOs and FIXMEs should be resolvedSW-D1000 Extensions shouldn't override declarationsSW-R1020 Duplicate import statements are redundant and can be removedSW-W1000 Unused parameters in a closure can be replaced with the underscore identifierSW-W1009 Audit: Use of legacy functions to generate random values can be insecureSW-A1000 Comparing two identical operands is likely a mistakeSW-W1015 Unit tests marked `private` are silently skippedSW-W1016 Void functions should not be used with ternary operatorsSW-W1018 Use of unrestricted base URL in web viewSW-S1000 Use of insufficient number of iterations during hash computationSW-S1001 Audit: Use of potentially insecure options during XML parsingSW-A1001 Prefer using `Array(seq)` over `seq.map { $0 }` to convert a sequence into an ArraySW-R1000 Always specify message when invoking `fatalError()`SW-R1021 Do not name an enum member as `none`SW-R1025 An `XCTFail` call should include a description of the assertionSW-R1032 `@IBOutlet`s shouldn’t be declared as weakSW-W1020 `fileprivate` should be avoidedSW-R1027 Delegates should be weak to avoid reference cyclesSW-W1025 Prefer using the `hash(into:)` function instead of overriding `hashValue`SW-R1001 Use named arguments in multiline Swift closuresSW-R1004 Swift constructors are preferred over legacy convenience functionsSW-R1008 Prefer `.zero` over explicit init with zero parametersSW-R1009 Returning values from a function returning `Void` should be avoidedSW-R1014 Extensions shouldn’t be used to group code within the same source fileSW-R1028 Force casts should be avoidedSW-W1013 self refers to the unapplied `NSObject.self()` method, which is likely not expectedSW-W1017 Implicitly unwrapped optionals should be avoided when possibleSW-W1022 Prefer using `Set.isDisjoint(with:)` over `Set.intersection(_:).isEmpty`SW-R1007 Shorthand syntactic sugar should be used, i.e. `[Type]` instead of `Array<Type>`SW-C1003 `@objc` is redundant when used with implicit Objective-C attributeSW-R1011 Setter access control should be different from the variable's access levelSW-R1013 Avoid using unneeded break statementsSW-R1018 Fallthrough should be avoidedSW-W1012 Types used for hosting only static members should be implemented as a caseless enum to avoid instantiationSW-R1030 String enum values can be omitted when they are equal to the enum case nameSW-R1031 Follow conventions while naming typesSW-C1000 Missing documentation commentSW-D1001 Use shorthand syntax for optional bindingSW-C1001 Prefer `flatMap` over `map` followed by `reduce([], +)`SW-P1008 `where` clauses are preferred over a single `if` inside a `for` loopSW-R1005 `nil` coalescing operator is never evaluated as it's in RHSSW-R1010 Redundant `Optional` initializationSW-R1012 Declare operators as static functions instead of free functionsSW-R1015 Use `#unavailable`/`#available` instead of `#available`/`#unavailable` with an empty bodySW-R1017 Do not explicitly call `.init` methodSW-R1022 Unused control flow label should be removedSW-W1010 Unimplemented functions should be marked as `unavailable`SW-W1014 Use `assertionFailure()` and `preconditionFailure()` over `assert(false)`SW-W1021 Generic type name should only contain alphanumeric characters, start with an uppercase character and span between 1 and 20 characters in lengthSW-C1002 Prefer checking `isEmpty` over comparing `count` to zeroSW-P1005 The constant literal should be placed on the right-hand side of the comparison operatorSW-R1003 Catch statements should not declare error variables without type castingSW-R1019 Empty `XCTest` method should be avoidedSW-W1031 Prefer checking `isEmpty` over comparing `string` to an empty string literalSW-P1006 Function with cyclomatic complexity higher than thresholdSW-R1002

SW-C1003

Shorthand syntactic sugar should be used, i.e. `[Type]` instead of `Array<Type>`SW-C1003

Minor

Style

Using the shorthand syntactic sugar for defining arrays, i.e., [] instead of Array, can make the code more concise and readable. Here are some reasons why:

Readability: Using the shorthand notation can make the code more concise, and it is easier to read and understand. It is a common practice in Swift and most other languages, and most developers expect to see it.

Ease of Use: Using the shorthand notation can make it easier to work with arrays, as it is more natural and requires less typing. It is also easier to remember the syntax, which can save time and reduce the number of errors.

In summary, using the shorthand notation for defining arrays in Swift can improve the readability, and make it easier to use. It is generally recommended to use the shorthand notation whenever possible.

Bad Practice

let numbers: Array<Int> = [1, 2, 3]
let x: Optional<Int>

Recommended

let numbers: [Int] = [1, 2, 3]
let x: Int?