どういうプログラムを関数化をしたほうがいいのか しないほうがいいのか

質問

phpで、使いまわす可能性が高いコードを関数化しようか
迷っているんですが、関数化するとソースがどんどんカオス化していき
後から見て、ちゃんと管理ができるのかなあと不安になります。
他の人からみても分かるかどうかというのも問題です。
プログラムで、こういうソースコードを関数化したほうがいい
逆に、こういうコードは、直書きしたほうがいいというのがあれば
アドバイスお願いします。

回答No.1

nayuneko · ベストアンサー

フィーリングプログラマなので、「必ずこうする！」
という定石はないのですが、参考程度にでも。

1. 使用頻度の高いロジックを関数化
これは定番じゃないでしょうか。

2. 保守性の観点から見てわかりづらいものを関数化
ひとつの関数内にだらだらとロジックを書き連ねるのは保守の観点から見るとすごく見づらくなると思います。
なので、"ひとつの機能"を関数化して独立させてあげます。

もしその機能が、他のコードでも使いまわせるようならば、共通関数化してどのコードからも参照できるようにしちゃいますね～。
# どのコードからも使えるように汎用性を持たせるのが難しいですが…

3. ある程度の機能をファイルに分けて管理
関数化、というわけではないのですが、ある程度機能の方向性を分割して、ファイルごとに関数を管理しています。
たとえば、
hogehoge1.php
　function hoge_read() {}
　function hoge_write() {}
　hoge_func()
　{
　　hoge_read();
　　hoge_write();
　}

と記述するのではなく、
hogehoge1.php
　include_once('read.php');
　include_once('write.php');
　hoge_func()
　{
　　hoge_read();
　　hoge_write();
　}

read.php
　hoge_read();

write.php
　hoge_write();

のようにファイル分割して関数を管理するとカオス化するのを最小限に抑えられます。

こんなもんでしょうかねぇ…

お礼

回答ありがとうございます。
大変参考になります。
いかに、機能ごとに分割できるかというのがミソですね。
このあたりのアーキテクチャはオブジェクト指向の思想と
共通してるものがありますね。

回答No.5

gon987

自分の場合は最近はクラス化しますね。
である程度似たような機能やある程度まとまった処理のメソッド(関数)を
グループとしてひとつのクラスにしておきますね。
(データベース関連/日付計算/ログイン(セッションやクッキー)処理など機能ごとにひとまとめとして)
でそのまとまりでひとつの別ファイルをつくりまったく別のプログラムでも再利用しやすいようにしていますね。

ついでに
>関数化するとソースがどんどんカオス化していき
しっかりコメント書いている?
最低限
関数名・機能説明・引数の値の意味・戻り値の意味など書かないとだめですね。

お礼

回答ありがとうございます。

>しっかりコメント書いている?
いままで、あまる書いてませんでした！

コメントって相当重要ですね。

回答No.4

noname#58606

ＰＨＰでは、ある程度なんでも出来るけど、あまりロジックやアルゴリズムは自信が、猛烈にないのですが。＾＾；
関数ってほーっておくと、訳が分からなくなりますよ。ｗ

私も、分からなくなった口です。
◆関数はシンプルに、こまめに分ける。
◆関数名を分かりやすく。
◆関数の説明は分かりやすく。

すると、ある程度見通しがよくなりますよ。
あとは、グループで開発する場合は、ローカルルールを把握するのが、ポイントです。
それと、一つスクリプトを作った後、紙にプリントアウトして見直すと、「あー、ここは変だ。」ってのが、分かりますよ。
それを元に、もう一度同じスクリプトを作ると、ちょっとだけ効率的なスクリプトが、出来ます。
それの繰り返しが、上達のコツだと、思いますよ。

あとは、感謝と根性ですかねー。ｗ

お礼

回答ありがとうございます。

＞関数の説明は分かりやすく。

関数に必ず
処理内容の説明　引数の説明
を入れたら大変分かりやすくなりました。

回答No.3

yambejp

よほどのことがないかぎり直書きしたほうがいいソースなんてないでしょ。
（もちろんハローワールドくらいはじかに書いてもいいですけど）

まずはメインルーチンをつくって最低限のフローをブロック化するだけの
関数をかいておき各関数の中から、単機能ごとに必要な関数をつくって
してしまえばよいでしょう。
実際にはほとんどクラスで管理することになるでしょうから。
メインさえすっきりさせておけば、ソースは追っかけやすくなります。

再利用性の高いソースは、commonクラスなど汎用クラスをつくっておいて
どんどん放り込んでやれば、実際に利用するときにはincludeするだけなので
個別のプログラムでカオス化することはすくないとおもいます。

お礼

回答ありがとうございます。
まさしく、そのような設計がオブジェクト指向なんでしょうか。

ライブラリや、サンプルソースを見ると
みやすいソースって確かにメインがすっきりしてますね。

commonクラスというか、commonファイル的なファイルを実際に作って見たところ
大変管理しやすくなりました。
とりあえずは、機種依存文字を置換する処理なんですが
何も考えなくても、そのファイルさえ呼び出しておけば
機種依存文字が使われないことが保障されるので大変扱いやすいです。
追加する時も本当に簡単ですし・・・。

大変参考になりました。　ありがとうございます。

回答No.2

hrm_mmm

＞関数化するとソースがどんどんカオス化
関数を作ったら、スパゲッティソースになるというのは、よっぽど変な作りかたしているとしか思えない。
まずは、メインの流れの中に関数定義は置かないこと。
同じファイル内なら、定義部分はソースの最後でよい。（トップダウン方式ともいう、私はもっぱらこの方が理解し易い）
考え方はいろいろあるので、先に関数定義をざっと並べておいて、最後にメインルーチンという方法もある。（ボトムアップ方式）
関数定義を別ファイルにする方が、メインルーチンでは、requireで読み込んだ後は、組み込み関数と同じ感覚で呼び出しすればいいので、よりすっきりする。

関数名の管理が、ごちゃごちゃする（かち合うと２重定義エラーになるし）というなら、命名規則を自分で作ってそれに沿って名付ける。
変数は、関数内でのみ使う局所変数は、他の関数で使っていてもなんの関係もないので、内部で、解りやすい命名をおこなう。
そのルーチンは一回しか使わなくても、変数の局在化の目的で関数にすることもある。

関数定義の別ファイルが大量に出来て、ファイル群がカオス化すると言う意味なら、ファイル名も命名規則で見分けやすくするとか用途別にディレクトリ分けするとか。

読む方の読みやすさというのは、つまり、数ヵ月後その中身を忘れた頃に自分が読んで直ぐに理解できるかってあたりで判断してもよいかとおもいます。
ということで、私は、コメントは残しておく方です。

例 トップダウン方式
// // main routine
$s = start_func();
if( $s ){
$a = syori_1($s);
}else{
$a = syori_2($s);
}
print_body($s,$a);
end_func();
// // 以下定義
/*
この定義の並べる順番は、phpにとっては、どうでもよいが、読む方にとっては、実行順の方が理解しやすいだろう。
*/
function start_func(){
$res = true;
$res = header_else($res); // header 関係操作とか いろいろ実行
return $res;
}
// 関数の内容表題　引数の意味、返値の意味などコメントしておくとよい
// 引数($s : startの返値);
// return string
function syori_1($s){
$res = 'performed'; // いろいろ実行
return $res;
}
// ...略...
// end //

お礼

回答ありがとうございます。
トップダウン方式で書いてみたところ、
関数系プログラムが一番下に固まるので大変見やすくなりました。
直書きから、インクルードに切り替える時も
一番下に固まってるので大変取り出しやすいです。

ファイル名のつけ方も惜しみなく長い名前にしたほうがよさそうですね。
エンコード変換関数とかでsjis to eucを　s2e　とかする人いますが、
一見なにやら、よくわからないですものね。

ありがとうございました。