16

How to fix Line Length Violation?

Relevant part of alert message that isn't allowed due to Line Length Violation: message: NSLocalizedString("\nYou will be requested to Use %@ to Sign In. %@ doesn't share any information about you. The permission is required to post your Live Video.", ⚠ Line should be 120 characters or less: currently 208 characters (line_length)

Yatko
  • 8,715
  • 9
  • 40
  • 46

3 Answers3

34

Make the line shorter:

message: NSLocalizedString(
    ["\nYou will be requested to Use %@ to Sign In. ",
    "%@ doesn't share any information about you. The ",
    "permission is required to post your Live Video."].joined()
)

or better, using vacawama's multi-line solution:

let message = 
    """

    You will be requested to Use %@ to Sign In. \
    %@ doesn't share any information about you. \
    The permission is required to post your Live Video.
    """

That's a generic solution, but isn't really appropriate for NSLocalizedString because it breaks tools that scan for localized strings like genstrings.

Your other solution is to turn off the warning for that line by adding a disable on the line immediately before:

// swiftlint:disable:next line_length

See Disable rules in code for full details on disabling swiftlint rules.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • 8
    If you end the lines with backslash it won't introduce newlines. – vacawama Feb 24 '18 at 18:22
  • @vacawama whoa… I didn't know that. That's awesome. – Rob Napier Feb 24 '18 at 18:25
  • 1
    Disabling linting rules is never a good solution. If you start doing that, there is no point in having a linter in the first place. The root problem is the fact that localization tools want you to use the default message as the localization key. There is no point in putting the whole message in code, a simple string code, e.g. "sign_in_info' would work too. – Sulthan Feb 24 '18 at 18:34
  • I disagree that disabling linting rules is never a good solution. If that were true, they would be compiler errors. The fact that we separate even warnings from linting is intentional. Linting is intentionally over-strict. Even Go, where things as benign as failure to use a variable is a compile-time error, there is still a linter (govet) that is sometimes correct to ignore. The correct choice between shortened localization keys versus using automated tools has no universal answer. Saying "the linter forbids using Apple's localization tools" is a foolish consistency. – Rob Napier Feb 24 '18 at 19:07
  • 2
    (I say this as a long-time advocate for there being a "1 true Swift style" such that clang-format would enforce exactly one way lay out Swift code. Even if I'd had my way, there would be times to ignore a linter. http://openradar.appspot.com/radar?id=5886836526284800) – Rob Napier Feb 24 '18 at 19:10
  • `// swiftlint:disable:next line_length` is the answer we found best – Yatko Mar 14 '18 at 22:41
30

In this case just update your line_length rule with ignores_interpolated_strings like this:

line_length:
  warning: 120
  ignores_function_declarations: true
  ignores_comments: true
  ignores_interpolated_strings: true
  ignores_urls: true

and make sure you are using last version of swiftlint (it was added just a few weeks ago)

ethanhuang13
  • 483
  • 5
  • 13
Ilya Ilin
  • 2,283
  • 21
  • 27
4

This line added in .swiftlint.yml rule file its works for me

# implicitly 
line_length: 110
kishor soneji
  • 795
  • 1
  • 9
  • 16
  • Where i can find this file .swiftlint.yml? I have installed through brew commands, will this in be my project folder as hidden? – – karthikeyan Oct 27 '22 at 13:57