Swift

Swift

Made by DeepSource

Categories

Programming language

Latest version

v0.6.1

Updated on

May 7, 2024


Total issues

83

Autofix

22

Sample configuration

version = 1

[[analyzers]]
name = "swift"

  [analyzers.meta]
  swift_version = "5.8"
  skip_doc_coverage = [
    "struct",
    "enum"
  ]

Stats


Anti-pattern

30

Bug risk

27

Documentation

2

Performance

13

Security

7

Style

4

Issues


View all
Comparing two identical operands is likely a mistake SW-W1015
Bug risk

Comparing two identical operands in a binary operator can be a mistake. If two identical operands are used in a binary operator, the result is always predictable and will always be true. This can lead to unintended consequences if the code is meant to compare two different variables.

Audit: Use of legacy functions to generate random values can be insecure SW-A1000
Security

Legacy functions like arc4random() or arc4random_uniform() should not be used for generating random numbers. These functions are provided through imported C APIs, and depending on the platform that is executing the code, their underlying implementations can be unsafe.

Prefer using min() or max() over sorted().first or sorted().last SW-P1011
Performance
Autofix

Using sorted().first or sorted().last can be inefficient, as the entire collection needs to be sorted, which is not required if we only need the minimum or maximum element. This can cause performance issues, especially when dealing with large collections.

Duplicate import statements are redundant and can be removed SW-W1000
Anti-pattern
Autofix

Duplicate import statements are redundant and can be removed from Swift source code. Importing an entity twice does not add any value and can clutter the code. It can lead to increased build times and difficulties in debugging and maintaining the codebase.

try! statements should be avoided SW-W1008
Bug risk

Force tries in Swift should be avoided as they can lead to runtime errors and make error handling difficult. Force tries are denoted by using a try! statement before a throwing function call. It basically makes an assertion that although the function has the ability to throw an error, it will not throw in this particular scenario and you want to skip the error handling.