免責聲明：這份清單純粹來自我的大腦。這是關(guān)于成為一名好的Swift開發(fā)者的感覺。我有偏見。這是我在準備課程和制作應(yīng)用程序時閱讀了Swift文檔和WWDC視頻后發(fā)現(xiàn)的。

1.縮進,不夠快捷。

我看到過很多開發(fā)人員編寫如下代碼， 

func neverDoThis() 
{ 
  let fuglyCode = true 
  if (fuglyCode == true) 
  { 
    print("This is atrocious") 
  } 
} 

如果我看到上面的代碼類型，我真的很難判斷。我以為他/她從來沒有閱讀過API指南/文檔或任何人的Swift代碼。我們來看看WWDC的蘋果工程師如何撰寫。 

// How Swift engineers would write 
func swiftyWay() { 
  let isLegit = true 
  if isLegit { 
    print("This is fine") 
  } 
} 

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

如果你一直在附近，確保你了解它們之間的差異， 

as as! as? 
try try! try? 
Int Int! Int? 

如果你不知道自己在做什么，并且使用Xcode左側(cè)的那些，你一定會看到“發(fā)現(xiàn)意外的零”消息。不要被動。移動你的屁股并理解他們的意思。特別是對于那些參加Udemy初級課程(包括我自己)的人，你需要弄清楚你自己的。

3.不要超過20行功能

我的朋友昨天要我回顧他的代碼。一個函數(shù)有50行。它涵蓋了整個Xcode黑屏。我就像，這個狗屎不會去任何地方。我告訴他，“我不想讀你的代碼，因為你的代碼很糟糕”。我告訴他把它分解成碎片并模塊化。真相傷害，但他是我的朋友，我需要真實而清楚。沒有廢話試圖取悅他。

例如，不要寫這樣的東西，盡管下面的內(nèi)容不太。。。 

把它分解成幾塊。 

4.UI主線程，網(wǎng)絡(luò)后臺線程

多重威脅(由CPU完成的一組任務(wù))的概念令人望而生畏。我不怪你。我沒有計算機工程背景，但我仍然不太了解。

我寫了兩篇文章，為什么你需要使用UI更新的主線程和后臺線程進行聯(lián)網(wǎng)。所以，我會跳過這一部分。

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

我第一次學(xué)習(xí)如何制作應(yīng)用程序時犯了這個錯誤。我制作了一個包含多個UIViewController類和模型的超過800行的文件。這是我不會重復(fù)的。一旦你入侵，你永遠不會回去。當然，如果文件是JSON或基于內(nèi)容的文件，它可能包含數(shù)以千計的行。

我不會詳細解釋所有這些概念，但我會告訴你，你可以學(xué)習(xí)什么，并使你的整個應(yīng)用程序更加干凈。

有幾個方法可以從根本上減少行數(shù)并仍然可讀。您可以使用UITableVIew和UICollectionView使用面向協(xié)議的編程來制作可重用的代碼。如果您使用的是代表Massive View Controller的MVC，則可能需要了解MVVM的工作原理。

6.永遠不要輸入任何東西。

你是否意識到我們可以在Xcode中自動完成許多屬性的原因是由于Enums?這看起來很明顯，但對初學(xué)者來說可能并非如此。

你想在編程中做的最后一件事是硬核打字，而不是挑選。例如，當您創(chuàng)建UIAlertViewStyle時，UIKit工程師創(chuàng)建， 

public enum UIAlertViewStyle : Int { 
 case `default` 
 case secureTextInput 
 case plainTextInput 
 case loginAndPasswordInput 
} 

你能想象打字每個案件嗎?我不能，因為我不考慮它，因為這是必須的。不要為自己編寫硬編碼，而是為了你隊友的灰白頭發(fā)。

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

根據(jù)Swift API指南，開發(fā)人員應(yīng)該遵循一些標準。

a.公約>獨特性

每種編程語言都有自己的特點和風格。雖然是主觀的，但是可以通過閱讀在開源項目中編寫的Swift文檔和Swift文件來找到約定。同樣，我強烈建議你看看用Swifty的方式寫什么感覺。相反給你舉例，我會在下面給你提供資源。

b.表現(xiàn)力>令人印象深刻

有些帥哥喜歡把東西扭曲，讓他們感到優(yōu)越感，因為別人看不懂。這是廢話。沒有人應(yīng)該這樣做。這完全是關(guān)于彼此之間的有效溝通。是的，代碼是人類與計算機交流的一種方式。但是，它也在我們之間，開發(fā)者和極客之間。請不要成為那個試圖用莎士比亞的話來留下印象的傲慢家伙。沒必要。

c.清晰度>簡潔

Swift的開發(fā)者要求我們清楚地說出名字，以便在三周后回來時，我們很好。但是，沒有黑色和白色。這是使用描述性名稱和減少總體行數(shù)的平衡。

“簡潔本身不是一個有價值的目標。簡潔的代碼是使用上下文線索的結(jié)果“ -——Doug Gregor，Swift Engineer 

// Too brief & Lack of context 
let a = "A" 
let b = "B" 

如果我要閱讀上面的代碼，我會困惑到底是什么a和b始終。所以，我必須一直找到它們。為什么我們不能通過寫作來更具描述性， 

// How I would do it 
let capLetterA = "A" 
let capLetterB = "B" 

8.使用Guard

Guard語句不僅可用于展開optioanls，還可用于替換if-else語句，并使用break或using return提前退出函數(shù)。它允許任何人識別如果在沒有滾動查找其他塊的情況下沒有滿足條件會發(fā)生什么。我們來看一個真實世界的例子。 

let name = "Bobby" 
func checkName() { 
  // Early Check 
  guard name == "Bob" else { 
  print("You ain't Bob") 
  return 
 } 
  
 // I can do anything I want without seeing the else block. 
 // So much freedom 
 // You don't even need to read this 
 // Why are you even reading this 
 // Now, you may leave. I'm not going to say anything important 
 // In this block of code 
  
 // Lol... you still here? 
 print("You Good, bro") 
} 

如果您不明白打開option和提前退出意味著什么，請檢查下面的資源。

9.如果可以的話，不要使用NS

我沒有在Objective C中編寫代碼，所以我盡量避免它在精神上和身體上都能達到。除非你正在與Objective-C API交互，否則即使Swift自動將一些Objective-C類型轉(zhuǎn)換為Swift類型，并將一些Swift類型轉(zhuǎn)換為Objective-C類型，也遠離使用NS。

Swift的確受到Objective-C和其他許多語言的啟發(fā)，但它是一門獨立的語言。我不確定轉(zhuǎn)換速度有多慢，但建議Swift開發(fā)人員盡可能避免。由于Swift提供了自己的本地庫和API，因此您可以查看替代方案。 

“歷史筆記：如果你想知道為什么你遇到的很多類都有NS前綴，那是因為可可和Cocoa Touch的歷史。可可開始使用收集的框架來構(gòu)建NeXTStep操作系統(tǒng)的應(yīng)用程序。當蘋果在1996年購買NeXT時，大部分NeXTStep都被納入到OS X中，包括現(xiàn)有的類名稱。 Cocoa Touch作為Cocoa的iOS平臺引入; Cocoa和Cocoa Touch都提供了一些類，盡管每個平臺都有很多獨特的類。像NS和UI這樣的雙字母前綴(用于iOS上的用戶界面元素)保留給Apple使用“。 ——Apple

10.不要依賴分段

當故事板看起來像蜘蛛網(wǎng)時，初學(xué)者往往會制造太多的Segues。一旦超出了某個閾值，它就變得難以管理，很難跟蹤每個視圖控制器。因此，使用Delegate / NSNotification發(fā)送數(shù)據(jù)。使用多個故事板而不是一個。如果您對Delegate感到滿意，則可以開始使用RxSwift或ReactiveCocoa傳遞數(shù)據(jù)或僅通過幾行代碼發(fā)送通知。