因為這幾個TypeScript程式碼的壞習慣,同事被罰了500塊

華為雲開發者社群發表於2021-04-17

作者:Daniel Bartholomae

翻譯:瘋狂的技術宅

原文連結:https://startup-cto.net/10-bad-typescript-habits-to-break-this-year/

近幾年 TypeScript 和 JavaScript 一直在穩步發展。我們在過去寫程式碼時養成了一些習慣,而有些習慣卻沒有什麼意義。以下是我們都應該改正的 10 個壞習慣。

1.不使用 strict 模式

這種習慣看起來是什麼樣的

沒有用嚴格模式編寫 tsconfig.json。

{
  "compilerOptions": {
    "target": "ES2015",
    "module": "commonjs"
  }
}

應該怎樣

只需啟用 strict 模式即可:

{
  "compilerOptions": {
    "target": "ES2015",
    "module": "commonjs",
    "strict": true
  }
}

為什麼會有這種壞習慣

在現有程式碼庫中引入更嚴格的規則需要花費時間。

為什麼不該這樣做

更嚴格的規則使將來維護程式碼時更加容易,使你節省大量的時間。

2. 用 || 定義預設值

這種習慣看起來是什麼樣的

使用舊的 || 處理後備的預設值:

function createBlogPost (text: string, author: string, date?: Date) {
 return {
    text: text,
    author: author,
    date: date || new Date()
  }
}

應該怎樣

使用新的 ?? 運算子,或者在引數重定義預設值。

function createBlogPost (text: string, author: string, date: Date = new Date())
 return {
    text: text,
    author: author,
    date: date
  }
}

為什麼會有這種壞習慣

?? 運算子是去年才引入的,當在長函式中使用值時,可能很難將其設定為引數預設值。

為什麼不該這樣做

?? 與 || 不同,?? 僅針對 null 或 undefined,並不適用於所有虛值。

3. 隨意使用 any 型別

這種習慣看起來是什麼樣的

當你不確定結構時,可以用 any 型別。

async function loadProducts(): Promise<Product[]> {
 const response = await fetch('https://api.mysite.com/products')
 const products: any = await response.json()
 return products
}

應該怎樣

把你程式碼中任何一個使用 any 的地方都改為 unknown

async function loadProducts(): Promise<Product[]> {
 const response = await fetch('https://api.mysite.com/products')
 const products: unknown = await response.json()
 return products as Product[]
}

為什麼會有這種壞習慣

any 是很方便的,因為它基本上禁用了所有的型別檢查。通常,甚至在官方提供的型別中都使用了 any。例如,TypeScript 團隊將上面例子中的 response.json() 的型別設定為 Promise <any>。

為什麼不該這樣做

它基本上禁用所有型別檢查。任何通過 any 進來的東西將完全放棄所有型別檢查。這將會使錯誤很難被捕獲到。

4. val as SomeType

這種習慣看起來是什麼樣的

強行告訴編譯器無法推斷的型別。

async function loadProducts(): Promise<Product[]> {
 const response = await fetch('https://api.mysite.com/products')
 const products: unknown = await response.json()
 return products as Product[]
}

應該怎樣

這正是 Type Guard 的用武之地。

function isArrayOfProducts (obj: unknown): obj is Product[] {
 return Array.isArray(obj) && obj.every(isProduct)
}

function isProduct (obj: unknown): obj is Product {
 return obj != null
    && typeof (obj as Product).id === 'string'
}

async function loadProducts(): Promise<Product[]> {
 const response = await fetch('https://api.mysite.com/products')
 const products: unknown = await response.json()
 if (!isArrayOfProducts(products)) {
 throw new TypeError('Received malformed products API response')
  }
 return products
}

為什麼會有這種壞習慣

從 JavaScript 轉到 TypeScript 時,現有的程式碼庫通常會對 TypeScript 編譯器無法自動推斷出的型別進行假設。在這時,通過 as SomeOtherType 可以加快轉換速度,而不必修改 tsconfig 中的設定。

為什麼不該這樣做

Type Guard 會確保所有檢查都是明確的。

5. 測試中的 as any

這種習慣看起來是什麼樣的

編寫測試時建立不完整的用例。

interface User {
  id: string
  firstName: string
  lastName: string
  email: string
}

test('createEmailText returns text that greats the user by first name', () => {
 const user: User = {
    firstName: 'John'
  } as any
 
  expect(createEmailText(user)).toContain(user.firstName)
}

應該怎樣

如果你需要模擬測試資料,請將模擬邏輯移到要模擬的物件旁邊,並使其可重用。

interface User {
  id: string
  firstName: string
  lastName: string
  email: string
}

class MockUser implements User {
  id = 'id'
  firstName = 'John'
  lastName = 'Doe'
  email = 'john@doe.com'
}

test('createEmailText returns text that greats the user by first name', () => {
 const user = new MockUser()

  expect(createEmailText(user)).toContain(user.firstName)
}

為什麼會有這種壞習慣

在給尚不具備廣泛測試覆蓋條件的程式碼編寫測試時,通常會存在複雜的大資料結構,但要測試的特定功能僅需要其中的一部分。短期內不必關心其他屬性。

為什麼不該這樣做

在某些情況下,被測程式碼依賴於我們之前認為不重要的屬性,然後需要更新針對該功能的所有測試。

6. 可選屬性

這種習慣看起來是什麼樣的

將屬性標記為可選屬性,即便這些屬性有時不存在。

interface Product {
  id: string
  type: 'digital' | 'physical'
  weightInKg?: number
  sizeInMb?: number
}

應該怎樣

明確哪些組合存在,哪些不存在。

interface Product {
  id: string
  type: 'digital' | 'physical'
}

interface DigitalProduct extends Product {
  type: 'digital'
  sizeInMb: number
}

interface PhysicalProduct extends Product {
  type: 'physical'
  weightInKg: number
}

為什麼會有這種壞習慣

將屬性標記為可選而不是拆分型別更容易,並且產生的程式碼更少。它還需要對正在構建的產品有更深入的瞭解,並且如果對產品的設計有所修改,可能會限制程式碼的使用。

為什麼不該這樣做

型別系統的最大好處是可以用編譯時檢查代替執行時檢查。通過更顯式的型別,能夠對可能不被注意的錯誤進行編譯時檢查,例如確保每個 DigitalProduct 都有一個 sizeInMb。

7. 用一個字母通行天下

這種習慣看起來是什麼樣的

用一個字母命名泛型

function head<T> (arr: T[]): T | undefined {
 return arr[0]
}

應該怎樣

提供完整的描述性型別名稱。

function head<Element> (arr: Element[]): Element | undefined {
 return arr[0]
}

為什麼會有這種壞習慣

這種寫法最早來源於C++的範型庫,即使是 TS 的官方文件也在用一個字母的名稱。它也可以更快地輸入,只需要簡單的敲下一個字母 T 就可以代替寫全名。

為什麼不該這樣做

通用型別變數也是變數,就像其他變數一樣。當 IDE 開始向我們展示變數的型別細節時,我們已經慢慢放棄了用它們的名稱描述來變數型別的想法。例如我們現在寫程式碼用 const name ='Daniel',而不是 const strName ='Daniel'。同樣,一個字母的變數名通常會令人費解,因為不看宣告就很難理解它們的含義。

8. 對非布林型別的值進行布林檢查

這種習慣看起來是什麼樣的

通過直接將值傳給 if 語句來檢查是否定義了值。

function createNewMessagesResponse (countOfNewMessages?: number) {
 if (countOfNewMessages) {
 return `You have ${countOfNewMessages} new messages`
  }
 return 'Error: Could not retrieve number of new messages'
}

應該怎樣

明確檢查我們所關心的狀況。

function createNewMessagesResponse (countOfNewMessages?: number) {
 if (countOfNewMessages !== undefined) {
 return `You have ${countOfNewMessages} new messages`
  }
 return 'Error: Could not retrieve number of new messages'
}

為什麼會有這種壞習慣

編寫簡短的檢測程式碼看起來更加簡潔,使我們能夠避免思考實際想要檢測的內容。

為什麼不該這樣做

也許我們應該考慮一下實際要檢查的內容。例如上面的例子以不同的方式處理 countOfNewMessages 為 0 的情況。

9. ”棒棒“運算子

這種習慣看起來是什麼樣的

將非布林值轉換為布林值。

function createNewMessagesResponse (countOfNewMessages?: number) {
 if (!!countOfNewMessages) {
 return `You have ${countOfNewMessages} new messages`
  }
 return 'Error: Could not retrieve number of new messages'
}

應該怎樣

明確檢查我們所關心的狀況。

function createNewMessagesResponse (countOfNewMessages?: number) {
 if (countOfNewMessages !== undefined) {
 return `You have ${countOfNewMessages} new messages`
  }
 return 'Error: Could not retrieve number of new messages'
}

為什麼會有這種壞習慣

對某些人而言,理解 !! 就像是進入 JavaScript 世界的入門儀式。它看起來簡短而簡潔,如果你對它已經非常習慣了,就會知道它的含義。這是將任意值轉換為布林值的便捷方式。尤其是在如果虛值之間沒有明確的語義界限時,例如 null、undefined 和 ''。

為什麼不該這樣做

與很多編碼時的便捷方式一樣,使用 !! 實際上是混淆了程式碼的真實含義。這使得新開發人員很難理解程式碼,無論是對一般開發人員來說還是對 JavaScript 來說都是新手。也很容易引入細微的錯誤。在對“非布林型別的值”進行布林檢查時 countOfNewMessages 為 0 的問題在使用 !! 時仍然會存在。

10. != null

這種習慣看起來是什麼樣的

棒棒運算子的小弟 ! = null使我們能同時檢查 null 和 undefined。

function createNewMessagesResponse (countOfNewMessages?: number) {
 if (countOfNewMessages != null) {
 return `You have ${countOfNewMessages} new messages`
  }
 return 'Error: Could not retrieve number of new messages'
}

應該怎樣

明確檢查我們所關心的狀況。

function createNewMessagesResponse (countOfNewMessages?: number) {
 if (countOfNewMessages !== undefined) {
 return `You have ${countOfNewMessages} new messages`
  }
 return 'Error: Could not retrieve number of new messages'
}

為什麼會有這種壞習慣

如果你的程式碼在 null 和 undefined 之間沒有明顯的區別,那麼 != null 有助於簡化對這兩種可能性的檢查。

為什麼不該這樣做

儘管 null 在 JavaScript早期很麻煩,但 TypeScript 處於 strict 模式時,它卻可以成為這種語言中寶貴的工具。一種常見模式是將 null 值定義為不存在的事物,將 undefined 定義為未知的事物,例如 user.firstName === null 可能意味著使用者實際上沒有名字,而 user.firstName === undefined 只是意味著我們尚未詢問該使用者(而 user.firstName === 的意思是字面意思是 '' 。

 

點選關注,第一時間瞭解華為雲新鮮技術~

相關文章