LLM注意
Claude Opus 4.6のチャットさんとの勉強会まとめです。
HTMLに入れるとき
HTMLファイルのお作法に従って
<script>
// コードの中身
</script>と、囲う必要あり。
JavaScriptのお作法
超基本文法編
- 基本的に上から上から読み込まれて実行される
- コメントアウトは
//（ダブルスラッシュ） - インデントの有無ではエラーにならない
- 1文（1つの指示）の文末（行末）には
;（セミコロン） - まとめて何か書きたい時は
{}（波括弧）で囲う
インデントに意味を持たせないからこそ、セミコロンの意味が大きそう。
（実際は書き忘れてもブラウザが頑張って推測するらしいが、推測ミスが出るのでセミコロン大事らしい）
変数と定義方法
操作（計算や置換その他）の対象になる対象にラベル的な名前をつけて扱いやすくしたものが変数。
JavaScriptには変数を宣言する方法が2つ（＋古い方法が1つ）ある。
後から中身を定義し直せるlet、中身をいじろうとしたらエラーになるconst、とのことで、基本は「絶対に後から変わると分かっているもの」だけlet、迷うならconstで書いておいて、後から変更が必要だとなったらletに書き換えるのがお作法とのこと。
let（中身を後から変えられる変数）
let weather = "晴れ";
console.log(weather);
weather = "雨";
console.log(weather);これを（ブラウザの開発者ツールにある）コンソールから見ると、ユーザーメッセージとして1行目に晴れ、2行目に雨、と表示される。
ブラウザには何も表示されない。
というのも、console.log();は、コンソールに括弧の中身をログとして出力しますよという指示。
ブラウザには表示されないが、やっていることの中身の確認のために開発者が使うツールとのこと。
const（中身の固定された変数）
const birthday = "4月1日";
console.log(birthday);
birthday = "5月1日";これをコンソールから見ると、4月1日、そして次の行にエラー。
Uncaught TypeError: Assignment to constant variable.
とのことなので、文字通り、変化しないはずの値をさわろうとしたよ。のエラーである。
var
昔のJavaScriptで使われていた宣言方法、今は使われないことがほとんどとのこと。
型について
数値（計算させたいもの）はそのまま、文字列はクォート（ダブルでもシングルでも揃ってさえいれば大丈夫そう？）で囲う。
なお、数値と文字列を混在させてしまってもエラーにはならない。
（個人的には恐ろしいことに）足し算の時は数値を文字列に揃えて扱う。これを 暗黙の型変換 と呼ぶ。
let a = 10;
let b = 3;
console.log(a + b);
let c = "10";
let d = "3";
console.log(c + d);
let e = 10;
let f = "3";
console.log(e + f);これらは上から順に13,103,103となる。
+は、数値なら足し算、文字列なら後ろに連結していく。
そう、一番下が怖い。めっちゃ怖い。
ミスに気付くのが遅れそうで怖い。要注意。
エラーについて
大きく、SyntaxErrorとその他エラー（TypeErrorなど）に分けられる。
そもそも破綻しているのか、何かの定義をミスったのか。
SyntaxError
文法エラー。
そもそもJavaScriptとして破綻しているとき。
文法に沿っていない場合などに出る。
セミコロンの後に更に何かよく分からないものが続いているとか。
多分クォートや括弧を閉じ忘れても出そう。
構文を定義通りに書かなくても出た（当たり前、詳しくは後述）
SyntaxErrorを出した場合、JavaScriptとして成り立つ以前の問題と判断され、1行も実行されずに拒否される。
VSCodeにも突っ込まれるレベルのエラー。
TypeError
実行時エラー。
一見JavaScriptとしては成り立っていそうだけれど、定義が変とか、やってみたら矛盾したとか。
上から実行していくというプログラムの動きは前述の通りで、引っかかるまでの行は実行される。
VSCodeに出ないので、事前察知が大変そうだなぁの感想。
ReferenceError
定義されていない変数を呼び出そうとするなどすると出てくるエラー。
本日のわーさんの興味と好奇心の所為で何度も出会した。
覚えた。
これもVSCodeには出なかった。
やっぱりSyntaxErrorじゃないと出ないのかも。
条件分岐と繰り返しについて
条件分岐
const score = 75;
if (score >= 80) {
console.log("優");
} else if (score >= 60) {
console.log("良");
} else {
console.log("もう少し頑張ろう");
}これは上から「もしこの条件なら」「違った場合でなおかつこの条件なら」「違った場合なら」と順にふるいにかけている様子。
プログラムは上から順に実行される＝上から順にふるいにかけるので、より狭い条件を上に乗せる必要がある。
セル画を描く時に細かい線や陰影を先に乗せて、後から広範囲に塗り潰す様子と同じ……というのは、流石に喩えの方がニッチだな、今はデジタルイラストで下のレイヤーでクリッピングなんて登場したからお絵描き時の作業が大体の場合で逆だし。余計なこと言いました。
繰り返し、からの大暴走
本日最もわーさんの好奇心を刺激した項目。
for (let i = 1; i <= 3; i++) {
console.log(i + "回目");
}
console.log(i);これをコンソールから眺めると、1回目、2回目、3回目、そしてReferenceErrorとなる。
わざわざここでReferenceErrorまで話が出ているが、わーさんが丸括弧の中にセミコロンがいっぱいあることに混乱したり、今まで最初に定義されてたletが場所移動している！ とテンションをぶち上げてしまい、クロードさんが質問攻めにされた結果である。
わーさんが気になりまくったのは、以下が成り立つのかどうか。
let i = 1
for (i <= 3; i++) {
console.log(i + "回目");
}答えは、SyntaxError。
forという指示（構文）を書くときには、丸括弧の中に2つのセミコロンを置いて（初期の数値を定義し直し; 繰り返しを続ける条件; 繰り返すときに与える変化）と3つに区切る必要があるらしい。
そういう文法として定義されているとのこと。
つまり、上のコードでは、丸括弧の中にセミコロンが足りない。
文法エラー。
let i = 1;
for (; i <= 3; i++) {
console.log(i + "回目");
}
console.log(i);これならイける。1回目、2回目、3回目、4。
で、先ず自分の好奇心で突っ走ったことを書いたが、これらの背後には山のようなお作法が転がっている。
i++ は「i の中身に1を足す」の省略形、i--だと「iの中身から1を引く」らしい。
また、丸括弧と波括弧の話も改めて整理することになった。
丸括弧は「何を対象にするのか」、示したり条件で絞ったり。
丸括弧と対比した場合の波括弧は「何を実際に実行するのか」、今のところは全部console.log()でひたすらコンソールに出して眺めている。
また、超基本文法編にて、波括弧をまとめて何か書きたい時に使うと言われていたけれど、constやletを波括弧の中で定義すると、その外には出せない仕組みとなっている。
サンドボックスみたいな話だと思う。
繰り返しになるが、
for (let i = 1; i <= 3; i++) {
console.log(i + "回目");
}
console.log(i);これをコンソールから眺めると、1回目、2回目、3回目、そしてReferenceErrorとなる。
波括弧のために丸括弧で定義されているletなので、波括弧が終わったらもういないのである。
let i = 1;
for (; i <= 3; i++) {
console.log(i + "回目");
}
console.log(i);これであれば1回目、2回目、3回目、4と、波括弧の外のiは（波括弧の影響を受けつつも）元から「外」のものなので残っている。
動きとしては
「1の入っているiをもらった」
「3以下である」
「コンソールにi（1）回目と出す」
「iに1足して2にする」
「2の入っているiを（略」
「3の入っているiをもらった」
「3以下である」
「コンソールにi（3）回目と出す」
「iに1足して4にする」
「4の入っているiをもらった」
「3以下ではないのでforはもう用済み」
「forが終わったから次のconsole.log(i);を実行する」
「コンソールにi（4）と出す」
……ただし、このように外で変数を大量に生き残らせると、意図しないタイミングで混在からのエラーに繋がりやすいため、基本的にループ（や、似たようなコマンド）の中でしか使わないものは、潔くその中で定義してディスポに使い切るのが安全である。
まさにサンドボックス。
因みに、この「変数が生き残っている範囲」のことを スコープ と呼ぶらしい。