Javascriptによる大規模開発の覚え書き がずいぶんブックマークされているようですが、「3.引数のJSON化(Hash化)せよ」については、 「ハタさん」は (少し手抜きですが) とも書いてありますが、実際にこのまま取り入れるのは良くないと思います。

サンプルのため簡単に書いたのだと思いますが、大事なところが手抜きされているため、 代わりに手抜きしない場合の説明とコードを載せようと思います。

この項目の導入として、引数の数を増やした場合と比較して、 「引数の順番で混乱してしまいがちです。また、引数が省略された場合に混乱してしまいそうです。」 と言っていて、Hash化を進めている訳ですが、Hash化した場合の欠点について触れていません。

欠点は、Hash名を書き間違えた時に、引数の順番を間違えた時よりも気づきづらい、と言うことです。 特に、例示されていた関数のように、省略時のデフォルトが存在する場合はなおさらです。

プログラムをかなり書いて来た人でも、変数名や関数名を書き間違えて後で気づいたことが 一度もない、と言う人はいないと思います。 たとえば、上記のinputAのところでtabIndexと書くべきところがtabIndxeになってしまっていますが、 入力した直後に気づかないと、統合開発環境でもなかなかここは指摘してくれませんし、 実行時にもスクリプトエラーになるわけではないので、すぐに気づくとは限らないと思います。

で、チェック用の関数って書くの結構たるいんですよね。 今回のように任意のパラメーターのほかに必須のパラメーターが存在する場合もあるし、 じゃあパラメーターの型もチェックした方が良いんじゃないの、とか考えるときりがないし。 なので、私は殆どHashの引数って使ってませんでした。

けど、これを機会にちょっと作ってみました。 型はチェックしてませんが、必須パラメーターと任意パラメーターの両方を指定できて、 必須パラメーターが存在しない場合や、必須と任意のどちらにも存在しないパラメーターが 存在した場合に例外を出すことができます。

どんなパラメーターでも受け付ける場合もあるので、任意パラメーターを指定しなければ 後者のチェックはしません。 また、リリース時に関して、神経質な方は、function CheckArguments(){return true;} で置き換えれば 良いかと思います。

引数でスペルミスしたら検出されたり、たとえばtypeを必須属性と言うことにして、 createInputの中を CheckArguments(options, ['type'], ['defaultValue', 'tabIndex', 'readOnly']); に変えたりすると動作が確認できるかと思います。