これからコードを書く人に絶対やって欲しいこと★3

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2013/06/04(火) 22:43:46.92
もしくはやって欲しくないこと
先輩方のアドバイスをください

前スレ
これからコードを書く人に絶対やって欲しいこと★2
http://kohada.2ch.net/test/read.cgi/prog/1365269189/
2013/06/09(日) 23:40:38.18
>>95
お前には一生分からない気がしてきたｗ
まともに設計出来ているソフトウエアでは、一部の複雑度が高いメソッドのみが
リファクタリング対象になって、低いメソッドはそのままでいい
なんて事は起こらんよ。
2013/06/09(日) 23:47:17.87
>>103
とりあえずお前の言ってる平均値っていうのは
（複雑度の合計÷個数）の値のことでいいんだな？
もし違うならぜひとも算出方法を教えてくれ
2013/06/09(日) 23:47:26.97
>>103
逆に言えば、まともに設計できてないソフトでは、
一部の複雑度が高いメソッドのみが リファクタリング対象になって、
低いメソッドはそのままでいい ってことが起きる。
2013/06/09(日) 23:48:08.12
指数値の平均を出すことに何の意味があるんだ？
2013/06/09(日) 23:53:27.54
あるモジュールにものすごく複雑な関数Aがある。（複雑度100）
目標は関数Aが含まれたモジュールの問題点を解決することとする。

そこで同じモジュールに複雑度1の関数Bを付け加える。
複雑度の平均は(100+1)÷2で50.5。

同じように複雑度1の関数を100個付け加える。
(100+100)÷101＝1.98

このモジュールの複雑度は1.98
さて関数Aはシンプルになったであろうか？

関数Aの複雑度だけを見ると、以前と変わらないので100のまま。
目標である問題点は解決されていない。

つまり、複雑度の平均値に意味は無い。

反論があるならどうぞ。
2013/06/10(月) 00:05:21.02
>>107
そんなことは現実には起こらないから安心しろ
2013/06/10(月) 00:11:30.50
>>103
ちょっと何を言ってるのかわからない。
2013/06/10(月) 00:22:09.24
>>109
要するに平均的に高いか低いかのどちらかしかない。
お前らが想定してるような、分布が広い結果は本当に設計が稚拙な場合には
あるかもしれんが、実際に見たことはないし、もしあったとしても全体的に再設計だな。
2013/06/10(月) 00:38:20.33
>>110
平均値が低いからといって問題が無いとは言えないというのがどうしてわからないのか。
2013/06/10(月) 00:39:12.63
ここで議論してるやつの大半は
複雑度が分かったところで、その後どうするか分かってない
2013/06/10(月) 00:41:50.47
平均とか言ってるやつは数学どころか算数もできない。だから分析方法で平均しか使えない。

そんな人間が計算する指標だから役に立たない。
2013/06/10(月) 00:45:52.21
大半って、3,4人しかいないでしょ
2013/06/10(月) 01:21:23.65
循環的複雑度の平均は意味が無い

なぜなら、問題点＝循環的複雑度が高いものを
探す（そして修正する）のが目的だから。

他に比べて高い問題点を探すというのに、
他に紛れ込ませてどうするよｗ
2013/06/10(月) 01:28:32.83
考えて見ればわかることだけどどんな人が作っても
すべての関数の複雑度が、同じように高いってことはありえない。

どんな人が書いても例えば文字列の長さを取得する関数が
複雑度20を超えるってことはないだろう。

問題ってのは、モジュールの中で一部の関数何個かが
極端に複雑度が高い。という形で発現する。
だから平均をとってはいけない。
意味が無いどころか問題点が埋もれる。
2013/06/10(月) 01:41:23.85
そもそも、もうそれ以上リファクタリングが全くできないという循環的複雑度の
高いメソッドが存在するってのがまれだろ。
2013/06/10(月) 01:51:53.41
なんか基本的な事がわかってない人がいる気がしてきた。

循環的複雑度が高い関数ってのは、
その中のコードを改善して直すってのもあるけど、
高すぎる関数の場合は関数を分割したり、一部の処理を外出しすることで
循環的複雑度が小さい複数の関数で実現するように修正するんだよ。
2013/06/10(月) 02:01:02.22
その辺にしておけよハゲども

よく理解していない道具を飛躍した解釈で使おうとするからそんな意味不明な議論になるんだ。
まずは、自分が書いたコードを全て自分でテスト書いて自動化してこい。
そうすればこんな議論にはならないから。
120仕様書無しさん
垢版 |
2013/06/10(月) 02:14:16.80
テストを自動化するってよく聞くけど、具体的にどうするの？
2013/06/10(月) 02:19:14.45
>>120
テストで手作業で確認している事をプログラムにして自動化するんだよ。
詳しくはググれ
2013/06/10(月) 02:20:03.91
>>120
おいおいそこから？
2013/06/10(月) 02:23:15.26
テストの簡単な解説サイトないですか？
2013/06/10(月) 02:25:12.45
テストでは入力に対して出力がどうなっているか確認する。
だからシンプルな関数はテストが簡単。
逆に複雑な関数ではテストが困難。

だから何よりも先に循環的複雑度を低く保てる技術力をつけていないといけない。
これが出来ずにテストを自動化しようと思っても
テスト自体の数が爆発的に増え、管理困難に陥る。

腐ったコードにテスト自動化を導入しようと思っても
それは困難な道でしか無い。
2013/06/10(月) 02:27:17.56
テストファーストで書いて複雑になるわけがない
2013/06/10(月) 02:29:12.44
まあ循環的複雑度が低いからといってテストしやすいとは限らないんだけどね。
2013/06/10(月) 02:29:30.86
だいたい、この手の話を理解できない奴っていうのはテストをする能力がないか、めんどくさがってテストをやってないんだよな。
自分のケツは自分で拭く様にすれば、自然と複雑さと副作用の少ない設計になるはずなんだが。
2013/06/10(月) 02:30:45.97
>>126
循環的複雑度が低いという事は、テストケースが少ない。
つまり、バグ発生率が低い。
2013/06/10(月) 02:31:33.48
循環的複雑度を初めて知ってはしゃいでるのか
2013/06/10(月) 02:34:41.85
>>129
単語だけ知って、なんとなくすごい事を知った気分になってるけど、よく理解してないんだろう。
いつの時代も新しい考えが生まれると、この手の困ったちゃんが大暴れするんだよな。
2013/06/10(月) 02:36:08.46
>>125
テストファーストで書いてれば・・・ね。
2013/06/10(月) 02:36:58.82
>>129
ん？誰にいってんの？
はしゃいでるだけの人ってどれよ？
2013/06/10(月) 02:40:41.72
ハイ、この話もうやめー

スレタイ読もうね

スレタイ！

スレタイ読もう！！！
2013/06/10(月) 02:43:44.05
3回も言わんでも
2013/06/10(月) 02:45:36.65
>>134
前スレの流れみるとしつこく言わないと延々続くからｗｗｗ
2013/06/10(月) 02:46:15.55
>>133
じゃあスレタイに則って言うぞ

循環的複雑度を下げろ(笑)
2013/06/10(月) 02:54:12.52
コードを書く人に絶対やってほしいことってのは
一つじゃない。たくさんある。

循環的複雑度を下げろっていうのは
その中の一つとして、正しいことなのに
妙に突っかかってくる人がいるんだよね。

なんでだろ？
自分の知らないことを言われたのが
悔しいとかなのかな？
2013/06/10(月) 02:58:22.10
オブジェクト指向を使えと言われて
極端に反論する奴と同じたぐいの人間だろうな。
2013/06/10(月) 03:02:18.15
>>137
平均値がーとか、例外的に循環的複雑度が高いメソッドがーとか頑張る奴がいるから
この話が終わらないんだよ。
2013/06/10(月) 03:13:13.79
>>124
アサートや例外も確認するし、出力というか挙動と言ったほうが良くね？
2013/06/10(月) 03:22:30.20
>>139
循環的複雑度の平均値を出すことに意味はない。

循環的複雑度の値の傾向としては、一部のメソッドが
ずば抜けて高くなることが多い。

で終わりじゃないか。
2013/06/10(月) 03:25:48.16
悪いプロジェクトでは循環的複雑度が
・低い・・・それなりの数がある
・中ぐらい・・・結構ある。
・高い・・・結構ある。
・ひどい・・・いくつかある。

良いプロジェクトでは
・低い・・・ほとんど
・中ぐらい・・・いくつかある。
・高い・・・無いか、まれにある程度。
・ひどい・・・全くない。


悪いプロジェクトでも、循環的複雑度が低い関数の数は
たくさんあるので平均を取ると少なくなってしまうので意味が無い。
143仕様書無しさん
垢版 |
2013/06/10(月) 03:52:10.59
循環的複雑度（英: Cyclomatic complexity）とは、ソフトウェア測定法の一種である。Thomas McCabe が開発したもので、プログラムの複雑度を測るのに使われる。
プログラムのソースコードから、線形的に独立した経路の数を直接数える。

循環的複雑度は、プログラムの制御フローをグラフとして描くことで計算される。グラフのノードはプログラムのコマンドに相当する。
2つのノードを結ぶ有向エッジは、第一のコマンドを実行後、次に第二のコマンドが実行される可能性があることを示している。

M = E - N + 2P
ここで
M = 循環的複雑度
E = グラフのエッジ数
N = グラフのノード数
P = 連結されたコンポーネントの数
2013/06/10(月) 03:52:19.80
>>142
s/悪いプロジェクトでは/循環的複雑度で判断可能な悪いプロジェクトの一例では

良いプロジェクトとよく似た循環的複雑度の分布を持つクソプロジェクトとかもあるから、
その文脈で提示する悪いプロジェクトの悪さの種類と一例であることは明示したほうが良いかと。
その文書だと「循環的複雑度が低ければOK」って言ってるようにみえるぞ。
2013/06/10(月) 03:52:58.04
ほう
2013/06/10(月) 03:54:54.08
無理やり下げようとすると「連結されたコンポーネントの数」を減らす方向に向かわなくてはならないが
個人情報のように分割すると管理しにくくなるだけのものはやっぱり残さないといけないよね。
2013/06/10(月) 03:55:15.96
>>144
> その文書だと「循環的複雑度が低ければOK」って言ってるようにみえるぞ。

そんなこと一言も言ってないし。
2013/06/10(月) 04:41:45.84
>>147
んなことは分かってるが、そう読めてしまうって事だよ。
>>55の下二行を見落とした>>58(56)とか居たわけだけど、>>142はそれ以上に誤解を招きやすいと思うが？
2013/06/10(月) 04:54:29.73
読解力無いんじゃね？
2013/06/10(月) 07:39:24.05
PNG仕様書読んでるが、心が折れそうです
そんな時は？
2013/06/10(月) 08:50:25.20
>>143
それwikiの丸々コピペじゃねえかｗ
2013/06/10(月) 09:00:57.23
>>150
GIFの仕様書を読んで気分転換
153仕様書無しさん
垢版 |
2013/06/10(月) 09:21:10.96
>>151
ああ、Wikipediaって入れるの忘れてた。

唐突に説明入れること自体に突込みが入るかと思ったけど入らなかったな。
「つかそれみんな知ってるから」みたいなの。
154仕様書無しさん
垢版 |
2013/06/10(月) 09:54:56.10
勉強すること自体を目的にしないで欲しい
別に具体的に何かを作る目標を持たなくても良いけど
勉強とアウトプットはセットで
今の自分の能力より少し難しい物を作ることにチャレンジしよう！
今作れるのが電卓や、トランプまででも全然恥ずかしくない
（最初からグランツーリスモを作れる人などいないし、
複雑なプログラムも実は単純な小さなプログラムの組み合わせだ）

綺麗なコードとか、デザインパターンとか吹聴する奴らは
本当に複雑なプログラムを作ることから逃げ出してる弱虫な
糞野郎なので勧誘に乗らないように！
彼らがぞれにはまるのは、自分の頭を使うことから逃げ出したいから
何かにすがりついてるだけで自信の無さの証明でしかない
ネットワークビジネスとかネズミ講みたいな物で、
それはあなたの才能をみるみる腐らせていく毒薬である

実は複雑なプログラムはアルゴリズムや、プログラム構造の設計手法を学んだだけでは
組むことが出来ない。
複雑なプログラムのロジックを頭の中で辻褄が合うように組み立てる事と
それを実際のプログラムコードに落とし込む訓練が必要なんだ
これは本を読んだだけでは絶対に身につかない
本ばかり読んでもオリンピック選手になる為には成れないように、
プログラムも実践によって、脳の特定の部位を訓練する必要がある
この訓練の差が、人によってコーディング速度に（誇張無しで）100倍の差が出る理由だ
2013/06/10(月) 10:32:09.12
もうやめようと思ったけど、いい例が出てるので書いておく

>>142
> 悪いプロジェクトでは循環的複雑度が
> ・低い・・・それなりの数がある
> ・中ぐらい・・・結構ある。
> ・高い・・・結構ある。
> ・ひどい・・・いくつかある。
>
> 良いプロジェクトでは
> ・低い・・・ほとんど
> ・中ぐらい・・・いくつかある。
> ・高い・・・無いか、まれにある程度。
> ・ひどい・・・全くない。

この悪いケースは、俺が平均的に高いと言ってるケース。
複雑度が高い、ひどい部分のみ抜きだして複雑度を下げようとしても
結果、小手先のテクニックで無理矢理分割するだけになるので、効果は薄いし、
最悪よけいに分かりにくいコードが出来あがる。
低い、中も含めて全体的に設計をみなおすべきケースだな。
きっと俺の言うことが理解出来ない連中は、ここの認識が違うんだろうけど、
何度も言うが、複雑度が高いメソッドを探して、そこだけどうこうしようとするのは無駄な努力。

良いケースでは複雑度が高く出ているものは、単純に並列の分岐数が多いなどの理由で
実際は複雑ではないから、テストが書きにくいという事もないし、リファクタリングも必要ない。
こういうケースでは高いメソッドを含めて平均値を出しても、ほとんどその影響は出ない。
2013/06/10(月) 11:20:01.04
は？
if分の分岐とかまさにリファクタリングの対象だろ。
2013/06/10(月) 11:26:05.80
>>155
お前は原因と結果が全部逆なんだよ。

良い設計なら、循環的複雑度が大抵低い。
テストが書きやすいメソッドは、大抵循環的複雑度が低い。
これは正しい。

だからといって、
循環的複雑度が低ければ良い設計であるとは言えず、
循環的複雑度が低ければテストが書きやすいとも言えない。
2013/06/10(月) 11:36:55.48
>>155
> 複雑度が高い、ひどい部分のみ抜きだして複雑度を下げようとしても
> 結果、小手先のテクニックで無理矢理分割するだけになるので、効果は薄いし、

なんで、「小手先のテクニックで無理矢理分割するだけになる」とか決めつけてるの？
「複雑度が高い、ひどい部分」を、正しいテクニックでリファクタリングすればいいでしょ。
2013/06/10(月) 12:08:46.96
>>157
お前のレスは明後日の方向ばかり向いていて、正直もう、どう反応していいか分からんｗ
2013/06/10(月) 12:42:00.39
このスレはけっこう大したことないな
言ってる割にメチャクチャ
2013/06/10(月) 12:46:29.54
>>159
そっくりそのままお返しします。
2013/06/10(月) 12:51:18.46
>>158
どうやらリファクタリングをいまだに小手先と言っちゃう輩が居るらしい
2013/06/10(月) 12:52:44.64
>>155
> 何度も言うが、複雑度が高いメソッドを探して、そこだけどうこうしようとするのは無駄な努力。
そこだけ改善すれば全ての問題が解決するかどうかはわからないが、まずそこの問題を解決することが
重要だよね。決して無駄な努力ではない。
2013/06/10(月) 12:55:10.01
>>155
> 単純に並列の分岐数が多い
のなら、そこをリファクタリングすればいいじゃない。
2013/06/10(月) 13:08:17.44
複雑なことをやろうとしたら、勝手に複雑度も高くならね？ｗ
2013/06/10(月) 13:12:39.79
>>128
テストケースの多寡じゃなくて、テストし易さの話をしてるんだけど。
2013/06/10(月) 13:14:32.65
そんな遠いアンカーに言われましても
2013/06/10(月) 13:42:07.26
まだ平均値とか言ってる馬鹿がいるのか
2013/06/10(月) 14:52:49.15
理牌（リーパイ）
2013/06/10(月) 20:49:18.81
うむ。今日は見方がたくさんで
俺がレスする必要がないなｗ
2013/06/10(月) 21:56:34.06
>>155みてて思ったのだけど、「平均」って単語を、数学的な意味での平均値としてじゃなく
「俺がこう感じたから平均的(?)にこうだ」っていう、間違った言葉の使い方をしているんじゃないかって気分になった

あと、重箱の隅だけどさ、
> 小手先テクニックで無理やり分割
具体例に紐づくような情報が少なくて、脳内想定が見えてこず、どういう作業を指しているのか読み取り辛い。
おそらく、リファクタリングでなんとか出来る状態じゃないコードが、大量に生み出されてしまったプロジェクトを想定し、
メソッド分割してもその場しのぎで意味が無い、って考えてるのではないかと推測してみているけれど、あってる？

でもそもそも、循環的複雑度やリファクタリング、ユニットテストの話は、全部火事の予防策であって、
炎上したり焼け焦げて残った失敗プロジェクトの、消化や立て直しを行うためのものではないよ。

> 全体的に設計をみなおすべきケースだな。
コードの循環的複雑度を調べるような段階で設計レベルの見直しは、現実的に不可能だと思う。
個人で開発してるならともかく、納期があるような仕事でやるのはコスト的に無理だろう。

もう既に>>157で簡潔にまとめてあるけれど、
設計が糞なのは、循環的複雑度が高いことで起きているのではなく、
メンバー全体のレベルが低かったりして、こういう基礎知識がなかった故に起こることだと思う。

そんな状況の中で循環的複雑度を測っても、もはやどうしようもないし、
本来の使い方ができない値の平均なんて出しても、特に意味はないと思う。
2013/06/10(月) 22:00:17.92
前の方にテストファーストの話がちらっとでてたけど、
テストファーストでコーディングするには、ある程度実装経験がないと難しいと思う。
どういう機能を実装していくかのある程度の目安がたってないと、テストが書けない。
だから、これからコードを書く人にいきなり要求するのは、結構きついんじゃないかなーと。

まぁ、それでもテストは実装後に、みたいなアホなことだけは極力やめてほしい。
この考えのままの人間が大量に居る業界だけど、これからコードを書く人は
そういう間違った手法を、引きずり続けないようにしてほしい。

メソッドを実装するときは、そのテストケースの実装も考えながら、進めてほしい。
173仕様書無しさん
垢版 |
2013/06/10(月) 22:11:24.46
俺、循環的複雑度とか使った事ないけど
平均とか意味がないと思う。

どれくらい平易に書かれているかということなので
複雑度×行数で工数が出てくるって事だろ。

だけどよくできているかどうかはバグがない、出にくいことと
性能試験で期待できる性能が出てるかどうかまで見ないといけないかな。
2013/06/10(月) 22:16:06.18
俺も循環的複雑度使った事が無いので今測定したら
平均６ほどだったが、３０以上が所々にあった
これはズルいなｗ
2013/06/10(月) 23:53:41.45
問題点を知るために、他とは特出して悪いコードを探すのが
循環的複雑度を図る目的なのに、
それを平均化して何がわかるというのか？
2013/06/10(月) 23:59:39.05
>>171
> メンバー全体のレベルが低かったりして、こういう基礎知識がなかった故に起こることだと思う。
>
> そんな状況の中で循環的複雑度を測っても、もはやどうしようもないし、
メンバー全体のレベルが低いからこそ、
第三者が考えた方法で計測するんだよ。

レベルが低い奴は、レベルが低いということすら自覚できない。
メンバー全員がそうなのに、どうやって悪いということを自覚するのさ？
自分らでは出来ないから、そういうメンバーにこそ
現実をつきつけなきゃいけない。

と言っても俺がつきつけることは出来ないからな。
循環的複雑度を計測するのは簡単だから、とりあえずやってみろと言うしか無い。
自分らのレベルが低いとか高いとかどうでもいい、とりあえずやってみて、その結果を受け入れろ。
2013/06/11(火) 00:13:41.42
自称できる奴の面白い所は
「周りがみんなバカで忙しい」
と言いながら、なんの改善案も提示出来ない所だな。

本当に忙しいなら環境を改善する。
改善出来ない理由は、自分でも何が悪いのかがよくわかっていない事と、自分が有能だと思いこみたいから。
2013/06/11(火) 00:16:24.35
他のスレでボロ出して赤っ恥かいてた循環的複雑度マンセーバカが消えたと思ったら
今度はこのスレで暴れてたのかｗ

たぶん噛み合ってないと思うから気づいてると思うけど
そいつ、まともに物作れないよ
開発経験も限りなく少ない
2013/06/11(火) 00:22:33.49
>>178
俺も見た記憶があるんだが、どのスレだっけ？

最近覚えた単語らしく、よく理解してないのに絶賛してたのが笑えたんだよな。
2013/06/11(火) 00:24:16.50
技術力が低い会社にありがちなこと
http://kohada.2ch.net/test/read.cgi/prog/1344190799/

自己解決した
2013/06/11(火) 00:50:17.29
>>178
君が循環的複雑度マンセーバーカだと思う人を
論破して見せたら？

現時点では、どう見ても、お前が負け犬にしか見えないから
2013/06/11(火) 01:01:55.93
循環的複雑度を否定している人が、何ひとつ根拠を示ていない件について
2013/06/11(火) 01:40:15.49
誰がいつから否定したんだよｗ
2013/06/11(火) 04:36:33.17
>>182
循環的複雑度を誤解してる奴と誤解を否定してる奴しか居ないな。
誤解が正しいと思ってる奴が誤解の否定を循環的複雑度自体への
否定として受け取りだすと話がこじれるから一遍否定している人のレスを読みなおしてみ。
2013/06/11(火) 06:10:44.14
否定のレスのおかげで弁証論的に循環的複雑度の理解は深まった
そんでレビューのネタ探す程度には使えるってのはわかった
ついでに循環的複雑度が使えるって言ってる奴がとことん使えない奴ってのもわかった
2013/06/11(火) 07:51:10.63
今気付いたが、循環的複雑度ってオイラーの多面体定理の公式にそっくりだね
2013/06/11(火) 08:44:01.08
循環的複雑度がソフトウェアメトリクスにおける銀の弾だと思っちゃったんだろうね。
2013/06/11(火) 10:04:22.68
品質評価の手法だから、コードを書く時に使おうとしてもあまり意味がない物だけど
普段理論武装してる奴が過剰な拒否反応を示すのは痛々しいな。
2013/06/11(火) 10:26:32.45
過剰な拒否反応？どのレス？
みんな、頓珍漢な俺理論を見逃せなかっただけ。
2013/06/11(火) 10:33:49.76
おかしな持論を曲げない奴が頑張るとスレが無駄にのびる。
おじゃばとか。
2013/06/11(火) 10:35:44.66
>>157が真理だと思うぞ
コードを書く時に意識するとか平均とか意味不明な事言ってるから突っ込まれる
2013/06/11(火) 21:19:29.46
だいたいいつもこんな流れ

ある手法が登場
↓
馬鹿：その手法は完璧じゃない！と否定する
↓
そもそも「ある手法」は完璧なんて誰も言っていない。
↓
馬鹿：完璧じゃないから、全く使えないと極論言い出す
↓
この手法がどういう時に使えて、どういう時に使えないのか説明する
↓
馬鹿：聞く耳持たない。
2013/06/11(火) 21:31:51.86
今回は逆パターンだけどね

馬鹿：ある手法をゴリ押し
↓
皆が間違ってるところを指摘。
↓
馬鹿：俺の理論は絶対なんだよ！指標にすべし！とゴリ押し継続
↓
誰も完全に否定してるわけじゃない。だがおかしなところもある。
といって説明する。
↓
馬鹿：否定する根拠を示せと言って人の説明をガン無視、聞く耳を持たない
2013/06/11(火) 21:58:29.83
>>193
逆じゃんｗ
結局間違ってなかったわけだから。
2013/06/11(火) 22:03:49.90
↓
分析する馬鹿が現れる
↓
それを煽る俺が現れる
2013/06/11(火) 22:11:13.27
否定していないというだけで、まるで全肯定でもしてるかのように
脳内変換されてしまう>>194の脳がとっても心配
2013/06/11(火) 22:26:01.86
もうその話題飽きたお
2013/06/11(火) 22:36:27.95
スレタイに相応しいことでも書くか。
シングルトンクラスのgetInstanceメソッドに引数をつけない。
2013/06/11(火) 22:47:53.12
職場でBGMはいいが歌は流すな
2013/06/11(火) 22:53:47.51
循環的複雑度を計測せよ
2013/06/11(火) 23:10:00.17
省力可能な引数作るな
関数名みたら使い方がわかる様に作れ
2013/06/11(火) 23:20:46.96
平均値馬鹿はいい加減あきらめろ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況