絖綛 N@i.jp  昨日:00019694
 今日:00010266
 総計:00048316
keywords
管理者専用
  Post   Add link   Control Panel 































新しいトピック
最新:10/01 12:07


新しいコメント
最新:07/28 16:47






管理人へMAIL

プライバシーポリシー

QuickIR を pycodestyle で検査してみた

Pythonのコーディング規約って結構厳しいのね


PEP日本語訳:<http://tdoc.info/PEP-ja/>
PEP8日本語訳:<http://pep8-ja.readthedocs.io/ja/latest/>

1. pycodestyle とは

 Pythonは概念や文法が比較的易しい簡潔な言語で、習得しやすいと言われています。しかし、プログラムの読みやすさ(可読性)については強いこだわりがある事でも知られています。そのこだわりは、プログラムの構造をインデント(字下げ)で表現する(その結果、誰が書いてもプログラムの構造が把握しやすくなる)という文法にも現われています。
 しかし、それ以外にもコーディング規約があり、PEP8という文書で公開されています。(PEPとは"Python Enhancement Proposal"の略で、日本語では「Python向上提案」とでも言えば良いのかな。)このコーディング規約を読むと、プログラムの可読性を高めるために準拠すべき項目が結構細かく定められています。
 趣味のプログラムならともかく、標準で提供されているライブラリ(パッケージ)では、PEP8に準拠する事が厳しく求められているようです。ただ、人手でPEP8に準拠しているかチェックするのは面倒な作業なので、そのためのチェックツールがあります。それが pycodestyle で、以前はダイレクトに pep8 という名前だったそうです。

2. インストール方法

 pipコマンドでインストールするのが一番簡単です。

$ sudo pip3 install pycodestyle
$ pip3 list
Package     Version
----------- -------
pycodestyle 2.2.0

3. QuickIRのソースプログラムを検査させてみる

 QuickIRのソースプログラム"QuickIR.py"を pycodestyle で検査させてみました。"QuickIR.py"はGUI部分だけですが、800行近くあります。すると出るわ出るわ。pycodestyle には --statistics という統計情報を出力するオプションがあるので、これで出力させた統計情報が以下です。

11      E221 multiple spaces before operator
1       E225 missing whitespace around operator
2       E261 at least two spaces before inline comment
2       E265 block comment should start with '# '
14      E302 expected 2 blank lines, found 1
1       E305 expected 2 blank lines after class or function definition, found 1
86      E501 line too long (80 > 79 characters)
1       E701 multiple statements on one line (colon)
1       E711 comparison to None should be 'if cond is None:'
2       W291 trailing whitespace

 全部で121箇所。6.6行に一回はコーディング規約違反しているということになります。一番多いのが1行が長過ぎるという指摘ですね。でも tkinter のAPIは引数が多いので、どうしても行が長くなりがちです。行を折り返すことで、かえって読みにくくなる場合もあるので、この指摘については少し大目に見てもらって、それ以外はできるだけ修正するようにしました。修正した結果、

9       E221 multiple spaces before operator
33      E501 line too long (83 > 79 characters)

となりましたが、長い行を折り返した結果、170行以上増えて970行のプログラムになりました。
 やみくもにコーディング規約に準拠すれば良いというわけではなく、目的はあくまで「読みやすくする」ですから指摘箇所を全部修正すれば良いという事ではないでしょう。ということで、このあたりで止めることにしました。あとは修正によってバグを作り込んでいないかチェックすることも重要ですね。


< 過去の記事 [ 12月の プログラミング リスト ] 新しい記事 >

2016 calendar
12月
123
45678910
11121314151617
18192021222324
25262728293031


掲示板
最新:08/15 17:19


GsBlog was developed by GUSTAV, Copyright(C) 2003, Web Application Factory All Rights Reserved.