変数の型がわからないのはIDEを使ってないからかも!ということで、有名そうなpyCharmをインストールして、作っていたライブラリを開いてみた。
テキストエディタのように普通に開けたのだが、スクロールバーが見づらいなぁ。
あ、これ全部指摘だ・・・。
全部は見ていないけど、PEP8という指摘が多い。
コメントがああだこうだ出ている。
Python のコーディング規約 PEP8 に準拠する - Qiita
ほう、そういうものがあるのか。
しかし・・・細かい。
無理に従うつもりはないのだけど、今から変な癖を付けたくもないので、理解できるところは対応しよう。
しかし、指摘はスクロールバーにしか表示してくれないのか?
あ、色設定がtwilightだから見えなかっただけのようだ。
・関数内の変数は小文字にしよう
ちっ、私にしては珍しくキャメルを使ってやったのに、この仕打ちか!
・関数名も小文字にしよう
えっ、そうなの?
アンダースコアでつなげるタイプなんだ。
・引数にlenとか使っちゃいかん
そんな短いのを標準で使わないでおくれ・・・。
・そこに括弧はいらないよ
tupleで値を返すのに括弧で囲んでいたのだけど、いらないんだ。。
・ブロックコメントは「#」で始めよう
?
ああ、「#こめんと」じゃなくて「# こめんと」とスペースを空けろということか。
・行末にセミコロンはいらん
習慣なんだよ、習慣!
・関数間は2行空ける
あー、はいはい。
・行が3行以上空いている
。。。
・docstringはダブルクオーテーション3つで
普通のところはシングルクオーテーション3つで何も言われないけど、ファイル先頭だけは指摘された。
pydocでコメント化されるからだろうか。
・1行が長い
改行するよ!
と改行したら、こんな警告が出てきた。
どうやら、改行後の位置まで指摘しているらしい。
a = abc + def + ghi + jkl
のghiとjklの間で改行したい場合は、
a = abc + def + ghi
+ jkl
のようにするとよいようだ。
やれやれ。。。
この辺をRefactorを使いつつ修正して、今まで作っていたサンプルを動かそうとしたら、動かない。
変更した関数名が、下々に反映されていないのだ。
Refactorを使ったのに、なぜ・・・。
そうか、プロジェクトの設定で、作ったライブラリが有効になるようにしていなかったから、下々は関連性がわからずに反映されていなかったということか。
確認欄に出てくるファイル名が少ないと思っていたんだ。。。
pyCharmの「File > Settings > Project:xxx > Project Structure」で、Add Content Rootをライブラリのあるフォルダにしたら見えたのだけど、何か設定が違う気がしている。
PYTHONPATHに追加するだけだったのだけど、Project StructureじゃなくてProject Interpreterの方に追加するのかしら。
でも、こっちでローカルのファイルを追加しようとするとエラーになるのよねぇ。
__init__.pyがないからかしら。
まあ、これは後日調べよう。
簡単な対応は上記くらいで、あとはコード部分になってきた。
まず、単なる足し算の行が指摘されている。
なんだよ・・・
あ、pythonって、「+=」が使えるんだ!
++が使えなかったので、+=も無いと思い込んでいたのだ。
不覚。。。
この指摘って、マウスカーソルを外すとすぐに消えてしまうのだが、なんとかならないだろうか。。
検索したくても消えてしまうのだ。
doxygen用の「##」も指摘されるのか。
pydocのものでも処理はしてくれるそうだ。
http://www.doxygen.jp/docblocks.html#pythonblocks
ただ、私がdoxygenを使いたいのは、引数の説明(型としてこれを取ります、など)を書きたいからなのだ。
だから、doxygen形式で書きたいのだけど、そうするとPEP8指摘が多数出てしまう。
特定のコメントを書くと無視してくれるらしいけど、うーん。。。。
How to disable a pep8 error in a specific file? - Stack Overflow
あ、#を連結しても、その後に文字列が続かなければ警告が出てこなかった。
##
# 関数のコメント
# @param[in] xxx aaa
こんなのでよいらしい。
ちゃんと先頭は@briefで拾ってくれているようだ。
最後に、そんな属性はない、という警告が残った。
検索すると、import文で出てくるという例はあったのだが、関数内の方は見つからなかった。
動いているから、ないってことはないと思うのだが、わからんので放置だ。
多少、口うるさいという印象を受けなくはないが、C言語もこのくらい規約がうるさければ、人によってソースの書き方がずいぶん違うと言うこともなかっただろう。
まあ、時代が違うから、C言語の自由さとその結果から得られたものだ、と思うことにしよう。
口うるさい厳しさも優しさですよ・・・(お母さんを思い浮かべながら)
返信削除おかーさーん!
削除