こんにちは、かつコーチです。
前回は<script>タグの書き方と、defer・asyncの違いを解説しました。
今回は、JavaScriptを書くうえで一生付き合っていくことになる「デバッグ」について、console.logを使った基本のやり方を紹介します。
初心者のうちは「エラーが出た=失敗」と感じがちですが、エラーは原因を教えてくれる大切な手がかりです。
うまく付き合う方法を早いうちに身につけておきましょう。
デバッグとは?
プログラムの不具合を見つけて直す作業
デバッグとは、プログラムの中にある不具合(バグ)を見つけて、原因を特定し、修正する作業のことです。
「バグ(bug)」は英語で「虫」を意味し、それを「取り除く(de-)」という語源から、デバッグと呼ばれています。
JavaScriptに限らず、プログラミングでは「一度書いたコードが最初から完璧に動く」ことのほうが珍しく、むしろデバッグの作業に多くの時間を使うのが普通です。
console.logがデバッグの基本ツールである理由
前回までの記事で紹介したconsole.log()は、「今、この変数の中に何が入っているのか」を確認するための、最もシンプルで手軽なデバッグ手段です。
高機能なデバッガーツールもありますが、初心者のうちはconsole.logをコードのあちこちに置いて、処理の流れを目で追う方法から始めるのがおすすめです。
console.logの基本的な使い方
変数の中身を確認する
まずは基本の形から見ていきましょう。
const userName = "かつコーチ";
const age = 35;
console.log(userName);
console.log(age);
コンソールには、それぞれかつコーチ、35という中身がそのまま表示されます。
「この変数、今どうなっているんだっけ?」と迷ったときは、まずconsole.logで中身を出してみる、というのが基本の動きです。
ラベルをつけて何の値かわかりやすくする
console.logに複数の値を渡すと、どの値が何を表しているのか見分けやすくなります。
const price = 1000;
const taxRate = 0.1;
const total = price * (1 + taxRate);
console.log("price:", price);
console.log("taxRate:", taxRate);
console.log("total:", total);
このようにラベルをつけておくと、コンソールにログがたくさん並んだときも「どれがどの値か」をひと目で判断できます。
複数の変数を扱うようになったら、必ずラベル付きで出力する癖をつけておくと、後で見返すときに困りません。
エラーメッセージの読み方
エラーの基本構造
JavaScriptでエラーが起きると、コンソールに赤字でエラーメッセージが表示されます。
構造はだいたい次のようになっています。
Uncaught TypeError: Cannot read properties of undefined (reading 'name')
at main.js:5:20
TypeError:エラーの種類Cannot read properties of undefined (reading 'name'):エラーの具体的な内容at main.js:5:20:どのファイルの何行目・何文字目で起きたか
まずはatの後ろに書かれているファイル名と行数を見れば、エラーが起きた場所がすぐにわかります。
よく出会うエラーの種類
初心者のうちに特によく出会うエラーを3つ紹介します。
| エラーの種類 | 主な原因 |
|---|---|
SyntaxError | 文法のミス(括弧の閉じ忘れなど) |
TypeError | 存在しないものに対して操作しようとした |
ReferenceError | 定義していない変数を使おうとした |
エラーメッセージの最初の単語(TypeErrorなど)を見るだけでも、原因の見当がつけやすくなります。
つまずきやすいポイント:undefinedとnullの違いによるエラー
かつコーチが実際にハマった原因
私が実際につまずいたのが、undefinedとnullの違いをよく理解しないまま、if文でチェックしていたときのバグです。
❌ Before:undefinedのチェック漏れでエラーになる
function getUserInfo(user) {
console.log("ユーザー名: " + user.name);
}
const guestUser = undefined;
getUserInfo(guestUser);
このコードを実行すると、次のエラーが表示されます。
Uncaught TypeError: Cannot read properties of undefined (reading 'name')
userにundefined(まだ値が代入されていない状態)が渡されているのに、user.nameのように中身を読み取ろうとしたことでエラーになっています。
このとき私は、console.log(user)を関数の一番上に置いていなかったせいで、「そもそもuserに何が渡っているのか」を確認できておらず、原因の特定にかなり時間がかかりました。
✅ After:関数の入口でconsole.logし、undefinedチェックを入れる
function getUserInfo(user) {
console.log("受け取ったuser:", user); // まず何が渡ってきているかを確認する
if (user === undefined) {
console.log("ユーザー情報がありません");
return;
}
console.log("ユーザー名: " + user.name);
}
const guestUser = undefined;
getUserInfo(guestUser);
関数の入口でconsole.logを置いて中身を確認する癖をつけたことで、userがundefinedのまま渡ってきていることがすぐにわかるようになりました。
さらにif文でundefinedかどうかをチェックすることで、エラーを未然に防ぎつつ、想定していないデータが渡ってきたことにもすぐ気づけます。
「エラーが出たら、まず疑わしい変数の直前にconsole.logを置いて中身を確認する」——これがデバッグの一番の基本です。
デバッグをスムーズに進めるコツ
処理の前後でログを挟んでみる
処理のどこで意図しない結果になっているかわからないときは、複数箇所にconsole.logを仕込んで、どこまで正しく動いているかを絞り込んでいきます。
function calculateTotal(price, quantity) {
console.log("① 受け取った値:", price, quantity);
const subtotal = price * quantity;
console.log("② 計算後のsubtotal:", subtotal);
const total = subtotal * 1.1;
console.log("③ 税込みのtotal:", total);
return total;
}
calculateTotal(1000, 3);
このように番号をつけてログを出すことで、コンソールに表示された結果を上から見比べながら、「②までは正しいのに③でおかしくなった」といった形で問題箇所を絞り込めます。
使い終わったログは消す・コメントアウトする
デバッグ用のconsole.logをコードに残したままにしておくと、後から見返したときにどれが本来必要な出力か分からなくなります。
原因が特定できて修正が終わったら、デバッグ用に置いたログはこまめに削除するかコメントアウトしておく習慣をつけましょう。
// console.log("① 受け取った値:", price, quantity); // 原因特定できたのでコメントアウト
まとめ
この記事のポイント
- デバッグとは、プログラムの不具合を見つけて修正する作業のこと
console.logは変数の中身を確認する、最も基本的なデバッグ手段- エラーメッセージは「エラーの種類」「内容」「発生場所」の3点をまず確認する
- 疑わしい変数の直前に
console.logを置いて、中身を確認してから対処する - 原因特定が終わったデバッグ用のログは、削除するかコメントアウトする習慣をつける
次に読むべき記事
デバッグの基本を押さえたところで、次は学習効率を大きく左右するエディタの環境設定について解説します。
VSCodeを使った便利な設定を知っておくと、この先のコーディングがぐっと快適になります。
→ 次の記事:JavaScript開発に便利なエディタ設定(VSCode)