綺麗なコードを心がける。 ― 2007年01月13日 03時45分00秒
- キミのコードが汚い理由 (@IT)
賛否両論出ているようですが。。。おいらとしては概ね賛同。
コードを綺麗に書くことによって得られる最大の利点は、メンテナンス性にあります。可読性の低いコードは、修正や拡張が困難になる。ソフトウェア資産は蓄積されてゆくものだから、メンテナンス性の低いコードが量産されれば、それをメンテナンスし続ける企業にとっては不良債権にもなりかねないわけです。
実際それが原因で一方的に契約を切られた挙句、1年間近く無償の瑕疵保証対応に駆り出され続けた某社の人たちを現場で見てきたわけですが。。。
で、話を記事のほうに移すわけですが、冒頭のサンプルプログラムに対する批判が多いっすね (^_^; 。客観性を排除してこのサンプルに限って議論するなら、リスト 2 が優れているのは、二人のプレイヤーの対称性、可換性を、うまく表現している点にあると思う。「一般化できる問題は、できる限り一般化する」というのはプログラミングにおける基本中の基本。プレイヤー 1 よりプレイヤー 2 の方が勝っている場合と、逆の場合とで、別個にコードの記述が存在するようでは、後の仕様変更で、片方のケースしか仕様変更が適用されなかったというミスに繋がりかねない。これを「メンテナンス性の欠如」と言わずして、なんと言おうか。
但し、リスト 1 の方が、リスト 2 よりも可読性は高そうだ。恐らく、このサンプルがいまいち納得されにくくなっている一番の要因は、この点にあるんじゃないかと思う。リスト 2 に対しては、適切なコメント付けが必要になるんではないかと思う。逆にいえば、適切なコメントが追加されるのであれば、リスト 2 がリスト 1 より劣っていると言える理由は、他にはなくなるんじゃないかと思う。インデントに関する好みとか、細かい部分での意見の分裂はあるかもしれないけど。
汚いコードができる理由については、最初、3 つの項目を見たときには、「なんか微妙に体育会系っぽい意見だなぁ」とか思ってしまったわけですが、読み進んでいくうちに概ね納得しました。まぁ、プログラミングって、キータイプが速けりゃ仕事も早く片付くってもんでもないし、一般化・抽象化できる要素を洗い出す作業に時間をかけるより、コピペしちゃったほうが早い、ってのも確かなんだよね。ブラッシュアップ工数を見積もりに計上したいってのが、多くの開発者にとっての本音でもあり。。。
学習については、、、おいらの体験談を明かすならば、大学ではもっぱら C と BASIC とアセンブリ言語ぐらいしか講義としては扱われなかったってこともあって、当時 C++ や Java で取り入れられ始めていた「例外」って概念を知らなかった。入社一年目の仕事で、とある C++ で書かれたプログラムのメモリエラー検出を、new 演算子が返すポインタの NULL チェックでやるのをやめて、bad_alloc 例外を検出する方法で書き直そう、という話があって、そのときおいらが担当していたモジュール (NG 喰らった前任者が残していった、それこそ不良債権w) でも対応作業を行ったわけですが、なんだか 2000 行近くある関数内の至るところに new が散りばめられていて (^_^; 、まぁ、関数内全部 try で括っちゃえばよかったんですが、それをやらずに散りばめられた new ごとに対応する try ~ catch を書いて、なんてことをやっていたら、後のコードレビューで流石に顰蹙買ってしまいまして、なんてことをやらかしたこともあったもんで、、、ただ体験的に綺麗なコードを書くことを心がけることの重要性を知らしめるのも重要っちゃ重要なのですが、やっぱりプログラミングスタイルを決定付ける様々な概念に対して、知識を深めることもまた、同時に同じくらい重要なんだろうなぁという気はするのでありまする。
熱意ってのは、よーするに優先度の問題ってことかな。大切なことだとは分かっていても、どうしても軽視してしまいがち、ってのはあるかもしれないね。だからこそ、それを適切に評価する機会を設けるってのは、大切なことだと思う。コードレビュー、ちゃんとやってますか?
注釈ポップアッププラグイン 2.0 released!! ― 2007年01月13日 16時42分22秒
こいつが早くも 2.0 にバージョンアップしますた。w
設置方法、利用方法にいくつかの変更点がありますので、ご注意ください。
こんな感じで動作します。
このサンプルは、是非、Javascript を off にした状態での閲覧もお試しください。今回のバージョンアップの真価が、ご理解いただけることと思います。
なお、括弧書きと注釈ポップアップのハイブリッド (こんな感じで、注釈ポップアップ時には両端の丸カッコが非表示になる。Javascript が off ならば、普通に括弧書きとして表示される) も可能です。
- 何故、Javascript を off にした状態で試す意味があるのか?
- Javascript を off にした状態でも (更にいえば、Javascript が使用できない環境でも)、表示に不自然さがないことに、お気付きいただけるはずです。
使い方
- annopop.js ファイルをダウンロードし、あなたが管理する Web スペースに upload する。アップロードした annopop.js ファイルの URI をメモしておくこと。(ここは前回と同様)
- 注釈ポップアッププラグインを使用したいページのどこかに、以下の HTML を追加してください。
<script type="text/javascript" src="(1.でメモしたURI)" charset="UTF-8"></script>
v1.0.x からの変更点: 必ず、charset="UTF-8"属性を記述してください。また、ダウンロードした annopop.js ファイルのキャラクターセット (エンコード方式) を変更しないでください (UTF-8 で保存されています)。
<head>要素の中で記述するのがベストですが、基本的にはどこでも構いません。ブログなどであれば、フリースタイルのブログ部品として記述しても ok です (このブログではそうしてます)。なお、本ブログのように、本文テキストが固定幅でレイアウトされているような場合、annopop_view_rect変数のプロパティを変更することによって、注釈の窓が表示される領域を制限することができます。その場合は、以下のような記述を更に書き加えてあげてください (HTML 4.01 の場合)。<script type="text/javascript"><!-- annopop_view_rect.left = 0; annopop_view_rect.right = 560; //--></script>
もちろん、XHTML の場合はコメントタグ<!--~-->の代わりに、<![CDATA[~]]>を使うようにしましょう。 - 実際に注釈を記述する方法は、2通りあります。1 つは、v1.0.x と同じ方法です (互換性のために残してあります)。これについては、前回の記事を参照してください。
今回追加された新たな方法は、以下のような書式です。<a href="#annopop-(任意のID名)">注釈を入れたいテキスト</a> <span id="annopop-(任意のID名)">(注釈の内容)</span>
- 注釈を入れたいテキストは、アンカータグ
<a>で挟みます。そして、href属性に、annopop-で始まる任意の名前のアンカーを、飛び先として指定します。 - 注釈を挟むタグは何でも ok です。
id属性に、a. で指定したannopop-で始まる名前を、そのまま記述します (もちろん#は不要)。なお、注釈を挟むタグに、<dl>タグ、または<span>タグを使用した場合に限り、以下のように動作します。<dl>タグを使用した場合 ... 子要素に含まれる 1 つ目の<dd>要素の内容のみを、注釈ポップアップとして表示します。<span>タグを使用した場合 ... 注釈の内容の両端を丸カッコ (全角でも半角でも ok) で括っている場合、両端の丸カッコを取り除いた内容を、注釈ポップアップとして表示します。
- 注釈を入れたいテキストは、アンカータグ
注意事項
前回の記事の「注意事項」を参照ください。
メモ
<a> タグの href 属性を Javascript にて取得すると、IE だけなぜかフルパスになる件。つか、変数をまんま挿入できない Javascript の正規表現は微妙にめんどいなぁ (Perl が柔軟すぎるだけ?)。
あと、IE は IE7.0 になっても DOM 回りの互換性というか標準への対応は全然為されてないのね。Node オブジェクトぐらい用意しておけと。。。
IE 6.0 でずいぶんと離れた場所に注釈ポップアップが表示されちゃうケースがあったので、やっぱり position: absolute で表示するように修正しますた。(v2.0.5)
window.scrollX / scrollY に対応していない IE で、document.body または document.documentElement の scrollLeft / scrollTop を使用する方法を解説されているこちらのサイトさんが参考になりました。m(_ _)m





最近のコメント