「読みやすい」「メンテナンスしやすい」など、美しいコードの書き方について解説したおすすめのウェブサイトや本を教えてください。
特に言語は問いませんが、個人的にLL、特にPHPに特化しているとうれしいです。
「PHPなんかで美しいコードはかけないよ!」というそもそも論はナシの方向で。
「読みやすい」「メンテナンスしやすい」というところだととりあえず
PEAR :: Manual :: 標準コーディング規約
http://pear.php.net/manual/ja/standards.php
でしょうか。
あと、命名規則を整理することがわりと重要なのではないでしょうか。変数名のつけ方とかわりときちんとした正解、というか王道というのがどれなのかボクもいまだによくわかりませんが。
ちなみに過去この件で考えたことのまとめをブログに書いてます↓(どうでしょうか?)
命名規則もろもろ(ファイル名、変数名、関数名、クラス名)。 - Kemworld::Diary
http://d.hatena.ne.jp/kemworld/20071009/1191902294
あとはデザインパターンとかですかね↓
http://www.doyouphp.jp/sample/sample_class_list.shtml
正直読みやすいかどうか、という観点だと超オブジェクト指向的なコーディングよりも、ほどほどな感じの、手続き型っぽい?コーディングのほうが分かりやすいよなあ、と思ったりもするんですが。
ボクも非常に興味あることなので是非他の方の回答も読みたいです!
すこし古いしCの本ですが、こういうトンデモなソースの例を見ると、意識が変わるかもしれません。
Cプログラミング診断室―さらに美しく健康的なプログラムのために
あと、デザインパターンの話が出ていましたが、デザインパターンはどちらかというと大局的というか、アーキテクチャや実装の構造を設計するときに頭に入っていると役立つ考え方です。
リファクタリングは逆に、実装しながらコードを壊さずに整えていく手法を提唱するものです。
こういった手法がマスターできると、命名に失敗したと思っても、安全に修正することができます。
リファクタリング―プログラムの体質改善テクニック (Object Technology Series)
あとは、ツールをうまく活用することも重要というかオススメです。
PHPの開発についてはあまり知りませんが、
・ドキュメント生成ツール(doxygen) - コメントやドキュメントは重要です。
・UML設計・リバースエンジニアリングツール(Enterprise Architect) - みんながわかりやすい構造にするのも重要です。
・開発環境(Eclipse,etc) - 実践しやすい環境を選択するのも重要です。
などを使いこなすというのも一つの助けになるかもしれません。
#emacs/muleなどスペルチェッカ機能のあるエディタもあります。
#変数名のスペルミスを防ぐためにも重宝するかもしれません。
あとこれは個人的な経験ですが、「トリッキーなコード」を書くよりは、冗長でも「標準的なコード」を書くほうがメンテナンスなどは楽で美しく見えます。
「美しい」とは何を指すのか?というのは状況依存でしょうが、「トリッキーなコード」というのは、書いた本人は「何て頭がいいんだろう!スマートなコードがかけた!」と自己陶酔しやすいわけですが、そういうコードを他人が読んだときに一発で意味が理解できるかどうかは別問題だったりします。
そういう意味では、Perlなどはそういうコードが書きやすい一方、あとになって、「何でこんな風に書いたんだろう?」「何でこのコードでこういう動作になるんだろう?」という状況になりやすい側面もあるように思います。
自分ではコードのダメな部分って気づきづらいですからねえ…
あんまりたくさん本を読んで、さぁ書くぞとなると堅苦しくて一行も書けなくなっちゃいますよ?
これくらいのルールで私は十分美しいと思うのですが。
1.ルーチンごとに数行、なにをするか注釈をいれる。引数説明があればベター
2.ネストは必ずタブでインデントする
3.数行おきにコードの「意図」をコメントする
4.50−60行でひとまとまりを終わりにする
5. 省略形のifは使わない
こんなもんですが。ダメですかねぇ。
>美しいコードが書きたいです。
>「読みやすい」「メンテナンスしやすい」
美しさは数値化できませんが、ソースコードの「読みにくさ」のメトリクスとして
「McCabeのサイクロマチック数」(マッケーブの循環的複雑度)というものがあります。
以下に解説がありますが、
http://www.linkclub.or.jp/~tumibito/soft-an/metrics/mccabe.html
2.循環的複雑度の意味するところ,数値の目安
試験(特にホワイトボックステスト)のしにくさや保守(変更)作業のしにくさを表します.
文献 [2] p.230 によると,以下のような目安をあげています.
1. 10 以下であればよい構造
2. 30 を越える場合,構造に疑問
3. 50 を越える場合,テストが不可能
4. 75 を越える場合,いかなる変更も誤修正を生む原因を作る
誤修正する確率も以下であると言われています。
< 10 約 5%
20 - 30 約 20%
50 以上 約 40%
100 近く 約 60%
以下のSourceMonitorというツールを使用すると測定できます。
http://www.campwoodsw.com/sourcemonitor.html
PHPは対応していませんが、以下の言語の測定ができます。
関数(モジュール)単位で複雑度が測定できます。
いきなり、複雑度の高い関数に手をつけると、悲惨な目にあいますので(100超える関数はプログラマなら見ると絶対さわりたくなくなります><)
普段から測定して複雑度が10~20程度を超えないように、また複雑度の高い関数はリファクタリングを行うようにすることで、読みやすく、メンテナンスしやすいコードになると思います。
本のタイトルがまさに、ですが。
http://d.hatena.ne.jp/asin/0596510047
言語はバラバラなのですが、コードが記述者自身(半端じゃない面子です!)により解説されているという、涎垂ものの一冊です。
「美しい」という言い方は人により感じ方が様々になってしまうので難しいところですが、著名な方が何を善しとしてコードを書いているのかを知ることは参考になると思います。
プログラムに限ることではありませんが、自分で書いた古いコード(できれば、1ヶ月以上前に書いたもの)を読んでみることをお勧めします。コードを書いたときの記憶が鮮明じゃないものが良いです。
そうすると、まるで他人の書いたコードのように読みづらいとか、意味がわからないと感じるコードがあると思うのです。そこに気づくことが最初のステップです。逆に言えば、おそらく、他人があなたのコードをみた場合にはほとんど同じように感じるわけです。
そして、今の自分ならどう修正できるかなと考えてみましょう。コードを修正する時間と自由があるのなら、実際に修正してみるのが良いです。自分のコードを読み直すという作業をやっていくだけでもコードはどんどん洗練されていくはずです。
私は20年以上プログラムを続けていますが、過去のコードには恥ずかしいものが多いです。逆説的にいえば成長したなぁというわけでもありますが・・・。そういう意味では、美しいコードを書くことにゴールはないのでしょう。
PHPの話でなく(ハンガリアン記法の話)、また具体例が少ない記事で恐縮ですが、
冒頭の、コードで「きれい」さを保つ考察は「読みやすい」「メンテナンスしやすい」に通じており、
一読の価値ありと思います。
「間違ったコードは間違って見えるようにする」
http://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9...
命名規則は重要ですねー。
自分で書いたコードでさえも「なんだこの変数…」となることがしばしば…