【Perl関西】Perlベストプラクティス～プログラミング作法は何故必要か？

　昨夜、kansai.pmのPerlベストプラクティス勉強会#2(略してＰＢＰ)に参加してきた。
　勉強会の内容は、エクストリームリーディング方式で「Perlベストプラクティス」を読む読書会。
　るびま勉強会と違って、物静かだが、コアな議論ができた。

【1】Perltidyrc～Perlベストプラクティスに従ったPerlプログラムのCheckStyle

　コーディング流派の多いPerlは、どうしても、ソースの可読性が低くなりがち。
　例えば、Perlの場合、$変数がスカラー変数なのか、参照変数なのか、が分からなくなる時がある。
　だから、変数名に「ref_」「_ref」を付けるやり方があるらしい。

　話を聞いたら、Perlベストプラクティスの本がPerlのプログラミング作法らしい。

　そのためのチェックツール「Perltidyrc」があるらしく、それを使うと、Perlベストプラクティスの本の何頁と相違しているから警告メッセージが出た、ということができるらしい。
　但し、英語の本らしいけれど。
　すごすぎ～。

【2】何故、プログラミング作法は必要なのか？～JavaでもRubyでもPerlでも同じ

　インデントや変数名のネーミングルール、1ステートメントの改行などの細かなルールがPerlベストプラクティスにある。
　何故そこまでこだわるのか？
　
　答えは、プログラムの可読性を高めたいから。
　その理由は、運用保守フェーズで、プログラムの可読性が保守性と密接に関わっているから。
　
　だが、ラフにプログラムを書きたい時がある。
　パッと思いついたアイデアを書き込んで動かしてみたい時、コーディングルールや整合性にあまりこだわらずにサクッと書きたい時がある。
　そして、実際に動かしながら、書いたプログラムのロジックの整合性を突き詰めながら、自分のアイデアを確かめていく。
　そんな時に、パッと思いついたプログラムは、上級者になるほど読みやすい構造になっている時が多い。

　いのうえさんが「7年経ってようやく長い変数名が自然に出てくるようになりました」と言っていたのが印象的だった。
　プログラムを書く手が自然にプログラミング作法に則っているのが上級者。
　スパゲティのようなプログラム、手が全く動かず空白の多いプログラムが多いのが初心者。

　個人的には、モデリング作業がプログラミングと同じ感覚で、簡単に動作確認できて、モデルの整合性をチェックできるようになれたらいいのに、と思う。