使用SwiftLint和Danger进行Swift最佳实践

该帖子最初出现在 Swift Post中 ,可在 此处找到

苹果公司的Swift在开发者社区中越来越受欢迎。 我们大多数人已经开始适应我们的项目。 在采用时,我们可能没有像我们应该的那样谨慎,因为Swift是一种非常灵活的语言,很容易滥用它。 特别是来自Objective-C文化,应用最佳实践变得非常重要。

阅读了Göksel的Swifty Tips之后,我意识到可以使用SwiftLint自动检查他的一些技巧。 另外,我们是懒惰的人,我们往往会忘记合并之前就检查我们的代码。 就在这里, 危险穿着闪亮的衣服登上舞台,并指出我们在做危险的事情。

听起来很有趣。🤔但是这些工具实际上是什么?

SwiftLint💪

SwiftLint是用于实施Swift样式和约定的开源工具。 它是由Realm开发的。 您可以设置编码样式规则,并在开发过程中强制执行。 SwiftLint具有命令行工具,Xcode插件,AppCode和Atom集成。 因此,它始终适合您的开发环境。 如果您违反棉绒规则,它将向您显示警告和/或错误。

您可以从此处查看设置指南和教程。 安装后,默认情况下您将具有一些规则。 例如,当您使用私有IBOutlet或在可选选项中强制展开时,它会发出警告。

让我们看看Göksel的技巧。 他说:“切勿使用隐式解包可选内容”。 SwiftLint默认情况下完全按照他的描述提供此功能。 当您隐式打开一个可选项(除非它是IBOutlet)时,SwiftLint会警告您。 另一个是“避免_滥用”。 SwiftLint足够聪明,可以指出您何时不使用绑定的可选项目。

if let _ = Foo.optionalValue { } // Trigers a warning 
if case .some(let _) = self {} // Triggers a warning
if foo(){let _ = bar()} //不触发警告
if foo(){_ = bar()} //不触发警告

除了单独应用最佳实践,我们还希望使代码库保持一致。 使自定义规则更容易应用。 但是,这些规则应符合最佳做法。 可从.swiftlint.yml文件处理配置棉绒 。 该文件位于项目的主路径中。 我们可以在此YML文件中启用,禁用或编写自定义规则。 让我们看一些例子。

首先,编写大型函数通常是一个不好的信号。 如果您的职能越来越大,则意味着您应该分担责任。 将以下代码段添加到您的.swiftlint.yml文件。 这警告开发人员功能少于200行。 如果程序员达到300,则SwiftLint会生成错误。 请记住,您可以忽略警告,但不能忽略错误。 😉

  function_body_length: 
-200#警告
-300#错误

几乎每个项目都具有无法更改的依赖项或代码段。 这些代码片段不应完全删除。 例如,如果一个项目使用CocoaPods作为依赖项管理器,则它将具有Pods文件夹,该文件夹将保留所有依赖项文件。 我们需要将该文件夹从整理过程中排除。 正如您在下面看到的那样,这非常容易。

 排除: 
-豆荚

公司准则或项目中的开发人员都具有编码风格。 SwiftLint帮助新移民在入职过程中采用这些样式。

从示例中可以看出,SwiftLint的额外优势在于灵活性。 有时,您必须在特殊行或文件中违反规则。 这些情况在SwiftLint中以特殊注释处理。 在这些情况下,可以使用以下内容调整规则。

添加此注释以禁用文件中的规则:

//swiftlint:disable rule_name

添加此注释以禁用以下行中的规则:

//swiftlint:disable:next rule_name

添加此注释以禁用上一行中的规则:

//swiftlint:disable:previous rule_name

您可以通过在终端中运行swiftlint rules命令来获取所有规则的列表。 😏

最后,我们完成了规则,现在我们可以和平地进行编码了。 但是,即使在某些情况下,您也必须比仅应用棉绒规则更加谨慎。 这就是危险发生的地方。

PS:您可以在here中找到我的预定义的.swiftlint.yml文件。

危险⚡️

每个项目/代码段都有自己的特定流程。 随着项目的发展,维护和添加新功能变得更加困难。 容易出错。 仅仅拥有编码准则和应用最佳实践通常是不够的。 我们是人类,我们会犯错误。 危险可以捕获基本错误,让我们思考更棘手的问题。 例如,它可以捕获常见的输入错误或生成的文件更改,而您不应自己更改这些更改。 如果编写的代码超过20行,它也可能会迫使您编写测试。 这些规则与SwiftLint一样在您手中。

危险是在提取请求/合并请求过程中在CI中运行的Ruby gem。 当您的规则被违反时,它会留下消息,评论或什至使您的配置项构建失败。 Danger可以在多种CI工具上运行,并且可以在GitHub,Bitbucket和GitLab上聊天。

危险可能会在PR / MR上留下消息,警告和错误。 资料来源:danger.systems

您可以按照此处的安装指南将Danger安装到CI流程。 Danger应用Dangerfile中编写的Ruby脚本中的规则。 让我们看看我们在那里可以做什么。

为了单一责任和简化代码审查,开发人员不应打开大型请求。 如果拉取请求的代码行超过600行,则应发出警告,以拆分拉取请求。 危险可以通过单行配置来提供:

 如果git.lines_of_code> 600,则警告“大公关,请考虑将其拆分成较小的” 

还有什么? 如果您正在使用“测试后”开发过程,则可以轻松地忘记编写测试。 另一方面,应该为“您忘记添加测试”注释提供一种自动方式。 通常,如果您更改20行以上的代码,则应编写测试。 行数取决于您的决定,但是您知道了。 让我们来看看如何使用Danger来实现:

  ##让我们检查项目文件夹中是否有任何更改 
has_app_changes =!git.modified_files.grep(/ ProjectName /)。empty?
  ##然后,我们应该检查测试是否已更新 
has_test_changes =!git.modified_files.grep(/ ProjectNameTests /)。empty?
  ##最后,让我们将它们组合起来并放入额外条件 
##用于更改代码行数
如果has_app_changes &&!has_test_changes && git.lines_of_code> 20
失败(“测试未更新”,粘性:false)
结束

危险适用于各种项目。 它通过插件为多种语言提供了广泛的配置。 在Swift的情况下,Ash Furrow为SwiftLint开发了一个插件。 多亏了这个插件,我们才能在Pull请求中将SwiftLint警告作为内联注释。 您可以在此处查看安装指南。 安装后,您需要在Dangerfile的末尾添加以下行之一。

  swiftlint.lint_files 
swiftlint.lint_files内联模式:true

Dangerfile确保您的开发准则适用于您的代码。 它使您更加自信。 从长远来看,警告会教您多加小心。 这里有一个参考指南,可让您更详细地了解Danger的功能。

注意:您不必配置CI。 可以使用本地danger local命令在本地计算机上运行危险。

感谢Eren的响应,如果在上次打开的PR上未运行danger local命令,则始终可以使用以下命令:

 危险pr https:// YOUR_PR_URL --dangerfile = YOUR_DANGERFILE_PATH 

PS:您可以在here中找到我预定义的Dangerfile

奖励:SwiftLint和Git Hook

如果您正在使用SwiftLint不支持的其他文本编辑器或IDE,则只能使用命令行工具来整理代码。 这是一个额外的步骤,很容易忘记。 好东西,我们可以自动化。 Git中的Hook功能是另一个使事物自动化的地方。 基本上,Git钩子是脚本,在该脚本中,Git在诸如提交,推送和接收之类的事件之前或之后执行。 我们可以在这些脚本之一中运行SwiftLint。 就个人而言,在Sublime Text中编写Swift时,我在pre-commit钩中使用了SwiftLint。

PS:您可以在😉中找到我完整的预提交钩子。 如果要使用相同的文件,只需将上面的文件放在项目内的.git / hooks文件夹下。 (您将在其中看到示例挂钩脚本。将它们放在其中。)您还可以将其用作其他挂钩。 您可以在此处查看可用挂钩的列表和更多信息。

结束😌

让Danger和SwiftLint为您处理琐碎的事情。 从现在开始,您可以跳过基本问题,而在代码检查过程中专注于更复杂的事情。 SwiftLint和Danger确保一切都在您想要的位置。 要试试吗?