勉強を兼ねて Ruff の lint ルールを全て確認しています。(多分更新していきます…)
主観でおススメ度を 5 段階でつけているので、良ければ参考にしてください。
- 5: デメリットがないため、必ずつけるべき
- 4: 一定の制約がつくが、つけた方が良い
- 3: つけてもつけなくてもいい
- 2: つけない方がいい場面が多い
- 1: つけるべきではない(そんなルールあるのかって感じですが…)
公式のルール一覧はこちら
Pyflakes(F)についてはこちら
- flake8-annotations (ANN)
- ANN001(missing-type-function-argument) 4/5
- ANN002(missing-type-args) 4/5
- ANN003(missing-type-kwargs) 4/5
- ANN101(missing-type-self) 2/5
- ANN102(missing-type-cls) 2/5
- ANN201(missing-return-type-undocumented-public-function) 4/5
- ANN202(missing-return-type-private-function) 4/5
- ANN204(missing-return-type-special-method) 3/5
- ANN205(missing-return-type-static-method) 4/5
- ANN206(missing-return-type-class-method) 4/5
- ANN401(any-type) 4/5
- 終わりに
flake8-annotations (ANN)
flake8-annotations (ANN)は linter の flake8-annotationsから移植された lint ルールになります。
そのため、以下のルールの詳細を確認する際は必要に合わせて flake8 のルール集も参照してください。
ANN001(missing-type-function-argument) 4/5
関数の引数にタイプアノテーションがついていない場合に警告を出します。
悪い例
def foo(x):
...良い例:
def foo(x: int):
...ルールの制約は強い(手間が増える)ですが、Python でチーム開発する上では必須のルールだと思います。
ANN002(missing-type-args) 4/5
順序付きの可変長引数*argsに型ヒントが無い場合に警告を出します。
悪い例
def foo(*args):
...良い例:
def foo(*args: int): # こう書くとargs: list[int]として型があたります。
...ANN001 と同じく、ルールの制約は強い(手間が増える)ですが、追加推奨です。
(そもそも*argsをあまり使わない方がいいような気はしますが…)
ANN003(missing-type-kwargs) 4/5
名前付きの可変長引数**kwargsに型ヒントが無い場合に警告を出します。
悪い例
def foo(**kwargs):
...良い例:
def foo(**kwargs: int): # こう書くとkwargs: dict[str, int]として型があたります。
...ANN001 と同じく、ルールの制約は強いですが、追加推奨です。
(そもそも*kwargsをあまり使わない方がいいような気はしますが…)
ANN101(missing-type-self) 2/5
インスタンスメソッドのselfにタイプアノテーションがない時に警告を出します。
悪い例
class Foo:
def bar(self):
...良い例:
class Foo:
def bar(self: "Foo"):
...このルールについては明示的に型を当てなくてもタイプアノテーションが自然につく IDE が多いため、導入するメリットがあまり無いように思います。(PyCharm や VSCode は自動的に self に Foo のインスタンスとしての型補完があたっているように見えました。)
ANN102(missing-type-cls) 2/5
クラスメソッドのclsにタイプアノテーションがない時に警告を出します。
悪い例
class Foo:
@classmethod
def bar(cls):
...良い例:
class Foo:
@classmethod
def bar(cls: Type["Foo"]):
...ANN102 と同様にこのルールについてもタイプアノテーションが自然につく IDE が多いため、導入するメリットがあまり無い気がします。
ANN201(missing-return-type-undocumented-public-function) 4/5
関数の返り値にタイプアノテーションが無い場合警告を出します。
悪い例
def add(a, b):
return a + b良い例:
def add(a: int, b: int) -> int:
return a + bANN001 と同様にチーム開発をする上で必須のルールだと思います。
ANN202(missing-return-type-private-function) 4/5
プライベート関数(関数名の先頭が_のもの)の返り値にタイプアノテーションが無い場合に警告を出します。
悪い例
def _add(a, b):
return a + b良い例:
def _add(a: int, b: int) -> int:
return a + bANN201 と同様に追加推奨ですが、プライベート関数についてはルールを緩くするということはプロジェクトによってある気はします。
ANN204(missing-return-type-special-method) 3/5
初期化に用いられる特定のマジックメソッド(__init__, __new__, __call__)の返り値にタイプアノテーションが無い場合に警告を出します。
悪い例
class Foo:
def __init__(self, x: int):
self.x = x良い例:
class Foo:
def __init__(self, x: int) -> None:
self.x = x私は初期化のマジックメソッドを None 以外で用いたことがほとんど無いためメリットを感じていないですが、コード全体に統一感を持たせるために lint の対象として追加しても良いと思います。
このルールを使用する場合は、mypy-init-returnをセッティングファイルに追加する必要があるようです。
[tool.ruff.lint.flake8-annotations]
mypy-init-return = trueANN205(missing-return-type-static-method) 4/5
static メソッドの返り値にタイプアノテーションが無い場合に警告を出します。
悪い例
class Foo:
@staticmethod
def bar():
return 1良い例:
class Foo:
@staticmethod
def bar() -> int:
return 1ANN201 の static メソッド版になります。ANN201 と同様の理由で使用必須だと思います。
ANN206(missing-return-type-class-method) 4/5
static メソッドの返り値にタイプアノテーションが無い場合に警告を出します。
悪い例
class Foo:
@classmethod
def bar(cls):
return 1良い例:
class Foo:
@classmethod
def bar(cls) -> int:
return 1ANN205 の class メソッド版になります。ANN201 と同様の理由で使用必須だと思います。
ANN401(any-type) 4/5
Anyをタイプアノテーションに使用している場合に警告を出します。
悪い例
def foo(x: Any):
...良い例:
def foo(x: int):
...個人的にはタイプアノテーションで Any を利用するメリットを理解できていないため、使用必須に感じます。
終わりに
ANN は基本的に導入必須の lint ルールだと思います。
ただ、ANN101, ANN102は手間になるだけに感じたので個人的に無い方がいい、ANN204は無くてもいいかなと感じました。
というわけで、私が導入するなら以下のようになりそうです。
[tool.ruff.lint]
select = ["ANN"]
ignore = [
"ANN101", # [missing-type-self]
"ANN102", # [missing-type-cls]
"ANN204", # [missing-return-type-special-method]
]
コメント