+ JavaScript の質問用スレッド vol.122 + [転載禁止]©2ch.net

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

■前スレ
+ JavaScript の質問用スレッド vol.121 +
http://peace.2ch.net/test/read.cgi/hp/1410603104/
+ JavaScript の質問用スレッド vol.121 +(c)2ch.net
http://peace.2ch.net/test/read.cgi/hp/1415213701/

■過去スレ全集
http://www2.atpages.jp/mirror/2ch/javascript/
http://usamimi.info/~mirrorhenkan/2ch/javascript/ (閲覧のみ)

■関連スレ
ECMAScript デス 4
http://toro.2ch.net/test/read.cgi/tech/1325448978/
【jQuery】JavaScript ライブラリ総合質問所 vol.3
http://toro.2ch.net/test/read.cgi/hp/1369444026/
【WHATWG】HTML5 Part6【W3C HTML WG】
http://toro.2ch.net/test/read.cgi/hp/1393153279/
Webサイト制作初心者用質問スレ part239
http://toro.2ch.net/test/read.cgi/hp/1393828207/
CSS初心者スレッド＝12th＝
http://toro.2ch.net/test/read.cgi/hp/1343429848/
Canvasについて語ろう
http://toro.2ch.net/test/read.cgi/hp/1305093769/

■各種仕様 ( 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)
https://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)

　

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


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

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

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

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

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

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

jQuery 2.1.2リリース！
https://github.com/jquery/jquery/releases

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

あげ

ほげ

前スレより

(function(){
'use strict';

function a(){
b();
}

function b(){

}
})();

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

'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.
~

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

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

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

jslintのチェック精度の問題じゃないの
グローバル空間の変数関数しかチェックしていないとか

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

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

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

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

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

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

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

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

>>17
それは違うかな

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

違うだろ。

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それは思い込み。

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

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

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

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

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

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

> 誰が書いても同じ形になりやすいPythonでさえくそコード生み出す人はいるので規約はいるのだ

規約で正せるのは、コードの質全体のほんの5%ぐらいだろう。

上級者によるコードレビューじゃなければ、どんな言語でもクソコードになる。
Pythonでコードレビューしたこともある経験に基づいた話。

最終的にコードの質を保つのは技術力でしか無い。
規約で保証できるのは、ですます調は統一しましょうぐらいなものだ。
それを統一した所で良い文章は書けないし、
良い文章をかける人なら、ですます調の統一ぐらい出来る。

技術力が伴ってないのに、規約で統一した所で何の意味もないんだよ。
だからガイドラインで十分という話。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>49
他人がするコードレビューはほとんど無意味だと思ってる
それをする意味があるのは、本当に優秀なやつがコードを本気で直す時だけだ

>>45
おまえはコーディング規約が不要という意見ではなかったのか？
「規約は不要、レビューすれば十分」といっていただろうが
規約が必要ならレビュー前から守らせろよ

>>52
だから規約は不要だって。
AとBが話し合えばいいだけの話。
そんな細かいことにいちいち規約を作るな。

>>50-51
プログラマなら普通だれでも相互にレビューするだろ
まさかプログラマの壁を超えた奴が一人もいないのか？

プログラマがいないのに、
どうやって規約なんて作れるんだ？

正しいコードを採用すればいいだけの話。
どちらが正しいかは論理的に考えれば
だれでも同じ答えにたどり着くだろ。

レビューで指摘するのはそういうこと。

それでもなお、意見が別れるものに関しては
どちらでもいいから、そんなものは規約で決める必要がない。

という話なんだが？

>>54
しないよ
どんだけ暇なんだよ
大量のコードを書く職場だったらどんだけ非効率な事か分かるだろ
もちろん本人はレビューとテストを徹底的にするがな

> 大量のコードを書く職場だったらどんだけ非効率な事か分かるだろ

大量のコードを書かなくていいようにするために
レビューするんだけど？

レビューしないと、質の悪いコードになる
質の悪いコードとは、コードの量が多くて
コードの見通しが悪いコード

誰もそれを指摘しない。

そしてそれを参考にして、他の人が書く。
その時、コピペしてそのまま使えないからと一部だけ修正する
最初のコードよりもさらに質が落ちる。

そしてそれを参考にして、以下繰り返し。
でどんどん破綻していくんだけど。

>>57
> 大量のコードを書かなくていいようにするために
仕事の規模が大きかったらどうすんだよw

> 質の悪いコードとは、コードの量が多くて
完全にダウト
コードの量と質は全く関係無い
非常に複雑で大きなコードを書く事だってあるが、複雑で大きいコードだからと
いって悪いコードなんて事は全くない
それを他人が一々レビューするのは全く非効率

誰でも担当外のコードをすぐ見て理解出来る程度の仕事規模なら、レビューでもすればいいよ

>>53
事前に話し合いでルール(規約)を決めておかないわけ？
問題が起きてから相談してルールを決めるのは効率が悪すぎる上に致命的な問題だったら放題な時間を費やすことになる

バグを他人に発見されるのは恥かしい事なんだよ
他人にレビューしてもらってバグが発見されるようなら、プログラマとして終わってる
ってぐらいの緊張感とプライドでコードを書く必要があるんだよな

それでも、ある時期には一旦コードの更新を止めて全員でバグチェックとレビューはした方がいいだろうね

その時はマジでやるかやられるかぐらいの緊張感があるべきだね

>>58
> コードの量と質は全く関係無い
関係ある。コードの質は客観的な方法で計測可能。そのための指標はいくつかあるが、
コードの量が計測に入っているものも多い

例えば
http://msdn.microsoft.com/ja-jp/library/bb385914.aspx
> コード行 - コード内の行の概数を示します。
> 数が非常に大きい場合、型またはメソッドでの処理が多すぎるため、
> 分割が必要であることを示すことがあります。

>>59
決めておかなくても、技術力があれば
問題ないコードをかけるから、心配する必要はないし、
コーディング規約なんかで防げるのは
コードの質の全体の5％ぐらいなもん。

問題が起きるならば、起きる人の技術力が低いわけで
技術力が低い人が、決められたルールを守った所で
もっと大きな問題が起きる。

前提として、コーディング規約では致命的な問題を解決することは出来ないってことを知るべき。

> それを他人が一々レビューするのは全く非効率

レビューに時間が掛かるから非効率だと考えてしまう。

ではなぜレビューに時間がかかるかというと

まさに、コードの量が多いから

このことで、コードの量が多いということが問題であると
はっきりわかっただろう？


指摘するべき問題があるのに、非効率という言葉で問題を解決しないことになる。
コーディング規約があってもそうなってしまっているということだ。

だからコーディング規約なんかに頼ることはやめて
レビューによる技術力アップをするべき。

>>60
> バグを他人に発見されるのは恥かしい事なんだよ

念の為に言っておくと、コードレビューで行うのは
バグの発見ではない。だからコードレビューでテストをする必要もない。

もちろん質の悪いコードをみて、バグを見つけたら
指摘していいが、そっちはおまけ。

コードレビューでやるのは、コード質の向上や開発効率の向上。
レビュー時間を短縮するためにも、可読性が高いコードが必要になる。
レビューに時間が掛かるなんて言ってる時点で、
コードに大きな問題があるってことなんだよ。

コードレビューをやらないとどんどん開発効率は落ちていく。
コーディング規約程度では守れない問題。

なお、コードレビューよりも効果が高いものがあって、
それはペアプロ。

実質リアルタイムにコードレビュー状態になるから
早いうちに問題点を取り除ける。

「早いうちに問題点を取り除く」の反対（悪い方）は
問題があるのにそれに気づかずに、コードがどんどん作られ
後になってバグの修正などでコードをみた時に
長く複雑なコードと対峙してコードを解析するのに時間がかかること。
問題を直すのは後になればなるほど時間がかかるからね。

普段他人のコードを"解析"することが多いならば大いに反省するべき。
コードはスラスラと読むものであって、解析するものではない。
っていうか、解析が必要な難問を自分らで生成してどうするよｗ

コーディング規約は精神安定剤みたいなもんだろう。

これさえ守っていれば、コードの質は保たれるんだーみたいな。

実際には質が悪いにももかからわず、ただただ
精神を安定させるために使われてる。

>>64
正直それは理想論だな
理想を否定する気はないが、本当に専門性の高いコードは他人が見ても分からない

単にコーディング規約を守ってるかぐらいはレビューすれば分かるが
それがコードの質を高める事に繋がるのか？

コードが長いか短かいかは誰がどういう判断で決めるんだ？
何度も言うが専門性が高いコードは安易に良い悪いは決められない

・コーディング規約を守ってるか？
・1つの関数が長くないか？

これだけだったら、新人教育という範疇だろう
それだったら、ちゃんと毎回レビューして指摘すべきだろうけど

「とりあえず、やってみて問題が起きてから話し合う」って日本人だから出来る考え方だよな
空気を読んで足並みを揃えるってやつ
アメリカで同じ事が起きたら「決めておかなかったのが悪い」で一蹴される

あと、新人教育やレビューは他人の為にやる事だから、ちゃんと職場の理解がないと
単に仕事が遅い使えないやつと思われかねない
難しい問題ではある
実力主義でやってるようなところは特にやりずらいだろうね

結局、話し合いで決める規約が存在するんだろ
それをコーディング規約と呼ぶか呼ばないかの違いでしかない
文書化せずに口約束レベルで統一をはかろうってのは証拠が残らないし、後で齟齬が発生しても仕方がないと思うがね

長文先輩多すぎ

スレチイタチの類

レベル差がなくても他人の目を通すとわかること結構あるよね
イラスト左右反転したらデッサンの狂いに気づくのに似てる

自分は5年位独学でやってて、そのあと偶然入った仕事でペアプロやる事になったんだけど
それまで自分のプログラミングってどっかおかしい？って自信持てなくなってたのが
あれ俺思ってたより悪くない？って確認できたのと
刺激と緊張感でスキルアップできたな

>>72
ペアプロが有効なのは否定しない
人件費やお互いのプライドなんかの問題が無ければやるべきだとは思うよ

ペアプロで試されるのはコーディング力より人間性ｗ

>>72
スキルアップに有効なのは否定しないが、規約の必要性は別問題

>>74
人間性も重要だろう
プログラムに限った事じゃないけど、平気でバグ出すやつとか滅茶苦茶気を付けてるやつとか
の違いって結局人間性の違いだしね

>>67
> 「とりあえず、やってみて問題が起きてから話し合う」って日本人だから出来る考え方だよな
> 空気を読んで足並みを揃えるってやつ
> アメリカで同じ事が起きたら「決めておかなかったのが悪い」で一蹴される

それ、逆だぞ。

一個人のブログだが、いろいろ調べてみるといい。同じような話が見つかるはず。
http://mojix.org/2010/10/05/yatteminai-to-wakaranai

> ＜私は社内でアメリカ人からうんざりされることが多い。プロジェクトの業務要件を決める会議などで、
> レアケースも含めて網羅的に考慮ポイントを説明したりすると、最初のうちはうなずきながら
> 興味深そうに聞いているのだが、次第に疲れが顔にではじめ、ついには「いや、色々あるのはわかったけど、
> とりあえずやってみて、駄目ならその時考えよう」と言われることが非常に多い＞。
>
> ＜アメリカ人は総じて、事前に考慮事項を洗い出し、シミュレーションして対策を講じるというのが苦手で、
> あれこれ考える前にとりあえずやってみようというアプローチをとることが殆ど。そういう点でアメリカ人は
> 事後にストップする仕組みをきちんと整備しているというよりむしろ、うまくいかなかったら軌道修正したり、
> 場合によってはストップすることを前提に物事に取り組むといったほうが正確だろう＞。
>
> これは面白い。アメリカ人は総じて、「とりあえずやってみて、ダメだったらやめる」という考え方をする、とのこと。

だいたい、最初に問題なんて全部洗い出せるわけがないわけで。

>>66
> コードが長いか短かいかは誰がどういう判断で決めるんだ？

コードメトリクスで検索しろ。

>>75
> スキルアップに有効なのは否定しないが、規約の必要性は別問題

規約を過大評価しすぎ。あってもなくても
コードの質に大きな影響を与えない。

コードレビュー（ペアプロ含む）をやれば、
大きな効果があるし、規約の内容をカバーできる。

aaaっていうclass名のついた要素のidを取得したいんですけど、どうやったらできますか？

<div id="????(変わるが常に何かしらのIDがついている)" class="aaa"> </div>

<script>
element = document.getElementsByClassName("aaa");
alert(element.id);
</script>

だとunderfinedになってしまいました。
よろしくお願いします。

>>80
aaaが複数ある場合はどうするの？

var id = $(".aaa").attr("id");　// aaaが複数ある場合は最初のものを参照する

aaaがない場合も考えられるな

>>80
<script>
elements = document.getElementsByClassName("aaa");
alert(elements[0].id); //最初のclass="aaa"のidを取得
</script>

elements.lengthでclass="aaa"の個数が分かるから、条件分岐とかで適宜使うといい

あと>>81はjQueryっていうプラグインを使っている
そのままじゃ使えないから注意な

jQueryはプラグインじゃなくてライブラリな。
JavaScriptではDOM操作をする時によく使われているライブラリ。
Microsoftも採用しているよ。

>>83さんのでできました！ありがとうございます！
81,82,84さんもありがとうございました！

また質問で申し訳ないのですが、
var hoge="aaa";
document.getElementsByClassName(hoge);
ってすることはできないのでしょうか？

できまそ

聞く前にコンソールで実行してから聞いたの？
試しもせずに何でも聞くなよ？

自己解決しました

自己解決したのならその詳細を事細かに書け
他の人の参考にならないだろ。

>>88
実行したのですが、動きませんでした
どこか間違ってないか確認してみます
>>89は私じゃないです

じゃあ動かない。が答えですよ

>>91
まず基礎から勉強したほうがいいよ
はっきりいうけど基礎も分かってない

正月から勢い強すぎだろ

こっちが使われないと困る荒らしが必死に盛り上げるからね〜


ちなみに現行スレはこちら
+ JavaScript の質問用スレッド vol.122 +©2ch.net
http://peace.2ch.net/test/read.cgi/hp/1420095379/l50

var x=5;
if(
x.match(/\d/)
)
{
alert("数字")
}

これだと動かないけど
var x="5";
にすると動きます

matchって数値の変数には対応してないんですか？

String型のメソッドだからそうだろうね

http://peace.2ch.net/test/read.cgi/hp/1420095379/74-75

ES6のmoduleって名前空間と何か違うんですか？
ES4の名前空間は二度と考慮しないって言うのはどうなるんですか？

はい
こちらへどーぞー



現行スレ
+ JavaScript の質問用スレッド vol.122 +©2ch.net
http://peace.2ch.net/test/read.cgi/hp/1420095379/l50

lodash 3.0 リリース間近！

https://github.com/lodash/lodash
3.0-preから-preが外れました！


スレが多すぎてどこに書けばいいかわからないので
関連スレすべてにマルチポストしています。m(__)m