const divMatchPattern = document.getElementById('matchPattern');
const txtMatchPattern = "/(\\/\\*[\\s\\S]*?\\*\\/|\\/{2,}・・・/g\n";
divMatchPattern.value = txtMatchPattern.toString();というコードがあって、
id=matchPatternなオブジェクトが無い場合があるので
const divMatchPattern = document.getElementById('matchPattern'); if(divMatchPattern){
const txtMatchPattern = "/(\\/\\*[\\s\\S]*?\\*\\/|\\/{2,}・・・/g\n";
divMatchPattern.value = txtMatchPattern.toString(); }とすると読みにくいから「保存（Ctrl+S）」すると
const divMatchPattern = document.getElementById('matchPattern');
if(divMatchPattern){
const txtMatchPattern = "/(\\/\\*[\\s\\S]*?\\*\\/|\\/{2,}・・・/g\n";
divMatchPattern.value = txtMatchPattern.toString();
}となって長くなるから１行でも短くしようと捻って
for (const divMatchPattern of document.querySelectorAll('#matchPattern')) {
const txtMatchPattern = "/(\\/\\*[\\s\\S]*?\\*\\/|\\/{2,}・・・/g\n";
divMatchPattern.value = txtMatchPattern.toString();
}とか
document.querySelectorAll('#matchPattern').forEach((divMatchPattern) => {
const txtMatchPattern = "/(\\/\\*[\\s\\S]*?\\*\\/|\\/{2,}・・・/g\n";
divMatchPattern.value = txtMatchPattern.toString();
});とか
try {
document.querySelector('#matchPattern').value = "/(\\/\\*[\\s\\S]*?\\*\\/|\\/{2,}・・・/g\n";
} catch() {}; ※とミスっても原因が～になるパターンとか最後には
document.querySelector('#matchPattern') {左辺がnullじゃなければ右辺も続けて評価する演算子} .value = "/(\\/\\*[\\s\\S]*?\\*\\/|\\/{2,}・・・/g\n";があったらいいなぁとか思う。
Null合体演算子（??)が近いけど、基本は || なので
const 結論＝(Aプラン) ?? (Bプラン) ?? （冗談ではない）；
的に
const ストーリィ展開＝(なんだかわかないけど) ?? (なんかわかった) ?? もうどうなってもいいや；
の様に使うものなので、
document.querySelector('#matchPattern') ?? .value = "/(\\/\\*[\\s\\S]*?\\*\\/|\\/{2,}・・・/g\n";は期待通りには動かない。
「.」を「.$.」にすると左辺がnullだったらもうどうなってもいいやドット演算子があったらいいな
document.querySelector('#matchPattern').$.value = "/(\\/\\*[\\s\\S]*?\\*\\/|\\/{2,}・・・/g\n";一応、try ・・・ catchで包まれていたらthrowするけど
try {
document.querySelector('#matchPattern').$.value = "/(\\/・・・"; ※中で throw(undefined)する
※Throw.resume()で、ここに戻る
} catch (ex, stack) {
if(ex) console.log(ex) ※ ex が undefinedなので
else stack.resume(); ※ throwした直後に戻る。
※ 状況は stack.stackを読む
※ 行番号とかカラムとかnullな処理箇所が判ると助かる
}だといいな。
あとドット演算子（.）とアロー演算子（->）の違いの記事を読んだ感想。
昔のC言語では、メモリがとっても少なかったので作りがとても簡素で
簡素な構文解析に落とし込まないとメモリに入らない
というゲーム制作みたいな理由。
変数は基本的にアドレス＋オフセット＋サイズとして考えるポインタ変数でプリミティブな型変数はオフセットが０でサイズがプリセットで決まっているポインタ変数。
このため、構造体のドット演算子もポインタ変数のアロー演算子も「この変数の構造（オフセット）を見てオフセットを計算してね」という意味では同じだから一緒で良かったハズ。
しかし、基本な皆中身がポインタ変数なので、内部構造であるハズのポインタ変数を明示的に使われるとコンパイラは
- 普通の変数は梱包済み
- ポインタ変数は開梱済み
を切り分けて処理するのも面倒なので
※２通りの変数の種別があると毎度毎度似た様な処理が４通り必要になるのでウザい
仕方なく演算子（という表現上で人が指示する様に）を分けた様に思える。
昔のソースって概ね一本の長さが８０列×２５行程度に収まってたのもあるけどね。