網路上流傳著無數的 Python 最佳實踐，對每個最佳實踐的看法可能會因你詢問的人而異。網路使專業知識民主化，允許任何人——包括我自己——分享他們的觀點。然而，在本文中，我們將重點關注 10 個永恆的 Python 最佳實踐，這些實踐已達成廣泛共識並被廣泛認為是基礎。

Pandas 備忘單

Git 指令備忘單

前 50 個 SQL 面試問題

提示1：函數應指定參數與傳回型別
定義函數時，您希望始終指定參數的類型以及函數傳回的資料類型。這將幫助您和團隊中的開發人員知道會發生什麼，而不必總是使用列印語句來獲得直覺的理解。

提示 2：函數應該處於同一抽象層級
當我們談論處於相同抽象層級的函數時，我們指的是函數應該執行單一、定義良好的任務的想法。該任務在整個功能中應該處於一致的抽象層級。換句話說，該功能應該專注於特定的細節或複雜程度，並且所有功能的操作都應該在同一級別上進行。

技巧 3：函數應該很小
函數應該是可重複使用的。而且函數越大，可重複使用的可能性就越小。這也與為什麼一個函數應該只做一件事有關。如果它只做一件事，那麼它很可能會很小。

技巧4：開閉原則
開閉原則 (OCP) 規定類別、方法或函數必須對擴展開放，但不能對修改開放。這意味著定義的任何類別、方法或函數都可以輕鬆地重複使用或擴展用於多個實例，而無需更改其程式碼。
這不符合 OCP，因為每當有一個新的國家時，我們就需要寫一個新的 if 語句來補充它。現在這可能看起來很簡單，但想像一下我們有 100 個或更多的國家需要考慮。看起來怎麼樣？

提示 5：不惜一切代價避免發表評論
評論有一種虛假的真實性。它們將讀者的注意力從程式碼實際執行的操作轉移到其他人所說的執行的操作上。

隨著時間的推移以及程式碼收到更新或更改，這可能會變得非常成問題。在某些時候，評論會變成謊言，現在每個人都必須透過謊言的鏡頭觀察真相。

必須不惜一切代價避免發表評論。評論迫使讀者繼承你的想法，而你的想法充其量只是過去的。當函數或類別更改時，它的註解很可能不會隨之更改。最有可能的是，它們阻礙了讀者向前思考。

註釋顯示作者精神上無法提供描述性良好的類別、函數或變數名稱。它暴露了程式設計師平庸的態度，並迫使團隊繼承這樣的態度。

提示 6：避免使用幻數
幻數是一個硬編碼值，可能會在稍後階段發生變化，但因此很難更新。

例如，假設您有一個頁面在「您的訂單」概覽頁面中顯示最後 50 個訂單。 50 是這裡的神奇數字，因為它不是透過標準或約定設定的，它是您出於規範中概述的原因而編造的數字。

現在，您要做的就是在不同的地方擁有這50 個訂單— 您的SQL 腳本（從訂單中選擇前50 個*）、您的網站（您的最後50 個訂單）、您的訂單登入資訊（對於(i = 0; i

提示 7：避免深層嵌套
限制循環、條件或函數內的巢狀層級以提高可讀性。

提示 8：避免硬編碼路徑
避免對檔案路徑或 URL 進行硬編碼；請改用設定檔或環境變數。

提示 9：班級規模宜小
是的！班級規模應盡量小。就像函數一樣。

唯一的區別是，在函數中，大小由該函數中的行數決定，而在類別中，大小由該類別中的職責數量決定。

通常，類別名稱代表它可能擁有的職責類型，但是當名稱不明確或太籠統時，很可能我們賦予了它太多的職責。

這讓我們回到了 SRP（單一責任原則），它規定一個類應該只有一個理由——一個責任——來改變。

提示 10：避免複雜的三元表達式
避免使用過於複雜的三元表達式；優先考慮可讀性而不是簡潔性，以使程式碼更容易理解。