JavaScriptのコードには、こんな書き方もある

この記事はコードの書き方について、書き方そのものを推奨するものではなく、このような書き方も出来るという紹介です。コメント欄まで一緒にみていただくと学びになります。 ※記事はいただいたコメントを反映しましたので、当時のコメントと記事の内容に差分があります 1.破壊的メソッドを避ける 破壊的メソッドとは、元の配列の要素を変えるメソッドです。以下の例ではconstで宣言した変数numbersが、pushメソッドにより更新されています。 対応前 const numbers = [1, 2, 3] numbers.push(4) console.log(numbers) // [1, 2, 3, 4] この場合、元の配列の要素を更新するのではなく、スプレッド構文を使って新しい変数に代入します。変数はなるべくイミュータブルにしておくと、意図しない不具合やプログラムの可読性や保守性が向上します。push

[otchy210]

コメントが優しい。自分が本文読んだ時はすでに大部分が修正済みで突っ込みどころは少なかった。著者が素直にアドバイスを受け取っているのも良い。美しいインターネットだ。

[north_korea]

3、6、7はよく使う。イキリとかではなくて読みやすいし間違いが起こらない。

[J138]

イキったコードが見当たらない。マサカリで伐採されたのか。

[ustam]

コメント欄も参考にしつつ、まあ話半分で。知っておいた方がよいのは確か。

[nananashi]

コメント欄筆頭のstandard-software氏はTypeScript不要論という極端な考えの方ですよ。 https://b.hatena.ne.jp/entry/s/qiita.com/standard-software/items/0b2617062b2e4c7f1abb

[lHMaUyzK]

これは言われてみればそうだけど意識してなかった　“万が一文字列のconstructorやtoStringが渡された時にfunction toString() { [native code] }が出力”

[fukken]

"配列ではなく文字列などが渡された場合で挙動が変わるため、厳密等価演算子(===)を常に使用すべきです" String.prototype.length もnumberを返すと思うのだが（常に厳密比較を使う方が望ましい、という話ではあるが）

[UDONCHAN]

1の標準の配列操作が破壊メソッドなのはJSの罠だよなあ。あと4は趣味の問題の領域では。

[hiromi_ayase]

技術ブログにあるマサカリの典型例を見た気がする

[tettekete37564]

ホント JS はすげーもやもやする。と思ったら初心者っぽい

[latena]

>==

[mas-higa]

1e8 って単なる浮動小数点表記やん (それ以外のとこは参考になった)

[smeg]

破壊的メソッドで書き換えるのと変数を増やすのではどちらが複雑性が増すの？100回pushするときに100個変数用意するの？

[sa-yama321]

不要論の俺がまともなこといってたら脳がバグるかい？JSを徹底的に使いこなせていたら、TSのコンパイルや型パズル解きは十分に面倒だ、ってなるのは別に普通だと思うけどね。ｗ> nananashi

[xlc]

配列にpushしたら元の配列が書き変わるのが予想される動作なのに、何を問題視してるんだ？厳密さより「びっくりさせないこと」を主眼においた方がよいと思うよ。

[fashi]

エレガントに書こうとすると可読性が悪くなるやつ

[ragari]

イキって、、うんこでもしてるん？

[hase0510]

ところで num = 10000000000000001; ってやると面白いことになるので、どうなるか知らない人はDevToolsを出してやってみてほしい。

[yuzuk45]

コメント欄が本文

[xzone]

こっち系の記事は必ずコメント欄で論争が起きるのがおもしろいｗ

[yurikago12]

コメント欄が参考になる。

[degucho]

柔軟すぎる言語は困るなと思わせる。自分は書かなくても読むとき必要になるんよねこういうの

[Kenju]

JavaScriptは進化が速すぎてな・・・。

[yarumato]

“破壊的メソッドを避ける：push()をスプレッド構文に。lengthは配列ではなく文字列が渡された場合で挙動が変わるため、厳密等価演算子(===)を常に使用すべき。分割代入。条件分岐をなるべく使わない”

[mayumayu_nimolove]

こう言うのって実例がないとなかなか覚えられないんだよな。