Swift lint 사용

저는 swift lint와 이걸 소개하는 학습회 영상을 받았는데 끝까지 못 참았어요.
몇 번째 원문 정지가 더 행복하지 않나요?알아차렸기 때문에 겸사겸사 스스로 총결해 봅시다.
그래서 이거.
realm/SwiftLint: A tool to enforce Swift style and conventions.

뭐 공부 해요?

lint라고 들었어요.문법을 분석하는데 뭐가 틀린 놈이야.그거 스위프트 버전.마치.
좋은 설정을 통해 지정된 규칙을 따르지 않는 글쓰기를 발견하면 오류와 경고로 시끄럽게 된다.참 오지랖이 넓다.
팀 업무에서 인코딩 규칙을 강제로 집행할 때 틀림없이 매우 편리할 것이다.

설치하다

Homebrew는 징그러워서 안 써도 돼요.
어차피 자기가 쓸 줄 몰라서 이렇게 종목을 욕하는git.

cd <project_dir>
git submodule add https://github.com/realm/SwiftLint.git

이렇게 하면 디렉터리를 만들 수 있으니 설치하세요.중간에 관리자 권한 요청

cd swiftLint; make install

이어서 Xcode Project를 호출합니다.
Target 구축 단계가 열리고 왼쪽 상단의 +에 새 실행 단계가 추가되었습니다.틀린 문장을 살짝 놀렸다.

if which swiftlint >/dev/null; then
  swiftlint
else
  echo "warning: SwiftLint not installed. To install, run 'cd <proj_dir>/swiftLint; make install'"
fi

lint이기 때문에 Comple Sources 이후에 실행
마우스로 드래그하여 이동합니다.
cmd-b로 구축, 오류와 경고가 산처럼 대량 생산, lint 씨가 싫어하지 않으면 성공합니다.

구성 파일 만들기

파일이 프로젝트의 디렉터리에 배치되도록 설정하면 됩니다 .swiftlint.yml.
우선 Pods와 SwiftLint를 제외합니다.

cd <project_dir>
vi .swiftlint.yml

# Swift Lint Rules

excluded: # excluded directory
  - Pods
  - SwiftLint

참고로 코드에 특정 기법에 대한 평론을 써도 조작할 수 있지만 어차피 하지 않는다.원래 하지 말았어야 했는데.

// swiftlint:disable <rule>
// swiftlint:enable <rule>
let noWarning2 = NSNumber() as! Int // swiftlint:disable:this force_cast

설정 작성

경고!!!
...이기 때문에 순서대로 죽인다.

마지막에 주목(trailing_whitespace).이것은 규칙명인 것 같다.
규칙에 관해서는 출처를 읽어주세요!본격적인 던지기 자세.
See the Source/SwiftLintFramework/Rules directory to see the currently implemented rules.
그러니'벌써 다 됐다'는 마음으로 바라보자.

// SwiftLint/Source/SwiftLintFramework/Rules/TrailingWhitespaceRule.swift
public func validateFile(file: File) -> [StyleViolation] {
        return file.lines.filter {
            $0.content.hasTrailingWhitespace()
        }.map {
            StyleViolation(ruleDescription: self.dynamicType.description,
                severity: configuration.severity,
                location: Location(file: file.path, line: $0.index))
        }
    }

이것은 무엇입니까...
공행하면 예외를 두는 게 일반적인데 왜 설정의 여지가 없지?
이럴 때...

이 경우 disabled_rules: 네가 쓰면 규칙이 무효가 되고 평화가 온다.

disabled_rules:
  trailing_whitespace #since has no option to treat empty line,,,

추적 후 cmd-b를 한 번 더 하면 경고가 사라집니다.
그래, 그래.
그리고 무의미한 엄격한 행수 제한을 용설란주에 완화시킵니다.

line_length: #max length of each line
  warning: 200
  error: 500

type_body_length: #max line num of class body
  warning: 1000
  error: 3000

이렇게 하려면 우선 살육이 끝난 규칙부터 시작해야 한다.태그 요소의 표시 속성을 수정합니다.
한마디로 현 상황은 이렇다.완전 개인 주관이야.

disabled_rules:
# vvv will never enable
  - trailing_whitespace
  - opening_brace
  - closing_brace
  - statement_position
  - todo
  - force_cast
  - force_try
  - file_length
  - cyclomatic_complexity
# vvv may enable in someday
  - return_arrow_whitespace
  - control_statement
# vvv may enable in nearday
  - legacy_constructor
  - legacy_constant
  - trailing_newline
#

사용자 정의 규칙

지금까지 표준 규칙의 아쉬움 정도를 알아본 여러분의 기쁜 알림은 사용자 정의 규칙을 정의할 수 있을 것 같습니다.
정규 표현식을 쓰면 돼요.
예를 들면, 이런 느낌.
class와func의 선언 사이에 빈 줄을 넣으세요.

custom_rules:

  spacer_line:
    name: "Spacer Line"
    regex: "(\}\n)([ \t]*)((public )|(private )|(internal )|(override ))*((class)|(func))"
    message: "Need empty line between func or class"
    severity: error

이후match_kinds 형태 분석 결과 때문에 범위를 좁힐 수 있을 것 같지만 어느 것이 무엇으로 처리되었는지는 수수께끼로 사용할 수 없어 아쉽다.
(지금) 기세의 정규 표현식으로 겨우 얼렁뚱땅 넘어갈 수밖에 없다.

감상

최초의 오류 수는 놀랍지만 필요하지 않은 것을 블랙리스트에 넣으면 축소 기능을 사용할 수 있다.
warning/error는 Xcode에서 처리할 수 있기 때문에 구축이 느려지는 것 외에는 모두 가능합니다.
사칭이 어디에 있든 (쉽게 읽히면) 무엇이든 좋습니다. 자신에게는 규칙을 어기면 warning을 보내게 하고,commit 전에 조금만 정리하고 사용하면 편리할 수 있습니다.
또한 {를 if의 다음 줄에 쓰는 것을 허락하지 않기 때문에 이 점에서 전쟁···원래는 사전협상이 중요하다.

기타

실수가 많네요.근데 코드가 기억이 안 나요.
이렇게 생각하면 Swift Lint가 자신의 코드를 평가하고 경고와 오류를 내뱉는 것은 정말 록적이다...