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

JavaScript覧 / PC版 /

みんなの評価 :

1 2 3 次へ

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

1 = :

JavaScript に関する何でも質問スレです。
お気軽にどうぞ。

3 = :

■各種仕様 (http://fiddle.jshell.net/vSqKr/33/show/#Link も参照 )
◆ Standard ECMA-262
http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/ （ECMAScript 3 和訳）
http://www.ecma-international.org/ecma-262/5.1/ （ECMAScript 5.1 HTML版）
http://people.mozilla.org/~jorendorff/es6-draft.html （ECMAScript 6 有志HTML版）
http://kangax.github.io/es5-compat-table/ （ECMAScript 5 compatibility table）
http://kangax.github.io/es5-compat-table/es6/ （ECMAScript 6 compatibility table）
◆ HTML Standard (HTML5)
http://www.whatwg.org/specs/web-apps/current-work/multipage/
http://momdo.s35.xrea.com/web-html-test/spec/WD-html51-20130528/Overview.html （HTML5.1 部分訳）
http://www.hcn.zaq.ne.jp/___/WEB/WebStorage-ja.html （Web Storage 和訳）
◆ Document Object Model (DOM) / CSS Object Model (CSSOM)
http://www.hcn.zaq.ne.jp/___/WEB/DOM4-ja.html （DOM Standard (DOM4) 和訳）
http://www.w3.org/TR/DOM-Level-3-Events/ （DOM3 Events）
http://www.w3.org/TR/uievents/ （UI Events）
http://www.hcn.zaq.ne.jp/___/WEB/cssom-ja.html （CSSOM 和訳）
http://www.hcn.zaq.ne.jp/___/WEB/cssom-view-ja.html （CSSOM View Module 和訳）
◆ その他のWeb関連仕様
http://domparsing.spec.whatwg.org/ （DOM Parsing and Serialization - innerHTML等）
http://www.hcn.zaq.ne.jp/___/WEB/XHR-ja.html （XMLHttpRequest 和訳）
http://www.hcn.zaq.ne.jp/___/WEB/File_API-ja.html （File API 和訳）
http://www.whatwg.org/specs/ （WHATWGの仕様一覧）
◆ MDN (Netscape/Mozilla)
http://developer.mozilla.org/ja/docs
◆ JavaScript Garden (ja)
http://bonsaiden.github.com/JavaScript-Garden/ja/
◆ JSON (JavaScript Object Notation) 4
http://www.json.org/json-ja.html
◆ MSDN Library
http://msdn.microsoft.com/ja-jp/library/yek4tbz0.aspx (JavaScript)
http://msdn.microsoft.com/ja-jp/library/cc427807.aspx (JScript)
http://msdn.microsoft.com/ja-jp/library/cc409712.aspx (DHTML)

4 = :

　

以上、テンプレはここまでです。

================================================

この後は自治厨の無駄なあがきを御覧くださいｗ

5 = :

JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合はhttp://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) ライブラリ関連の質問もOKです。
(10) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。

6 = :

あれ？テンプレ消しスレはここがまだあるのに
なんで新しく建てたの？

+ JavaScript の質問用スレッド vol.121 +
http://peace.2ch.net/test/read.cgi/hp/1410603104/l50

8 = :

>>6
新しくスレが立てられそうだからフライングしたんだろう
いつものことながら呆れる

11 = :

前スレより

(function(){
'use strict';

function a(){
b();
}

function b(){

}
})();

test.js|4 col 14 warning| 'a' is defined but never used.

12 = :

'use strict';

function a(){
b();
}

function b(){

}

test.js|3 col 10 warning| 'a' is defined but never used.
test.js|7 col 11 warning| 'b' was used before it was defined.
~

13 = :

だからエラーメッセージに書いてあるとおりじゃん

14 = :

それは何故無名関数で囲うと警告がでなくなる理由になってない

15 = :

エラーと無名関数のありなしはまったく関連がない件

17 = :

>>14
スコープの問題を考えて見ればわかるだろう

18 = :

質問を曖昧なまま継続するからこうなる
自業自得だな

19 = :

無名関数でかこうとエラーが変わるのは、単にLintの実装もしくはLintの作者の思想に依存してるだけじゃない？
Javascriptの仕様に基づいた理由は無い気がする

俺はむしろ、前方参照がなんでだめなのかわからない
だってJSって順序関係ないし、全部パース終わってから実行するのは元々わかってる
そうじゃなかったら関数とかくそめんどくさいことにならない？

変数は、代入が実行される時まで値が束縛されないから
前方で宣言されていても束縛しないで使ったらundefinedになることが自明だからなんの問題もない
ちゃんと宣言してないとグローバルまで探しに行くから、グローバルに同名のがあったらundefinedにならないから
前方参照があるせいでちゃんとスコープ内の変数だってわかってundefinedになる

と理解してるんだけどなんかおかしい？

20 = :

>>19
もう少し用語の混乱を何とかしてほしいのだが…。
「前方参照」は「変数のhoisting」を表していると認識して良いのか？

hoistingはプログラマが直感的に理解しづらいのがデメリットであって理解して使う分には何の問題もない。
ただ、自分一人で完結するならともかく、チームを組んでいるなら底辺に合わせるのが常識だ。
全員が同等の知識レベルを持ち、外部に公開する事のないコードならあなたのいうように問題はないだろう。

21 = :

>>17
それは違うかな

22 = :

> 「前方参照」は「変数のhoisting」を表していると認識して良いのか？

違うだろ。

例えば、Javaなどの他の言語であっても、
前にある関数が、後ろにある関数を参照できるのは当たり前
参照できないのはC言語ぐらいだろ？
そのC言語は前方宣言という機能で対応している

>ただ、自分一人で完結するならともかく、チームを組んでいるなら底辺に合わせるのが常識だ。
底辺関係ねーだろ。
お前が底辺って言いたいだけじゃねーの？
気持ち悪いやつだな。

23 = :

>>19は日本語が下手だけど言いたいことはこういうことだと思う↓
http://compute-taso.blogspot.jp/2013_08_01_archive.html
俺はこの意見に賛成
なのでLintの宣言は頭でまとめろや後に宣言されてるよ警告はくそくらえ思想だと思ってる

24 = :

>>17
エラーメッセージに書いてあるとかスコープの問題を考えてみればとかとんちんかんなんだよお前

25 = :

最初の2エントリと次の次のその間違ったhoisting問題をぶち壊す！というところな

26 = :

>>20
> ただ、自分一人で完結するならともかく、チームを組んでいるなら底辺に合わせるのが常識だ。

チームに未経験新入社員が入ってきた。

よし、底辺に合わせよう！

いくら力があっても新入社員レベルになるため
プロジェクトは失敗しましたｗ

27 = :

仕様通りなら問題ないというならあらゆるコーディング規約が不要だな
全部理解してるなら規約で縛る必要はなかろう

28 = :

> 仕様通りなら問題ないというならあらゆるコーディング規約が不要だな

俺もそう思う。コーディング規約は不要で
必要なのはコーディングガイドライン。
違いは、ガイドラインは破ってもいいってところ。

世の中のコーディング規約っていうのは規約にするまでもないことのほうが多いよ。
どっちでもいい問題にたいして、白黒つけたがる。

絶対にだめという事以外はルール化する必要はないだろう。

29 = :

>>23
> なのでLintの宣言は頭でまとめろや後に宣言されてるよ警告はくそくらえ思想だと思ってる

俺も頭でまとめたりしない。

jslintは設定ができないんで、殆どの人はjshintを使っているだろうけど
jshintのデフォルトは頭でまとめる必要はなかったはず。

だいたい変数の巻き上げが起こったからといって困ることはなにもないんだよね。
あれ？ varの前より変数が使える？ってなることぐらいで、
普通はvarの前で変数を使うことはない。使っていたらそれはバグなわけで。

変数を頭で宣言すると問題の方が多くて、変数名が冗長になるのとコードが複雑になる。

一見関係無いように思えるけど、変数を近くにすることで「この辺りでしか使われてない変数だ」って
分かりやすくなるから変数名も短くて済む。遠くにあると変数同士を区別するために長い名前にしなくちゃいけなくなる。
そして変数が近くにあると、これ一時的な変数だからコードを合わせれば不要になるよねと
コードを最適化しやすくなる。

これが底辺が書いたコードをレビューした時に実際に感じたこと。
ちなみにこの底辺は元々COBOL使いだったからか、変数を頭にまとめる傾向がある。

ついでにチームを組む時に底辺に合わせたらだめだよねって言っておく。

30 = :

規約にするまでもないことをこまごまつけるのは
多数の人間にやらせる関係、言語仕様より人間の都合に由来するように感じられる
原稿を入稿するときに印刷所のフォーマットにあわせてね、というレベルの話
そうではなくもっと根本的などのようなスタイルがよりベストか？というのは
規約ではなく言語仕様のみから自然と導かれるのが理想だとは思うよ

31 = :

>>28-29
あなたは仕様に厳格な書き方を好む人なのだろう
私も同じだが、チームを組む場合は共通認識が必要だ
各々が仕様に忠実に、自由なスタイルで書いていたらコードに統一性がなくなってしまう
一定の法則に沿ったコードにする為にコーディング規約が存在する
「仕様に忠実で読めれば何でもいい」というならコーディング規約は不要だが、メンテナンス性は著しく落ちるだろう

32 = :

> 各々が仕様に忠実に、自由なスタイルで書いていたらコードに統一性がなくなってしまう

それは思い込み。

あれだ。底辺に合わせようとして、技術が低い人は低いまま
高い人は高いままでやるからそうなるんじゃね？

高い技術に合わせて行けば、だめなコードはコードレビューで取り除かれ、
必然的にコードは統一される。みんなが何がよくて何がだめかを知っているからね。

だからわざわざ文書化する必要がなくなる。

33 = :

なんでこんな話になってるんだww
仕様通りなら何やっても良い、ではなく警告が重要でないこともあるんでは？ということがいいたかった
まあ根拠がない規約は悪い宗教だと思う

PerlなんかはJS以上にどうにでも書けるけど、ベストなスタイルは一般に思われてるより浸透してますね
CPANのレベルの高さが大きいかな
あれだけ自由度過ぎる言語でも人の美的感覚でなるようになるもんだ
けど場末の会社にCPANレベルの人が集まるわけじゃないからねー
誰が書いても同じ形になりやすいPythonでさえくそコード生み出す人はいるので規約はいるのだ

34 = :

こうしんされてたわ
理想論としては32に超同意
現実はなかなか難しいー

36 = :

技術力が均一化されるのが理想だが、実現性か今一つ信用出来ない
個人間の才能の差をどうやって埋めるというのか
具体的な対策があるなら興味があるな

37 = :

コードレビューだよ？
普通やるでしょ？

誰もコードを確認しないままOKってやっちゃうの？
それって校正しないままニュースを発表するようなものだと思うけど。

38 = :

各々で自由に書かせてレビュアーが全部校正するのか
明確な基準もなしにコードを書かせるのだから校正には恐ろしく時間がかかるな
非効率的すぎて話にならん

39 = :

そもそも、コードレビュアーの独断と偏見に一任して上手くいく理由がわからん
コードレビュアーは一人にすることで統一性をはかってるのかね
であれば、レビュアーが変わったらコーディングスタイルも変わるが、レビュアーが辞めたらどうするんだろうな

40 = :

>>38
お前んの頃の人材は、
レビューするたびに前回の指摘を忘れてしまうのか？

なんで校正に恐ろしく時間がかかるんだ？
レビューの量は1コミット数十行程度だろ

その程度ならレビューなんて数分～十数分程度で終わるし、
もしかして数日とか数週間かけて作ったものを
一度に全部コードレビューするとか一緒にテストとかやってないか？

それだと効率悪いだろ。早いうちに小さな修正をバンバン指摘していくんだよ。
そうすればすぐに小さな指摘をする必要はなくなる。

41 = :

>>39
それはどうでもいいところを統一しようとするから
そんなことになるんだよ。

コードレビューで指摘するのは、どうでもいい規約を守らせるためじゃなくて
問題点。悪い所を直すこと。AとBがあったとき、明確にAの方が
優れている場合に指摘すればいいんだよ。

AもBもどっちも書き方の違い的な場合は、指摘する必要はない。
こっちのほうがいいんじゃないですか？ぐらいの提案はするけどな。

コーディング規約でどうでもいいことを厳密に守らせようとするから
レビューアの好みとかそういう話が出てくるんだよ。

な？（絶対守る）規約はデメリットばかりだろ？

42 = :

コードレビューで質が維持されるってのは同意だな
ゲームの攻略wikiのような参加者の文章レベル低そうなところでも
更新のたびに多数が相互に推敲繰り返すから文体が統一されたり、自然とそつのない文になってくだろ
複数人作業の醍醐味だな
酷いものは自然と淘汰されんだよ

大抵の人間にはそういう最低限の判断センスがあるんだが…
>>30の例えを借りると、原稿の中身の良さはレビューしないとどうにもならんが、原稿サイズでさえ合わせてこないやつがたまにいるので規約がある

世の中にはいるんだよ、既存のスペース4インデントのソースに、タブ混ぜて来るようなやつが
スペース2かスペース4かというのは宗教だが、スペースにタブを混ぜてなにも感じないのはおかしい
プログラミングのレベルの問題じゃなくて、そういう違和感が絶望的にないやつがいるから規約がなくならない
あとはどっちでもいいけど宗教論争になるとどっちでもいいだけに不毛な所を先に決めておく的なやつ

43 = :

>>40
レビュー者の評価が正しい事は誰が保証するんだ？
レビュー者AとBの評価が違ったらどうする？
独断と偏見のレビューなど、何の役にも立たん

44 = :

>>41
> コーディング規約でどうでもいいことを厳密に守らせようとするから
> レビューアの好みとかそういう話が出てくるんだよ。
逆だろ
レビュアーに一任するからレビュアーの好みが反映されるんだろ
個人間でチームを組むなそれでいいが、会社としてやっていくなら個人の好みが反映される仕組みにするべきではない
何のためにGoogleがガイドラインを作っていると思ってるんだ
守らなくていいガイドラインなら作る必要はないんだよ

45 = :

>>43
> レビュー者AとBの評価が違ったらどうする？
そんなことAとBで話し合って決めろよ。
コミュ障かよ？

それともコーディング規約を作れば解決できる問題なのか？
今度はコーディング規約内容をどうするかでAとBが対決するだけだろ。

46 = :

>>42
> 世の中にはいるんだよ、既存のスペース4インデントのソースに、タブ混ぜて来るようなやつが

そういうのは、技術が低いからなだけ。
スペース派、タブ派の違いはいるが、混ぜる派はいない。
技術が低いから混ざってしまう派だ。

そういう奴は技術が低いのが原因。たかがスペースなどという
どうでもいいことを揃えた所で技術力は高くならない。
どちらにしろそいつのコードは信用出来ないんだよ。

47 = :

いまどきそんな混雑させるエディタを使うのが惡い

48 = :

レビュー出来るぐらい優秀ならば、その分他人が書くべきコードを引きとって
コードをバリバリ書いた方が結果的にはいいものが出来るというジレンマ

49 = :

コードレビューできる＝優秀なのか・・・
普段どんな酷いコードばかり書いて
それでシステムが動いているんだろうか。
客には言えないな。

50 = :

>>49
コードレビューできる＝優秀
もちろんそうだ

1 2 3 次へ

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

JavaScript一覧へ