ＰＨＰ４とＰＨＰ５

ＰＨＰ４とＰＨＰ５では仕様が色々と違う。
と言っても、高度？なプログラミングをしていなければ、問題になることは無い。
ＰＨＰ４用のスクリプトの多くはＰＨＰ５でも動くだろう。あくまで多くの。

ＰＨＰ５のサーバーを使っていて、欲しいスクリプトがＰＨＰ４用に作られたものとする。
そして、運が悪くＰＨＰ５の仕様だと動かないとする。
しかし諦めるのはまだ早い。ＰＨＰ５にはＰＨＰ４互換モードが存在していて、ＰＨＰ４のみ動くスクリプトを動かせる可能性がある。

やりかたは、php.iniか、.htaccessに記述となるが、通常は.htaccessに記述となるだろう。
php.iniに記述したらサーバー全体に適用されてしまい、php5の機能が制限されてしまう。

php_flag zend.ze1_compatibility_mode On

もしＰＨＰ５のサーバーに引っ越して動かなくなったら、試してみると良いだろう。

phpはいけてる？

こんな記事をみつけた。
PHPを今まさに使っている（学んでいる）人へ
非難されやすい言語というのは初耳だった。
まぁ、どんなジャンルでも人気が出ると、それを受け入れてない人からは攻撃されるもだ。

phpが最も優れている徹底的証拠はこれだ。
>PHPを使ってる有名サイト：Yahoo!, GREE, digg, facebook, CNET, Wikipedia, goo, wordpress, 楽天
他にも、はてなや、その他思い浮かぶほとんどの有名サイトはphpを使っている。

今あるメジャーは言語はというと（phpびいきな説明。あくまでwebアプリ開発が前提）

・perl(CGI)　（昔使っていた）
Web用ではなく、汎用的な言語。
それだけに細かいところを操作しやすい。
逆に言えば、細かいところを操作しないといけない。
Ｗｅｂに特化していないため、余計な処理が多く開発に手間がかかりやすい。
また、短くもできるが、難解なコードとなりやすい。
そうなるともう、ソースの可読性を保つのが大変。
何でも取り込み肥大化し、枯渇した言語とも言われている。
伝統的に今も使われているだけにすぎない、マイナー化しつつある言語なのが現状。

perlといえばCGIなので、CGIについて書くと。
CGIは、呼び出されるたびにインタプリタが実行され、その上でperlが動く。
結果、大量のメモリ、大量のＣＰＵ処理が必要となる。
だいたい、php(mod_php)の１００倍遅いと思って良い。
たとえば、同時に１００人きたら、１００個のインタプリタが起動するわけだ。

・mod_perl　（使った事が無い）
採用しているレンタルサーバーは無いに等しい。
したがって、perlといったら普通はCGIのことを指す。逆もまたしかり。(他言語のＣＧＩもマイナーすぎるため)
もしmod_perlが使えれば、今主流のphpと同等の実行速度となる。
どっちが早いかは、処理内容でわずかに違う程度。
でもやっぱ、webに特化した大きなソフトは、仕組み上phpのが速いと思うが。

mod_** とは、サーバーにあらかじめインタプリタを組み込んだ形式と思えば良い。
なので、呼び出すたびに起動する必要もなく、１つですむ。
結果、最低限のメモリとＣＰＵ処理で実行し、高速になる。

・php(mod_php)　（今使っている）
Webに特化した言語。perlが使いにくいために登場した。
最小限の手間で最大限の効率を得る今もっとも効率的な言語だ。
Webに特化しているため、とてもスマートに記述でき、htmlに記述を埋め込めるため、とても柔軟となっている。
perlに比べて、初心者から上級者まで楽に扱える言語である。
なんせ主流なので情報に困る事も無い。
欠点は、楽に組み込める代償として、セキュリティー上の問題に注意しなくてはならないというのがある。
ちなみにPHP5.2以上を強く推奨。様々な強化がされ、よりいっそう使いやすくなっている。
大幅な高速化、強力なライブラリ、クラスの強化などがある。
ただでさえ強力なPHPがさらに強力になっていっている。

・ruby　（使った事が無い）
国産のインタプリタ言語。
これもまた、phpと同じくperlが使いにくいために誕生した言語である。
オブジェクトパスカル（Delphi）に近い書式を採用のように見える。
オブジェクト指向に特化させて、開発の保守性を向上させている。
ただし、実行速度はperlよりもかなり低速となる。数倍の時間が掛かると思って良い。
これは、コンパイル無しで実行するインタプリタ形式によるためだ。
他言語は、実行する直前にコンパイル/最適化するため速い。
（しかしrubyでも同様の処理をするためのテスト中。これでperlと同じ速度にまでいくかもしれない）
rubyはさらに、ドキュメントも少なく、ライブラリも少なく、敷居は高くなっている。
ただし、言語の仕組みで海外からも高い評価を受けており、これからの発展で変貌するかもしれない。

他に、たまに登場するマイナー言語には
・Python　（ほとんど知らない）
可読性に特化した言語なのだろうか。とにかく見やすいソースになりやすい。
スタイリッシュな言語と言えるだろうか。
ほとんど見ないので、よく知らないが。

ということで、今から始めるなら、PHP以外に選択脇は無いと思ったほうが良い。
わざわざ多言語から開始する理由は、ほとんどの人には無い。
perlを使っている人は、昔から使っているからであり、rubyを使っている人は、元々プログラミングに精通している人である。

PHPのコーディング方法

プログラミングをしていて、おのずと学んでいく事になるコーディング方法。
綺麗で見やすく分かりやすいコーディング方法ね。
知らなくても、長くやってれば自然と分かってきて、身についてきます。

でも初心者は思うでしょう。
なぜ、綺麗に分かりやすく書かなきゃいけないのか。
動けばいいじゃん。一人でやってるんだから、自分がわかればいいじゃん。
初心者は必ずそう思います。
でも、初めての方はまず動かしてプログラミングになれることも必要なわけで、
めちゃくちゃでも、始めの頃は動けば良いとも思います。
挫折するよりはね。

プログラミングにある程度慣れてきたら、わかるはずです。
自分が書いたプログラムが汚くて自分でもわかりにくい。
時間がたつほど、自分が書いたルーチンなのに、何しているのかわからなくなる。
汚いから、ミスが多くてバグフィックスばっかしている。
機能を増やそうとしたら、１からやりなおしたほうが早い。綺麗に書いておけば・・・。

そう、たとえ他人が見なくても、綺麗に書くことは大切だとわかってきます。
短いプログラムなら『どうにでもなる』、という初心者の頃とは違ってきますからね。
これに気が付いたら、一歩前進してみると、プログラミングがぐっと楽になると思います。

綺麗になるヒントは、php コーディング規約 で検索するとわかります。
phpを書いて長いですが、実は初めて見直してみました。

これら規約の内容は、あくまで基本です。
実際のプログラミングは、もっと様々なことに注意をはらわなければ、大きなソフトは作れないでしょう。
複数の規約を見ると、どれもほとんど内容は同じです。
行き着く先は、同じということです。それぞれが真似してるわけではないのです。

全てを真似る必要性はまったくありません。
異なったルールでやっているグループもあります。
一番大切なのは統一性です。

最も変化があるのは、名称ルールでしょう。
現在一般的なのは、『getBlogData』というような書き方です。
小文字から初めて、次の単語からは大文字で始めます。
昔の標準的な書き方は、『GetBlogData』でした。
自分で定義したものは大文字からはじめ、外部ライブラリは小文字というルールです。
ライブラリにある関数なのか、自作関数なのかを明確にするためです。
そうすれば、ライブラリの関数を全て覚えていなくても、他の人のソースをスムーズに読めます。

また、あるコーディングルールには、変数の型を変数名に含めるという方法もあります。
キャラクタ型なら c_abc、数値型なら i_abc という感じです。 c はchar型で、i は int型です。
でもphpには型の定義が無く、自動で変換されるのでこういった定義方法は使う事は無いでしょう。

私がよく使う関数名のルールにはこんなのもあります。
関数の置かれているソースのファイル名を頭につけて、関数の重複回避や、ソースを追うのに役に立っています。
『filename_functionName』 です。
html内に無造作に複数の独立したphpをインクルードする場合に都合が良いです。
この関数はどこのライブラリだっけ？という疑問も、関数名でわかり便利です。
全ての関数をクラス分けでもいいですが、長くなって面倒ですからね。ケースバイケースです。

ずっと疑問に思っていたことも、これら規約を見て解決したのもある。
文字列を囲むとき、『 ' 』にするか『 " 』にするか。
なんとなく『 ' 』にしていたけど、やっぱこの方が変数が無いか調べない分サーバーの負担も減るのでしょうね。
そこまでは書いてないけどね・・・・。
ただどの規約にも書いてないのは、『 " 』で変数を混ぜるのと、『' ' . $abc . ' '』のように外にだすのとで、どっちが良いのか。
文字の連結には『.』を使うようにって書いていながら、『""』で一緒に書くルールも書いてある。
おそらく文字列変数同士を連結させる場合は『.』という意味なのだろうけど。
混ぜる場合は、『" {$abc} "』 のように通常は『 {} 』でくくるよう配慮したほうが良いと思う。
どっかの規約の例では『 "あいうえ$abcおかき"』のようになっていたが、やってはいけない方法だ。
たぶん、日本語訳を書いた人のうっかりミスだろう。
これはエラーの原因になる。実行する機械から見ると、どこまでが変数名か判断しにくいからだ。
後ろに続く文字によっては、変数名と認識されてエラーになる。
たとえば、『$abcおかき』という変数名と認識されるかもしれない。（この文字では試していない）
自動認識を当てにしてはいけない。

コーディング規約を見ていて一番びっくりしたのは、　『 { } 』の扱い方です。
昔調べたときは、様々な方法が書いてあって、どれが良いのか答えがわかりませんでした。
そこで色々試した結果、行き着いた最善の書き方。
それがどのコーディング規約にも書かれていた。

関数は、『 { 』を関数の頭にそろえて書き、ifなどのルーチンでは その行の最後に書く。
昔調べたときは、どっちかに統一する書き方ばかりでした。
それで色々試した結果、別々の書き方が見やすいと結論したわけです。

と、色々試行錯誤した内容は、私がこっそり？配布しているスクリプトに現れています。
すなわち、統一性がちょっと低いという、素人じみたソースです。
その日によって、ルールを変えてやりやすさを調べていました。
理論より実践です。

さて、書き方のルールがわかったら、次はルーチンを組み方に慣れる必要があります。
だらだらと書くのではなく、関数等にわけてスマートに書くのが楽です。
これも初心者は疑問に思うでしょう。
何故、関数に分ける必要があるのか。一気に書いちゃった方が楽じゃないの。
昔から多くの人にこういった質問を受けていました。

確かに、一回しか使わないルーチンなら関数にまとめる必要は無いかもしれない。
しかし、同じ処理をする一連のルーチンを何度も書く場合はどうか。
初心者は思う。　「コピペすればいいだけじゃん。」
それでできたのが、同じ処理が数箇所に記述される長いソース。
もし、その処理にバグがあったら？
もし処理内容を改善したくなったら？
もしかしたら、その修正過程で、あるルーチンだけ記入ミスするかもしれない。
たいだい、同じ処理をしている箇所を全部探すのが大変、書き直すのが大変、長くてみにくい。
長くてみにくいと、そこにバグが生まれる。
だから一箇所にまとめて共通で使ったほうが便利。修正もその一箇所ですむ。
実際にそうすると、もっと様々な利益（効率）があることに気が付くでしょう。
オブジェクト指向はこうやって始まりまりました。
たとえその時は一回しか使わない処理内容でも、区切りのいい場所でわけて関数等にすると良い。
そうすれば、ソースが見やすくなり、どういった処理をしているのか一目でわかり、バグが発生しにくくなる。
これが、オブジェクト指向と呼ばれる考えの原点です。
各処理をオブジェクト（関数等の部品）としてつくり、それらオブジェクトを組み合わせて一連の処理を行う方法です。
これをやりやすくするために、クラスと呼ばれる物が生まれました。

長くなってきて、初心者向きでなくなってきたのでここまでにしておきましょうか。