zoukankan      html  css  js  c++  java
  • swiftlint 你所要知道的所有!!

     

    swiftin

    Should the opening brace of a function or control flow statement be on a new line or not ?:) This and many other questions cross my mind when I think about coding style. I love the comment from Ray Wenderlich’s Swift style guide:

    "You like braces on new lines @elephantronic ? This will strain our friendship!" …hehe, so it really does matter!:)

    But coming back to the main subject: This year one of the items on my to do list is a task to learn more about static code analysis tools: linters, Sonar and everything else that can fight against bad smells. In our previous post Maciej mentioned more about code quality and about Codebeat. Today I would like to concentrate on SwitLint, which can help us keep cohesion in our code without straining friendships in our project team:)

    SwiftLint checks the source code for programmatic as well as stylistic errors. This is most helpful in identifying some common and uncommon mistakes that are made during coding. SwiftLint is based on guidelines from Swift style guide. Simply saying it can just helps us with:

    • maintaining a higher level of code discipline,

    • increasing the reliability of the code.

    Installation

    • using brew:
    • or by downloading and installing a fresh release.

    Necessary after installation check version using command swiftlint versionand compare it to the latest version available on website.

    Running

    We have two options:

    • just type the following command in the Terminal:
    • or we can integrate SwiftLint with Xcode:
    RunScriptRunScript

    Just for the test I have run SwiftLint with default options in my current project and I wish I had been using it from the beginning of the project  :

    SwiftLint Rules

    All available rules which you can use are here.

    If you want to have a possibility to control which rule is disabled/enabled and to set thresholds for warnings and errors for a given rule, just create a .swiftlint.yml file in your project directory:

    swiftlintYMLswiftlintYML

    You can download the example configuration file from here.

    Now by typing in the Terminal swiftlint rules you can check your settings:

    SwiftLintRulesSwiftLintRules

    Running Options

    Sometimes running options can be very useful. Let’s focus on them:

    • -- path The path to the file or directory. For example if you want to lint only one file:
    • -- config The path to SwiftLint’s configuration file .swiftlint.yml:
    • -- use-script-input-files read SCRIPT_INPUT_FILE* environment variables as files. When using this parameter can be useful? For example when we only would like to lint modified files and new files tracked in our github repository. Example of usage which I found here:
    • -- quiet flag that prevents status messages like ‘Linting ‘ & ‘Done linting’ from being logged.

    • -- reporter generates report with selected format: JSON, Checkstyle, CSV, Xcode. For example:

    Autocorrect

    Very nice feature of SwiftLint is the auto-correction swiftlint autocorrect, which can automatically fix violations in your code. What type of violations can we fix?

    • Closing brace. Closing brace with closing parenthesis should not have any whitespaces in the middle:
    closingBraceclosingBrace
    • Colon. Colons should be next to the identifier when specifying a type:
    colonRulecolonRule
    • Comma Spacing. There should be no space before and one after any comma:
    commaRulecommaRule
    • Legacy Constant. Struct-scoped constants are preferred over legacy global constants:
    legacy_constant

    Very nice article explaining the why.

    • Legacy Constructor. Swift constructors are preferred over legacy convenience functions:
    legacy_constructor
    • Opening Brace Spacing. Opening braces should be preceded by a single space and on the same line as the declaration:
    opening_brace
    • Statement Position. Else and catch should be on the same line, one space after the previous declaration:
    statement_position
    • Trailing Newline. Files should have a single trailing newline:
    trailing_newline
    • Trailing Semicolon. Lines should not have trailing semicolons:
    trailing_semicolon
    • Trailing Whitespace. Lines should not have trailing whitespace:
    trailing_whitespace

    Cyclomatic Complexity

    In SwiftLint you can find very nice rules, for example:

    • File length rule: Files should not span too many lines.
    • Function Parameter Count: Number of function parameters should be low.
    • Type Body Length: Type bodies should not span too many lines.
    • Type Name Rule: Type name should only contain alphanumeric characters, start with an uppercase character and span between 3 and 40 characters in length.

    But when I first looked at the rules list my attention was captured by the Cyclomatic Complexity rule. What is this? Wiki says:

    "is a software metric (measurement), used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program’s source code."

    This parameter just says how complex our functions are. To many ifs are not recommended. If you add 3rd nested if, you should wait a moment and reconsider your solution. This is my weakness, because sometimes I propose really overcomplicated solutions for quite easy problems: it can always be done much simpler… great rule for using by me:) How to add this bodyguard to your config file? Just add it on the end on .swiftlint.yml:

  • 相关阅读:
    iOS开发日记1-tableview编辑
    nginx安装-del
    linux服务器su之后变成bash-4.1#
    PhoneGap & HTML5 学习资料网址
    PhoneGap通信机制的实现原理
    Android调用Java WebSevice篇之二
    Android调用Java WebSevice篇之一
    Java开发牛人十大必备网站
    百度地图生产工具
    PS制作圆角透明图片
  • 原文地址:https://www.cnblogs.com/lidarui/p/8318718.html
Copyright © 2011-2022 走看看