dolem0.8.1のリリース

Read More

今回のdolem0.8.1でのアップデートはリビジョンアップデートになる。
つまり大した修正ではない。

どんな内容だったかというと、ソースコードのインデントを全てタブに統一させただけ。

Ver0.8.0より以前のものはインデントに半角空白が使われていたり、タブが使われていたりと完全統一されていなかった。
中にはファイルによってそれらが混在してしまっていたものもあった。

さすがに気にはなっていたので今回はそれに手をつけたのだ。

さて、タブに統一する修正自体は大したことはないのだが、全ファイルを対象に行ったものなのでその修正が広範囲になってしまった。

そこで、他の機能などを追加したりする前に区切りとしてリビジョンナンバーを一つ増やしたというわけだ。

しかし、そもそもなぜそんなことになっていたのかというとちょっと長い話になる。


--
俺は以前からインデントにはタブを使う派だった。まあ今もそうだが。

そして同じ会社の人でインデントに半角空白を使う人がいた。

半角空白を使う理由を聞いてみたところ、エディタによってタブの解釈の仕方が違うことがあるらしく、あるエディタでは期待通りのインデント表示がされるのに対して、同じファイルを別のエディタで開くとインデントが崩れることがあるのだそうだ。

それが嫌になってそれ以来インデントには半角空白4つを使っているのだという。
ふーん、そういうこともあるのね。


で、だ。


この時は全員が同じ、統合開発環境であるイクリプスを使っていたのでそこまで問題にならなかった。
イクリプスではインデントの広さを指定することができるからだ。

タブ1つの広さを、半角空白4つぶんにしてしまえば表示もそこまで大きく崩れることはなかった。
…いま思えばこの時もタブと半角空白が混在しているな。

でもまあしばらくはそれでよかった。
しかしその後困ったことになる。

インデントに半角空白2つを使う人があらわれたのだ。

つまり、これでタブ派と半角空白4つ派と半角空白2つ派の三つになってしまったのだ。


最初はそれぞれ好きにやっていたのだが、そうするとだんだん収集がつかなくなってきた。
表示が崩れまくりでソースコードの可読性が落ちる。落ちまくる。
ちょっと我慢できないレベル。


こりゃいかんということで急遽話し合いをした結果、新たなコーディングルールとして全員半角空白4つを使うように統一しようということになった。
そう、人が増えると決め事も増えるのだ。
これはまあ仕方ないことだ。


しかしこういう時、中には子供のように駄々をこねるやつもいたりするんだよ。

「昔はこんなじゃなかった」
「もっとやりやすかった」
とか言ってな。

まとめる気持ちあんの?

「押し付けられるのは嫌い」
とか見当違いなこと言われたひにゃあーた、もうブチ切れそうになるよ。


おっと話がそれた。


まあこの時は半角空白4つが落とし所だったんだよ。

そこで俺はまたもやイクリプスの機能にたよった。
イクリプスには、ファイルを保存する際タブがあったらそれを任意の数の半角空白に変換して保存してくれるという機能があったのだ。


そう、もう言わなくてもわかると思うが、俺はこの環境でdolemのファイルなんかも編集したりしちゃってたのだ。

そして家での環境は以前のまま。


結果、見事にタブと半角空白4つが混ざったファイルの出来上がりというわけ。


幸いなことに今はこの環境から抜け出すことができたので、インデントに半角空白を使用することもなくなった。

なので今回このタイミングで修正をいれたのだ。



ちなみにインデントの問題は今後も同じように起こりうる可能性は十分ある。

そして、インデントにタブを使うと別のエディタでずれることがあると言われたが、実は仮にこれがタブでなく半角空白であってもやはり同じことが起こりうる。


つまるところ開発環境を同じにしなければ解決し難い問題であると言えるだろう。



最後に個人的な感想だが、インデントに半角空白を使うのは玄人の人ほどその率が高い気がする。
なんとなくだが。
いや、webからソースコードをコピーとかしてたら半角空白になってることも多いか。

あとインデントが半角空白2つってのはHTML書くときくちゃっとなるので嫌いです。

タブは縦のラインをそろえやすいので好き。
バイト数も半角空白4つに比べると少ないよ!
だからなんだって感じだが。





Comments(4)

1  みやびさん  2013/02/25 (月) 11:31 ID:XXXXXXXXX
Zendフレームワーク触ってわかったんですけど、
PDOが良い子過ぎて生きるのが辛い(´Д⊂
・ストアドプロシージャ使える
・プレースホルダ使える
・PHPでのDBの取り扱い速度NO1
・MySQLとSQLite完全対応

DolemってPDO対応してましたっけ?

2  シラサヤ  2013/02/25 (月) 21:02 ID:XXXXXXXXX
dolemはPDOに対応させてないよ。
PDOの良いと思って挙げてくれてる例がそのまま使わない理由にあてはまるな。

・ストアドプロシージャが使える
->DB側にSQLが残りプログラム側だけで完結しない。結果、後から参加した人にわかりにくい。
->DBMSごとに書き方が違う。DBMSを変えたりすることたま~にある。
->DBMSで対応していないものがある。

・プレースホルダ
->SQL文字列の一部を置換するメリットがわからない。わかりにくくなるだけ。条件式となるWHERE句なんかはそのまま書かれていた方が扱いやすい。

・PHPでのDBの取り扱い速度がNo.1
->速度がNo.1と思ってない。早い理由がわからないから。
->というかそもそもクラス化しているのが気に食わない。
->よく使うものはクラスではなくグローバル関数の方が使い勝手がよい(と思っている)。
■参考サイト
PDOやらのベンチマークテストやってるサイト↓
ttp://zapanet.info/blog/item/972


--
むかーし文字コードですんごーい苦労したことがあるのでDBやSQLに関するものはなるべくシンプルなものが良いと思ってるんだよね。
# プログラムもSQLもDBや文字コードに関しても


あと海外製品は日本語の問題が起きても対応するのがすごい遅い。
PEARやZend、CodeIgniterなんかで実際にそれを経験してるのでなるべく使いたくない。
まあdolemを作ろうと思った理由の一つだね。

あ、PDOに関しては「PDO 文字コード」なんかでググッたらそれっぽい記事とかヒットすると思うよ。



おまけ:
大きな会社はどこでも自前のフレームワーク持ってる。
中小なんかがZendを使うのは自前でそれを作る体力/知識が無いのと、社員の知識向上を二の次に考えているからだと俺は思っているよ。




3  みやびさん  2013/02/28 (木) 20:36 ID:XXXXXXXXX
うーむ、フレームワークの利点としてよく「コードの品質が保たれる」とありますが、
Zendは品質が保たれているとは言えない…

OpenPNE 2では独自のフレームワークでしたが、3ではsymfonyを採用してますね。
これはシステムを丸ごと人に提供するので、仕様が決まってる他フレームワークの方が都合が良さそう。
中小企業はシステムを納品することも多いでしょうし、公開されているフレームワークを採用するメリットは有ると思います。


DBの文字化けに関しては昔を知らないのでなんとも…
UTF-8が使われて当然の時代にやり始めたのでPDOの怖さは分からないですね。
過去の遺産をどうのが来ない事を祈るばかりですが、一応SJISのSQLインジェクションは覚えておきます…

PDOの速度はNO1ではないんですね
C言語で書かれているのでPEAR系よりは遥かに高速ですが、
クラスでどうのこうのしてる分mysqlやmysqliよりは遅そうですね。

4  シラサヤ  2013/03/01 (金) 04:36 ID:XXXXXXXXX
zendのメリットデメリットか。
まあさ、あれが最高だったなら他のフレームワークなんか出てこないよ。
他のがあれより確実にしょぼけりゃ今頃とっくに淘汰されてるだろうしね。
その辺が答えだろうね。
もっともそれで言うと逆のことも言えるわけだけど。


納品についてはその通りだね。
まあ契約とる段階から手を打てばいいとも思うけど。
そういえば難読化なんて方法とってる企業もあるね。
俺はあれみたら笑うが。
隠すほどのもんかと。
よっぽど他に資産価値がないんだなあって思いながら難読化解除しちゃう()



文字化けに関しては、
昔ほどじゃないにせよ問題は残ってるから心配しなくてもちゃんと苦労するときがくるんじゃない。
できれば責任が大きくない歳のうちに、でかい問題を経験できるように祈る。



PDOなんかに関してはもうとくにいうことはないかな。
まあPEAR使うのだってありだと思うし。
つまるところ自分が何を一番大事に思ってるかってことなんだろう。
自分単体でよかれ、ならば何使おうがどう組もうが構いやしないし。
あーでもこれってプログラムに限った話じゃないなあ。