BLOG.QuelLENcode

by Moza USANE (a.k.a. Mozamimy)

Recent Tweets @Mozamimy


(photo by buffcorephil :: Tools of the trade)


$ means “jQuery”

jQueryは本当によくできたライブラリである。jQueryでは、jQuery.ajax()などと書く代わりに、$.ajax()と書くことができるのはご存知だろう。つまり、$はjQueryを意味する省略記号であるというわけだ。ここに、チーム開発におけるコンセンサスの重要さを垣間見ることができる。


物議をかもす$記号

Perlの文法では、$rabbit = 1のように変数の頭に$記号を付与する。Perlの流儀といえばそれまでだが、Perlを嫌うプログラマに問うと、冗長な$記号を嫌いなポイントとして挙げることが多い。

JavaScriptでは、変数の先頭の$記号を積極的に推奨しているわけではないが、文法上使ってよいということになっている。Perlに代表される「$言語」から流れてきたプログラマに対する措置だろう。


省略記法

一般に、ソースコードの可読性は高いほど良いとされる。優れたプログラマは、可読性を損なわないギリギリのラインでコードの行数を切り詰めることで、さらに可読性をアップさせる。その一方で、過度の省略は可読性を落とす原因となる。言葉遊びのようにワンライナーを考えるのは非常に楽しいが、他人の書いたワンライナーを読むのが大好きというプログラマは少ないだろう。

つまり、ソースコードにおける省略とは、諸刃の剣だ。


コンセンサスありきの省略記法

$記号は一種のクセであるので、jQueryにおける$記号は、ともすればプログラマに不快感を与えるものになりかねない。また、他のライブラリの$記号の定義とバッティングして面倒なことになるリスクもはらんでいる。

しかしながらjQueryでは、jQueryを意味する$記号が好まれて使われている。なぜか?

その答えは、「jQueryとはそういうものだ」という確かなコンセンサスがそこにあるからだ。なので、プロジェクトにjQueryを持ち込んだ時点で、$を汚染するようなコードやライブラリを組み込んではいけない。これで$記号の定義バッティングの問題も解決だ。


コーディングスタイル = 思想

jQueryにおける省略としての$記号から見えてくるのは、コーディングスタイルとはすなわち思想であるということだ。

コーディングスタイルの比較は、プログラマの間の宗教戦争の定番ネタだ。あなたもプログラマなら、気に食わないスタイルのコードを見てストレスを感じたことがあるだろう。

たとえば、わたしは以下のようなコードを好んで書く。

# nameというidを持つ名前入力用のテキストボックスがあるとする

$name = $("#name")
name = $name.val()

# 以下テキストボックスに対する処理
$name.on "click", ->
  alert name
  # :
  # :

$(“#name”)と何度も書くのがブサイク&指がこむら返りしそうなので、$nameというオブジェクトにしてしまうわけだ。そして、テキストボックスの内容はnameというオブジェクトにする。

このコードは、嫌いな人には嫌いなコードだと思う。$記号を変数の先頭に付与することで、これはDOMオブジェクトであることを明示しているわけであるが、一種のハンガリアン記法とみなすこともできるからだ。

一方、$記号を使わずに等価なコードを書くと以下のようになる。

# nameというidを持つ名前入力用のテキストボックスがあるとする

name_text_box = $("#name")
name_content = $name.val()

# 以下テキストボックスに対する処理
name_text_box.on "click", ->
  alert name_content
  # :
  # :

先に$記号を使ったコードを見ていると、$記号を使わないコードが冗長でクドく思えないだろうか?$記号を使ったコードのほうがスッキリしていて読みやすく感じないだろうか?それは、両スタイルの比較を通して、あなたとわたしの間でコーディングスタイルのコンセンサスができているからだ。つまり、先頭に$記号のついている変数はDOMオブジェクトを表しているよという暗黙の同意だ。


設定より規約

以上の考え方は、Ruby on Railsの原理である「設定より規約」に似ている。コーディング規約をしっかりと決め、背景にある考え方をプログラマ同士で共有することで、コーディング時のストレスを減らすことができる。

規約という「縛り」があるからには、そこには必ず理由がある。すべての場合に対応できる規約を決めることは現実的ではないが、プログラマ同士、ある程度のコンセンサスをとっておくことは大切である。

  1. wcoloract2012blからリブログしました
  2. act2012bltechbiasからリブログしました
  3. techbiasmozakoからリブログしました
  4. mozakoの投稿です