本章は、プログラミング・スタイルに関する諸問題についてのメモです。 FML.ORG のソフトウエア・コーディング・スタイルの詳細は FNF (FML.ORG Natural Form) を参照して下さい。 default という単語を変数名のどこに入れるか？は悩ましい問題です。 一般に、一番左に来る（たいてはい最初の _ までの）文字列部分は、 大きな”くくり”でのクラスを意味すると考えられます。 たとえば article というくくりがあるとします。 その場合、 記事関連の変数は、すべて article_* (article の右側に単語が続く変数群) という名称だと期待するでしょう。 そう考えると、 default_* (つまり default クラスが存在すると考える)より、 「クラス_default_変数」ないしは「クラス_変数_default」 というシンタックスが素直と考えます。 よりシステマティックな変数命名ルールを考えていくと、 ここでも、 基底クラスと継承という考えを（ある程度）導入する方がよいと考えます。 たとえば、次のようなものです。 mail は「いわゆるメール」つまり messager/rfc822 形式のものです。 fml システムへ入力されるデータも mail 、出ていくデータも mail です。 それらは mail から派生したサブクラスと考えられるため、 「PREFIX_mail_属性」形式に統一する方が良いでしょう。 ただし、 ものすごく厳密に行なうと、逆に、わけがわからないのでほどほどにしましょう。 mail_何とか mail_default_何とか use_incoming_mail_何とか incoming_mail_何とか use_outgoing_mail_何とか outgoing_mail_何とか use_report_mail_何とか report_mail_何とか この例でも、 厳密には outgoing_report_mail とかするべきでしょうけど、 そこまではやらないのがほどほどってところでしょうね。 ヘッダ関連の場合、こういった感じになるでしょう。 header_なんとか header_default_なんとか article_header_なんとか use_article_header_なんとか command_mail_header_なんとか use_command_mail_header_なんとか クラスの階層構造 であらわすと、このような感じになるとおもいます。 command { SOMETHING_command admin_command } directory { XXX_directory } file { template_file } mail { incoming_mail outgoing_mail report_mail } message { reply_message } article { article_digest (digestではなく、article の digest だとわかる命名を) article_spool (spoolではなく、article の spool だとわかる命名を) } use_変数 = yes か no # ディレクトリなら最後に _dir がつくことが望ましい 変数_dir = 文字列 # ファイルなら最後に _file がつくことが望ましい 変数_file = 文字列 変数_type = 文字列 変数_format = 文字列 変数_format_type = 文字列 変数_limit = 文字列(数字だけど文字列扱い) 変数_upper_limit = 文字列(数字だけど文字列扱い) 変数_lower_limit = 文字列(数字だけど文字列扱い) 変数_restrictions = reject_属性1 check_属性2 permit_なんとか 属性1 = パターン1 パターン2 … 属性2 = var1 var2 プログラム_変数_属性 スタイルについては、 FNF も参照して下さい。 サーチするキーに対して quotemeta() を オブジェクトの中身のキーを直接使わずに、 常にアクセスメソッドを定義すること。 例: main_cf へのアクセスは $curproc->{ ... }->{ main_cf } ではなく $curproc->main_cf(); を使うこと @EXPORT @EXPORT_OK は、できれば、やめたい… Srting::is_japanese_string() くらいの階層に浅くするべきではないだろうか？ せめて 3 段目くらいで止まってほしいような〜 ログとして、原案のメモ(注: 単なる走り書き)をここに記録しておきます。 読みづらくて失礼ですが… Perl では、 ポリモーフィズムと実行時バインディングができることに重視。 多重継承などに頭を使うより、 ポリモーフィズムと実行時バインディングによる コンポーネント指向ぽい方向性を模索する。 Perl 5 のパッケージを使った、 オブジェクトぽい書き方は変数自身が自分のパッケージを知っているので、 単にパッケージ修飾(例: :: )を使わなくてもよいくらいに思う方がよい。 そのために、 再利用性と抽象度を高くしたインターフェイスは オブジェクトぽい書きかたが良さそう。 Perl 5 だと必然的にオブジェクトぽくなってしまうが、 オブジェクト、オブジェクト、 オブジェクトし過ぎないようにバランス感覚に注意しよう。 他人のモジュールを使う場合はともかく、 自分達で書くモジュールでの”深い”継承はできるだけ避けたい。 何でも深くすればよいというものではないでしょう。 libexec/ や libkern.pl にある関数は、 main:: に記述される部分は基本的なフローを記述している。 これらは基本的な枠組を示すものであるため、 $curproc (C でいえば struct *curproc にあたるもの)を受け渡す、 構造化プログラミング的な書き方をしている。 しかし、そのひとつ下の層、そしてさらにその下では、 再利用性とポリモーフィズムに傾いた方がよさそうにおもえる。