search

kyomind / blog-reply

Code and Me 部落格留言
https://blog.kyomind.tw/
0 stars 0 forks source link

《Python 工匠》筆記（三）有關「變數」的程式設計建議 - Code and Me #43

Open utterances-bot opened 3 months ago

utterances-bot commented 3 months ago

《Python 工匠》筆記（三）有關「變數」的程式設計建議 - Code and Me

這是《Python 工匠｜案例、技巧與開發實戰》筆記的第 3 篇，你可以把它當作是一則重點整理，加上我個人的開發經驗與心得。

https://blog.kyomind.tw/python-craftsman-03/

gbaian10 commented 3 months ago

關於第四點(能不宣告變數就別宣告)

ruff 的 RET504 可以做到不錯的檢查效果

當然範例中的雙變數比較沒辦法，但通常看到警告我就會一起改了

有時候真的會額外多寫一個變數來回傳

kyomind commented 3 months ago

@gbaian10 竟然還有這種東東！感謝告知 看樣子 ruff 少見的驗證，值得再研究一下

gbaian10 commented 3 months ago

以前我就有用 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真的太噩夢了。

gbaian10 commented 3 months ago

分享一下自己的 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

kyomind commented 3 months ago

@gbaian10 非常驚人XDDD 這些內容已經足夠單獨寫一篇文章介紹了 你所屬的團隊對這些規則都沒有意見嗎XD 詳細的規則可以增進團隊寫作一致性，但也容易招至抱怨😷

不過沒錯，ruff 已經實作了不少規則，只用基本的又有點浪費 這真的是一分覺悟，一分追求

gbaian10 commented 3 months ago

@gbaian10 非常驚人XDDD 這些內容已經足夠單獨寫一篇文章介紹了 你所屬的團隊對這些規則都沒有意見嗎XD 詳細的規則可以增進團隊寫作一致性，但也容易招至抱怨😷

不過沒錯，ruff 已經實作了不少規則，只用基本的又有點浪費 這真的是一分覺悟，一分追求

團隊沒太多人🤣，大家也覺得 ruff 很厲害，也希望能引入使用

如果怕對團隊造成太大負擔，可以先自己跑一次，然後挑幾個自己覺得特別有用，你覺得改下去很有幫助的規則就好

我最常見的警告大概就是使用 magic number 了 😅