Open utterances-bot opened 4 months ago
@gbaian10 竟然還有這種東東!感謝告知 看樣子 ruff 少見的驗證,值得再研究一下
以前我就有用 ruff ,只是以前都用 isort + black + ruff + mypy (我的 python 四寶😀),《Python 工匠》這本書也是用差不多的組合,只是他是用 flake8 而不是 ruff 。
也是因為上周看了你寫 ruff 遷移我才開始認真研究 ruff,之前不想遷移的原因是 isort 跟 black 真的設定跟使用都太簡單了,而且許多開源專案也都用這兩個。
不用不知道,一用才發現 ruff 全身都是寶,ruff 真的實作了非常多可以檢查出 code smell 的規則,例如前幾篇提到的 直接註解程式碼
就可以靠 ERA001 來檢測出來,另外還有一樣是前幾篇提到的 docstring, ruff 也有一系列的標準 docstring 檢查/建議可以使用。
不過由於他規則太多了,我也懶的一個一個規則去看,所以就直接 select = ["ALL"]
直接開起來然後執行 ruff 後去一一檢查,把不好的地方修掉,把不適合自己或自己團隊的加入 ignore ,有時候裡面一堆建議已經不只是簡單的建議修改的程度了,甚至還會有,原來python還有這種功能? 的發現了。
當然如果公司團隊不能馬上習慣這些改動,也可以先維持現有規則就好,但至少我覺得修這些比修 mypy 簡單多了🤣,如果是一個大專案從0開始修mypy真的太噩夢了。
分享一下自己的 ruff check 設定
[tool.ruff.lint]
select = ["ALL"]
ignore = [
### Intentionally disabled
"E501", # line-too-long (format 會自動處理)
"COM812", # missing-trailing-comma (會與 ruff format 衝突)
"ISC001", # ingle-line-implicit-string-concatenation (會與 ruff format 衝突)
"EM", # flake8-errmsg (錯誤訊息字串要先分配給變數)
"S101", # assert (for pytest)
"UP040", # non-pep695-type-alias (mypy no supported)
"BLE001", # flake8-blind-except (不要使用 BaseException 或 Exception)
"TID252", # relative-imports (不要使用父母/兄弟姊妹級別以外的 相對 import)
"RUF001", # ambiguous-unicode-character-string (不要使用不明確的 Unicode 字元)
"RUF002", # ambiguous-unicode-character-docstring (不要使用不明確的 Unicode 字元)
"RUF003", # ambiguous-unicode-character-comment (不要使用不明確的 Unicode 字元)
"ANN101", # missing-type-self (self 缺少類型註釋)
"SIM117", # multiple-with-statements (不要使用嵌套 with)
"B904", # raise-without-from-inside-except (不要使用 raise 但沒有 from)
"TD", # flake8-todos (註釋包含 TODO 的一大堆限制)
"FIX002", # flake8-fixme (註釋包含 TODO)
### TODO: Enable gradually
"D", # pydocstyle, (docstring 檢查)
"T", # flake8-print (不要使用 print)
"ERA001", # commented-out-code (不要註解程式碼)
"PTH", # flake8-use-pathlib (不要使用 os.path,改用 pathlib)
"INP001", # implicit-namespace-package (缺少 __init__.py)
"TRY003", # raise-vanilla-args (自定義例外包含額外的長訊息)
]
這邊我參考了 pandas 的 ruff 設定註解,把一些未來想啟用,但目前直接啟用需要花非常多時間修改的加入後半段的 ### TODO: Enable gradually
,等待未來修改.....會這樣說的人以後都不會改
其中我覺得自己很想保留但又覺得有時候太煩的就是 FBT系列規則,我覺得這非常適合 clean code 思維,但有時候真的要求太多了很煩,我後來是決定保留,只有當自己覺得現在這樣就好時候才直接在程式碼加入 # noqa
講了一堆,結果前面講的兩個例子 ERA001
和 D
都被我加入 ignore....👻,D系列真的不是不想用,是短時間遷移成本大!
不過D系列就算要使用我應該也只會挑著用,不然裡面規則真的太多XD
@gbaian10 非常驚人XDDD 這些內容已經足夠單獨寫一篇文章介紹了 你所屬的團隊對這些規則都沒有意見嗎XD 詳細的規則可以增進團隊寫作一致性,但也容易招至抱怨😷
不過沒錯,ruff 已經實作了不少規則,只用基本的又有點浪費 這真的是一分覺悟,一分追求
@gbaian10 非常驚人XDDD 這些內容已經足夠單獨寫一篇文章介紹了 你所屬的團隊對這些規則都沒有意見嗎XD 詳細的規則可以增進團隊寫作一致性,但也容易招至抱怨😷
不過沒錯,ruff 已經實作了不少規則,只用基本的又有點浪費 這真的是一分覺悟,一分追求
團隊沒太多人🤣,大家也覺得 ruff 很厲害,也希望能引入使用
如果怕對團隊造成太大負擔,可以先自己跑一次,然後挑幾個自己覺得特別有用,你覺得改下去很有幫助的規則就好
我最常見的警告大概就是使用 magic number 了 😅
《Python 工匠》筆記(三)有關「變數」的程式設計建議 - Code and Me
這是《Python 工匠|案例、技巧與開發實戰》筆記的第 3 篇,你可以把它當作是一則重點整理,加上我個人的開發經驗與心得。
https://blog.kyomind.tw/python-craftsman-03/