>>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がない場合も考えられるな

>>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
まず基礎から勉強したほうがいいよ
はっきりいうけど基礎も分かってない

正月から勢い強すぎだろ

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の名前空間は二度と考慮しないって言うのはどうなるんですか？