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

JavaScript覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

354 = :

>>349
まあまあだね。じゃあ勝手にレビュー。

ソート関数が汎用的になっていない。
ソート関数を実装する人がよくやりがちだけど、
引数で処理を変えるんじゃなくて関数そのものを変えた方がいい
そのほうが処理がスッキリして明確になる。

つまりrows.sort内の処理を二つにわけ、
$('button#numb').on('click',function(){ sortTable(0, numberSort); });
$('button#name').on('click',function(){ sortTable(1, stringSort); });

こうすうることで、tableと関係ない汎用的なsort関数にすることが出来る。

この0と1からわかると思うけど、var obj = {略} の所、numberでソートの時は
nameいらないわけで無駄な値を取ってきてるね。
0と1だとマジックナンバーだから定数にした方がいいかもしれないけど。

それとrowsを使っている所、mapを使った方がいい。
配列 から 同数の配列を生成したいならばmapと言えば簡単だろう？

360 = :

>>353
まあ色々やってみたかった、一つづつ処理を負いたかったってのはわかるよ。
結果として無駄なことやってるだけだけどｗ

他に人に最初に補足、これは実験的な機能を使ってるので
Chromeでオプション変えないと動きません。

まずtextsがsortされるし、関数実行中に画面描画はされないので、
deliverChangeRecordsは不要。
それ以前に関数実行中に画面描画はされないので、そもそもobserveを使う意味が無い。

recs.lengthを見ればわかるが、値の合計は15。
つまり8個しかないのに、tdへの代入が15回発生している。
だからobserveを使わずにsortし終わってから代入したほうがいいね。

あと細かいところで1/0は単純にInfinityでよい。

363 = :

>>340

> return (!a || !b) ? a < b : a > b

これが見にくいのは三項演算子だからではなく
優先順位がわかりにくいからだよ。

四則演算程度の優先順位ならだれでも知って当然だが、
?と<がでてきたら、えっ？えっ？ってなっちゃう。
もしかしたらこうかも知れないしさ。

(!a || !b) ? a < b : a　　　> b

カッコでくくるだけでシンプルになる
return (!a || !b) ? (a < b) : (a > b)

もしてもう一つ、式を変更しよう。否定というのは何かとわかりにくい。
(!a || !b) この形が出てきたら有名な、ドモルガンの法則がでてくる人は珍しいのかな？

法則に従って直せば、! (a && b) となる。頭の!は三項演算子の残り二つを入れ替えれば消える。

(a && b) ? (a > b) : (a < b)

まあこれはこれで正しく動くのかよくわからんがｗ

366 = :

>>359
そんなはずはないはずなんだが？
何か勘違いしてね？

367 = :

他の言語でも同じだが、省略できる括弧は絶対に書かないのが
coolだと信じてるヘボPGの多いこと多いこと。

370 = :

>>367
> 他の言語でも同じだが、省略できる括弧は絶対に書かないのが
> coolだと信じてるヘボPGの多いこと多いこと。
その通り。

確かに省略できる所を省略しても、
正しく動く。正確に判断してくれる。

だがそれは ”コンピュータが” だ。

ソースコードは人間のために読みやすいように書こう。
人間が読みにくいと思ったら、
コンピュータが読めてもそれは
人間が読むコードじゃないんだよ。

えらいのは人間様です。人間様に優しくしましょうｗ

371 = :

>>369
それは技術をわかってないだけ。

ファイルサイズの話だと思うが、
確かに文字は少ない方がいいんだが
実のところほとんど意味は無い。

なぜなら普通はgzip圧縮して配信するから
その時長い単語や空白はよく圧縮できる。

1バイトでもというが、本当に
数バイトとしか変わらなかったりするよ。
画像ファイルサイズを考えてみ？

372 = 277 :

>>371
今はね、回線も太くなったしサーバも強固になったから楽なんだけど
昔から書いてる人はそうもいかなかったんだよ

ユーザから見たらたかが数バイトでも
サーバから見ると×アクセス数だから
その名残で、短く書く癖が付いちゃってる人もいるんだぜ、って話

373 = :

ちくしょう、考えちまったからレスしとくかｗ

> (a && b) ? (a > b) : (a < b)

そもそもソート関数で、比較条件が逆になるってことが
おかしいことなんだよ。
ソートは常に同じ条件を使うことで正しく並ぶはず。

ただ例外はある。多分空文字だろう？
空文字では適切に並ばなかったため、「じゃあ逆にしたら並ぶんじゃね？」という
安直な発想で、条件を逆にしてしまったのだろうが、
そうではなく、空文字を例外として扱うコードを書いた方がいい。

いいというのは人間にとって読みやすいという意味。
このように書くことで、空文字はちゃんとこのように扱っていると
コード上に明確に書く事ができる。

374 = :

>>372
それは最後までちゃんと計算してない。
バイト数だけで考えていて、
パーセンテージを出してないだろう。

たかだか数バイト。それが積もり積もって1GB。
大きいと思ったとしても1キロバイト中の1バイトであったら、
1000GBもの通信をしているわけ。
普段1000GBのデータ容量を使ってる所が
1GBが問題になるようなことはないよ

そんなことより人間の人件費を考えなさいと。
読みにくいコードは読むのに時間がかかる。
10秒余計にかかったら、それが積もり積もって（略

381 = :

クレクレ厨に餌をあたえないでください

382 = :

>>381
まあこれくらいならやってほしいけど
>>379
http://ideone.com/U2HT6B
とりあえずこれでオシマイ
observeに凝るの疲れた

384 = :

せやな…

385 = :

>>382
なんか無駄に複雑になってるなｗ
面倒なのでもうレビューしないけど1つだけ。

mapもさすがにそれだけあると
目ざわりだからこうするといいよ。

var map = function(array, func) { return [].map.call(array, func); };

まあ、実際にはunderscoreとか使えっちゅー話でもあるが。

386 = :

>>385
修正した

あと読みやすいようにアロー関数にしてみた
http://ideone.com/DRbOd4

387 = :

querySelectorAllってさ、イベントバインドするのに
ループ使わないといけないの？

jQueryみたいに

$('a').on('click', function() {}); （全てのa要素にclickハンドラをつける）

って簡単に書きたいんだけど？

388 = :

NodeList.prototype.map を作ったんだね。

mapとして取り出すか、メソッドはやすかは
方針次第だからどっちでもいいけど、
俺は将来NodeListにmapが追加されたら・・・とか
思っちゃうからあまり好きではないね。

389 = :

>>388
あくまでお遊びだから
あと暫くはES6の
array = Array.from(arrayLike)
を使ってねってなるんだと思ってる

ってことで
>>387
これでいいんじゃね
Node.prototype.on = function (evt, func) {
this.addEventListener(evt, func)
}

NodeList.prototype.on = function (evt, func) {
[].forEach.call(this, function (elm) {elm.on(evt, func)})
}

390 = :

>>386
アローって誰得なの…

391 = :

returnとfunctionを書かずに済むからmapなんかとの相性抜群
やはり短いほうが読みやすい

392 = :

>>391
短いほうが読みやすいってのはわかるんだけどな、
その前にまず、自分のコードを読みやすくしてからにしろと。
そんな小手先の書き方の前にまずやることがあるだろと。

http://jsfiddle.net/NwA63/1/

393 = :

愚痴るけどさぁ、ぶっちゃけ初期バーションで
これぐらいのコード書いて欲しいんだよね。仕事なら。

上で出てるようなコードとか書かれてもさ
レビューに時間がかかるだけで全部書き直しだもの。

このコードもソート時の値の取得に、時間がかかりそうだから
メモ化するとか改善する点はあるわけ。

そのレベルでレビューしたいんだけど、
現実は上で出てるようなコードを
時間かけて読みといて、ダメな点を教えなきゃいけない。

はぁ、ここまで育ってくれるのにどれくらいかかるのか。

394 = :

>>392
講釈はありがたく受け取りますけど
数字ソート失敗してますがな…

395 = :

足りんかった
Firefoxで数字ソート失敗してます
講釈は重々承知致しましたが…

396 = :

五月雨で申し訳ございません
元の質問で、というか必要条件であるところの
空文字列だった場合のソートも失敗しているようでございます

お言葉は仰るとおりですので心に刻みたい所存であります

397 = :

ソートのルールはlocaleCompareでしょ？
この規則は>>382丸パクリで変えてないよ。

これだけ読みやすければ、修正するのも簡単でしょ？
そのやり方でまたセンスが見えてくるんだが・・・。

398 = :

コード修正するつもり無いし、
他の人のレスまとうと思ったけど
面倒になったので、アイデアだけ。

コード上でソートルールを書くのは
せっかくコードがテーブルに依存しなくなったのにもったいない。
（試してないけど、列数が増えてもコードに修正はいらないはず）

ソートのルールというのは、本質的には値の型の問題なので
colgroup要素とdata-*属性を使うかな。data-typeとか。

399 :

ワロタ
>>392先輩は会社でも同じようなことしてんだろうなｗ

400 = 399 :

>>398
そもそもなんでsortに比較関数渡せるのかっつーと
本質はそういうことだろうねえ

前へ 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