私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.128 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
もっと言うと大体の変数はconstで書ける
自分も人に見せるような気分でコードを書くときは最近は全部constで書く。
別にvarでもいいが、constで書けるとこなら、const使ったほうが情報量が増えて好き。
逆に嫌いな点は文字数が多いところ。
そして、for文などconstが使いようのない場所でletを使うという感覚だ。
一方適当にコードを試したりするときは基本的にletを使う。
ただしletを用いてコンソールで遊ぶと、再実行時に二重定義エラーとなるのが嫌い。
とは言え、レガシーなイメージのあるvarを使うのも楽しくない。
自分も人に見せるような気分でコードを書くときは最近は全部constで書く。
別にvarでもいいが、constで書けるとこなら、const使ったほうが情報量が増えて好き。
逆に嫌いな点は文字数が多いところ。
そして、for文などconstが使いようのない場所でletを使うという感覚だ。
一方適当にコードを試したりするときは基本的にletを使う。
ただしletを用いてコンソールで遊ぶと、再実行時に二重定義エラーとなるのが嫌い。
とは言え、レガシーなイメージのあるvarを使うのも楽しくない。
変数の数が減るかどうかは別としてもスコープを最小限に抑える事自体は正しい設計だよね
頭のメモリ領域も削減してストレスフリーなコーディングをしたい
頭のメモリ領域も削減してストレスフリーなコーディングをしたい
まあなんとも言えん。
全て関数スコープというのもある意味ではシンプルでスマートであり、
複雑なスコープを関数内で使う必要もないとも言えるのかもしれないと思わないこともなくない。
全て関数スコープというのもある意味ではシンプルでスマートであり、
複雑なスコープを関数内で使う必要もないとも言えるのかもしれないと思わないこともなくない。
>>100
var の初期化処理は巻き上げられて関数初頭で undefined で初期化される
let はブロックスコープだが、巻き上げられないという性質がある
だから、var を使う場合は undefined で巻き上げられても正常に動作するようにアルゴリズムを考慮する必要がある
http://bonsaiden.github.io/JavaScript-Garden/ja/#function.general
function hoge () {
console.log(a); // undefined
console.log(b); // ReferenceError: b is not defined
var a = 1;
let b = 2;
}
hoge();
巻き上げ(hoisting)を知っている人は関数初頭でvarで初期化するコードを書く人もいる(賛否両論はある)
function hoge () {
var a;
console.log(a); // undefined
a = 1;
}
一般には let の挙動の方が直感的でバグを発見しやすくて良いと評価される
var の初期化処理は巻き上げられて関数初頭で undefined で初期化される
let はブロックスコープだが、巻き上げられないという性質がある
だから、var を使う場合は undefined で巻き上げられても正常に動作するようにアルゴリズムを考慮する必要がある
http://bonsaiden.github.io/JavaScript-Garden/ja/#function.general
function hoge () {
console.log(a); // undefined
console.log(b); // ReferenceError: b is not defined
var a = 1;
let b = 2;
}
hoge();
巻き上げ(hoisting)を知っている人は関数初頭でvarで初期化するコードを書く人もいる(賛否両論はある)
function hoge () {
var a;
console.log(a); // undefined
a = 1;
}
一般には let の挙動の方が直感的でバグを発見しやすくて良いと評価される
>>102
スコープを最小限にする事は言語を問わず、プログラミング全般で大原則
ES5に浸りきったプログラマが今からブロックスコープを習得するのは敷居が高いと感じる向きもあって一部で反感を買っているようだが
http://www.google.co.jp/search?ie=UTF-8&q=%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%97%20%E6%9C%80%E5%B0%8F%E9%99%90
スコープを最小限にする事は言語を問わず、プログラミング全般で大原則
ES5に浸りきったプログラマが今からブロックスコープを習得するのは敷居が高いと感じる向きもあって一部で反感を買っているようだが
http://www.google.co.jp/search?ie=UTF-8&q=%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%97%20%E6%9C%80%E5%B0%8F%E9%99%90
ハードルが高い？
ただ単にvarをletに置き換えれば済むことが99％だろう。
だれもvarでしか出来ない挙動の活用に慣れ親しんでる人はいないと思う。
ただ単にvarをletに置き換えれば済むことが99％だろう。
だれもvarでしか出来ない挙動の活用に慣れ親しんでる人はいないと思う。
let使ってるからってあえて同じ変数名にするのはどうかと思うけどな
あえて衝突させる事で実体化する変数の数を減らすテクニックとか普通に使わん？
ブロックスコープどころか関数スコープでも変数名を衝突させる事は良くあるんだが
ブロックスコープどころか関数スコープでも変数名を衝突させる事は良くあるんだが
forループでね
インデントされてるからこそわかるけど
注意深くみないとどっちのiを参照してるのかわからないようなコードは好ましくないと個人的に思う
インデントされてるからこそわかるけど
注意深くみないとどっちのiを参照してるのかわからないようなコードは好ましくないと個人的に思う
なるほど、俺はもう慣れたし、必要ないのに上位スコープのループ変数iを参照可能なコードが美しくないと感じてしまうな
感覚の違いか…
感覚の違いか…
実際のところどちらでも良いケースが殆どなのだから
「必要ないのに～」という論はどちらに慣れてるのかということでしか無い
varに慣れていればletは特殊な場合でしか必要ないように見えるし、逆もまた然り
「必要ないのに～」という論はどちらに慣れてるのかということでしか無い
varに慣れていればletは特殊な場合でしか必要ないように見えるし、逆もまた然り
どちらでも良いならletを使わない理由が特にないな
hoistingしないし、スコープは最小限に抑えられるし、メリットしかない
hoistingしないし、スコープは最小限に抑えられるし、メリットしかない
letが使えるならいくらでも使うが、ブラウザの対応が揃ってないので使ったことないわ
>>113
巻き上げが必ずしも悪いというものでもないし、
スコープは最小限に抑えられるが有効なスコープの数は自体は増えるだろう。
実際各エンジンではまだ最適化しきれておらず、for-letのパフォーマンスが悪い。
だから自作のゲームAIエンジンでは泣く泣くvarを使ってる。
巻き上げが必ずしも悪いというものでもないし、
スコープは最小限に抑えられるが有効なスコープの数は自体は増えるだろう。
実際各エンジンではまだ最適化しきれておらず、for-letのパフォーマンスが悪い。
だから自作のゲームAIエンジンでは泣く泣くvarを使ってる。
まあ変数宣言以前がundefiendとTDZ、どちらが自然かというのを決めるのは難しいかもな
無名関数って複数の処理を行った結果が欲しいけど、
1度しか使わないのでわざわざ関数にする必要がないようなときに使うもんですよね？
1度しか使わないのでわざわざ関数にする必要がないようなときに使うもんですよね？
いや、巻き上げ処理が自然に感じるかという感覚の問題じゃなくてね
巻き上げが発生する事によるメリットが何もなくてデメリットしかないと自分は思うんだ
変数文より手前で変数をundefinedとして評価したいケースが全く思いつかない
それなら間違って評価しないように変数文より前で評価した時にReferenceErrorにした方が親切だと思う
巻き上げが発生する事によるメリットが何もなくてデメリットしかないと自分は思うんだ
変数文より手前で変数をundefinedとして評価したいケースが全く思いつかない
それなら間違って評価しないように変数文より前で評価した時にReferenceErrorにした方が親切だと思う
それは即時関数や狭義のクロージャで、無名関数の使われ方の一部。
もっと一般的に言うと、関数を数値や文字列等と同列に値として扱いたい時で、
名前は必要ないときに使う。
もっと一般的に言うと、関数を数値や文字列等と同列に値として扱いたい時で、
名前は必要ないときに使う。
>>120
その厳しさはブロックスコープだからこそ自然に映えるものだと思う
関数スコープしかない世界で考えると、例えばfor(var iと数カ所に書いても動いて欲しいし、
コードの順序を入れ替えたりしても気軽にエラーになってほしくも無いだろう
その厳しさはブロックスコープだからこそ自然に映えるものだと思う
関数スコープしかない世界で考えると、例えばfor(var iと数カ所に書いても動いて欲しいし、
コードの順序を入れ替えたりしても気軽にエラーになってほしくも無いだろう
>>123
ごめん、何を言いたいのかわからない
> for(var iと数カ所に書いても動いて欲しい
let にしても動くよね？
> コードの順序を入れ替えたりしても気軽にエラーになってほしくも無いだろう
具体的にコードで書くと？
ごめん、何を言いたいのかわからない
> for(var iと数カ所に書いても動いて欲しい
let にしても動くよね？
> コードの順序を入れ替えたりしても気軽にエラーになってほしくも無いだろう
具体的にコードで書くと？
ひょっとしてこういうこと？
悪いけど、エラーにならないのが気持ち悪いコードだ
'use strict';
for(var i = 0; i < 9; ++i);
for(i = 0; i < 9; ++i);
↓
'use strict';
for(i = 0; i < 9; ++i);
for(var i = 0; i < 9; ++i);
悪いけど、エラーにならないのが気持ち悪いコードだ
'use strict';
for(var i = 0; i < 9; ++i);
for(i = 0; i < 9; ++i);
↓
'use strict';
for(i = 0; i < 9; ++i);
for(var i = 0; i < 9; ++i);
>>126
for(i = 0; i < 9; ++i); だけ見たらグローバル変数を宣言しているように見えて
for(var i = 0; i < 9; ++i); を見て初めてhoistingしたローカル変数だと理解できる
そもそも、これは両方とも var i すればいいし、わざわざ var を省く理由もない
コードを入れ替えても何の問題もない
hoistingするメリットが全く無い
for(i = 0; i < 9; ++i); だけ見たらグローバル変数を宣言しているように見えて
for(var i = 0; i < 9; ++i); を見て初めてhoistingしたローカル変数だと理解できる
そもそも、これは両方とも var i すればいいし、わざわざ var を省く理由もない
コードを入れ替えても何の問題もない
hoistingするメリットが全く無い
メリットとかの話ではなく、重複宣言でエラーにならないというのと、
その重複宣言がより必要な関数スコープというのと、
巻き上げで最初からundefinedで宣言されるという性質はセット。
その重複宣言がより必要な関数スコープというのと、
巻き上げで最初からundefinedで宣言されるという性質はセット。
>>123は俺もよくわからん、解説してくれ
横からだけど、varを有用に使ってるコードを思い出した。
<script src="script.js"></script>
<script>
var foo = foo || {};
alert(a);
</script>
一つ目の<script>で読み込まれるscript.jsには、変数fooにオブジェクトを代入するコード（var foo = ...）が書いてある。
けど、script.jsが正しく読み込まれる保証はない。
二つ目の<script>は、
一つ目の<script>がちゃんと読み込まれていれば、その読み込んだfooを用いて、
一つ目の<script>が読み込まれていなければfooに初期値{}を代入する、
というコード。
<script src="script.js"></script>
<script>
var foo = foo || {};
alert(a);
</script>
一つ目の<script>で読み込まれるscript.jsには、変数fooにオブジェクトを代入するコード（var foo = ...）が書いてある。
けど、script.jsが正しく読み込まれる保証はない。
二つ目の<script>は、
一つ目の<script>がちゃんと読み込まれていれば、その読み込んだfooを用いて、
一つ目の<script>が読み込まれていなければfooに初期値{}を代入する、
というコード。
そりゃ無数の要素の組み合わせが考えられるが、
「エラーにならない」という許さのバランス上そういう組み合わせであるのが自然であるということ。
例えば、重複はOKだけどTDZがあるとか変だし、
TDZが無いということで、undefinedになるというのなら自然
「エラーにならない」という許さのバランス上そういう組み合わせであるのが自然であるということ。
例えば、重複はOKだけどTDZがあるとか変だし、
TDZが無いということで、undefinedになるというのなら自然
まあ、重複不許可ならこんなコードではまる事も無いよな
/* グローバルコード */
var name = ['Ken', 'Alice', 'Vega'];
console.log(name); // "Ken,Alice,Vega"
/* グローバルコード */
var name = ['Ken', 'Alice', 'Vega'];
console.log(name); // "Ken,Alice,Vega"
だがしかしそれだとvarを最初に纏めるスタイルに限定されてしまうということか
いや、彼の言葉を信じるなら重複不許可ならTDZが使えるからhoistingが発生しないんじゃないか？
JavaScriptはもっと厳しくしてもいい
JavaScriptはもっと厳しくしてもいい
varの挙動を変える必要はないと思う。
もしあるならstrict mode導入時に変わっているはず。
もしあるならstrict mode導入時に変わっているはず。
ぶっちゃけ、重複許可するメリットがわからなくなった
>>131はメリットといえなくもないけど、RererenceErrorになるならそっちの方が自然な気もする
>>131はメリットといえなくもないけど、RererenceErrorになるならそっちの方が自然な気もする
>>135は let にするとブロックスコープ化して期待通りに動作するな
let すげえいい
let すげえいい
そうか？
グローバルにやたらめったら定義したり、よほど関数内管理しきれない能力じゃなければ
変数名の衝突で困ることなんて非常に稀なケースだと思うけどな。
グローバルにやたらめったら定義したり、よほど関数内管理しきれない能力じゃなければ
変数名の衝突で困ることなんて非常に稀なケースだと思うけどな。
letが良いのは分かったけど、じゃあconstの方がもっと良いの？
>>143
衝突が滅多に起きないのは同意だけど、衝突が起きた時に気が付く方がデバッグしやすい
衝突が滅多に起きないのは同意だけど、衝突が起きた時に気が付く方がデバッグしやすい
入力した文字列から秒数を求める関数を作りたいのですが、正規表現の後方参照で出来ないでしょうか？
'3h50m32s' → 3 * 3600 + 50 * 60 + 32
'30m10s' → 30 * 60 + 10
'1時間3分' → 1 * 3600 + 3 * 60
自分でやろうとすると置換してevalとか、indexOfで指定位置検索して
手前の数字を抜き出したりとかになってしまいそうです＞＜
ちなみに↓みたいな感じで作ろうとしてるんですが、何か根本
的に間違っておりますでしょうか？
str.match((\d+)h(\d+)m(\d+)s);
'3h50m32s' → 3 * 3600 + 50 * 60 + 32
'30m10s' → 30 * 60 + 10
'1時間3分' → 1 * 3600 + 3 * 60
自分でやろうとすると置換してevalとか、indexOfで指定位置検索して
手前の数字を抜き出したりとかになってしまいそうです＞＜
ちなみに↓みたいな感じで作ろうとしてるんですが、何か根本
的に間違っておりますでしょうか？
str.match((\d+)h(\d+)m(\d+)s);
>>148
すいません、１番目の入力だとIndexの1に時間2に分3に秒が入って
上手く機能するんですが２番目だとnullになるので、hやm等特定の
ものが無くても上手く機能してすっきり書ける方法がないかなと
//1番目
var str1 = '1h30m10s'
str1 = str1.match(/(\d+)h(\d+)m(\d+)s/);
//2番目
var str2 = '30m10s'
str2 = str2.match(/(\d+)h(\d+)m(\d+)s/);
すいません、１番目の入力だとIndexの1に時間2に分3に秒が入って
上手く機能するんですが２番目だとnullになるので、hやm等特定の
ものが無くても上手く機能してすっきり書ける方法がないかなと
//1番目
var str1 = '1h30m10s'
str1 = str1.match(/(\d+)h(\d+)m(\d+)s/);
//2番目
var str2 = '30m10s'
str2 = str2.match(/(\d+)h(\d+)m(\d+)s/);
30m10sも1時間3分も許容する必要なんてあるの？
本当はもっと限定的でいいはず。
本当はもっと限定的でいいはず。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.125 + (1001) - [97%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.108 + (1001) - [97%] - 2013/9/21 15:16
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.129 + (981) - [97%] - 2016/5/5 8:16
- + JavaScript の質問用スレッド vol.129 + (926) - [97%] - 2017/7/27 13:45
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.126 + (952) - [97%] - 2015/11/18 13:15
- + JavaScript の質問用スレッド vol.126 + (348) - [97%] - 2023/1/12 17:00
トップメニューへ / →のくす牧場書庫について