Commit Graph

21 Commits

Author SHA1 Message Date
Martin Redington 04791929a7
Improve `identifier_name` documentation (#4784) 2023-02-25 20:02:02 +01:00
kyounh12 5ec6112ba1
Interpret strings in `excluded` option of `*_name` rules as regex (#4655) 2023-01-10 23:29:04 +01:00
Danny Mösch 74dbd52add Fix/improve some rule descriptions 2023-01-10 22:29:13 +01:00
JP Simard 4ccf9eebb4
Fix line count calculation for multiline string literals (#4587)
Fixes https://github.com/realm/SwiftLint/issues/4585

Update body length rule thresholds for SwiftLint
2022-11-24 16:40:51 +00:00
JP Simard 4bd7da32ea
Reduce visibility of rules to be `internal` (#4533)
There's no reason to expose these publicly and this will make it nicer
to move to a new module outside of the core SwiftLint functionality.
2022-11-09 11:01:26 -05:00
JP Simard fa6bf50a22
Rethink body line count calculation (#4369)
A long-standing limitation with SourceKit's "editor open" request is
that we weren't able to get certain tokens, such as braces, brackets and
parentheses.

This meant that this code block would be counted as two lines:

```swift
print(
  "hi"
)
```

because the trailing `)` would be treated as a whitespace line.

This meant that our "body length" family of rules that measure the
effective line count of declarations like functions, types or closures
would often significantly under-count the number of content lines in a
body.

Now with SwiftSyntax, we can get all tokens, including the ones
SourceKit was previously ignoring, so we can get much more accurate line
counts when ignoring whitespace and comments.

In addition, we weren't very thorough in how we measured body length.

As an exercise, how many lines long would you say the body of this
function is?

```swift
func hello() {
  print("hello")
}
```

Does the body span one line or three lines?

I propose that we consistently ignore the left and right brace lines
when calculating the body line count of these scopes so that we measure
body line counts like this:

```swift
// 1 line
{ print("foo") }
// 1 line
{
}
// 1 line
{
  print("foo")
}
// 2 lines
{
  let sum = 1 + 2
  print(sum)
}
```

Now with those changes in place, in order to keep the default
configuration thresholds to similar levels as before, we need to adjust
them slightly. Here's what I'm suggesting:

|Rule|Before|After|
|-|-|-|
|closure_body_length|20/100|30/100|
|function_body_length|40/100|50/100|
|type_body_length|200/350|250/350|

This is a pretty significant breaking change and I suspect we'll hear
from users who are surprised that some of their declarations now exceed
the rule limits, but I believe this new approach to calculating body
lines is more correct and intuitive compared to what we've had until
now.

OSSCheck is also going to report a bazillion changes with this, which is
expected given the scope of this change.
2022-10-14 03:16:26 -04:00
Chris Brakebill 9db303e3a3
Respect 'validates_start_with_lowercase' for function names in `identifier_name` rule (#4188) 2022-09-09 23:36:55 +02:00
Danny Mösch d730e0b3fa
Let all example verification tests be generated by Sourcery (#4076) 2022-08-10 22:49:28 +02:00
Danny Mösch 449190d324
Verify examples in rules by default and enforce explicit exclusion (#4065)
A rule must conform to ManuallyTestedExamplesRule to skip generation of a test for its examples.
2022-08-09 22:32:09 +02:00
Marcelo Fabri db2721f78e
Require Swift 5.0 in runtime (#3886)
* Require Swift 5.0 in runtime

* Fix violation

* Enable legacy_rule by default

* Update changelog

* Fix changelog after rebase

* More cleanup
2022-03-11 14:01:27 -08:00
Artem Garmash 67114bb729
Exclude `id` from `identifier_name` by default (#3730) 2021-10-04 21:13:40 +00:00
JP Simard d628c41665
[IdentifierNameRule] Allow "allowed symbols" as first character (#3403)
This means that if `allowed_symbols` contains `_`, you can now write
identifiers like `let _myLet`.

Fixes https://github.com/realm/SwiftLint/issues/3306
2020-11-07 09:54:04 -08:00
Marcelo Fabri f8ef7d649c Enable legacy_multiple and prefer_self_type_over_type_of_self in our codebase 2020-08-05 01:11:17 -07:00
JP Simard fe5baca7cd
Migrate to use SourceKitten's new ByteCount/ByteRange types (#3037)
New APIs were introduced in SourceKitten to allow for a more typesafe distinction between integers meaning NSString-based distances and byte-based distances.

* https://github.com/jpsim/SourceKitten/pull/639
* https://github.com/jpsim/SourceKitten/pull/642

This PR migrates SwiftLint's use of those APIs.
2020-01-16 15:18:37 -08:00
Paul Taykalo ac40778cb3 Use SwiftLintFile wrapper over the File 2019-11-07 15:19:17 +02:00
Paul Taykalo 8c963d2c15 Working solution with SouceKittenDictionary wrapper 2019-11-07 08:50:50 +02:00
JP Simard ffb2f4f76d
Require Swift 5.0 to build (#2857)
* Require Swift 5.0 to build

* Update CI

* Stop testing with Swift 4.x & Xcode 10.0/10.1
* Use official Swift docker image instead of norionomura's
* Use Xcode 10.3 as latest stable version

* Update READMEs

* Fixup xcodeproj

* Fixup CI Swift container image tag

* Fixup changelog
2019-09-03 11:42:57 -04:00
Marcelo Fabri b24fd6cdd4 Enable `contains_over_filter_is_empty` in SwiftLint itself 2019-08-25 20:58:11 -07:00
JP Simard f08c3e4239
Use firstIndex(where:) instead of index(where:) (#2600)
to silence a Swift 5 warning. This is compatible with Swift 4.2.
2019-01-27 20:19:16 -08:00
JP Simard 0e862ca9c4
Enable vertical whitespace rules in SwiftLint
and fix violations
2018-12-02 14:01:23 -08:00
JP Simard 3961d6482b
Organize rules by kind in Xcode project (#2341) 2018-08-05 18:54:05 -07:00