著者アーカイブ 杉浦

著者:杉浦

変数や関数の使用されている場所を探す

　変数や関数の使用されている場所を探すにはファイルを横断して検索を掛けるという方法が考えられます。正規表現を用いた正規表現によっていくらかは絞り込めますが、完璧に行うには正規表現のみでは力不足です。
　変数名や関数名といった識別子を検索すれば、ある程度、変数や関数の使用されている場所を探すことができます。

　このままではhogeやhogebも検索結果に含んでしまいます。識別子でない文字で括られていることを判断する正規表現で、余分な識別子を検索結果から弾きます。

　[^a-zA-Z\$_]の部分は言語によって異なります。上記の正規表現はJavaScriptの規則に従っています。

JavaScript の識別子は必ずアルファベットかアンダースコア (_) かドル記号 ($) から始まらなくてはなりません。続く文字は数字 (0-9) も使えます。JavaScript は大文字・小文字を区別するため、使えるアルファベットは “A” から “Z”（大文字）と “a” から “z”（小文字）です。
引用　変数 – JavaScript | MDN

　ざっくばらんに行うならこの方法で十分ですがこの方法には問題点があります。問題点はスコープを無視するという点と、変数と関数と文字列の区別をつけない、という点にあります。下の様なコードを検索した場合、一つ目の変数hogeの呼び出しカ所を知りたいのに、関数名hogeや文字列hoge、即時関数内のhogeを検索結果に含んでしまいます。

var hoge = 0;
console.log(hoge);
(function hoge(){
	var hoge = 1;
  console.log(hoge);
})();
console.log(' hoge ');

　スコープを無視する、変数、関数の区別がつかない、という問題の単純な解決法は同名の識別子で宣言を行わないことです。固有な識別子をそれぞれが持つならば、このような問題は起こりません。

著者:杉浦

早めに処理を抜けるソースコード

　条件文を重ねてネストが深くなったソードコードは往々にして読みにくいものです。何々なら処理を行うという意味で作られた条件文を何々なら処理を行わないという条件文に書き換えることでソースコードを読みやすくできることがあります。
　次のコードは、もしデータが未定義でなく、データのidが数字ならば、処理を行う、という動作をそのまま書き下したソースコードです。

function (data){
	if(data !== undefined){
		if(typeof data.id === 'number'){
			//処理
		}else{
			return;
		}
	}else{
		return;
	}
}

　実際のコードでは”//処理”の部分が大きくなり、else以下を読もうとした時このelseの元のifはなんだったか、となることがあります。ならなくともifの中を覚えておくことに記憶領域を一部占有されます。
　このコードの条件文による分岐で行いたいことは”条件に合えば処理を行う”ということであり、これは”条件に合わなければ処理を行わない”と言い換えられます。この言い換えの通りに先のコードを書き換えると次の様になります。

function (data){
	if(data === undefined){
		return;
	}
	if(typeof data.id !== 'number'){
		return;
	}
	//処理
}

　元のコードではelse以下の文を読む時ifの中を記憶したまま”//処理”の部分を通る必要がありましたが、書き換えたコードならば処理を行わない条件に当てはまった場合、処理を行わずに抜けるということがすぐにわかります。これにより条件文の中身を覚えておく必要がなくなりました。またこの例の場合、単純で短い条件文二つ程度なのでさらにまとめて下の様にするのもよいです。

function (data){
	if((data === undefined) || (typeof data.id !== 'number')){
		return;
	}
	//処理
}

　一見、data===undefinedの時にdata.idを参照することによってnull参照でエラーが起きる、と思えますがそうはならない言語が多数です。大体の言語には評価が決まった時点で評価を返す機能である短絡評価機能が備わっています。そのためdata===undefinedの時にはdata===undefinedを読んだ時点で条件はtrueと評価されif節の中に入ります。結果data.idは参照されずエラーは起きません。

著者:杉浦

ソースコード中のコメントした方がいいこと、悪いこと

　ソースコード中には自由にコメントを書くことができます。コメントの良い点はプログラミング言語の記法に縛られることなく自然言語で書き手の意図を読み手に知らせることが出来る点です。コメントの悪い点はソースコード中の文字数が増えるところです。
　良い点が悪い点を超える際にのみコメントを記述することが理想になります。しかしながら困ったことに読み手がどのような人かによって良い点が悪い点を超える瞬間は大きく左右されます。例えば、次のようなコードがあります。

array_object = Array.prototype.slice.call(array_like_object)//array_like_objectを配列に変換する

Array.prototype.slice.callはjavascriptで配列っぽいオブジェクトを配列として変換したい時によく使われる慣用句みたいなものです。”Array.prototype.slice.call”（完全一致）でググると約171,100件もヒットします。散々使われ倒しているため、javascriptをやり込んでいる少なくない人にとって、このコメントは余分な情報で邪魔者です。一方で、Array.prototype.slice.call(引数)という文面には引数を配列に変換するという意味の単語はまるで使われていません。これがarray_like_objectを配列に変換するコードだと連想することは難しいでしょう。初めて読んだ時は自分も何だこれとなりました。javascriptを学んでいる途中の人にはこのコメントは必要でありがたいものです。慣れという部分でコメントをするべきしないべきかが変わり境界は曖昧です。
　明確にコメントを行うべきでないという場合はソースコード中の記述がそのままコメントの内容と同じになるときです。javascriptのES6記法では配列っぽいオブジェクトを配列として変換したい時に次の様な記述ができます。

array_object = Array.from(array_like_object)//array_like_objectを配列に変換する

　コメントはいらないのではないかというくらい動作を連想しやすい記述です。そのまま英語として読めるくらいです。このような際にコメントは多くの人にとって邪魔なものになるでしょう。
　おまけに極端な場合を紹介します。
　情報を伝えないコメントは単に無駄なだけでするべきでないコメントです。コメントアウトされている過去のコードは特にこの手のコメントになりやすいです。
　コメント行がより多くのコード行を説明できる場合、コメントは有用になりやすいです。プログラム、ファイル、関数のようなまとまり全体を説明する場合、大体これにあてはまります。コメント十行でコード数百行を説明するような感じです。