私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.132 +

みんなの評価 :
レスフィルター : (試験中)
533を読んでみたけど
難解な処理を書かない、読んですぐ意図がわかるコードを書く、
遠くで宣言された変数の代入・再利用などわかりづらいことをしない、
そうすればバグが目に見えて減ると思う、
と、こういう主張だった
全然違くね?使ってる単語が似てるっぽいURLを後付で見つけてきただけじゃね?
難解な処理を書かない、読んですぐ意図がわかるコードを書く、
遠くで宣言された変数の代入・再利用などわかりづらいことをしない、
そうすればバグが目に見えて減ると思う、
と、こういう主張だった
全然違くね?使ってる単語が似てるっぽいURLを後付で見つけてきただけじゃね?
>>552
いや、あってるよ?
だから俺は疑問なんだ。
>>519がなんで固有とか列挙可で変なバグを出すのか?
ライブオブジェクトで変なバグを出すのか?
俺はここ数年(十年超えるかもね)そんなことでバグを出したことはない
かと言って、ぜったいにバグを見逃ししないぞと気を張って作業してるわけじゃない
俺のコーディングスタイルは最小のコード記述量で書くこと
書く量が少なければそこに入るバグも最小になる
もちろん難解な処理なんてないし、意図が変わるコード
遠くで宣言する変数とか再代入もしない、まさにそのサイトで主張している通り
それで俺はそんなバグなんか起きてないのに、
>>519がそんなことでバグでハマるのはそもそもの書き方に
問題が有るんじゃないかってこと。
おそらく些細なバグが起きないように、毎回対策のためのコードを書いてるのが原因じゃないか?
俺は些細なバグが起きないように、コードを書かない状態で対策されてる状態にしている。
いや、あってるよ?
だから俺は疑問なんだ。
>>519がなんで固有とか列挙可で変なバグを出すのか?
ライブオブジェクトで変なバグを出すのか?
俺はここ数年(十年超えるかもね)そんなことでバグを出したことはない
かと言って、ぜったいにバグを見逃ししないぞと気を張って作業してるわけじゃない
俺のコーディングスタイルは最小のコード記述量で書くこと
書く量が少なければそこに入るバグも最小になる
もちろん難解な処理なんてないし、意図が変わるコード
遠くで宣言する変数とか再代入もしない、まさにそのサイトで主張している通り
それで俺はそんなバグなんか起きてないのに、
>>519がそんなことでバグでハマるのはそもそもの書き方に
問題が有るんじゃないかってこと。
おそらく些細なバグが起きないように、毎回対策のためのコードを書いてるのが原因じゃないか?
俺は些細なバグが起きないように、コードを書かない状態で対策されてる状態にしている。
>>557
タイプ数って勘違いしたのかw
面倒くさいな
そりゃ横に長い行を短くするのに一時変数に入れたりはするよ
そういうことじゃなくて、実行行と言ったら良いか?
定義行(代入行)ではなく処理の数を減らすんだよ。
と言ったら関数の先まで数えて同じとか言いそうだなw
コードというのは汎用的な処理とビジネス固有の処理に分けることができる
コード全体から汎用的な処理を切り離すことで、ビジネス固有の処理を減らすんだよ
汎用的な処理っていうのは、他で十分テストされ、例えば他のプロジェクトとかでも使われ
仕様が大きく変化することも、互換性が壊れる形で変化したりもしない、安定しているコード
だから基本読み飛ばすことができる。
読み飛ばせる部分を多くして、ビジネス固有の処理をへらす。これがバグをでなくするための方法
>>519はそういう所を毎回書いてるからバグだしてるんじゃねーのって話
タイプ数って勘違いしたのかw
面倒くさいな
そりゃ横に長い行を短くするのに一時変数に入れたりはするよ
そういうことじゃなくて、実行行と言ったら良いか?
定義行(代入行)ではなく処理の数を減らすんだよ。
と言ったら関数の先まで数えて同じとか言いそうだなw
コードというのは汎用的な処理とビジネス固有の処理に分けることができる
コード全体から汎用的な処理を切り離すことで、ビジネス固有の処理を減らすんだよ
汎用的な処理っていうのは、他で十分テストされ、例えば他のプロジェクトとかでも使われ
仕様が大きく変化することも、互換性が壊れる形で変化したりもしない、安定しているコード
だから基本読み飛ばすことができる。
読み飛ばせる部分を多くして、ビジネス固有の処理をへらす。これがバグをでなくするための方法
>>519はそういう所を毎回書いてるからバグだしてるんじゃねーのって話
書けば書くほどボロが出る
その口でこうすればバグが最小になると言う
その口でこうすればバグが最小になると言う
ライブなコレクションってgetElementsByClassName()の戻り値とかでしょ
ループに使うのがforでもfor inでもかかわりなく
ループの最初で別の変数に移して参照を持っておかないと
処理中に対象要素がなくなったら問題が出る
そういうもんじゃないの?
ループに使うのがforでもfor inでもかかわりなく
ループの最初で別の変数に移して参照を持っておかないと
処理中に対象要素がなくなったら問題が出る
そういうもんじゃないの?
仮に「最小のコード記述量=バグが最小になる」が
「コード分離して使い回せば記述量が減る」という意図だったとして
コードを分離できる状況かどうかや抽象性の設定などの問題もおいておくとして
しかしそれでもコード分離の話は>>537のURLには出てきていないな
「コード分離して使い回せば記述量が減る」という意図だったとして
コードを分離できる状況かどうかや抽象性の設定などの問題もおいておくとして
しかしそれでもコード分離の話は>>537のURLには出てきていないな
>>537のURLの趣旨はまとめるとこういうこと
「(速度やリソース消費など難が多少あっても)やりたいことをストレートに書けばバグが出ない」
富豪的プログラミングへの言及や神経を使うポインタを避ける
どの辺が「まさにそのサイトで主張している通り」なんですか
「(速度やリソース消費など難が多少あっても)やりたいことをストレートに書けばバグが出ない」
富豪的プログラミングへの言及や神経を使うポインタを避ける
どの辺が「まさにそのサイトで主張している通り」なんですか
>>565
> ライブなコレクション使うときはあれをしてはいけないこれを書いてはダメ
> などと神経使わなきゃいけないのは使いづらい
> そういう意味では>>537のURLの人が言ってることと同じだと思うんだけど
そういうこと。
神経を使わずに適切なコードが書ける状態になってないのが問題という話
コード書く時に神経使っちゃダメだよ?レビューする方も神経使うだろ?
あれこれ考えて抜けがないよな?抜けがないよな?と何度も確認しなきゃ安心できないコードよりも、
ひと目見ただけで、このコードにバグはないと言い切れるコード、
逆にどうやればこのコードにバグを入れられるんだよ?みたいな方が良いに決まってるだろ?
> ライブなコレクション使うときはあれをしてはいけないこれを書いてはダメ
> などと神経使わなきゃいけないのは使いづらい
> そういう意味では>>537のURLの人が言ってることと同じだと思うんだけど
そういうこと。
神経を使わずに適切なコードが書ける状態になってないのが問題という話
コード書く時に神経使っちゃダメだよ?レビューする方も神経使うだろ?
あれこれ考えて抜けがないよな?抜けがないよな?と何度も確認しなきゃ安心できないコードよりも、
ひと目見ただけで、このコードにバグはないと言い切れるコード、
逆にどうやればこのコードにバグを入れられるんだよ?みたいな方が良いに決まってるだろ?
ライブコレクションでハマるパターンは以下のようなもの
1. ある条件の要素のコレクションを取得
2. 全要素をループ
3. 条件1に該当するものは、要素に対して処理を行う
4. 条件2に該当するものは、要素を削除する
5. 削除によって「全要素」の内容が変わってしまう
6. 2に戻る(「全要素」の中身が代わってしまってるのでバグになる)
これは以下のように書けば良い
1. ある条件の要素のコレクションを取得
2. 条件1に該当するものだけをフィルタして処理をする
3. 条件2に該当するものだけをフィルタして削除
シンプルになってバグではまることもない
1. ある条件の要素のコレクションを取得
2. 全要素をループ
3. 条件1に該当するものは、要素に対して処理を行う
4. 条件2に該当するものは、要素を削除する
5. 削除によって「全要素」の内容が変わってしまう
6. 2に戻る(「全要素」の中身が代わってしまってるのでバグになる)
これは以下のように書けば良い
1. ある条件の要素のコレクションを取得
2. 条件1に該当するものだけをフィルタして処理をする
3. 条件2に該当するものだけをフィルタして削除
シンプルになってバグではまることもない
>>575
君の話は、前提として
・順番を逆にすることができる
・各々の処理が相互に関係しない
という処理である場合のみ利用可能すなわち汎用性に乏しいのでは
静的な配列にしてしまえばまず問題がない
答えられるかというのは何をだ
君の話は、前提として
・順番を逆にすることができる
・各々の処理が相互に関係しない
という処理である場合のみ利用可能すなわち汎用性に乏しいのでは
静的な配列にしてしまえばまず問題がない
答えられるかというのは何をだ
>>576
> 静的な配列にしてしまえばまず問題がない
ではそこが問題だな。
"毎回" 静的な配列になるようになっていないのが問題
静的な配列にするのが "追加作業" になっているならば
それを追加作業ではなく、標準(一番楽な書き方)で
そうなるようにしておくのが正しい
追加作業だとどうしても手抜きで見逃してしまう
ましてや追加作業が必要な場合がレアケースだと絶対にハマる
> 静的な配列にしてしまえばまず問題がない
ではそこが問題だな。
"毎回" 静的な配列になるようになっていないのが問題
静的な配列にするのが "追加作業" になっているならば
それを追加作業ではなく、標準(一番楽な書き方)で
そうなるようにしておくのが正しい
追加作業だとどうしても手抜きで見逃してしまう
ましてや追加作業が必要な場合がレアケースだと絶対にハマる
>>578-579
http://dictionary.goo.ne.jp/word/en/all-star/
((限定的)) (ある地域・リーグの中から選抜された)一流選手をそろえた,オールスターの
((限定的)) スター総出演の,人気俳優をそろえた
━━ [名詞] 〔スポーツ〕 ((通例 all-stars)) オールスターチームに選ばれた選手.
やっぱり意味が分からん。何をそろえたの?
((限定的)) (ある地域・リーグの中から選抜された)一流選手をそろえた,オールスターの
((限定的)) スター総出演の,人気俳優をそろえた
━━ [名詞] 〔スポーツ〕 ((通例 all-stars)) オールスターチームに選ばれた選手.
やっぱり意味が分からん。何をそろえたの?
>>578-579
ネットの記事で、jQueryやlodashの機能は今では標準のJSに取り込まれているので
使う必要がないという記述を見ました
そうなのでしょうか?
自分はそこそこは取り込まれているものの、
やはり今でも使った方がいいように思います
使う必要がないという記述を見ました
そうなのでしょうか?
自分はそこそこは取り込まれているものの、
やはり今でも使った方がいいように思います
取り込まれているのが本当なら、
jQueryやlodash使っていれば、これからも使えるってことだよ
だって標準で取り込まれたんだからw
jQueryやlodash使っていれば、これからも使えるってことだよ
だって標準で取り込まれたんだからw
必要だと思った奴だけ使えばいい
必要かどうか自分で判断できないと開発はやっていけない
必要かどうか自分で判断できないと開発はやっていけない
なるべくライブラリを使わない方針にしても
生JSがカバーしてない部分が出てくる
→その部分はライブラリを使う
→全面的にライブラリの作法に則った方が全体として綺麗になる
ってなりがちですよね
生JSがカバーしてない部分が出てくる
→その部分はライブラリを使う
→全面的にライブラリの作法に則った方が全体として綺麗になる
ってなりがちですよね
自分のブログ内の記事タイトルをランダムに表示させるスクリプトを作成することは可能でしょうか?
下記サイトのようにボタンをクリックするとランダムで過去記事のタイトルリンクが表示されるというものです
http://www9.plala.or.jp/oyoyon/html/script/randomlink.html
ツールを埋め込めば簡単なのですが、ページが重くなってしまうのでできればJavascriptやphpなどで対応できたらと考えてます
よろしくお願いします
下記サイトのようにボタンをクリックするとランダムで過去記事のタイトルリンクが表示されるというものです
http://www9.plala.or.jp/oyoyon/html/script/randomlink.html
ツールを埋め込めば簡単なのですが、ページが重くなってしまうのでできればJavascriptやphpなどで対応できたらと考えてます
よろしくお願いします
>>587
lodashはおいといて、jQueryで言うとその互換性担保の役割と
仮想DOM的な役割は終わりつつあるのは確かだと思う
jQueryって、荒れた凸凹の溶岩の上でも耐えられるオリハルコンの仮設住居を置いて
強制的にその中で作業させるくような感じだからね
でも今からは地面の荒れもだいぶ収まってきて気が利いた砂利くらいが引いてあるようになったから
いきなり仮設ドーンじゃなくて、舗装から少しずつ構築していって
必要十分な建物を作っていく方が良いんじゃないかって感じなのよ
lodashはおいといて、jQueryで言うとその互換性担保の役割と
仮想DOM的な役割は終わりつつあるのは確かだと思う
jQueryって、荒れた凸凹の溶岩の上でも耐えられるオリハルコンの仮設住居を置いて
強制的にその中で作業させるくような感じだからね
でも今からは地面の荒れもだいぶ収まってきて気が利いた砂利くらいが引いてあるようになったから
いきなり仮設ドーンじゃなくて、舗装から少しずつ構築していって
必要十分な建物を作っていく方が良いんじゃないかって感じなのよ
jQueryに「仮想DOM的な役割」(プギャーハライテーwww)などない。徹頭徹尾生DOMをイジるためのライブラリだ。
たしかにjQueryの互換性を吸収する役割はかなり小さくなったと思います
でもquerySelectorがあっても
removeClassみたいなのはないのでは?
複雑な処理ではありませんが、わざわざ自分で書きたくはありません
でもquerySelectorがあっても
removeClassみたいなのはないのでは?
複雑な処理ではありませんが、わざわざ自分で書きたくはありません



類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.102 + (1001) - [97%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
トップメニューへ / →のくす牧場書庫について