本章は、プログラミング・スタイルに関する諸問題についてのメモです。 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 にあたるもの) を受け渡す、構造化プログラミング的な書き方をしている。 しかし、そのひとつ下の層、そしてさらにその下では、 再利用性とポリモーフィズムに傾いた方がよさそうにおもえる。