因工作性質，平常都是寫一些自動化流程的 python script
近期開始嘗試開發 side project，但感覺寫出來的東西品質很差。我有試著找一些 github 比較有名的 python 專案，大致掃了一遍專案檔案目錄規劃、code 的邏輯設計架構、coding style、testing、documentation ... 等等
頓時感到十分挫折，不論從哪個面向來看，都和開源專案差了"好幾個等級"。一時之間不知道要先從哪裡改善起 ... 我嘗試在 youtube、bilibili 上找 "python 大補帖"，但絕大部分都還是著重在 "程式語言" 本身，而我感覺我所缺乏的是 "程式語言在工程面" 的實務操作知識
我有找到這篇 文章，感覺應該是我要的，我預計按照上面的建議，把裡面附上的連結挑一些出來閱讀。還請各位前輩幫我掃盲，確保我沒有"走彎路"
我主要是想多了解一些關於 "如何規劃、設計 python 開源專案相關" 的知識，提升 side project 之 readability, maintainability，之後才有臉拿出去開源
不知各位前輩是否有推薦的資源、tools 可以快速補足相關知識
(我總感覺 github 上的 code 寫成那樣，一定有使用不少輔助工具
已邀請的邦友 {{ invite_list.length }}/5
程式碼的編排目的不外乎就是您所提到的易讀性與可維護性兩種，所以在此就以這兩點來做說明。
原始檔與minify檔
比如說py的命名習慣如下：
| 類型 | 習慣 |
|---|
class|大駝峰
function|底線(或小駝峰)
constant|底線且全大寫
variable|底線(或小駝峰)
a += 1)[a, b] = [1, 2])[... for ... in ... if ...])lambda ...: ...)... if ... else ...)requirements.txt，以便他人進行模組的安裝與執行環境的架設#!/usr/bin/env python{version}來做所用版本的標註，先於第二條function與class來將功能統整類型限制或判斷+轉換來將可操作的部分規範於一定範圍內報錯與錯誤說明，使除錯更為方便if __name__ == "__main__": ...)來針對直接執行與引用狀態做執行步驟、內容的區別至於工具的部分主要還是利用編輯器的格式化功能，將程式排版整理乾淨，不過有時候格式化處理工具無法在正確位置換行(換行過於平凡)，所以一開始寫的時候就做好程式排版也是很重要的。
希望有幫助到您=^w^=
感謝分享，一般的 linter, formatter 我還是會用的
主要是專案整體架構的部分，我看 github 專案很多都會放各式非 ".py" 的檔案 (應該是工程需求)。這部份比較不明白，看起來不太像是手動建立的
requirements.txt
紀錄所使用之函式庫的名稱與版本，
# 生成當前環境已安裝之函式庫至requirements.txt
pip freeze > requirements.txt
# 快速安裝requirements.txt之內容
pip install -r requirements.txt
*.ipynb
i python notebook，為jupyter notebook、colab等編輯器支援的檔案格式，便於儲存py程式碼、md說明以及程式輸出。
*.md
markdown，該專案的說明文件，或開發者備註。
*.yml
yaml，層狀資料格式，通常供套件管理器或相關管理工具做取用。如：travis的.travis.yml、docker的docker-compose.yml
.gitignore
專案推上github時不要上傳的檔案及資料夾。
.gitattributes
定義各檔案之屬性，方便git管理，常見屬性有：text、eol、diff，可考這篇文章
LICENSE
創建github專案時可設定「執照(授權)」，專案創建時將自動建立該檔案。
VERSION
版本註記文件，供管理工具辨識。
.github/workflows
專案的github工作流(自動化作業)之設定，說明文件見此。
Dockerfile、Dockerfile.cpu、Dockerfile.gpu
給docker看的執行語法與前置作業。
setup.cfg
設定執行時，各傳入參數的預設值，說明文件見此。
.html、.htm
網頁檔案，專案說明或功能操作介面。
一些比較成熟的開源專案都會有 Contribution guide [1] 可以參考 ，如果沒有的話也還是有一些方式：
先加入 pylint 讓自己的 code 有一定的排版規範以及把自己的程式寫 unit tests。這兩者是開源專案最基本的。為了達到可測試性，自然而然會把自己的程式拆成小單位以符合 SRP。先完成以上就慢慢有頭緒了。
iThome鐵人賽
看影片追技術