JavaScript』というセッションのフォローアップ第二回目です。前回より以下のアジェンダでセッションの内容を紹介しています。機能なお、当日使用したスライドは以下になります。プログラマーの間では知っていて当然、知らないとちょっと恥ずかしい、ほぼ常識と化した記述方法あります。ここではそれについてのおさらいをしていきます。変数/関数の命名規則コーディングルールとしてまず抑えておきたいのは、変数と関数の命名規則でしょう。コードの記述においては、以下のようなものがあります。キャメルケース変数名/関数名を小文字ではじめ、二番目の単語の最初のアルファベットを大文字で記述する方法です。名前中の大文字がラクダのコブのように膨らんでみえることからキャメルケースと呼ばれます。呼び出されてインスタンスを生成して使用するものなのか区別するために、コンストラクタ関数の名前の先頭は大文字とします。しておけば文句は言われないでしょう。標準には含まれていません。ブラウザーで動作するとは限りませんよ。変数名と関数名には、基本的にキャメルケースを使用しますが、そうすると関数と変数の見分けがつかなくなってしまう場合があります。(アンダースコア)にするのも悪くないアイディアです。マークそのものは上書きしないほうが良いでしょう。メソッドの短縮形として使用されることが多いようです。以下のような使われ方をしているソースをよく見かけます。サポートされており、そのため日本語の変数名、関数名も使用できるようになっています。ダメってはなしになりますが)、日本語を知らない国の開発者が読めないということもあるので使用しないほうが良いでしょう。した場合問題が発生する」くらいしか誰に聞いても出てこなかったというのがあります。逆に言うと、それらを気にしなければ使っても問題ないような気がしますが、日本語の関数名や変数名が使われているプログラムは個人的にはあまり格好良くない気がするので使わない方が良いような気がします。教材とか、ネタとしてはいいかもしれませんが。ローマ字表記の関数名と変数名なども、なかなかグっとくるものがあります。なんて名前のついたコードを見ると懐かしすぎて目頭が熱くなり、たぶんスーツ着た人がコード書いてんだろーなー、とか思います。避けるため、関数の先頭ですべての変数を宣言します。文のブロック単位ではありませんので、変数の宣言をそれらコードブロック内で行うことには意味はありません。変数スコープをきちんと理解していない第三者がそれを見た場合、コードをメンテナンスする際に誤解が生じ、バグの原因ともなりかねないのでコードブロック内で変数を宣言するのは避けたほうが良いでしょう。文で上書きされてしまうため正常に動作しません。よる変数の宣言は複数回行ってもエラーにはなりません。よる変数の宣言だけであれば、それ以前に設定された変数の内容は変わることはありませんが、変数宣言と同時に初期値が設定される場合には当然のことながら上書きされてしまいます。名前空間の変数として扱われます。定義されていない}}グローバルな名前空間で、同じ名前の変数が定義されていた場合は上書きされてしまいます。この意図しないグローバル空間の変数/関数の上書きを「名前空間の汚染」と呼びます。関数ともどもそれぞれの異なる値を返します。//”Hello”ただし、関数や変数の宣言を以下のように呼び出し後に記述すると、一見、関数ローカルでの定義が完了するまで、グローバルの関数として動作するように見えますが、実際はエラーが発生して動作しません。スコープ内にはあるものの、その内容が設定される前に使用されるためエラーが発生します。上記のような問題を避けるためにも、関数内で使用しているすべての変数の宣言は関数の先頭で行うことをお薦めします。思われる点と、前述のサンプルのような、値の設定タイミングによるエラーの危険性を理解する必要があります。区切ってまとめて定義することもできます。省略することでデータ量を減らせるので良い」という人もおりまちまちです。結論から言えば、きちんと関数の先頭で変数の宣言が行われてさえいればどちらの記述方法でも良いと思います。可読性を上げたいときは1、従量課金制の通信環境など、データ量がコストに直結する、あるいは、帯域の細いネットワーク回線を使用していて、データを少しでも削る必要がある場合などは2にするなど、使い分けるのが良いかもしれません。前述の「変数を宣言する場所」でも書いたとおり、関数内で宣言されていない変数は、その上位の名前空間に宣言を探しに行き、宣言がされていない場合はグローバルの変数として扱われます。した意図しない名前空間で変数/関数が有効になり、他の同名の変数や関数を書き換えてしまうことを「名前空間の汚染」といいます。正常に動作しなくなります。した名前空間の汚染を防止するためにはいくつかの方法があります。ディレクティブを使用することで変数の宣言を強制することができるようになりました。ディレクティブが使用されている関数内で、未定義の変数を使用するとエラーが発生し、変数が定義されていないことを教えてくれます。コードを即時実行関数で包んでしまいます。具体的には以下のような感じです。内で記述されたコードは、無名関数内に書かれているため他の名前空間に変数名も関数名も公開しません。よって、名前空間を汚染することはありません。そのため、外部の名前空間から即時実行関数内の関数にアクセスすることもできなくなっています。関数は、外部から使用することはできません。アトリビュートに関数名を指定するといった昔懐かしい方法でのイベントハンドラの設定も行えません。メソッドを使用して関数を登録します。メソッドを使用します。エレメントのイベントの登録は、即時実行関数の中から行えますが、他の名前空間の関数に、内部の関数を使用させることはできません。この方法では、ライブラリなどは作ることできません。名前空間を極力汚染せずに、外部に対して関数を公開するには、名前空間を定義します。名前空間を定義するための機能は用意されていませんが、オブジェクトを使用して同様のことが可能です。公開し、その下でいくつでも関数を公開できます。内部の関数の呼び出し方は以下のようにします。myUtil.methodB(“引数”);オブジェクトの定義は、以下のように記述することもできます。内部の関数の呼び出し方は同じです。宣言を以下のようにすると、さらに安全にオブジェクトを定義することができます。(中括弧、ブラケット)です。前で改行しない記述をお薦めします。影響を避けるためです。記述しなくても動作します。(※聞こえませんがたぶん言ってます。追加しているから動作しているのです。セミコロン自動挿入は、状況によってはエラーを引き起こします。後ろに改行が入る以外はまったく同じコードです。左側の関数は正しく動作するものの、右の関数はエラーが発生し正しく動作しません。文の後ろに暗黙的にセミコロンが挿入され、構文が途中で終了しているとみなされるためです。前で改行しない記述をお薦めします。以上の処理を追加した際にはいずれにせよ中括弧の記述が必要になるものの、詳しくない人間が中括弧を書かないまま処理を追加してしまう危険性あり、メンテナンス性も劣るため、必ず中括弧を記述するようにします。エレメントのインスタンスを取得する必要があります。ツリーを検索するので、非常にコストがかかります。以下のコードは最悪の部類に入るアンチパターンのサンプルコードです。プロパティを設定しています。ツリーを検索し、見つかったエレメントの子ノードの数にアクセスしています。セレクターを使うなどするとさらに状況は悪くなります。ツリーの検索を減らし、処理効率を上げることができます。以下は、前述のアンチパターンのコードを効率よく処理できるよう修正したものです。ツリーの検索は行われず効率よく動作します。回以上アクセスされる可能性のあるものについては、そのインスタンスを変数に格納しておくことを心がけてください。言語の仕様/機能とは直接関係ない慣例的なコードの記述方法があります。これら先人たちが培ってきたルールが生まれた背景、そしてそれに則ってコードを書く理由としては以下のものがあります。ウケるwww」などと心無い誹謗を受けないようにするためです。(そうだっけ?)これで完全とはいえないでしょうが、これらを意識してコードを書いていれば、それほどひどいことは言われないと思います。機能」について書きたいと思います。FeedbackTrademarks。