元スレ+ JavaScript の質問用スレッド vol.142 +

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

401 = :

>>443
すみません。追記です。
forEach内での関数のvar宣言をした場合配列の数だけ繰り返し宣言されてしまうが
呼び出しであれば、宣言は1回と考えていいのでしょうか？

また、変数や配列の場合forEach内で宣言させないことで、多少なりとも速度に影響はでるのでしょうか？

402 = :

>>443-444
1. と書いても、コンパイラの最適化で、2. ように展開してくれないのか？

さすがに何回も、関数宣言が実行されたりしないだろ。
無駄だから、最適化するだろ

403 = :

>>442
Windows10 で、Edge, Chrome で実行したが、正常に、1回ずつ表示される！

404 = :

>>444
何度も宣言しない代わりに参照時に何度も外のスコープを見に行く手間が発生するでしょ
だから無闇にそういうことを考えることが無駄
ESの仕様書をスラスラ読めるようになってから考えたら良い

405 = :

>>445
コンパイラなるものがあって最適化されるんですね！！
ググったのですが、難しくて理解できなそうでした

>>447
外のスコープを見に行く方が、何度も宣言するよりも処理に時間が掛かるのでしょうか？
であれば、内々で処理を行うのがベターなんですね。

406 = :

大差ないから自分が読み易いと思う書き方をしなさい

407 = :

>>449
なんと。。。
構成が結構変わってくるので、職場ではこっちが多数みたいのがあれば
ぜひ教えてくださいませ。

408 = :

>>450
ここで誰かがこっちの方が良いと言えば一生それに従うのか？
そういう言語もあるがJSでは言語としてこっちのスタイルが標準的という決めごとはない
JSは壮年期に差し掛かっているかもしれないがまだまだいくらでも成長する言語だ
流行は勿論気にし続けないといけないが、それと同時に自由に常に自分で模索し続けて
自分なりの様々な感覚を養っていくことがWebやJSにおいては重要
それにどっちが自然かなんて全体的な様子で変わる

409 = :

>>445
どちらかというと逆でしょ
普通はインライン化されて、関数の中身がforEach内に展開されて
さらにforEach内全体で最適化がかかる
でもそこまで最適化されることは実際には少ない

最近のエンジンはインタプリタ強化に回帰していて
省メモリとかオーバーヘッド削減に力を入れている

410 = :

>>451
自分とこの会社では、自分の周りは冗長な記述が多く参考にはならず、
違う部署の人はレベル違いで読み解けずといった感じでして。

今の主流を知りたいと思っています。

411 = :

昔は推奨された書き方が今では遅いなんてのが結構あるからね
ブラウザによっても逆転するから一概に言えない

412 = :

ESのバージョンも無しに今の書き方って言われても分かんない

413 = :

>>453
主流なんて無い
極論を考えれば全部グローバルに宣言を出すのも馬鹿らしいし、
最小限になるようできるだけ細かく多くのスコープを区切るのも馬鹿らしい
どちらにすべきかではなくて、バランスを取ってその時その時で全体的に自然に書けとしか言えん

比較演算子で定数をどちらに置くべきかとか、拘るのが馬鹿らしい問題というのは数多くある
そんなことにいちいち惑わされる暇があったら別のところに時間を使え

414 = :

>>456
極論についてはおっしゃる通りですね。
ESの仕様を理解はできていませんがバランスを見つつ改善を続けていきます。

関数やら変数の宣言って、最初の読み込み時にエンジンが把握するためのもので、
呼び出し時に宣言されるってことではないですよね？
それだとスクロールイベントで宣言した場合、毎回宣言されて大変ですよね？

415 = :

大変かどうかは計測して判断しましょう

416 = :

結局うやむやにしてるだけじゃん
不親切だな

417 = :

最適化は仕様にない。各社、自由だろ。
無数にある環境・ブラウザの組み合わせを、考えても無駄！

例えば「Effective Ruby、2015」の項目47 では、

ループ内で、文字列リテラルを使うと、
文字列が生成して、すぐに破棄されるから無駄なので、ループ外に出す

次に、Ruby 2.1 では、文字列リテラル.freeze で、
文字列は、1回しか作られないから、ループ内でも大丈夫

次に、Ruby 2.3 では、スクリプトファイルの1行目に、
# frozen_string_literal: true
と書くと、すべての文字列リテラルは、immutable になる

このように最適化は、ドンドン変わっていく！

418 = :

お前は相変わらずrubyｷﾁｶﾞｲだけどな。

419 = :

>>457
宣言文というのは、関数コンテキスト生成時と、コンテキスト実行開始（スコープ到達）時、宣言文到達時にそれぞれ働きがある

420 = :

>>462
そういうのどうやって勉強すりゃいいの？
es仕様直接読む頭ないから噛み砕いて説明してくれる本がほしい

421 = :

仕様書なんて英語の文章としては超絶簡単な部類
その大部分がa is b , b is cで積み重ねだから
読むために必要な能力って言ったら追っかけ力だけで
それは読んでれば勝手に身につく

422 = :

>>458
計ってみても誤差で判別がつきませんでした

>>462
難しそうですね
読み込んだ後は宣言なしと一緒とかだと理解できたのですがｗ

ちょろっと計測しても誤差にしかならないのなら、いっそスコープ狭めた方が
読み手には優しいですよね。
無理してネストを浅くして、気にしないといけない変数が大量にあるよりも。
馬鹿な自分でもわかる方がいいですし。

423 = :

その考え方でよい
実行速度にシビアな場面で初めて優先順位が変わる

424 = :

あと念の為補足すると
varはブロックに入れてもスコープは狭くならない

425 = :

letで宣言してスコープを関数内
に留めるのがいいかも

426 = :

>>465
宣言文というものはスコープに変数を作らないといけない
スコープが作られるのは宣言文より前のステップだ
だから実際宣言文に達する前にスコープを作る段階で働く
ステップが宣言文に達したらまた別の働きをする
他の多くの構文にもこのようにRuntimeな働きとStaticな働きと言うものがある

427 :

今のJS初心者なんで
とりあえずletにしとこ、程度なんだけど
constにすると大きく違うシーンってどんなのがありますん？

自分じゃない人がメンテするときに
不用意に上書きされないってのはいいとは思うんですが

428 = :

>>470
基本は、とりあえずletにしとこうではなく、とりあえずconstにしとこうだよ
letにしないとエラーが出るとこ以外はすべてconstにするんだよ

430 = :

>>472
これ見るとJSはアホすぎて滅ぼしたほうがいいレベルだな
現実には生き残り続けとるが

431 = :

問題に神経質に対処しようとするのではなく
おおらかに問題を飲み込むコーディングができない人にはJSは難しい

432 = :

>>443
forEachの第三引数で渡せば良い
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach

433 = :

>>467
知りませんでした。
ありがどうございます。

434 = :

>>468
この文なんかおかしい。
いやletはブロックスコープで、関数直下に書くと関数スコープと一致するからそれはいいんだけどvarは関数スコープだから「letで宣言してスコープを関数内に留めるのがいいかも」って言及はなんか違う。
だってvarで書いても関数スコープなんだもん。
letの使用を推奨するのはいいんだけどその理由の説明が間違ってる。

435 = :

>>477
あ～確かに
関数内でvarで宣言してもスコープは関数内に留まるね
勘違いしてたっぽい

437 = :

>>475
forEachの第一引数がcallbackで第二引数がthisArgとあるが第三引数なんて出てないが。

439 = :

>>479
Uncaught SyntaxError: Unexpected identifier

440 = :

>>481
babel先生のお世話になってみるのはいかが？

441 = :

letやらconstやらclass構文使えない環境で頑張ってきていたら
むしろスコープや定数やクラスシステムを振る舞いから表現まで気にして
JSのバックグラウンドにも詳しくなってるはずだから
それらの構文を扱うのに経験なんて必要なく知って数日で馴染めるでしょ

442 = :

>>480
×　第三引数
○　第二引数

443 = :

それだとコールバックにアロー関数使えないな。

444 = :

アロー関数に拘る必要はないかと

445 = :

chromeで動いていた重いJavaScriptが
vivaldiだと落ちます
おそらく処理時間が長すぎるとタイムアウトを起こすようになってるんじゃないかと思いますが
ブラウザによってタイムアウトのメカニズムがあったりなかったりすると困りますよね？
処理時間が長くなる場合はsetTimeoutなどを使ってはじめから処理を細切れにしておくべきなのでしょうか？

446 = :

確保したメモリ使い果たしたとか
そういう話じゃないんだろか

447 = :

>>489
ありがとうございます
確かにメモリの問題だったようです
巨大な文字列を生成するのをやめたら動くようになりました

449 = :

jQueryは使ってるけど、jQueryプラグインは使ってないなぁ
jQueryは自分で実装するのが手間だから使うものだよ。
プラグインのためじゃない。普段コードを書かない人なのかな？

450 = :

クリックイベントとかの元々の処理を無効にする記述って
どのタイミングで書くかで変わったりする？
重たいしょりが思いつかなくて計測しても違いがわかりません
下の奴です
e.preventDefault();
jQueryと違ってイベント発火直後がいいのかな？