新しいblogに移行しました

新ブログ "All Yout Bugs Are Belong To Ass" に移行しました!

2012-10-03

[Perl]ここ最近で自分のコードで筋が悪いといわれた物。またの名を自戒ドリブン開発とも。


タイトルの通り、僕のコードで良くないといわれたところと、その理由や対処方法をメモしてみた。
後学のために、自戒ドリブン開発。

1. Exporterつかって関数EXPORTはやめる
たとえば MyExport でExporterつかってEXPORTしてても、それを使ってる側からコード追いかけるときに大変になりがち。

2. for my $x ( @array ) { ... } で書けば良いところを map { ... } @array するな
return map {...} @array みたいに、配列の写像を他で使う場合にはmapを使う。
しかし写像を使わない場合forをつかうべき。最悪メモリリーク。

3. Class::Loadみたいな動的なクラスローダの多用を避けよう
どの辺からが多用といわれるのかがちょっと人それぞれ感満載だけど、とりあえずload_class()の多用は可読性を落とし、コードの危険性を高める。7.プラガブルな機構を取り入れる際の注意 も参照。

4. Attributeに利点なし
かなり前(2年くらい前?)に指摘されたものではあるけど、よくよく罹患する患者さんが多い模様なので、再掲。
可読性をおとし、危険性を高める(segvる場合もあるとかなんとか)のでよくない。その割に得られる物はほぼなし。
ここらへんにまとめた。 http://togetter.com/li/107885

5. マイナーなモジュールの選定を避けよう
この辺はセンスを問われるところでもあろうかと思うけど、聞きなれないモジュールを使うよりも、メジャーなモジュールで同様のことができないか検討したほうがいい。
何か起こったときに、モジュールの選定をした人間が責任を持って直す必要が出てくる。

6. 極端に小さな機能実装を別モジュールに切り出すのも考え物
汎用性とか利便性とご相談ではあると思うけど、たとえば、配列リファレンスであろうがなかろうが強制的に配列にする、みたいなのは、可読性等の理由で、わざわざ別モジュールに切り出す必要はない。

7. プラガブルな機構を取り入れる際の注意
3とほぼ一緒。プラガブルな機構はメンテナンス性を下げるので、プラガブルにすることで得られるメリットがよほど大きくない限りは使用を差し控えた方が無難。

8. プラグイン機構を持つモジュールを利用する上での注意
プラグインを使用する際、自分の作ったモジュールの外でプラグインのロードを行うべき。もし自作モジュール内でプラグインのロードを行っていた場合、自作モジュールを使ったときに、暗黙的にプラグインがロードされて非常に混乱する。

9. 正規表現における文字表現クラス"\d"
"\d"は、flagged-utf8のときに意図しない結果となる。例えば、5文字の半角数字にのみ対応させたい場合、/^\d{5}$/ ではなく、 /^[0-9]{5}$/ とすべき。

10. 多重継承は混乱の元なのでやめる
継承するという事自体混乱の元っぽいので、移譲で対応するのが望ましい。

11. Class::Accessor::FastではなくClass::Accessor::Liteを使おう
アクセッサが欲しいだけなら、Class::Accessor::Fastを継承するのではなく、Class::Accessor::Liteでアクセッサを生成したほうが軽いし、@ISAに余分なものを追加しない。おまけにFastよりも動作がはやい。

12. モジュールの外からアクセスするわけでもない変数にourを使うのはやめる。
そのままですね・・・

13. CPANに上げるようなモジュールでは、XS依存度を下げておく
これもそのまま。めんどくさいpullreqを未然に防ぐことにつながる。


その他、あれば追記していく次第です。

0 件のコメント: