私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.108 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
http://javascript.crockford.com/code.html
The var statements should be the first statements in the function body.
The var statements should be the first statements in the function body.
>>449
スコープ内のどこで変数宣言しても全部最初に定義される。例えば
var a = 'hoge';
(function(){
console.log(a); // 2. undefinedになり
var a = 'fuga'; // 1. 最初にこの宣言だけ行われ(3. 代入はこの行で実行)
})();
こんな感じで
なので、そのスコープ内で宣言される全ての変数を把握していないと、おや?ということになる
ひとりで書いてれば気にならんけど、他人のコードをメンテする場合とか、結構イラッとする
スコープの最初に書き直されるのはどうかと思うけど
今いじってるスコープで宣言される変数の一覧を出すとか、色つけてくれたりしたら便利だと思う
スコープ内のどこで変数宣言しても全部最初に定義される。例えば
var a = 'hoge';
(function(){
console.log(a); // 2. undefinedになり
var a = 'fuga'; // 1. 最初にこの宣言だけ行われ(3. 代入はこの行で実行)
})();
こんな感じで
なので、そのスコープ内で宣言される全ての変数を把握していないと、おや?ということになる
ひとりで書いてれば気にならんけど、他人のコードをメンテする場合とか、結構イラッとする
スコープの最初に書き直されるのはどうかと思うけど
今いじってるスコープで宣言される変数の一覧を出すとか、色つけてくれたりしたら便利だと思う
警告を出すだけならJSLintとかの仕事だ
それを機械的に直したいっていうのはちょっとニッチすぎるな
それを機械的に直したいっていうのはちょっとニッチすぎるな
「var 」を全部「let 」に置換すればいいよ
letなら(まともに実装してれば)巻き上げないから動けば気にしなくていいし、
動かなければあんまりいい設計じゃないってことで動くよう最小限書き直せばいい
それで妥協するのでもいいと思うよ
letなら(まともに実装してれば)巻き上げないから動けば気にしなくていいし、
動かなければあんまりいい設計じゃないってことで動くよう最小限書き直せばいい
それで妥協するのでもいいと思うよ
ダメな先輩きたー
>>349が責任とってお相手して差し上げろよww
>>349が責任とってお相手して差し上げろよww
varを関数の上の方に持ってくるべきという主張にはあまり賛同できないな。
varを関数の途中に持ってくるのは、この変数はここから使います。
という意思表示に現れ。
それを上に持ってくるのは、自分の考えをJavaScriptという
言語仕様だけのためにねじ曲げられているということ。
varを関数に途中に持ってくるのは理由があってやっているが
頭に持ってくるのは理由がない。
こういうのは、関数内でvarで宣言するよりも前に
変数が使用されていたらjshintなどで警告出させるべきだが
さてそんなオプションあったっけ?
もう一つ、変数の再定義をした時にも警告を出す必要があるが
jshintであればデフォルトでONだったはず。
varを関数の途中に持ってくるのは、この変数はここから使います。
という意思表示に現れ。
それを上に持ってくるのは、自分の考えをJavaScriptという
言語仕様だけのためにねじ曲げられているということ。
varを関数に途中に持ってくるのは理由があってやっているが
頭に持ってくるのは理由がない。
こういうのは、関数内でvarで宣言するよりも前に
変数が使用されていたらjshintなどで警告出させるべきだが
さてそんなオプションあったっけ?
もう一つ、変数の再定義をした時にも警告を出す必要があるが
jshintであればデフォルトでONだったはず。
> こういうのは、関数内でvarで宣言するよりも前に
> 変数が使用されていたらjshintなどで警告出させるべきだが
> さてそんなオプションあったっけ?
latedefでいけるかな?
ちょっと手元に環境がないので試せない。
> 変数が使用されていたらjshintなどで警告出させるべきだが
> さてそんなオプションあったっけ?
latedefでいけるかな?
ちょっと手元に環境がないので試せない。
>>458
そりゃそうだ
自分もどこでもいいと思うよ
他の言語から入ってきた人やJS初心者とか
色んな人が触るコードでいろいろコーディングスタイル厳しく統一していったら
最初にまとめて書いておこうねってなるとは思うけど
その程度のことだと思う
そりゃそうだ
自分もどこでもいいと思うよ
他の言語から入ってきた人やJS初心者とか
色んな人が触るコードでいろいろコーディングスタイル厳しく統一していったら
最初にまとめて書いておこうねってなるとは思うけど
その程度のことだと思う
宣言より上の操作でエラーが欲しければlet使えばいい。
宣言前の使用は実行時エラーになるが、
二重宣言とかはコンパイル時エラーで出してくれる。
宣言前の使用は実行時エラーになるが、
二重宣言とかはコンパイル時エラーで出してくれる。
俺俺コーディング??
タブ流とスペース流みたいなものでどっちが正しいとかないと思うが
何言ってんだか……
タブ流とスペース流みたいなものでどっちが正しいとかないと思うが
何言ってんだか……
varとか宣言がブロックスコープになる言語使ってきた人じゃないのなら混乱もないだろうし、
>>458のメリットも捨てがたい
そもそも元々柔軟さをとってそういう仕様になったんだから
よっぽどの場合を除き、仕様に則ってコーディングするのが普通じゃない?
あえてJSのスタイルに逆らうほうがオレオレだと思うけど
>>458のメリットも捨てがたい
そもそも元々柔軟さをとってそういう仕様になったんだから
よっぽどの場合を除き、仕様に則ってコーディングするのが普通じゃない?
あえてJSのスタイルに逆らうほうがオレオレだと思うけど
>>463
え、JavaScript に関して言えば別だろ
え、JavaScript に関して言えば別だろ
JSは裾野が広すぎてスタンダードが決めづらいだろう
JsDocみたいな提唱はあるけど
JsDocみたいな提唱はあるけど
自分が作ったコードをあとで馬鹿たれが編集するかもしれないって考えてコーディングするのがプロとしての勤めじゃないの?
なんでトラブルの原因になるかもしれないものをわざわざ残すような書き方をするのか
なんでトラブルの原因になるかもしれないものをわざわざ残すような書き方をするのか
>>460
> 色んな人が触るコードでいろいろコーディングスタイル厳しく統一していったら
> 最初にまとめて書いておこうねってなるとは思うけど
いやしないほうがいいと言ってるんだよ。
コーディングスタイルに関してはjshint等で設定をつめて
それに従わせるだけだからあえて説明する必要もない。
(エラーの意味ぐらい自分で調べろというだけ)
変数の巻き上げが起きない別の言語の話だが、中途で入ってきた人が
前の会社の癖(COBOLらしいが)で変数を関数の上で全部宣言していたのよ。
その時は、まあそんなスタイルもありかと思ったが、まあこれがうちの(俺の)
やり方だからってことで変数を使用する所で宣言するように直していったら
コードがかなり見やすくなった。
理由としてはこんな所。
・変数を利用する範囲が小さいから変数名は短くても十分
変数を冒頭に置くと関数内で被らないようにしないといけないから
分かりやすくということで、長い名前になりがち。
変数を利用する範囲が小さいならば、コード見れば何の値なのかすぐに分かる。
・変数の宣言と初期化処理を二重に書かなくて済む。
コントロールブレイクっていうCOBOLでのコードパターンがあるんだが
ループ中にブレイクしたら変数初期化をするなんてコードがあるんだよね。
ループの中だけでしか使わない変数なら、その場で宣言して代入すれば良いのにって思う。
・変数に代入した後、その値を変える必要が少なくなった。
宣言と使用箇所が分かれてると必然的に変数の再代入が必要になる。
再代入はするべきではないって話は、関数型言語を知らばわかる。
ここもテストに出るので勉強しておくようにw
> 色んな人が触るコードでいろいろコーディングスタイル厳しく統一していったら
> 最初にまとめて書いておこうねってなるとは思うけど
いやしないほうがいいと言ってるんだよ。
コーディングスタイルに関してはjshint等で設定をつめて
それに従わせるだけだからあえて説明する必要もない。
(エラーの意味ぐらい自分で調べろというだけ)
変数の巻き上げが起きない別の言語の話だが、中途で入ってきた人が
前の会社の癖(COBOLらしいが)で変数を関数の上で全部宣言していたのよ。
その時は、まあそんなスタイルもありかと思ったが、まあこれがうちの(俺の)
やり方だからってことで変数を使用する所で宣言するように直していったら
コードがかなり見やすくなった。
理由としてはこんな所。
・変数を利用する範囲が小さいから変数名は短くても十分
変数を冒頭に置くと関数内で被らないようにしないといけないから
分かりやすくということで、長い名前になりがち。
変数を利用する範囲が小さいならば、コード見れば何の値なのかすぐに分かる。
・変数の宣言と初期化処理を二重に書かなくて済む。
コントロールブレイクっていうCOBOLでのコードパターンがあるんだが
ループ中にブレイクしたら変数初期化をするなんてコードがあるんだよね。
ループの中だけでしか使わない変数なら、その場で宣言して代入すれば良いのにって思う。
・変数に代入した後、その値を変える必要が少なくなった。
宣言と使用箇所が分かれてると必然的に変数の再代入が必要になる。
再代入はするべきではないって話は、関数型言語を知らばわかる。
ここもテストに出るので勉強しておくようにw
宣言を頭に持ってくるのは気持ちの問題でしかない
だってどこに書いても頭に持ってきたかのように振る舞うのだからね
あえて頭に書いてもロジック的なメリットはないし、同じことだ
それならどこにでも書けるというのを活かした方が正しい
少なくとも頭にまとめるべきというのは正しくない
現にそういうチェックはJSLintでもされてない
だってどこに書いても頭に持ってきたかのように振る舞うのだからね
あえて頭に書いてもロジック的なメリットはないし、同じことだ
それならどこにでも書けるというのを活かした方が正しい
少なくとも頭にまとめるべきというのは正しくない
現にそういうチェックはJSLintでもされてない
>だってどこに書いても頭に持ってきたかのように振る舞うのだからね
>あえて頭に書いてもロジック的なメリットはないし、同じことだ
え、JS素人ですか
>あえて頭に書いてもロジック的なメリットはないし、同じことだ
え、JS素人ですか
>>461
> 宣言より上の操作でエラーが欲しければlet使えばいい。
そのとおりだが、letはIE10以上でないと対応していないという
現実的な問題がある。
http://msdn.microsoft.com/en-us/library/ie/s4esdbwz(v=vs.94).aspx
> 宣言より上の操作でエラーが欲しければlet使えばいい。
そのとおりだが、letはIE10以上でないと対応していないという
現実的な問題がある。
http://msdn.microsoft.com/en-us/library/ie/s4esdbwz(v=vs.94).aspx
>>470
> 静的方面から入った人は頭を見れば全部わかるみたいに考える人が多いから
その言い方じゃ、静的言語を知らないとしか思えないぞ。
なぜなら静的言語で関数の頭でしか宣言できない言語は
ごくわずかだからだ。
ちゃんとどっちも勉強しておけよ。
全くどいつもこいつも(このスレだけの話じゃない)
> 静的方面から入った人は頭を見れば全部わかるみたいに考える人が多いから
その言い方じゃ、静的言語を知らないとしか思えないぞ。
なぜなら静的言語で関数の頭でしか宣言できない言語は
ごくわずかだからだ。
ちゃんとどっちも勉強しておけよ。
全くどいつもこいつも(このスレだけの話じゃない)
ここ1年IEを考えたことなんて数回しか無い。
できるだけ意図的に無視してるな。
できるだけ意図的に無視してるな。
>>475
バグの原因の一つは「そんなこと考えていなかった」だからね。
この機会に考えるようにしよう。
これが現在のブラウザの使用率だ。
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=3&qpcustomb=0
IE8 ・・・ 21.65%
IE10 ・・・ 18.65%
IE9 ・・・ 9.02%
それにしてもこれだけ使用している人が多いブラウザを
考えないでいい人って楽だね。
なんの目的にJavaScriptを使ってるの?
仕事じゃなさそう。
自分で動けば十分な使い方かな?
バグの原因の一つは「そんなこと考えていなかった」だからね。
この機会に考えるようにしよう。
これが現在のブラウザの使用率だ。
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=3&qpcustomb=0
IE8 ・・・ 21.65%
IE10 ・・・ 18.65%
IE9 ・・・ 9.02%
それにしてもこれだけ使用している人が多いブラウザを
考えないでいい人って楽だね。
なんの目的にJavaScriptを使ってるの?
仕事じゃなさそう。
自分で動けば十分な使い方かな?
>>476
0だよ
function f(){
var x
...
x = hoge
と
function f(){
...
var x = hoge
はロジック的に全くの等価
反例があるのならよろしくw
0だよ
function f(){
var x
...
x = hoge
と
function f(){
...
var x = hoge
はロジック的に全くの等価
反例があるのならよろしくw
なつかしー展開。
一昔前は、何人ROMってたんだよってくらい
突然勢い伸びてた時期もあったなー。
一昔前は、何人ROMってたんだよってくらい
突然勢い伸びてた時期もあったなー。
>>477
> そういう文化があるし、そういうコードがJavaでもC++でも大多数
大多数であるというデータがあるなら教えてよ。
少なくともJavaやC++で変数の宣言場所は自由だし、
俺の知る限りそれを守ってるプロジェクトなんか知らない。
上の方で宣言するしかない言語は知っているが、
どこでも宣言できるのに、上の方で宣言しろなんて文化は聞いたことがない。
> そういう文化があるし、そういうコードがJavaでもC++でも大多数
大多数であるというデータがあるなら教えてよ。
少なくともJavaやC++で変数の宣言場所は自由だし、
俺の知る限りそれを守ってるプロジェクトなんか知らない。
上の方で宣言するしかない言語は知っているが、
どこでも宣言できるのに、上の方で宣言しろなんて文化は聞いたことがない。
>>486
var a = 'hoge';
(function(){
console.log(a); // 2. undefinedになり
var a = 'fuga'; // 1. 最初にこの宣言だけ行われ(3. 代入はこの行で実行)
})();
これと
var a = 'hoge';
(function(){
var a;
console.log(a); // 2. undefinedになり
a = 'fuga'; // 1. 最初にこの宣言だけ行われ(3. 代入はこの行で実行)
})();
これは等価だと思うが?
var a = 'hoge';
(function(){
console.log(a); // 2. undefinedになり
var a = 'fuga'; // 1. 最初にこの宣言だけ行われ(3. 代入はこの行で実行)
})();
これと
var a = 'hoge';
(function(){
var a;
console.log(a); // 2. undefinedになり
a = 'fuga'; // 1. 最初にこの宣言だけ行われ(3. 代入はこの行で実行)
})();
これは等価だと思うが?
>>487
> スコープ内のどこでも、かぶっちゃいけないと思うの
いやいや、そういう話ではなくてね。
まず宣言の巻き上げが起きない
JavaScript以外の言語の話ね。
例はJavaScriptで書くけどw
function foo() {
for(let i = 0; i < 100; i++) {
console.log(i);
}
for(let i = 0; i < 100; i++) {
console.log(i);
}
}
こういうコードで、変数定義を関数の上の方に
持ってくるとかぶっちゃうわけよ。
スコープ内でかぶるとかいう話ではなく、
ブロックスコープが、関数スコープに
広がってしまうからかぶっちゃうのよ。
> スコープ内のどこでも、かぶっちゃいけないと思うの
いやいや、そういう話ではなくてね。
まず宣言の巻き上げが起きない
JavaScript以外の言語の話ね。
例はJavaScriptで書くけどw
function foo() {
for(let i = 0; i < 100; i++) {
console.log(i);
}
for(let i = 0; i < 100; i++) {
console.log(i);
}
}
こういうコードで、変数定義を関数の上の方に
持ってくるとかぶっちゃうわけよ。
スコープ内でかぶるとかいう話ではなく、
ブロックスコープが、関数スコープに
広がってしまうからかぶっちゃうのよ。
letを使うのは有用だけど、ここはESスレじゃないし
>>452のように、エディタやIDEでなんとかするのが建設的な気がする
とりあえず、sublimeのプラグインで書いてみようかと思うんだが
やっぱ色つけるのが良いですかね?他になにか案ある?
>>452のように、エディタやIDEでなんとかするのが建設的な気がする
とりあえず、sublimeのプラグインで書いてみようかと思うんだが
やっぱ色つけるのが良いですかね?他になにか案ある?
>>489
なんでJSすれでJS以外の言語仕様の話持ち出すの?
なんでJSすれでJS以外の言語仕様の話持ち出すの?
Web製作管理板とは言え、最近はWebアプリというものもあるし
最先端技術を蔑ろにする方が現実を見てないと思うな
もうIEガーはいいよ
最先端技術を蔑ろにする方が現実を見てないと思うな
もうIEガーはいいよ
>>494
「IEガー」がいい理由って何?
「IEガー」がいい理由って何?
>>498
えぇ、ですからJavaScriptの変数の宣言場所の話をしていますよ?
えぇ、ですからJavaScriptの変数の宣言場所の話をしていますよ?
それではEcmaScriptスレの意見を伺ってみましょう。
http://toro.2ch.net/test/read.cgi/tech/1325448978/319-331
うーん、やっぱりここが頼りみたいですよ。
http://toro.2ch.net/test/read.cgi/tech/1325448978/319-331
うーん、やっぱりここが頼りみたいですよ。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.105 + (1001) - [97%] - 2013/5/20 4:45
- + JavaScript の質問用スレッド vol.128 + (1001) - [97%] - 2016/2/26 6:45
- + JavaScript の質問用スレッド vol.107 + (1001) - [97%] - 2013/9/7 10:16
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.106 + (1001) - [97%] - 2013/7/20 9:30
- + JavaScript の質問用スレッド vol.109 + (1001) - [97%] - 2013/10/7 13:16
- + JavaScript の質問用スレッド vol.104 + (1001) - [97%] - 2013/1/28 4:00
- + JavaScript の質問用スレッド vol.103 + (1001) - [97%] - 2012/11/9 15:30
- + JavaScript の質問用スレッド vol.102 + (1001) - [97%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.101 + (1001) - [97%] - 2012/7/16 14:15
- + JavaScript の質問用スレッド vol.100 + (1001) - [97%] - 2012/6/13 22:46
- + JavaScript の質問用スレッド vol.120 + (1002) - [95%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.125 + (1001) - [95%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.124 + (1001) - [95%] - 2015/7/16 1:30
- + JavaScript の質問用スレッド vol.123 + (1002) - [95%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.123 + (966) - [95%] - 2020/10/20 2:30
トップメニューへ / →のくす牧場書庫について