コラム

CTC教育サービス・ホーム　＞　コラム　＞　ゼロから歩くPythonの道　＞　第68回　Pythonプログラムでエラーを出す前に確認したいこと　～誤解によるコード臭編1～

ゼロから歩くPythonの道

CTC 教育サービス

[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes

第68回　Pythonプログラムでエラーを出す前に確認したいこと　～誤解によるコード臭編1～ (菱沼佑香) 2025年9月

こんにちは、吉政創成　菱沼です。
今回も「きれいなPythonプログラミング（マイナビ出版）」という書籍を利用して学習します。

現在学習中の5章「怪しいコード臭」では、バグを未然に防ぐために、どういった点に注意した方が良いのか、対処するか否かの判断について学んでいます。
今回はあやふやな記憶による迷信についてです。

コード臭だと世間で言われているけど、気にしなくてもいいもの

本当はよくない事ですが、正直、学んだものの記憶があやふやになっているものというのはたくさんあります。人間なので、忘れてしまうのです。そして時が経てば、バージョンアップ等の事情により、それ自体がなくなる、もしくは代替手段の追加により、推奨される記述方法が変わることもあります。

Python3系に関して言えば、基本的にバージョン間での互換性は意識されていますが、新たに追加された構文や非推奨・廃止された構文や関数がいくつかあります。こうしたものを含め、諸々をあやふやなまま、もしくは変わったことを認識していないままにしていると、ちょっとした問題が出てくることがあります。なので、結局のところ私は必要に応じて調べています。

さて、書籍によれば技術書であっても間違った意見が書かれているため、注意が必要だというようなことが書かれています。中には昔の言語の仕様と、近年の言語の仕様の違いによって起きた誤解を引きずり続けたものも含まれていますが、それらの誤解に対して、筆者は「コード臭の迷信」と呼び、無視していい警告だと書いていました。なんとなくうっすらと怒りや呆れを感じますが...なにかがきっとあったんだと思います。
さて、そんな「コード臭の迷信」と指されているのは次の5点です。

---------------------------------------------------------------
P.85～89からの抜粋
・関数の最後にはreturn文を1つだけ入れるべきだ
・関数内でのtry文は1つまで
・フラグ引き数はダメ
・グローバル変数はダメ
・コメントは必要ない
---------------------------------------------------------------

今回は3つ目のフラグ引き数についてまでを、一つずつ確認していきます。

真実：returnはいくつあってもOK

まず1つ目から。

---------------------------------------------------------------
P.85
迷信：関数の最後にはreturn文を1つだけ入れるべきだ
「one entry, one exit（入口1つに出口1つ）」という考え方は、アセンブリ言語やFORTRAN言語でプログラミングをしていた時代の誤ったアドバイスから来ています。
（中略）
関数やメソッドの中でreturn文を1つにしようとすると、if-else文の並びが複雑になり、複数のreturn文を書くよりもはるかに混乱してしまいます。関数やメソッドの中に複数のreturn文があっても問題はありません。
---------------------------------------------------------------

昔使われていた言語とは違い、近年の言語は、早めにreturnを入れることで、コードが短くなるので、むしろ可読性が上がるため、複数のreturn文を入れることが推奨されているそうです。保守もしやすくなるのだとか。
PEP8にはreturnの数に関しては明言されていませんので、一貫性さえあれば良しということのようです。

真実：try文はむしろ複数使って覆う範囲は必要最小限に

2つ目です。

---------------------------------------------------------------
P.86
迷信：関数内でのtry文は1つまで
「関数とメソッドは1つのことを行うべきだ」というのは、一般的には良いアドバイスだと思います。しかし、これを「例外処理は別の関数で行うべきだ」と考えるのは行きすぎです。
（中略）
関数は小さくてシンプルであるべきですが、だからと言って何が何でも1つのことしかしてはならないと決めてしまうべきではありません。関数には複数のtry-except文があっても、関数内のコード全部を覆うような書き方になっていなくても問題ありません。
---------------------------------------------------------------

関数内で発生する例外処理を無理に関数の外に出してしまえば、かえって可読性や保守性が悪くなってしまうことがあるそうです。また、関数全体を1つのtry文で覆ってしまうと、どこで例外が発生したのか不明瞭になってしまう可能性が出てくるため、必要に応じて複数のtry文を使うことが推奨されているということのようです。
PEP8にもtry文の数の制限については記載されておらず、むしろ「tryで覆う範囲は必要最小限にとどめるべき」と書かれています。

真実：フラグ引き数は使ってOKだけど、使い方に注意

3つ目です。

---------------------------------------------------------------
P.87
迷信：フラグ引き数はダメ
（中略）プログラミングにおけるフラグは、「有効」や「無効」といった二値を示す値のことで、多くの場合ブール値で表されます。このようなフラグは、オン（True）にしたりオフ（False）したりして使います。
関数呼び出しのフラグ引き数が悪いという誤った考えは、次の例のように、フラグの値によってその関数が行う動作が全く異なるという主張に基づいています。


def someFunction(flagArgument):
    if flagArgument:
        # 何か処理を行う ...
    else:
        # 全く別の処理を行う　...

確かにこのような関数であれば、コードの半分を実行するかを引数で決めるのではなく、関数を別に2つ作るべきです。しかし、フラグ引き数を持つ関数のほとんどはこのようなことをしません。
（中略）
つまり、フラグ引き数が常に悪いという考えは、コード臭の迷信なのです。
---------------------------------------------------------------

if文で処理を分ける際、Trueの処理の延長線上にある内容をFalseの処理として書くのであれば問題はないものの、TrueとFalseで全く違う指示をするのなら違う関数にしましょうという事のようです。
これは1つの関数の中に、実質2つの異なる関数が入ってしまうと、関数の意図が分かりにくくなり、テストがしにくくなるという理由があるためです。
PEPではフラグ引き数自体は禁止しておらず、単純で明確な使い方ならフラグ引き数を使うのは問題ないそうです。

長くなってしまうので、今回は3つ目までで終了です。次回、残りの2つの迷信について確認します。
今回もお付き合いいただきありがとうございました。

IT研修はCTC教育サービス

AWS　Microsoft Azure　生成AI

Python　Power Platform

コンテナ　その他（研修を分野から探す）

前回のコラム
「第67回　Pythonプログラムでエラーを出す前に確認したいこと　～例外処理編～」