基础知识：Swift最佳做法
最近，我的伙伴对编程表现出了兴趣，因此自然而然地我推荐Swift作为一种很好的语言。 我花了很多时间亲自研究了Swift的最佳实践，我想确保她确实遵循了整个Swift社区的最佳/常见实践（我认为其中有些是最佳实践），并且没有从一些那里的教程。 即使这些教程为初学者提供了一个很好的起点，我也注意到一些确实困扰我的做法，我建议您反对。
注意
我应该指出， 这要取决于我在编写Swift代码时的最佳做法以及我在社区中的研究中所收集的内容。 我敢肯定会有人不同意，这很好。 我仍然会睡个好觉😉
首先，让我们从合作伙伴搜索初学者教程时遇到的编码实践开始。 我还将介绍与其他开发人员一起进行项目时所经历的一些经验。
1）冒号空间
尽管这看起来很小，因为它只是一个空格，但是它可以大大提高代码的可读性。
推荐的
命名：字符串
不建议
让名字：字符串
命名：字符串
让名字：字符串
简单。 在冒号之后，在类型之前添加一个空格。
2）花括号
当谈到花括号时，通常似乎是一个意见问题。 但是，在浏览互联网上的一些样式指南，Apple文档中的示例以及我个人的看法时，确实有一个赢家。
推荐的
如果isValid && list.count == 0 {
...}否则，如果isValid {
...}其他{
...
}
不建议
如果isValid && list.count == 0 {
...}
否则，如果isValid {
...}
其他{
...
}
要么
如果isValid && list.count == 0
{
...}
否则，如果isValid
{
...}
其他
{
...
}
要么
如果isValid && list.count == 0
{
...}否则为isValid
{
...}其他
{
...
}
要么
如果isValid && list.count == 0 {
...}否则，如果isValid {
...}其他{
...
}
请直接在}注意else 。 我一直都这样做，一旦切换到上面的“推荐”方式，我的代码的可读性似乎在使用if-else语句if-else大大提高了。
3）协议一致性
初学者教程中的协议一致性总是倾向于在类声明中进行。 尽管这样做可以更快地编写本教程，但它会向最有影响力且不知道有更好方法的初学者开发人员养成良好的习惯。 这通常会导致大量，结构化的文件。
推荐的
最后的类CustomClass：UIViewController {...}
扩展CustomClass：UITableViewDataSource {...}
扩展CustomClass：UITableViewDelegate {...}
不建议
类CustomClass：UIViewController，UITableViewDataSource，UITableViewDelegate {...}
这是增加代码可读性的另一种方法。 随着类的增加，它还在整个代码中提供了逻辑上的概念分离。
到现在为止，您可能会看到我对干净易读的代码有偏见。
4）命名约定
命名约定在初学者指南中并不常见，但值得一提。 在Swift中， 用于类，结构，协议等名称的最常用约定是camelCase或UpperCamelCase 。 比起我想承认的更多，我碰到了混合了camelCase ， UpperCamelCase和snake_case （真的吗？在Swift中是snake_case吗？）
推荐的
让myConstant：CGFloat
类CustomClass {...}
不建议
让MyConstant：CGFloat
var my_variable：CGFlat
class customClass {...}
class custom_class {...}
既然我们已经看到了一些我认为不是最佳实践以及如何实现相同概念的示例，那么我将提供一些示例和其他提示，以便在编码时牢记。
注意
我为什么建议以下内容的某些概念可能对于初学者而言太高级了，无法立即理解。
1) final课程和私有常量/变量
我与之合作的大多数开发人员似乎忽略了Swift中的final类和private变量。 通过使用这些关键字，您可以提高应用程序/程序的性能。 [1]
推荐的
最后一堂CustomClass {...}
私人让myConstant = 1
如果您是初学者，请注意使用这些关键字。 您只应在不会被子类化的类上使用final 。 同样， private将限制对该变量的访问。
即使谨慎起见，我还是建议一开始总是宣布一个新的班级为final 。 并在以后需要更改它时进行更改。 这样一来，您就养成了始终将final关键字添加到您的类中的习惯-制作它，并提高应用程序的整体性能，这是第二天性。
2）解包可选
Swift中的可选选项很棒。 但是，完全无视它们并一直强迫展开它们并不是一个好习惯。 就我个人而言，我讨厌看到一连串的武力解开了选装件。
在处理可选组件时， 几乎应该永远不要强制拆开它。 而是使用if-let语句， guard语句，或者提供默认值（如果该值为nil 。
推荐的
如果让name = dict [“ name”]为？ 字符串{...}
要么
警卫队让name = dict [“ name”]为？ 其他字符串{return}
不建议
let name =（dict as！[String：Any]）[“ name”] as！ 串
同样，如果您是初学者，我敦促您阅读guard声明，以便您可以有效地使用它们。 作为过去的初学者，我以前滥用过guard 。 它可能会导致一些不利的副作用。
3）评论
注释。 我曾经绝对鄙视评论。 我以为他们是浪费时间，并且阻止了我将更多的时间花在学习上。 我还发现，如果不及时更新它们，将造成更多的伤害，而不是有益的。 由于您可能需要多次更新它们，因此即使保持最新状态也带来了挑战。
尽管最后两句话是正确的，但在我的个人代码中，如果我更改了与该注释相关的代码块，我总是会尽力更新该注释。 我的未来自我总是为此而感谢我。
我非常不喜欢评论的原因之一是因为我发现自己做错了。 当有人要我对我的代码进行注释时，我会做出无用的注释，而这些注释都与注释无关。 该代码已经很好地解释了它。 不幸的是，从来没有人告诉我这是错的，所以我对评论的仇恨越来越大。
一个夸大的例子是：
//将y和z加在一起
令总和= y + z
这种类型的评论毫无价值。 您无需评论即可清楚地看到正在发生的事情。
注释应说明为什么要按原样进行，或者应使用注释来更好地了解可能需要更详细说明的复杂代码块。 Swift代码具有表现力； 完整的英语句子甚至更具表达力。 我建议注释您代码的另一个原因是，当您从一年后回到代码时，您可能会想：“为什么我要按此顺序执行？”。 通过添加注释来解释为什么以某种方式完成某项操作，其他开发人员（或您将来的自己）可以知道为什么以某种特定方式完成某项操作。
尽管本文的标题为“ Basics”，但它确实涉及一些稍微高级的主题。 但是，重点是要解决在那里的初学者教程中发现的一些不良做法，并尽早减少使用。 长期坚持下去，很难改掉坏习惯。 希望本指南能使您在开始/继续进行编码时牢记最佳实践。 无论是您的业余爱好还是职业，您都应该专注于编写可以编写的最佳代码。
[1]通过减少动态调度来提高性能，https：//developer.apple.com/swift/blog/？id = 27