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

JavaScript覧 / PC版 /

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

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

551 = :

>>530、>>523と、
>>533の引用部分、似た言葉を使ってはいるけど
内容同じと思いきやそうじゃないな

552 = :

533を読んでみたけど

難解な処理を書かない、読んですぐ意図がわかるコードを書く、
遠くで宣言された変数の代入・再利用などわかりづらいことをしない、
そうすればバグが目に見えて減ると思う、

と、こういう主張だった
全然違くね？使ってる単語が似てるっぽいURLを後付で見つけてきただけじゃね？

553 = :

あと、>>533を主張してるURLは、例にならってGoogleで調べたところ
他の1つのURLで引用されているのみだった
これでは一般的、世間に広く認められている、とはとても言えない

554 = :

>>552
いや、あってるよ？
だから俺は疑問なんだ。

>>519がなんで固有とか列挙可で変なバグを出すのか？
ライブオブジェクトで変なバグを出すのか？

俺はここ数年（十年超えるかもね）そんなことでバグを出したことはない
かと言って、ぜったいにバグを見逃ししないぞと気を張って作業してるわけじゃない

俺のコーディングスタイルは最小のコード記述量で書くこと
書く量が少なければそこに入るバグも最小になる
もちろん難解な処理なんてないし、意図が変わるコード
遠くで宣言する変数とか再代入もしない、まさにそのサイトで主張している通り

それで俺はそんなバグなんか起きてないのに、
>>519がそんなことでバグでハマるのはそもそもの書き方に
問題が有るんじゃないかってこと。

おそらく些細なバグが起きないように、毎回対策のためのコードを書いてるのが原因じゃないか？
俺は些細なバグが起きないように、コードを書かない状態で対策されてる状態にしている。

555 = :

× 意図が変わるコード
○ 意図がわかりにくいコード

556 = :

>>520「書かなくていいコードを書くからバグが出る」
>>533「手を抜いた状態が最善でなければならない」
>>533「手を抜くとバグるというのはヤバい」

Googleで出てきたURL「人間が見てわかりやすいコードはバグが出ないと思う」

曖昧な表現で逃げ、主張をコロコロ変える>>554はバグってるな

557 = :

>>554いわく
>俺のコーディングスタイルは最小のコード記述量で書くこと
>書く量が少なければそこに入るバグも最小になる

>>537のURLいわく

>ゆっくりと考えを巡らせてもっと簡素にかけないかを考える。
>ここで言う簡素というのはプログラムの長さではない。

「まさにそのサイトで主張している通り」って

558 = :

なんか伸びてるとおもってきたら
バカが暴れてるのか

559 = :

>>557
タイプ数って勘違いしたのかｗ
面倒くさいな

そりゃ横に長い行を短くするのに一時変数に入れたりはするよ
そういうことじゃなくて、実行行と言ったら良いか？
定義行（代入行）ではなく処理の数を減らすんだよ。

と言ったら関数の先まで数えて同じとか言いそうだなｗ
コードというのは汎用的な処理とビジネス固有の処理に分けることができる
コード全体から汎用的な処理を切り離すことで、ビジネス固有の処理を減らすんだよ

汎用的な処理っていうのは、他で十分テストされ、例えば他のプロジェクトとかでも使われ
仕様が大きく変化することも、互換性が壊れる形で変化したりもしない、安定しているコード
だから基本読み飛ばすことができる。

読み飛ばせる部分を多くして、ビジネス固有の処理をへらす。これがバグをでなくするための方法
>>519はそういう所を毎回書いてるからバグだしてるんじゃねーのって話

560 = :

書けば書くほどボロが出る
その口でこうすればバグが最小になると言う

561 = :

じゃあ反論どうぞ

ってか>>519はどんなコード書いてんのかって話なんだ

562 = :

ライブなコレクションってgetElementsByClassName()の戻り値とかでしょ

ループに使うのがforでもfor inでもかかわりなく
ループの最初で別の変数に移して参照を持っておかないと
処理中に対象要素がなくなったら問題が出る
そういうもんじゃないの？

563 = :

>>562
そういう場合は処理中に対象要素がなくなるような書き方をしなければいい
ループの配列から取り除くのとDOMから取り除くことを同時にやるからそうなる

564 = :

仮に「最小のコード記述量＝バグが最小になる」が
「コード分離して使い回せば記述量が減る」という意図だったとして
コードを分離できる状況かどうかや抽象性の設定などの問題もおいておくとして

しかしそれでもコード分離の話は>>537のURLには出てきていないな

565 = :

>>563
ライブなコレクション使うときはあれをしてはいけないこれを書いてはダメ
などと神経使わなきゃいけないのは使いづらい
そういう意味では>>537のURLの人が言ってることと同じだと思うんだけど

神経使わないで済むようにポインタじゃなくて文字列使えとか
スタックオーバーフローを怖がらずに定義どおりに再帰関数を書けとか

566 = :

>>537のURLの趣旨はまとめるとこういうこと
「（速度やリソース消費など難が多少あっても）やりたいことをストレートに書けばバグが出ない」
富豪的プログラミングへの言及や神経を使うポインタを避ける

どの辺が「まさにそのサイトで主張している通り」なんですか

567 = :

>>564
> しかしそれでもコード分離の話は>>537のURLには出てきていないな

そりゃそうよｗ

だって>>537のURLを出したのは
>>526が
> その一般論、見たことないんだけど

って言ったからで、その一般論というのは
この話なんだから

> 一般論としてコードというのは一番手を抜いた状態が
> 最善な方法になっていないといけない
>
> ましてや手を抜くとバグになる状態っていうのは一番やばい
> もしそんな状態が有るとするならまずそれを解決すべき

568 = :

>>567
>>553

569 = :

>>565
> ライブなコレクション使うときはあれをしてはいけないこれを書いてはダメ
> などと神経使わなきゃいけないのは使いづらい
> そういう意味では>>537のURLの人が言ってることと同じだと思うんだけど

そういうこと。
神経を使わずに適切なコードが書ける状態になってないのが問題という話

コード書く時に神経使っちゃダメだよ？レビューする方も神経使うだろ？
あれこれ考えて抜けがないよな？抜けがないよな？と何度も確認しなきゃ安心できないコードよりも、
ひと目見ただけで、このコードにバグはないと言い切れるコード、
逆にどうやればこのコードにバグを入れられるんだよ？みたいな方が良いに決まってるだろ？

570 = :

>>569
勘違いさせちゃって悪いんだけど、565のそのレスは
どちらかといえばむしろ>>519のほうが
>>537のURLと同じようなこと言ってると思う、っていう意味なんだ

hasownpropertyとか考えなくて良いようにオブジェクトを使わないで済む方法を選択
バッファ長や\0とか考えなくて良いようにポインタを使わないで済む方法を選択
ほら

572 = :

>>570
ライブなオブジェクトでハマってる時点で
問題解決してねーだろｗ

573 = :

>>571
変換などにより静的な配列を用いるのが確実
参照を保持している限り回収されず他関数等による影響も受けない
処理の順番や構造を気にする必要もなくなる

574 = :

ループを二回に分ければスッキリするのに
なぜか一つのループで別々の処理を行うやつが多い

>>571の例では要素に対しての処理と要素の削除
この別々の処理に対してループを使いまわしするのがいけない

なんでループを使いまわしてしまうのか？という答は
ループ処理を書くのが面倒くさいからではないのか？

だが>>571の下を見れば分かる通り、ループそのものがなくなってる。

ループ処理を書くのが面倒だからというのはわかるが、
1つのループにしてかつ注意して書くよりもそもそもループを無くした方が良い
根本的な問題を解決するのではなく、対処療法的な方法を取るから
逆に面倒になってることに気づこう

575 = :

>>573
> 参照を保持している限り回収されず他関数等による影響も受けない
> 処理の順番や構造を気にする必要もなくなる

じゃあどうするかって話だけど答えられる？
「ライブなコレクション」を保持して、ループで
一つ一つ処理している限りその問題は解决しない

>>571の後者の方法を更にシンプルにしよう（最初からそうしておけって？ｗ）

1. ある条件の要素かつ条件1に該当するものだけをフィルタして処理をする
2. ある条件の要素かつ条件2に該当するものだけをフィルタして削除

たったの2工程。しかもこれ1と2の順番を逆にすることだってできる

576 = :

>>575
君の話は、前提として
・順番を逆にすることができる
・各々の処理が相互に関係しない
という処理である場合のみ利用可能すなわち汎用性に乏しいのでは
静的な配列にしてしまえばまず問題がない
答えられるかというのは何をだ

577 = :

>>576
> 静的な配列にしてしまえばまず問題がない

ではそこが問題だな。
"毎回" 静的な配列になるようになっていないのが問題

静的な配列にするのが "追加作業" になっているならば
それを追加作業ではなく、標準（一番楽な書き方）で
そうなるようにしておくのが正しい

追加作業だとどうしても手抜きで見逃してしまう
ましてや追加作業が必要な場合がレアケースだと絶対にハマる

578 = :

もうすぐjqueryくるで

579 = :

そんなオールスターいらんｗｗｗ

580 = :

変な引用文と改行入れてんのはいつもの荒らしだから触んのやめなさいよ

>>544
const {width:a, height:b} = {width:100, height:100};

581 = :

>>580
そんな書き方があったのですねー
ありがとうございました

582 = :

>>579
オールスターって何？
単に一番単純な書き方が一番安全にするという話だけど
安全側に倒しておくだけ

583 = :

>>578-579

584 = :

http://dictionary.goo.ne.jp/word/en/all-star/

((限定的)) (ある地域・リーグの中から選抜された)一流選手をそろえた，オールスターの
((限定的)) スター総出演の，人気俳優をそろえた
━━ [名詞] 〔スポーツ〕 ((通例 all-stars)) オールスターチームに選ばれた選手.

やっぱり意味が分からん。何をそろえたの？

585 = :

>>578-579

586 = :

なんだあらしか

587 = :

ネットの記事で、jQueryやlodashの機能は今では標準のJSに取り込まれているので
使う必要がないという記述を見ました
そうなのでしょうか？
自分はそこそこは取り込まれているものの、
やはり今でも使った方がいいように思います

588 = :

取り込まれているのが本当なら、
jQueryやlodash使っていれば、これからも使えるってことだよ
だって標準で取り込まれたんだからｗ

589 = :

必要だと思った奴だけ使えばいい
必要かどうか自分で判断できないと開発はやっていけない

590 = :

なるべくライブラリを使わない方針にしても
生JSがカバーしてない部分が出てくる
→その部分はライブラリを使う
→全面的にライブラリの作法に則った方が全体として綺麗になる
ってなりがちですよね

591 = :

なりがちじゃないかもしれませんね

592 = :

自分のブログ内の記事タイトルをランダムに表示させるスクリプトを作成することは可能でしょうか？
下記サイトのようにボタンをクリックするとランダムで過去記事のタイトルリンクが表示されるというものです
http://www9.plala.or.jp/oyoyon/html/script/randomlink.html

ツールを埋め込めば簡単なのですが、ページが重くなってしまうのでできればJavascriptやphpなどで対応できたらと考えてます
よろしくお願いします

593 = :

可能です。
お礼は三行

594 = :

できますん

595 = :

>>587
lodashはおいといて、jQueryで言うとその互換性担保の役割と
仮想DOM的な役割は終わりつつあるのは確かだと思う

jQueryって、荒れた凸凹の溶岩の上でも耐えられるオリハルコンの仮設住居を置いて
強制的にその中で作業させるくような感じだからね
でも今からは地面の荒れもだいぶ収まってきて気が利いた砂利くらいが引いてあるようになったから
いきなり仮設ドーンじゃなくて、舗装から少しずつ構築していって
必要十分な建物を作っていく方が良いんじゃないかって感じなのよ

596 = :

>>592
javascriptにできないことはない
史上最強の言語

597 = :

jQueryに「仮想DOM的な役割」(ﾌﾟｷﾞｬｰﾊﾗｲﾃｰwww)などない。徹頭徹尾生DOMをイジるためのライブラリだ。

598 :

>>593
>>594
>>596
ありがとうございます
トライしてみます

599 = :

オリハルコンとかゲーム脳が過ぎるんじゃないかね

600 = :

たしかにjQueryの互換性を吸収する役割はかなり小さくなったと思います
でもquerySelectorがあっても
removeClassみたいなのはないのでは？
複雑な処理ではありませんが、わざわざ自分で書きたくはありません