|
|
51CTO旗下网站
|
|
移动端

iOS开发人员的十大基本规则

这份清单纯粹来自我的大脑。这是关于成为一名好的Swift开发者的感觉。我有偏见。这是我在准备课程和制作应用程序时阅读了Swift文档和WWDC视频后发现的。

作者:唐三_iOS来源:简书|2018-05-08 12:00

免责声明:这份清单纯粹来自我的大脑。这是关于成为一名好的Swift开发者的感觉。我有偏见。这是我在准备课程和制作应用程序时阅读了Swift文档和WWDC视频后发现的。

1.缩进,不够快捷。

我看到过很多开发人员编写如下代码,

  1. func neverDoThis() 
  2.   let fuglyCode = true 
  3.   if (fuglyCode == true
  4.   { 
  5.     print("This is atrocious"
  6.   } 

如果我看到上面的代码类型,我真的很难判断。我以为他/她从来没有阅读过API指南/文档或任何人的Swift代码。我们来看看WWDC的苹果工程师如何撰写。

  1. // How Swift engineers would write 
  2. func swiftyWay() { 
  3.   let isLegit = true 
  4.   if isLegit { 
  5.     print("This is fine"
  6.   } 

2.永不使用Try !, as !, String!除非%100确定

如果你一直在附近,确保你了解它们之间的差异,

  1. as asas
  2. try try! try? 
  3. Int IntInt

如果你不知道自己在做什么,并且使用Xcode左侧的那些,你一定会看到“发现意外的零”消息。不要被动。移动你的屁股并理解他们的意思。特别是对于那些参加Udemy初级课程(包括我自己)的人,你需要弄清楚你自己的。

3.不要超过20行功能

我的朋友昨天要我回顾他的代码。一个函数有50行。它涵盖了整个Xcode黑屏。我就像,这个狗屎不会去任何地方。我告诉他,“我不想读你的代码,因为你的代码很糟糕”。我告诉他把它分解成碎片并模块化。真相伤害,但他是我的朋友,我需要真实而清楚。没有废话试图取悦他。

例如,不要写这样的东西,尽管下面的内容不太。。。

把它分解成几块。

4.UI主线程,网络后台线程

多重威胁(由CPU完成的一组任务)的概念令人望而生畏。我不怪你。我没有计算机工程背景,但我仍然不太了解。

我写了两篇文章,为什么你需要使用UI更新的主线程和后台线程进行联网。所以,我会跳过这一部分。

5.不要使Swift文件超过200行

我第一次学习如何制作应用程序时犯了这个错误。我制作了一个包含多个UIViewController类和模型的超过800行的文件。这是我不会重复的。一旦你入侵,你永远不会回去。当然,如果文件是JSON或基于内容的文件,它可能包含数以千计的行。

我不会详细解释所有这些概念,但我会告诉你,你可以学习什么,并使你的整个应用程序更加干净。

有几个方法可以从根本上减少行数并仍然可读。您可以使用UITableVIew和UICollectionView使用面向协议的编程来制作可重用的代码。如果您使用的是代表Massive View Controller的MVC,则可能需要了解MVVM的工作原理。

6.永远不要输入任何东西。

你是否意识到我们可以在Xcode中自动完成许多属性的原因是由于Enums?这看起来很明显,但对初学者来说可能并非如此。

你想在编程中做的最后一件事是硬核打字,而不是挑选。例如,当您创建UIAlertViewStyle时,UIKit工程师创建,

  1. public enum UIAlertViewStyle : Int { 
  2.  case `default
  3.  case secureTextInput 
  4.  case plainTextInput 
  5.  case loginAndPasswordInput 

你能想象打字每个案件吗?我不能,因为我不考虑它,因为这是必须的。不要为自己编写硬编码,而是为了你队友的灰白头发。

7.姓名。具有描述性。造型指南

根据Swift API指南,开发人员应该遵循一些标准。

a.公约>独特性

每种编程语言都有自己的特点和风格。虽然是主观的,但是可以通过阅读在开源项目中编写的Swift文档和Swift文件来找到约定。同样,我强烈建议你看看用Swifty的方式写什么感觉。相反给你举例,我会在下面给你提供资源。

b.表现力>令人印象深刻

有些帅哥喜欢把东西扭曲,让他们感到优越感,因为别人看不懂。这是废话。没有人应该这样做。这完全是关于彼此之间的有效沟通。是的,代码是人类与计算机交流的一种方式。但是,它也在我们之间,开发者和极客之间。请不要成为那个试图用莎士比亚的话来留下印象的傲慢家伙。没必要。

c.清晰度>简洁

Swift的开发者要求我们清楚地说出名字,以便在三周后回来时,我们很好。但是,没有黑色和白色。这是使用描述性名称和减少总体行数的平衡。

“简洁本身不是一个有价值的目标。简洁的代码是使用上下文线索的结果“ -——Doug Gregor,Swift Engineer

  1. // Too brief & Lack of context 
  2. let a = "A" 
  3. let b = "B" 

如果我要阅读上面的代码,我会困惑到底是什么a和b始终。所以,我必须一直找到它们。为什么我们不能通过写作来更具描述性,

  1. // How I would do it 
  2. let capLetterA = "A" 
  3. let capLetterB = "B" 

8.使用Guard

Guard语句不仅可用于展开optioanls,还可用于替换if-else语句,并使用break或using return提前退出函数。它允许任何人识别如果在没有滚动查找其他块的情况下没有满足条件会发生什么。我们来看一个真实世界的例子。

  1. let name = "Bobby" 
  2. func checkName() { 
  3.   // Early Check 
  4.   guard name == "Bob" else { 
  5.   print("You ain't Bob"
  6.   return 
  7.  } 
  8.   
  9.  // I can do anything I want without seeing the else block. 
  10.  // So much freedom 
  11.  // You don't even need to read this 
  12.  // Why are you even reading this 
  13.  // Now, you may leave. I'm not going to say anything important 
  14.  // In this block of code 
  15.   
  16.  // Lol... you still here? 
  17.  print("You Good, bro"

如果您不明白打开option和提前退出意味着什么,请检查下面的资源。

9.如果可以的话,不要使用NS

我没有在Objective C中编写代码,所以我尽量避免它在精神上和身体上都能达到。除非你正在与Objective-C API交互,否则即使Swift自动将一些Objective-C类型转换为Swift类型,并将一些Swift类型转换为Objective-C类型,也远离使用NS。

Swift的确受到Objective-C和其他许多语言的启发,但它是一门独立的语言。我不确定转换速度有多慢,但建议Swift开发人员尽可能避免。由于Swift提供了自己的本地库和API,因此您可以查看替代方案。

“历史笔记:如果你想知道为什么你遇到的很多类都有NS前缀,那是因为可可和Cocoa Touch的历史。可可开始使用收集的框架来构建NeXTStep操作系统的应用程序。当苹果在1996年购买NeXT时,大部分NeXTStep都被纳入到OS X中,包括现有的类名称。 Cocoa Touch作为Cocoa的iOS平台引入; Cocoa和Cocoa Touch都提供了一些类,尽管每个平台都有很多独特的类。像NS和UI这样的双字母前缀(用于iOS上的用户界面元素)保留给Apple使用“。 ——Apple

10.不要依赖分段

当故事板看起来像蜘蛛网时,初学者往往会制造太多的Segues。一旦超出了某个阈值,它就变得难以管理,很难跟踪每个视图控制器。因此,使用Delegate / NSNotification发送数据。使用多个故事板而不是一个。如果您对Delegate感到满意,则可以开始使用RxSwift或ReactiveCocoa传递数据或仅通过几行代码发送通知。

【编辑推荐】

  1. Swift实践:使用CoreData完成一个通讯录存储
  2. TIOBE 11 月编程语言排行榜:iOS开发真没人要了?OC、Swift接连下滑
  3. 谷歌搞事情,Fuchsia OS操作系统运行Swift代码
  4. Swift多线程:GCD进阶,单例、信号量、任务组
  5. 谷歌开源 Swift for TensorFlow:我们是不是终于可以放下Python了?
【责任编辑:未丽燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

Microsoft SQL Server 2005技术内幕:存储引擎

本书是Inside Microsoft SQL Server 2000的作者Kalen Delaney的又一经典著作,是Inside Microsoft SQL Server 2005系列四本著作中的一本。...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊