【Python】コーディングスタイル

Python ドキュメントに「コーディングスタイル」という章があります。
まずは、引用してみます。

（１）インデントには空白 4 つを使い、タブは使わないこと。
空白 4 つは (深くネストできる) 小さいインデントと (読み易い) 大きいインデントのちょうど中間に当たります。タブは混乱させるので、使わずにおくのが良いです。

（２）ソースコードの幅が 79 文字を越えないように行を折り返すこと。
こうすることで小さいディスプレイを使っているユーザも読み易くなり、大きなディスプレイではソースコードファイルを並べることもできるようになります。

（３）関数やクラスや関数内の大きめのコードブロックの区切りに空行を使うこと。

（４）可能なら、コメントは行に独立で書くこと。

（５）docstring を使うこと。

（６）演算子の前後とコンマの後には空白を入れ、括弧類のすぐ内側には空白を入れないこと: a = f(1, 2) + g(3, 4)。

（７）クラスや関数に一貫性のある名前を付けること。慣習では UpperCamelCase をクラス名に使い、 lowercase_with_underscores を関数名やメソッド名に使います。常に self をメソッドの第 1 引数の名前 (クラスやメソッドについては クラス初見 を見よ) として使うこと。

（８）あなたのコードを世界中で使ってもらうつもりなら、風変りなエンコーディングは使わないこと。どんな場合でも、Python のデフォルト UTF-8 またはプレーン ASCII が最も上手くいきます。

（９）同様に、ほんの少しでも他の言語を話す人がコードを読んだりメンテナンスする可能性があるのであれば、非 ASCII 文字も識別子に使うべきではありません。

https://docs.python.org/ja/3/tutorial/controlflow.html#intermezzo-coding-style

規約とか、規則などという言葉を聞くと、ついつい抵抗感を抱いてしまいます。コーディング規約を言うのなら言語仕様にしてほしいくらいのものです。
それほどに、人とは言うことをきかない。

ともかくも。
以下、云々してみます。

（１）インデントは空白4つ

インデントが実行ルートを左右する Python にとっては重要、という以上に言語仕様レベルかもしれません。昨今のエディタではスマートインデント機能もありますから、空白4文字というのも苦にはなりますまい。タブの使用禁止は言語仕様なのだろうか。スマホでやっているとタブを入力しにくいので確認も面倒。いずれ確認してみたいところではあります。

（２）1行は79文字まで

なんと。このようなスタイルがまだ残っているとは。
昔はダム端末でコーディングしました。パーソナルコンピューターではありません。センターコンピューターに接続した端末です。その端末の1行がだいたい80文字だったでしょうか。80文字を超えたらどうなっていたかは、もはや記憶にはありません。折り返してインデントをガタガタにされたのか、カーソルで右方にスクロールしなければならなかったのか。どちらにしても、80文字を超えたコードを読むのは辛かった。
1行80文字までというのはその頃のコーディングスタイルです。古色蒼然としたこのスタイル。何故わざわざ持ち出したのだろう。「それくらいにコンパクトにおさめた方が読みやすい」ということだろうか。私自身は長い1行が苦手なのでこれでもかまわないとも言えるんだけど、一方で80文字をきっちり意識しているわけではない。「80文字まで」と、具体的に言われると窮屈な感じがするのは私だけでしょうか。

（３）関数、クラス、コードブロックの区切りに空行

普通にやってることではあります。
個人的には、関数やクラスの区切りとしては、空行だけでは物足りない。長いコメント行を入れることがしばしばです（「#」や「=」で1行を埋め尽くす）。最近のエディタはコメント行の色を変えてくれるので、こうすると目だってわかりやすかったりします。

（４）コメントは単独の1行で

これも、私にはいつも通り。
右の方に書いてもいいんだけど、長い行をついつい避けたくなる。

（５）docstring を使う

「docstring」はPythonの機能ですね。
そのうち使いましょう。

（６）演算子の前後に空白、コンマの後に空白、()の内側に空白なし

空白の有無・・・。
空白については、それこそいろいろ見てきた気がする。
私自身も、
　n = i + 1
と書いたり
　n[i+1]
と書いたり。
()内は
　func(a, b)
と書くけど、
　func( a, b )
というのもよく見る。
こういうのは、もう、統一は不可能な気がする。リンゴが好きか、ミカンが好きか、みたいな感じで。私はどっちでもいいし、今では混ざっていても気にならなくなってしまった。

（７）クラスや関数に一貫した名前

C++ は先頭大文字が推奨だった。
C は小文字を _ で区切ることが多かった。
今度はその二種類を使い分けろ、と。
うーん。
どちらがいいのかは、未だに結論を見ない。
初めて UpperCamelCase を見た時は新鮮で格好よく見えたものだけど、ついついスペルが長くなっていくことと（ UpperCamelCase を使うとなんとなく短縮しにくい）、ゴテゴテして見えることとがあって（隙間がなくて大文字が空間を圧迫するようで）、敬遠したくなりつつある。でも、それは私の好みでしかなくって、それとは逆に「小文字は単調だ」と思うような人もいるかもしれない。
「自分の書くコードくらい決めておけよ」というのもわかるけれども、混在にすると決めたとして、その混ぜ加減などはすぐにわかるのだろうか。関数と変数の違い？　それともグローバルかローカルかの違い？　一方のみというのであればすぐにわかるのだろうけど。
と言いつつも、確かにクラスは UpperCamel が多いか。
　クラスは UpperCamelCase
　それ以外は lowercase_with_underscores
これを試してみるのもいいかもしれない。

（８）文字コードは UTF-8

UTF-8 は最近はよく見る。それでもまだまだ SJIS も少なくない。デフォルトで SJIS としているエディタもありそう。ちょっと意識しておかないと、いつの間にか文字コードが変わっていた、なんてことも。

（９）ASCII コードのみを使うのが望ましい

ASCII のみ！　日本語は使うな、と。
うーん、どうなんでしょう。
最近の多言語化を見ると、ASCII のみというのは厳しく感じる。Python は数学に関するライブラリが豊富ならしいけど、言語も多様化しておいてほしいかな。
世界に視野を持っている人は頼まれなくても日本語は使わないのでしょう。そう言えば、ダム端末は日本語入力できなかったなぁ。いよいよ、「ダム端末に帰れ」と言われているようだ(笑)。

---