<!--
   $FML: style.sgml,v 1.14 2005/06/25 15:11:35 fukachan Exp $
-->


<chapter id="programingstyle">
	<TITLE>
	プログラミング・スタイル
	</TITLE>

<para>
本章は、プログラミング・スタイルに関する諸問題についてのメモです。
</para>

<para>
FML.ORG のソフトウエア・コーディング・スタイルの詳細は
<ulink url="http://www.fml.org/software/FNF/">
FNF (FML.ORG Natural Form)
</ulink>
を参照して下さい。
</para>


<!-- ==================================================== -->
<sect1 id="variable-naming-convention">
	<title>
	変数の命名規則（ネーミングコンベンション）
	</title>

<para>
default という単語をどこにはさむか？は悩ましいです。
</para>

<para>
一般に、一番左に来る（たいてはい最初の _ までの）文字列部分は、
大きな”くくり”でのクラスを意味すると考えられます。
</para>

<para>
たとえば article_* であれば記事関連の変数がすべて 
article_* (article の右側に単語が続く変数群)
に定義されていると期待するでしょう。
</para>

<para>
そう考えると、
default_* (つまり default クラスが存在すると考える)より、
「クラス_default_変数」ないしは「クラス_変数_default」
というシンタックスが素直に思えます。
</para>


<sect2>
	<title>
	変数の階層構造
	</title>

<para>
よりシステマティックな変数命名ルールを考えていくと、ここでも、基底クラ
スと継承という考えを（ある程度）導入する方がよいと思うようになりました。
たとえば、次のようなものです。
</para>

<para>
mail は「いわゆるメール」つまり messager/rfc822 形式のものです。
fml システムへ入力されるものも mail だし、出ていくものも mail です。
それらは mail から派生したサブクラスと考えられるため、
「PREFIX_mail_属性」形式に統一する方が良いでしょう。
ただし、ものすごく厳密に行なうと、逆に、わけがわからないのでほどほどに。
</para>

<para>
<screen>
mail_何とか
mail_default_何とか

use_incoming_mail_何とか
incoming_mail_何とか

use_outgoing_mail_何とか
outgoing_mail_何とか

use_report_mail_何とか
report_mail_何とか
</screen>
この例でも、厳密には outgoing_report_mail とかするべきなんでしょうけど、
そこまではやらないのがほどほどってところですね。
</para>

<para>
ヘッダ関連の場合、こういった感じになるでしょう。
<screen>
header_なんとか
header_default_なんとか

article_header_なんとか
use_article_header_なんとか

command_mail_header_なんとか
use_command_mail_header_なんとか
</screen>
</para>

<para>
<link linkend="list.variables.by.class">
クラスの階層構造
</link>
であらわすと、こーんな感じになるとおもいます。
<screen>
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 だとわかる命名を)
}
</screen>
</para>

</sect2>


<sect2>
	<title>
	標準パターン (例 log.cf lock.cf)
	</title>

<screen>
use_変数		=	yes か no

# ディレクトリなら最後に _dir がつくことが望ましい
変数_dir		=	文字列

# ファイルなら最後に _file がつくことが望ましい
変数_file		=	文字列

変数_type		=	文字列

変数_format		=	文字列

変数_format_type	=	文字列

変数_limit		=	文字列(数字だけど文字列扱い)

変数_upper_limit	=	文字列(数字だけど文字列扱い)

変数_lower_limit	=	文字列(数字だけど文字列扱い)
</screen>

</sect2>

<sect2>
	<title>
	パターン２ (例 acl.cf)
	</title>

<screen>
変数_restrictions	=	reject_属性1
				check_属性2
				permit_なんとか

属性1 			=	パターン1
				パターン2
				…

属性2			=	var1
				var2

</screen>
</sect2>


<sect2>
	<title>
	パターン3 (さらにプログラム名がつく場合)
	</title>

<screen>
プログラム_変数_属性
</screen>
</sect2>


</sect1>


<!-- ==================================================== -->
<sect1 id="design.policy">
	<title>
	デザイン/コーディングスタイルの上でいろいろ
	</title>

<warning>
<para>
スタイルについては、
<ulink url="http://www.fml.org/software/FNF/">FNF</ulink>
も参照して下さい。 
</para>
</warning>


<sect2>
	<title>
	２、３の注意点
	</title>


<para>
サーチするキーに対して quotemeta() を
</para>


<para>
オブジェクトの中身のキーを直接使わずに、
常にアクセスメソッドを定義すること。
例: main_cf へのアクセスは 
<screen>
$curproc->{ ... }->{ main_cf }
</screen>
ではなく
<screen>
$curproc->main_cf();
</screen>
を使うこと
</para>


<para>
@EXPORT @EXPORT_OK はできればやめたい…
</para>


<para>
Srting::is_japanese_string()
くらいの階層に浅くするべきではないかなぁ？
せめて 3 段目くらいで止まってほしいような〜
</para>

</sect2>

</sect1>


<!-- ==================================================== -->
<sect1>
	<title>
	プログラミング・スタイル (原案のメモ(注: 単なる走り書き))
	</title>

<warning>
<para>
ログとして、原案のメモ(注: 単なる走り書き)をここに記録しておきます。
読みづらいですが、失礼。
</para>
</warning>


<para>
<itemizedlist>
	<listitem>
	<para>

	Perl ではポリモーフィズムと実行時バインディングができることに
	重視すること。多重継承などに頭を使うより
	ポリモーフィズムと実行時バインディングによる
	コンポーネント指向ぽい方向性を模索する。
	</para>


	</listitem>

	<listitem>
	<para>

	Perl 5 のパッケージを使った、オブジェクトぽい書き方は
	変数自身が自分のパッケージを知っているので、
	単にパッケージ修飾(例: :: )を使わなくてもよいくらいに
	思う方がよい。
	</para>


	</listitem>

	<listitem>
	<para>

	そのために、
	再利用性と抽象度を高くしたインターフェイスは
	オブジェクトぽい書きかたが良さそう。
	</para>


	</listitem>

	<listitem>
	<para>

	Perl 5 だと必然的にオブジェクトぽくなってしまうが、
	オブジェクト、オブジェクト、オブジェクトし過ぎないように
	バランス感覚に注意しよう。
	</para>


	</listitem>

	<listitem>
	<para>

 	他人のモジュールを使う場合はともかく、
	自分達で書くモジュールでの
	”深い”継承はできるだけ避けたい。
	何でも深くすればよいというものではないでしょう。

	</para>
	</listitem>

</itemizedlist>
</para>


<para>
	libexec/ や libkern.pl にある関数は、
	main:: に記述される部分は基本的なフローを記述している。
	これらは基本的な枠組を示すものであるため、
	$curproc (C でいえば struct *curproc にあたるもの)
	を受け渡す、構造化プログラミング的な書き方をしている。
</para>



<para>
	しかし、そのひとつ下の層、そしてさらにその下では、
	再利用性とポリモーフィズムに傾いた方がよさそうにおもえる。
</para>

</sect1>

</chapter>
