PEP と PEP8 - コーディング規約の意味を考える
Table of Contents
[what] PEP とは ?
Python には PEP1 と呼ばれる「Python における開発を円滑に進める上で重要なことをまとめた文書群」がある.
もう少し詳しく: Python における新機能・環境を提案したり,現状の課題について議論して意見を集めたりすることで,今後 Python に追加されていくであろうものをドキュメント化するためのものである.
その中の PEP82 には,Python における コーディングの規約 が記載されている3.
これに従ってコーディングすることで,それ (Python) らしいコードが書けるみたい.
cf. https://legacy.python.org/dev/peps/pep-0008/
他の言語 (e.g. 私の場合は C 言語) で守っていたことが,Python だと NG だったりしている.ちょっと驚き.
### OK ### x = 0 y = 1 zzz = 2 ### NG ### x = 0 y = 1 zzz = 2
例えば,こんなの.
=
を列で揃えることはやらない (NG) らしい.
ただし,本質は チーム内で記述方法を統一すること だと思っている. なのでチーム内で規約を新たに決めてしまえば,上の NG 例を採用するのもあり (?).
[why] なぜ作られたか ?
PEP そのものは Python における開発の効率性を高めるために存在する文書群 (と認識している). コーディングするにあたって,効率が良いに越したことはないので,こういう文書群はプログラマーからするとやはりあった方が良さそう.
… 自分で書いておいて 効率 ってなんだろう … ?
と疑問に感じたので,ここでは PEP8 (コーディング規約) において,効率とやらについて考えてみた.
まず,コーディング規約でやりたいことは
開発者のセンス・技術の一部分をチーム全員で共有すること
だと思っている (<- いろいろ調べた結果の考え).
具体的には 2 つ:
- [可読性] 共有すれば,書き手の意図が読み手に伝わりやすい4.
-> 意図が伝われば5,理解しやすいので,どんどんコードが読める ! [保守性] 個々の個性を潰すことで,チーム内での技術的な溝をできるだけ埋める.
- 経験値が少ない人は,規約を一生懸命読みながら書けば,コードの質を保てる (?)
- 経験値が多い人は,規約に従って,わかりやすく一般的なロジックでコーディングをする (自身の技術レベルを周りに合わせる) ことで,経験値が少ない人の助けになる (チームの為になる).
-> 1., 2. より,全体的に読みやすくなって,ミスも減るので,正常に動作するプログラムを保ちやすくなるといえる !
他にも挙げればあるのだろうけれど,可読性 / 保守性を UP させることが規約を守る一番の意味だと現状思っている.
可読性 / 保守性が UP すれば,開発が捗る (効率が UP する) であろうことがなんとなく想像できる.
[How to] どう利用するか ?
PEP8 をなんとなく理解した. 概念が理解できれば,あとはそれをどううまく使うか.
まぁ,規約が理解できたのであれば,あとは単にその規約に従ってコーディングすれば良い訳なのだが, 規約を全て頭に入れて置くのは辛そう.
というわけで,それはツールに丸投げ !!
cf. https://qiita.com/ynakayama/items/8616f4c0c6e372de9a42
これは,規約と照らし合わせて,書き方が正しいかどうかを自動でチェックしてくれるというもの.
… しかし,上記記事を読んでも設定がうまくいかない !!
pep8 のパス指定あたりがよくわかっていない …
とりあえず記事をアップしておきたかったので,設定は保留. 近々追記 (ちゃんと設定)6 しようと思う.
ちゃんとした共同開発の経験がない !
ここまで書いておいて … 私自身,ちゃんとした共同開発の経験がない7. 仕様を固めて,規約を考えて,いざコーディング !! みたいな流れは,教授に相談こそしたが 1 人でしかやったことしかない.
なので,いろいろ考えてメモはとったが,結局上記内容は経験に基づくものではなく,ほぼ想像と言える.
企業で働き始めたらわかるのかな … (笑)
Footnotes
1 PEP: Python Enhancement Proposals
2 文書 No.8 のこと.PEP の一覧をざっと見た感じ,抜けている番号がかなりあった.RFC のように 廃止 制度がある模様.
3 これがいわゆる 標準 (デファクトスタンダート というやつ ?)
4 規約に「ここはこう書くと読みやすい !」とか「この部分のロジックは気をつけましょう」みたいなことを書いておいてチーム全員で共有できれば,「なぜこんな書き方をしているんだろう ?」みたいなことが起きにくい ... 気がする.
5 例えば … コメント無しで,コード (ロジック) だけで書き手の意図がしっかり伝わったらとても嬉しい (ような気がする)
7 ゼミ生と軽い共同開発はやったことがあるが,そのときはコーディング規約なんぞ決めていなかった.