>>848
> わかってるけど、コードをそのまま読むと変数を再宣言しているように見えてしまうんだよ

じゃあこれだと、j やrowsを再宣言しているようにみえるわけ？
同じ理屈で言えば、var iのループをぐるぐる繰り返すたびに、再宣言しているよう見えるはずだよね？

　function setColSpan (tableSection /* [... tableSection] */) {
　　for (var i = 0, l = arguments.length; i < l; ++i) {
　　　for (var j = 0, rows = arguments[i].rows, m = rows.length; j < m; ++j) {
　　　　for (var k = 0, cells = rows[j].cells, n = cells.length, cell, textContent, colSpan, nextCell; k < n; ++k) {

>>849
へーじゃぁforブロック抜けたあとでもcellとか参照できるんだーへー

お前もプログラム学び直せペテン師

>>849
何度もすまないね、ありがとう
そこは理解してるんだけど、コードを直感的に読んだときのイメージと仕様が折り合いつかなくてもやもやしてる感じ
hoistingを嫌って関数の先頭で全ての変数を宣言するスタイルと似てる

>>852
> へーじゃぁforブロック抜けたあとでもcellとか参照できるんだーへー

そのとおりだよ。
わざとなのかな？ｗ

>>852
全部varじゃなくてletって書いてあると考えればいいだけだよ。
意図的に巻き上げを使用したいことなんて無いだろ？

互換性を無視すりゃvarなんてあえて使う理由はないんだからどうせ将来はそうなる。
ブロックスコープというのがあって、ブロックで宣言したものはブロックだけで使えます。
変数の巻き上げなんて機能はありません。それで動くなんておかしいのです。
そう考えて書いていれば、もやもやすることはないよｗ

>>851
ごめん、>>853は忘れて
for文の第1式も再宣言しているように見えるといえば確かにそう
ただ、実際にはブロックスコープを期待している自分がいるのでそこだけ特別扱いしてる

>>856
全部、letだと思えば単純で簡単だよｗ
特別扱いすることも何もない。

>>857
そうだねえ
let脳になりきれてないのはある
パフォーマンス問題とブラウザの実装が追いつけば今すぐにでも使うんだけど

ただ、varとletは別物なので同じものと認識してコードを書くことはないかな
varを使わなくて書けるならそれは幸せなことだけどね

letが登場する前からvarをletのように使ってきたがなんの問題もないよ。
変数の巻き上げというのが有るということを知っていればOK。
あとは、var = バグありlet ぐらいの感覚で十分だと思うけどな。

まあ、googleだっけ？のコーディング規約は、
関数の頭で全部かけだけどさｗ

ついでに言うと、for文ではなくて、JSのeach()メソッドやjQueryなんかを使ってると、
クロージャー（関数）を引数に渡すので、ブロックのような使い方をしても
実は関数スコープができるので、頭にvarを集めるのも自然に行える。

で、話を戻すと>>790はなんでこんなコードを書いたのか理解できない

　function setColSpan (tableSection /* [... tableSection] */) {
　　for (var i = 0, l = arguments.length; i < l; ++i) {
　　　for (var j = 0, rows = arguments[i].rows, m = rows.length; j < m; ++j) {
　　　　for (var k = 0, cells = rows[j].cells, n = cells.length, cell, textContent, colSpan, nextCell; k < n; ++k) {
　　　　　cell = cells[k];
　　　　　textContent = cell.textContent;
　　　　　colSpan = cell.colSpan;

変数の巻き上げを、実際の動きに通りに合わせるならば、こう↓書くべきだろう。（やはり変数多すぎｗ）

　function setColSpan (tableSection /* [... tableSection] */) {
　　var i, l, j, rows, m, k, cells, n, cell, textContent, colSpan, nextCell;
　　for (i = 0, l = arguments.length; i < l; ++i) {
　　　for (j = 0, rows = arguments[i].rows, m = rows.length; j < m; ++j) {
　　　　for (k = 0, cells = rows[j].cells, n = cells.length; k < n; ++k) {
　　　　　cell = cells[k];
　　　　　textContent = cell.textContent;
　　　　　colSpan = cell.colSpan;


逆に、合わせないならばこれ↓でいいはず。

　function setColSpan (tableSection /* [... tableSection] */) {
　　for (var i = 0, l = arguments.length; i < l; ++i) {
　　　for (var j = 0, rows = arguments[i].rows, m = rows.length; j < m; ++j) {
　　　　for (var k = 0, cells = rows[j].cells, n = cells.length; k < n; ++k) {
　　　　　var cell = cells[k];
　　　　　var textContent = cell.textContent;
　　　　　var colSpan = cell.colSpan;

>>849
仕事でもWebやってる俺、これ知らなかったよ…マジかと思ってやったらマジだった
ブロック内で宣言したものはブロック内でのみ有効とばかりに考えてたわ
Javascriptはほんと変態だぜ

>>861
多分、僕と同じようにfor文だけ特別扱いしたんじゃないかな

>>860
なかなか大味な解釈だねえ
僕は全ての機能を使用を読みこなして理解するタイプだからvarとletは別機能と考えるよ
それぞれの機能にあったコーディングがあってしかるべきだと思っているからね
今回は仕様に自分を最適化できなくて自分のイメージが先行しちゃったわけだけど

コーディング規約は自分の感性と機能がいかに一致するかが大切
自分にあったコーディング規約をそれぞれが選択すればいいと思うよ

> ついでに言うと、for文ではなくて、JSのeach()メソッドやjQueryなんかを使ってると、
関数スコープを使うとGCの管理が面倒になるんだよね
その点、letやconstはGCの動きを考えなくていいので楽
いずれにしても好みの範疇だけど

最後に一言だけ
他人のコードレビューする時には否定だけで終わってほしくないな
否定の後に対案が出てくるなら良いし、相手の意見を尊重して自分の意見をいえるなら更に良い
逆にいえば、自分の正当性を主張することに拘って他人の意見を塗りつぶす物言いが良くないんだけどね
この辺りを意識すれば、もう少し平和的に物事を解決できるんじゃないかなーと思う

否定も何も、俺のコードは書いたじゃん。

修正結果。ちなみにオリジナルのコードは俺じゃないよ。
http://jsfiddle.net/eoxzjqwu/36/

> 関数スコープを使うとGCの管理が面倒になるんだよね
面倒になったこと無いけどな。
長ければ別関数にする。という普遍的なルール程度で十分。

>>864
> なかなか大味な解釈だねえ

そんなに大味かねぇ。少し考えてみたけど、
世の中には変数を宣言しないで使える言語がある。（strictモードじゃないperlとか）
関数の最初の方でしか宣言できない言語も有る。（古いC言語とか）

というのを知ってると、古いC言語で関数内で使用する変数全てを宣言して、
宣言したことを忘れた気持ちになったら、関数内でどこでも自由に変数が使えるのと同じになる。

JavaScriptでvarで宣言するのも、それと同じようなもので、どこで宣言しても関数の最初で全部宣言したのと同じ。
それは古いC言語やstrictモードじゃないPerlなんかと何ら変わらなくて、それでもやっていけてたんだし。

もちろん関数が長くなったら、わけわからんことになるかもしれんけど、
どうせ俺、そもそもそんな長い関数なんて作らないし。

それでもブロックスコープ風に使うのは、関数が長いときにスコープを小さくしておきたいというよりも、
関数が長くなった時に抜き出しやすいように、変数を使っている場所を明確にしたいからだな。
だからブロックの外からアクセスできるかどうかは関係なく、そのブロックの範囲でしか
使いませんということをわかりやすくするためにそうしてる。抜き出したい部分が塊になってないと
影響範囲がどこにあるのかわかりにくくなるからね。

俺は基本的に、そうする意味があると思った場合にはそうするが、意味が無いことにはこだわらない。
varとletの機能が違うからって、別々の使い方をする意味って無いじゃん。（ブラウザの対応問題は除く）
ブロックの中で宣言した変数を、ブロックの外で使いたいなんてこと無いんだしさ、
varをブロックの中でしか使えないもの（使えるのはバグ）だと思っていても問題ないでしょ？

imgフォルダの画像を並べて表示することってできますか？

>>866
僕がいってるのは「価値観の押しつけ」だよ
「おまえは間違ってる」感が強く出ている否定からは後ろ向きな考えしか生まれない
たとえば、「パフォーマンスよりも可読性が大切」と指摘するのが価値観の押し付け
酷いのになるとこうなる
「可読性は低くない→どう見ても変数多すぎ→おまえはこの程度も読めないの？」
これは可読性に対する指標が違うのが問題
それぞれが異なる指標を持っているから合意に至ることは決してない
だから、お互いの意見を交換したら終わりにするべきなの

>>790も一つの完成形だと僕は思うよ
全体とした見ると一筆書きのように走査していることが分かる
関数を小分けにしてもいいと思うけど、そこはポリシーの違いだろうね

ボタンクリックで関数を発火させた後、関数が実行され続けてしまいます。

$('input[type=button]').click(function() {
$('textarea').overlay([
{
match: /<.+?>/g,
css: {
'background-color': '#fcc'
}
}
]);
});

関数が実行され続けると(1文字入力するごとに正規表現をサーチするため)textarea入力中、重すぎるのです。
以下みたいな感じで、textareaクリックなどで実行され続けている関数を無効化したいんですが、うまくいきません(overlay is not definedになります)。

$('textarea').unbind('click', overlay);

要するにボタンクリックした時に1回だけoverlayを実行したいです。
overlayはhttp://qiita.com/yuku_t/items/516ec6fe59b77b93edc5 です。

答えはdestroyでした。
問題はdestroyするとtextareaのフォーカスを失います。

>>869
できる

>>870
価値観の押し付けじゃないよｗ

価値観の問題であれば、変数がこれだけある理由を
理由をちゃんと説明できるはず。
for文の行でvarしている理由だって、
「俺はこう思ってるから、ここで書いてるんだ」って言えるはず。

だから価値観の問題だって言うならば理由を言うべきだし、
言わないならば、価値観の問題じゃなかったってことになる。

>>870
> 全体とした見ると一筆書きのように走査していることが分かる
俺の最終形態のコード見た？

あれを一筆書きのように書き換えることだって出来るはず。
クロージャーを使ったコードを使わずに書くなんて簡単なんだら頭の中でやれるでしょ？
その時>>790みたいにcolspanとrowspanで別々の処理になってしまうかい？

「一筆書き」っていうのが具体的にどんなのか、完全にはわからんけどさ、
俺だったら「一筆書き」のルールでパフォーマンスも落とさずにもっとシンプルに書けるよ。

あと関数を小分けっていうのがよくわからない。俺のコード関数を小分けにしてないよね？どれのこと？
オリジナルではfunctionという単語は4つ。即時関数は例外としても3つ。
俺のコードも同じく4つ。そのうちは3つはeachを使ったクロージャーだからやろうと思えば
forに書き直せる。実質的な関数としては1つなんだが。

>>871
やってみたけど、重くなかったｗ

一文字入力するごとに正規表現サーチしてるなっていうのは
わかったんだけど重くないｗｗｗ

まあ、どうやればいいかは、jQueryプラグインの仕様なので
このスレの対象外だけどね。

>>874
「変数が多い」「変数が少ない」は主観的な感覚であって特別な理由がないという事
「これぐらい変数が多くても自分は問題なく読める(可読性が低くない)」というような感覚の違いね

>>875
君のコードと>>790のコードでは設計概念が全く違うわけで同じ設計で比較しないと一概に比較できないと思うんだけどね
「シンプル」も主観的な感覚だと思う
あえていうなら「シンプル」の定義で合意がとれないと議論にならないよね

> あと関数を小分けっていうのがよくわからない。
>>790のコードは一つの関数に処理を詰込みんでいるから変数が多い
小さな処理の単位に小分けすれば各関数の変数量が抑えられるって事

JavaScriptで書き出されてる要素内の属性を、別のスクリプトで削除する事はできますか？

>>879
できます

>>790と>>827のコードをベンチマークしてみたが、かなりの違いがあった
827がどう修正してくるか、楽しみだな
http://jsfiddle.net/eoxzjqwu/39/

DOM: 3801.931ms
DOM: 3056.431ms
DOM: 3045.302ms
DOM: 4044.294ms
DOM: 3092.358ms
jQuery: 15108.137ms
jQuery: 12758.646ms
jQuery: 11623.559ms
jQuery: 11727.616ms
jQuery: 11775.618ms

>>790が追及するのは「アルゴリズムの美しさ > コードの短さ」
>>732が追及するのは「コードの短さ > アルゴリズム上の無駄」
相反する価値観だから議論する余地はないんじゃない？
シンプル云々も>>790は自分のコードを複雑だとは感じてない気がする

全ブラウザで動作する前提なら >>790
自分で組んで適当に使うなら >>827 よりめんどくさい書き方になるであろう自分のコード

colspan,rowspan属性が存在するセルも正しく結合できるように修正した。
(せっかくなので、>>881のベンチマークコードを借用した。)
http://jsfiddle.net/eoxzjqwu/40/

出来ればHTMLCollectionのまま扱いたかったが、いろいろ面倒になって配列に変換してしまった。
それでも、想定したよりは遅くならなかったのが救いか。

>>884
setRowSpanの処理がおかしい気がする
--kを忘れてない？

>>885
仰る通りなので修正した。ありがとう。
http://jsfiddle.net/eoxzjqwu/41/

警告：応答のないスクリプト
by Firefox

>>887
loop回数が多くて固まっているだけ
しばらく待てばベンチマーク結果が出る

loop回数を半分(5000回)にしてボタンを押すまでベンチマーク処理が働かないようにしてみた
http://jsfiddle.net/eoxzjqwu/42/

>>877
> 「変数が多い」「変数が少ない」は主観的な感覚であって特別な理由がないという事

いや、事実として変数が減ってるやん？ だからこれは変数が多いであってるでしょ。
変数が多くても読めるとかいう話じゃなくてさ（実際俺は読んでから書き直したわけで）
その変数を作る理由が欲しいんだよ。

>>878
> 「シンプル」も主観的な感覚だと思う
俺の「シンプル」の定義は、

1. コードメトリクスを測定した時の成績が良い（例えば複雑度が低い）
2. 汎用性がない知識を、覚える必要が少ない。
3. 読む量が少ない。
（2は3とも関連していて、覚えてないもの＝読まなければいけないもの

これは誰でも同意すると思うんだけど、反論する人っているの？

> >>790のコードは一つの関数に処理を詰込みんでいるから変数が多い
> 小さな処理の単位に小分けすれば各関数の変数量が抑えられるって事
俺も一つの関数に処理を詰め込んでいながら、変数を少なくしたんだけど・・・。
俺のコードとの比較じゃなくて一般論って話ね。

念の為に言っておくと、俺はむやみに小さな処理の単位に小分けするとは言っていない。
小さくすることで可読性が悪くなることも有るからだ。特に項目が多いフォームの
バリデーションなんかはある程度長くても許容する。

関数が長くなったらもちろん分けようと考えるが、そのときに「役割」をきっちり定義してから分けるよ。
その役割が定義できいないならば分けることはない。

おう、書きかけで送信してしまった。
一部補足

1. コードメトリクスを測定した時の成績が良い（例えば複雑度が低い）
2. 汎用性がない知識を、覚える必要が少ない。
3. 読む量が少ない。

（2は3とも関連していて、覚えてないもの＝読まなければいけないものだから
可読性という意味で、覚えていないもの、覚えられないものが多いほど可読性は下がる。
汎用のライブラリを使うと、コードの中をまず読むことはないし、
覚えてしまえば、他のプロジェクトでも応用できるから、勉強することで読む量が少なくなる）

ということは、勉強しなければ読む量が減らないじゃないか？ 俺は面倒だから勉強したくない。
それよりも記憶できないコードを読む面倒さの方を俺は取るっていう
勉強したくない人間が世の中にいるってのは知ってるけどねｗ

>>881

> >>790と>>827のコードをベンチマークしてみたが、かなりの違いがあった
> 827がどう修正してくるか、楽しみだな

修正するかどうかは、ユースケースによる。

DOMとjQueryの差は1万回やって
・DOM: 3056.431ms
・jQuery: 15108.137ms

だ。

ということは、1回しか行わないならば
・DOM 約 0.31ms
・jQuery 約 15.11ms
だね？

俺の今までの経験上、100ms（0.1秒）の差がなければ体感上の違いは感じられない。
（ゲームのようにリアルタイムに反応しないといけない場合はもう少し短くなるが）

なので現時点では修正をする理由が見当たらない。
修正するべきという理由がでたら考えるよ。

>>882
> >>790が追及するのは「アルゴリズムの美しさ > コードの短さ」

おい、ちょっとまてやｗ

>>790はrowspanとcolspanで共通化もされてない
アルゴリズム的にも美しくないコードだぞｗ

それから修正する理由はないと言ったが、
それはこの場合の答えであって、パフォーマンス修正してもいいぞｗ
パフォーマンスを向上させる意味がないから通常はしないが、
別にパフォーマンスを上げること自体は嫌いじゃないから。

ただあらかじめ言っておくが、理由を無視してひたすら速度を上げるなら
アルゴリズム自体は俺のコードをベースするするけど、jQueryは使わないからな？
あとでjQuery使わなかったとか文句言うなよ？ｗ
jQuery使わないほうが速度が早いのは当たり前。そこまで速度を追求するまでの
理由が通常は存在しないから、実行速度よりも開発速度を重視した方がいいと言ってるわけで。


それはそれとしてどれと比較すりゃいいんだ？
なんか>>884で勝手に仕様変わってるしさ。

と書いたけど、>>881をベースにして、自分のコードだけ修正することにした。
>>884は俺のコード削られてるようなので。

ちなみに俺のマシンでの実行結果。僅かに早いようだね。
ブラウザはChrome。

DOM: 2061.469ms

DOM: 2044.572ms
DOM: 2331.078ms
DOM: 2380.810ms

DOM: 3246.959ms
jQuery: 9557.937ms
jQuery: 9436.855ms
jQuery: 9571.858ms
jQuery: 9578.245ms

jQuery: 9241.849ms

画面が固まるのに対処してみた
removeをremoveChildに変更すればIE11以下でも動きそうだな(Polyfillを使え、って事なんだろうけど)
http://jsfiddle.net/eoxzjqwu/43/

まず作業前にベンチマークのコードを修正させてもらう。
http://jsfiddle.net/eoxzjqwu/44/

なぜならば、今回比較するべきものはcolspan、rowspanのコードであって
ベンチマークのためだけに必要なDOM要素のコピー部分を含める理由はないからだ。
その部分を共通化しても問題なかろう？

DOM: 2283.255ms
DOM: 2768.348ms
DOM: 2621.069ms
DOM: 2806.366ms
DOM: 2894.334ms
jQuery: 10201.228ms
jQuery: 9341.192ms
jQuery: 9381.657ms
jQuery: 9464.179ms
jQuery: 9021.445ms

あとお断り入れておく。今日仕事が遅くまであって
まだ晩飯食ってないんだよ。（明日も遅い可能性あり）
修正は明日とかそれ以降になるかもしれんから宜しく。

>>890
> いや、事実として変数が減ってるやん？ だからこれは変数が多いであってるでしょ。
それは「他の条件が全く同じ場合」に比較対象として成立する
彼はかなりパフォーマンスに気を遣うタイプのようだから彼の期待するパフォーマンスを持つコードで変数の量を減らさないと
Gmailクラスの大型アプリだとかなり変わってくるし、この程度のコード量で効率化できるなら十分に採用基準に入るって人もいるよ
「これぐらい変数が多くても自分は問題なく読める(可読性が低くない)」と本人は思ってるからね
790の「変数の数が多い」と感じるボーダーラインが君より高いって事だね
だから、790は「パフォーマンス」を優先できる

> 俺も一つの関数に処理を詰め込んでいながら、変数を少なくしたんだけど・・・。
君のコードは可変引数になってないし、コールバック関数を4つ使ってるよね
http://jsfiddle.net/eoxzjqwu/36/
790はsetColSpanでは関数単体で処理したし、setRowSpanでは一つの関数(removeElements)しか呼び出さなかった
関数スコープで分けないコードは必然的に変数量が増える
http://jsfiddle.net/eoxzjqwu/

結局、ポリシーの違いなんだから790にあれこれ文句言っても仕方ないって事なんだけど、これ以上説明しても「ポリシー」の意味が伝わりそうにないのでこの辺にするよ
もうレスしないだろうけど、悪しからず

まず内側のeachをfor文に置き換え。
http://jsfiddle.net/eoxzjqwu/45/

DOM: 2569.792ms
DOM: 2205.576ms
DOM: 2765.529ms

DOM: 2275.650ms
DOM: 2915.722ms
jQuery: 8101.830ms
jQuery: 8366.998ms
jQuery: 7318.446ms

jQuery: 8236.739ms

jQuery: 7623.998ms

本当はちゃんとどこにボトルネックが有るか調べたほうがいいんだが、
経験上クロージャー呼び出しは、jQueryのeachだけじゃなくてES6のeachも遅い。
だからループで使用する場合は、修正する点の一つになりやすい。