俺は演算子の前後にスペースを入れない書き方が大嫌いなんだけど、for の括弧の中では例外的にスペースを入れないようにしていた時期があった。なんとなくまとまりのあるほうがいいかなぁって思っていたから。
でも最近 Javascript で var をちゃんと使うようにしてからはその変則的なルールをやめた。
for (var i=0; i<100; i++)
alert("pgr"); for (var i = 0; i < 100; i++)
alert("pgr"); var の後にはスペースがもちろん必須なわけで、そのあとに続く部分でスペースを空けないと var だけが浮いてしまう感じに見える。気持ち悪いのでスペースをあけるようにした。var とかない C でもスペースをあける。ほとんど同じ文法なのにスペースあける場所が違うとかは論外だからね。
構造が気持ち悪い。とりあえず tDiary の話。はてなにも言えるけどはてなはソースを変えられない時点で「諦め」があるので論外。
tDiary には CSS によるテーマ機能があって、(たぶん) それがウリなんだろうけど、そのせいで構造が変えにくい。「変えにくい」ってのはテーマを使いたいからでなく、スキンファイル (構造を決定するファイルってことにしてください。CSS は含みません。) が難読になっていたり、プラグインの吐くソースがキモかったりする。「どうせテーマを使ってもらうんだから構造は決めうち。スキンファイルは開発側が編集できればいいや」みたいな。
俺が tDiary を使っていたとき、そういう気に入らない構造の部分をざっくり修正して使っていたんだけど、バージョンアップしようと思ったときに死んだ。そしていろいろあって tDiary を使うのをやめた。使うのはやめたけど ML は読んでる。なんとなく。
少し前に「form 要素直下に input 置くと validator に怒られるので div で囲う」みたいなメールが流れてた。あはははって感じ。
誰もが納得できる構造にするのが一番いいんだけどそれは難しい。だから、スキンファイルをシンプルに。変なソースがあってもユーザが修正できるように。スキンファイルを編集しても別なところでエラーがでないように。バージョンアップのときにスキンファイルを変えなくてもいいように。
ちなみに「誰もが納得できる構造」であれば CSS によるテーマってのはすごく素敵なもんなんだよなぁ。というかおかしいんだよ。「誰もが納得できる構造」って何なんだ。
まぁでも、こんないちいちキモイ構造がどうとかいうのは strict ヲタクぐらいなもんだろう。
そもそもカテゴリが違うといえど blosxom はよろしいな。構造？なにソレ？ていうかボク HTML なんて知らないよ、みたいな。バージョンアップしねぇじゃんとかは禁句らしい。
放任したほうが楽ちん。やりたい人は tDiary 互換フレーバーとかあるしなぁ。よくわからんセクションになってるのは俺の頭が悪いうえに今眠いからです。