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

**仕様書無しさん** · 2013/06/04(火) 22:43:46.92

もしくはやって欲しくないこと
先輩方のアドバイスをください

前スレ
これからコードを書く人に絶対やって欲しいこと★2
http://kohada.2ch.net/test/read.cgi/prog/1365269189/

**仕様書無しさん** · 2013/06/15(土) 23:28:49.07

>>362
こうやれば関数増やす必要なくね？
再利用できない関数はこれでよくね？

function foo() {
　// ○○の処理
　do{
　　：
　} while( false )

　// △△の処理
　do{
　　：
　} while( false )

　// □□の処理
　do{
　　：
　} while( false )
}

**仕様書無しさん** · 2013/06/15(土) 23:32:20.68

>>348
テストしづらい例：
・メソッド内で直接現在時刻を取得し、その時刻に基づいて判断している場合
・メソッド内で直接物理デバイスをオープンしている
・メソッド内でConcrete Classをインスタンス化している
・マルチスレッドのテスト
等々。

循環的複雑度が高いコードをリファクタリングすれば以前よりテストはしやすなるのは
その通りだが、必要十分条件のように言われると、それは違うと言わざるを得ない。

**仕様書無しさん** · 2013/06/15(土) 23:40:17.41

> 必要十分条件のように言われると
誰もそんなこと言っていない。

だが概ね正解だろうな。
循環的複雑度が高いのはクソコード。

**仕様書無しさん** · 2013/06/15(土) 23:44:38.22

>>365
言ってないならそれでいいんだが、何故だか、そんなことあるわけないからコード出せと
いう奴がいなくならない。多分一人なんだと思うが。

**仕様書無しさん** · 2013/06/15(土) 23:49:31.55

>>363
変数と引数と戻り値、そしてテストコードを忘れている。

たしかにその例には書かなかったが、実際には変数と引数と戻り値がある。
関数は普通シンプルなものから少しづつ処理を付け加えて複雑になる。

最初は○○の処理しかなかったものにたいして、△△、□□を付け足す。
その時、たいていは○○で計算した結果を△△、□□で使う。
結果、グローバル変数と同じように、どこで何を触っているかわからなくなる。

次第に変数の使い方はごちゃまぜになり、分けようと思った時に簡単に分けられなくなる。
分けようと思ったときに、君に言うように都合よく分けられることは少ない。
修正の影響を避けてまた少しコードを追加する。ということを繰り返す。

最初のうちに、関数に分けておくという習慣を持っていれば、このような歴史を辿らなくて済む。

そして重要なのがテスト、関数の中で小さく分けられていても、その単位ではテストできない。
単純に呼び出せないというものもあるし、doなんて使ったやり方では関数のインターフェースである
引数と戻り値が明確にならない。

**仕様書無しさん** · 2013/06/15(土) 23:50:32.90

>>366
そりゃ、コードでなきゃいなくならないだろｗ
ちゃんとコード出して示してやればいいんだよ。

なんでそれが出来ないのさ？

**仕様書無しさん** · 2013/06/15(土) 23:55:34.78

>>368
>>364の内容でコードが思い浮かばない人とは議論しません。

**仕様書無しさん** · 2013/06/15(土) 23:56:51.11

続きはこちらへ↓

循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/

**仕様書無しさん** · 2013/06/15(土) 23:59:56.89

>>368
わざわざ頭の悪いコード書きたくないんじゃないかな。

**仕様書無しさん** · 2013/06/16(日) 00:01:50.42

>>364

http://kohada.2ch.net/test/read.cgi/prog/1370760670/6

6 名前：仕様書無しさん[sage] 投稿日：2013/06/15(土) 21:37:15.97
なかなかレスが来ないから先に書いておくわ。

それは「テストがしにくい処理」であって
「テストがしにくいコード」じゃねぇよ。

**仕様書無しさん** · 2013/06/16(日) 00:03:12.30

>>369
http://kohada.2ch.net/test/read.cgi/prog/1370760670/6

テストがしにくい処理と
テストがしにくいコードを
ごっちゃにしている人いるよね。
だからコード出せって言ってるのに。

**仕様書無しさん** · 2013/06/16(日) 00:23:12.22

例えば
bool foo()
{
now = systemtime(); // systemtime()はマシンの時刻を戻す
return now.hour < 9;
}
みたいなことなんだが、これがテストしづらい処理なのかテストしづらいコードなのかに
カテゴライズすることに何の意味があるんだろうか。

**仕様書無しさん** · 2013/06/16(日) 00:23:30.83

>>373
出したとして理解できるの？

>>367
> 関数のインターフェースである
> 引数と戻り値が明確にならない。
そら関数じゃないんだから引数や戻り値はないさ
だけど変数をできるだけ狭いスコープ内で宣言するようにしたらいいんじゃないかな。
そしたら残った変数が全体で使う変数だよ。

**仕様書無しさん** · 2013/06/16(日) 00:24:33.01

理由が書いてない（納得出来ない）
コーディング規約はゴミだ。作るな。従うな。

初心者のためのコーディング規約は糞だ。
（難しくてわからないから）○○機能は使わないこと。

糞な規約の例として
三項演算子は使わない。
クラスは作らない。
継承は使わない。
等がある。

**仕様書無しさん** · 2013/06/16(日) 00:42:53.30

>>374
> カテゴライズすることに何の意味があるんだろうか。
すごく重要。

テストしにくいコードは、リファクタリングで直すことが出来る。
リファクタリング＝処理の内容は変わらない。

処理の内容がどうこうではない。処理はやらなきゃいけないんだからやるしか無い。
同じ事を実現する処理ならば、複雑ではない書き方（コード）にした方がいいだろ。
処理ではなくコードが重要。

http://kohada.2ch.net/test/read.cgi/prog/1331998580/27 (当時日時に注意)
> 27 名前：仕様書無しさん[sage] 投稿日：2013/06/15(土) 21:39:58.61
> そのコードがテストしにくいかしやすいかが焦点なんじゃねーかよ。
> だから具体的なコードを出せと言ってるのに
> 処理だけ言ってコード出さないとか、頭悪いな。

>>375
> だけど変数をできるだけ狭いスコープ内で宣言するようにしたらいいんじゃないかな。

普通に関数でいいじゃねーか。
なんでテストしにくい方法にこだわる？

**仕様書無しさん** · 2013/06/16(日) 00:47:20.96

他人に見せるコードでタブ文字を使って桁合わせすると、タブ幅不一致の時に表示が崩れる。
インデントはスペースでもタブでも良いが、どちらか片方に統一しておかないと以下同文。
なので、桁あわせはスペース、インデントはタブ文字またはスペースのどちらか一方が良い。
読みやすいインデント幅が人による事を考えるとタブ文字インデントが望ましい。

但し、人に読ませる気のないコードや文法的にインデントルールが決まっている場合は除く。
最悪フォーマッタ通せば問題ないしね。

**仕様書無しさん** · 2013/06/16(日) 00:49:43.69

>>374
って複雑度が低いがテストしにくいコードってだけで、

複雑度が高いものは、テストがしにくいってことの
反論になってないんだが？

**仕様書無しさん** · 2013/06/16(日) 00:54:49.07

>>379
> 複雑度が高いものは、テストがしにくいってことの
> 反論になってないんだが？

>>363 のコードってテストしにくい？

**仕様書無しさん** · 2013/06/16(日) 01:00:40.78

>>380
しにくいな。

○○、△△、□□
それぞれでテストが出来ない。

これだと必要なテストの数が
○○の数 × △△の数 × □□の数に
膨れ上がってしまう。

それぞれでテストしていれば、
○○の数＋ △△の数＋ □□の数で十分なのに。

**仕様書無しさん** · 2013/06/16(日) 01:09:20.07

>>377
で、>>374のコードはテストしやすいの?しにくいの？

>>379
循環的複雑度が高いとテストしづらいということは、全員が認めてると思うが。
今の話題は、循環的複雑度が低くてもテストしづらい場合があるということ。

**仕様書無しさん** · 2013/06/16(日) 01:13:15.34

なんか一人だけ、複雑度が低くてもテストがしにくいって
話をしている人がいるな。

循環的複雑度を計測した時、複雑度が低いものを見るか？
普通は高いものを見て、落ち込むものだろ？ｗ

忍法帖【Lv=9,xxxP】(1+0：5) · 2013/06/16(日) 01:16:07.25

オブ指が理解できない俺はプログラマ向いてないのかな

**仕様書無しさん** · 2013/06/16(日) 01:18:13.04

>>383
興味ないならコード出せなんて言わずに、スルーしてくれていいんだよ。

**仕様書無しさん** · 2013/06/16(日) 01:18:46.06

>>381
> の数に
> 膨れ上がってしまう。

その認識が間違ってね？

**仕様書無しさん** · 2013/06/16(日) 01:26:47.91

>>386
間違っているというのなら
自分の意見をいうべきだ。

**仕様書無しさん** · 2013/06/16(日) 01:27:50.35

間違っているという自分の意見を言っただろ。
間違ってないという自分の意見を言っただろ。

**仕様書無しさん** · 2013/06/16(日) 01:28:06.50

ここまでスレタイすら読めない馬鹿がお送りしました

**仕様書無しさん** · 2013/06/16(日) 01:36:02.69

ここからはご覧の馬鹿の提供でお送りします

**循環的複雑度** · 2013/06/16(日) 02:02:03.25

このスレからの派生スレっていくつあったっけ
一文字変数は覚えてる

**仕様書無しさん** · 2013/06/16(日) 02:02:07.49

じゃあ、話を戻して、
コードを書く人に絶対循環的複雑度の計測をやって欲しい

**仕様書無しさん** · 2013/06/16(日) 02:08:16.22

コード書いてる本人はそんなの計測しなくても複雑かどうかわかるだろ。
いらんわ。

**仕様書無しさん** · 2013/06/16(日) 02:17:49.44

>>386
コードカバレッジ(コード網羅率)のC2網羅（条件網羅、経路網羅)って試験をするとそうなるよ。
だから、循環的複雑度が高いコード⊆テストが複雑なコード、となる。

C2網羅でないとチェック漏れしうる現象というのはあるにはあるがC1のそれより少ないし、
C2網羅でも完璧ではないしC2コストも高いことからC2自体省略されることも少なくなかったり。
しかし循環的複雑度が低いならばC2のコストも下がるわけで、それでC2すれば品質に繋がる。
363の様なコードがC1網羅で十分かを一々考えて合理的にC2除外を決めるのもナンセンスだしな。

>>393
「計測しなくても複雑かどうかわかる」は同感だが、意識に留めておくとかプロジェクト管理の一助にするのはアリだと思う。
「それを問題とも思わない奴の書いた無意味に複雑度の高いコード」が見つけやすくなるだろうから。

**仕様書無しさん** · 2013/06/16(日) 06:15:53.38

このスレの奴らとスタンドアップミーティングしたら、いつまで経っても終わらなさそうｗ
場をわきまえていない議論だとしても、相手が言い返してくる限りこちらの反論も許される、みたいな
オレオレルールを勝手に作ってそれ基準で行動する様は、まさに昨今のゆとり

**仕様書無しさん** · 2013/06/16(日) 06:25:17.26

ほんと見苦しいスレ
こいつらバグってんじゃね？

**仕様書無しさん** · 2013/06/16(日) 08:15:14.80

循環的複雑度君が言ってるテストや規模って、俺の考えてたテストと微妙に違う気がする
なんつーか、えらく低水準な領域のコードについて書いてるような
サンプル出さないから未だ平行線だけど

何にせよいい加減ウザイので別スレだな
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/

**仕様書無しさん** · 2013/06/16(日) 08:34:52.90

メモ
>>3-6 >>376 >>378

**仕様書無しさん** · 2013/06/16(日) 09:01:30.12

結局どのくらいの数値だと高いの？

**仕様書無しさん** · 2013/06/16(日) 09:29:14.58

平均より上が高い

**仕様書無しさん** · 2013/06/16(日) 09:31:06.38

平均バカ

**仕様書無しさん** · 2013/06/16(日) 10:49:55.21

>>399
http://www.slideshare.net/MoriharuOhzu/ss-9224836
5以下単純な構造
10以下良い構造
30以上構造に疑問
50以上テスト、デバッグ困難
75以上変更時に誤修正を生む原因を作る

32を超えているとバグを含んでいる確率が高くなる by IBM

**仕様書無しさん** · 2013/06/16(日) 10:54:19.63

Javaだとこんなツールもあるんだね。
http://www.ibm.com/developerworks/jp/java/library/j-eaed6/

> 循環的複雑度に関してよくある質問には、「自分が作成したコードを
> 他のコードと比較するにはどうすればよいのか？」、「ある特定のクラスに
> 望ましい数値は何か？」というものがあります。これらの質問に答えるのが、
> iPlasma プロジェクトです (「参考文献」を参照)。

> 数値は比率を示し、色は、その比率が業界の標準範囲 (多数のオープンソース・
> プロジェクトを基に算出された範囲) のどのあたりに収まるかを示します。
> 各比率の色は、緑 (範囲内)、青 (範囲未満)、赤 (範囲超過) のいずれかとなります。

**仕様書無しさん** · 2013/06/16(日) 11:05:38.49

> 11 名前：仕様書無しさん[sage] 投稿日：2013/06/16(日) 09:47:31.39
> 分割が適当でテストしやすいメソッドなら、意識する必要ないんじゃないの
> そもそも循環的複雑度なんて言葉、あのスレ見て初めて知ったわ

そこが日本のソフトウェア業界の低さを表しているんだよ・・・。

IBMでも使われてるし、色んな所で研究されてる。
探せばずっと前から色んな所で話題になってるだろ。

**仕様書無しさん** · 2013/06/16(日) 11:11:09.18

>>402-404
専用スレでやれ

**仕様書無しさん** · 2013/06/16(日) 11:12:56.61

断る
なぜなら、これからコードを書く人に絶対やってほしいことだからだ。

**仕様書無しさん** · 2013/06/16(日) 11:24:51.03

循環的複雑度は、ソフトウェアメトリクスの一指標に過ぎず、他にも重要な指標として
クラス内メソッド数やfan-in/fan-out、各メソッドの実効行数など様々なものがある。
だがそれらは、ソフトウェアの品質を客観的に判断する必要があるときには重宝するが、
設計やコーディング中にはそれらの数値を気にしてもしかたがない。
まずは、構造化設計手法を学ぶべきだね。OOPをやる場合でも。

**仕様書無しさん** · 2013/06/16(日) 11:29:36.59

最近循環的複雑度を知ってはしゃいでるのかな

**仕様書無しさん** · 2013/06/16(日) 11:35:22.38

>>406
おめー独りぼっちだって気づけ
テメー自身が度素人なのに他人に押し付けんな

ですな

**仕様書無しさん** · 2013/06/16(日) 11:37:09.57

>>407
他のメトリクスと、併用するべきだな。

循環的複雑度以外のメトリクスの話も聞きたいぞ。
なんか書け。

**仕様書無しさん** · 2013/06/16(日) 11:37:49.37

>>409
検索した結果、世界中で使われている
メトリクスですから、ぼっちではないなぁ。

**仕様書無しさん** · 2013/06/16(日) 11:38:27.70

いや書くんならアッチの専用スレで

**仕様書無しさん** · 2013/06/16(日) 11:43:05.57

>>411
>>338

**仕様書無しさん** · 2013/06/16(日) 11:44:04.22

>>412
いくら言ってもお前の願いはかなわないってｗ

**仕様書無しさん** · 2013/06/16(日) 11:45:01.41

スルー力無いねー

**仕様書無しさん** · 2013/06/16(日) 11:51:17.29

>>411
ここでボッチだってことには触れられたくないわけね

**仕様書無しさん** · 2013/06/16(日) 12:10:17.71

メモ
>>3-6 >>376 >>378

**仕様書無しさん** · 2013/06/16(日) 12:10:36.14

>>416
2ちゃんねるが世界の全てであるあなたには
ここでぼっちというのは、悪口になるんでしょうね。

**仕様書無しさん** · 2013/06/16(日) 13:20:58.71

「間違ってるのはネラーの方だ」

**仕様書無しさん** · 2013/06/16(日) 13:25:10.74

これからコードを書く人は、こんなクソスレは見なくてよろしい
この人たちは頭がバグってるから、議論のループにも気づかない

**仕様書無しさん** · 2013/06/16(日) 13:28:06.65

>>418
循環的複雑度を否定してる奴なんてこのスレにもいないよ。
否定されてるのは、お前の俺理論。

**仕様書無しさん** · 2013/06/16(日) 13:32:22.32

>>421
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/

**仕様書無しさん** · 2013/06/16(日) 13:33:02.73

>>421
俺理論の内容って何？

例えば俺は、循環的複雑度の平均を取ることは
意味が無いと、言ったわけだが、それはあってるよな？

**仕様書無しさん** · 2013/06/16(日) 13:33:29.27

>>423
循環的複雑度
http://kohada.2ch.net/test/read.cgi/prog/1371301844/

**仕様書無しさん** · 2013/06/16(日) 13:34:20.96

>>424
違う。

お前が言う「俺理論」の内容を言えって

**仕様書無しさん** · 2013/06/16(日) 13:46:41.97

>>425
いい加減ウザイよ？

**仕様書無しさん** · 2013/06/16(日) 13:53:36.23

ほら逃げたｗ

敵は一人だと思って
奴はこういうことを言ってる。と
決めつけてるんだろうなって思ってた。

**仕様書無しさん** · 2013/06/16(日) 14:03:44.87

こういう粘着質な奴が居座るからいつまでたってもこのスレはこんな感じのまま

**仕様書無しさん** · 2013/06/16(日) 14:09:05.48

自分も同じ穴のムジナって気づいてないんだろうな（苦笑）

**仕様書無しさん** · 2013/06/16(日) 14:18:52.40

相手が一人だと思ってるんだろうなぁ

**仕様書無しさん** · 2013/06/16(日) 14:20:26.36

某スレの自治厨もだけど
最近相手がひとりと決めつけて発狂するヤツ多くね？

**仕様書無しさん** · 2013/06/16(日) 15:24:51.46

連投やめようねｗ

**仕様書無しさん** · 2013/06/16(日) 17:36:58.84

別人だが？

**仕様書無しさん** · 2013/06/16(日) 19:31:12.71

メモ
>>3-6 >>376 >>378
>>370 >>410

**仕様書無しさん** · 2013/06/18(火) 01:51:20.53

使えない老害化したオッサンとかガキが紛れ込むとループする下らない罵り合いが続く

**仕様書無しさん** · 2013/06/18(火) 06:49:53.07

俺は老害化して使えなくなどなっていない
もともと使えないんだ

**仕様書無しさん** · 2013/06/18(火) 07:01:00.63

>>435
ようやく止まったんだからいちいち煽るな

**仕様書無しさん** · 2013/06/18(火) 09:57:30.64

OSSにすることを意識してもらう

**仕様書無しさん** · 2013/06/18(火) 21:43:23.88

【JavaScriptコードメトリックス】ソースコードの複雑さや保守の容易さを測定できるWEBサイト
http://shimz.me/blog/web/2279
http://jscomplexity.org/

こんなのがあったからjQueryの複雑度を調べてみたよ。

jQuery
5以下　481（82.4%）　単純な構造
10以下　55（9.4%）　良い構造
11～29　 46（7.9%）　普通
30以上 2（0.34%）　構造に疑問
50以上 0（0%）　テスト、デバッグ困難
75以上 0（0%）　変更時に誤修正を生む原因を作る

オープンソースだからかな。
やっぱりすごいね。

その中で高めなのが2つ。ajax関数とtrigger関数だった。
軽く見ただけだけどどちらも行数長くて
（と言ってもLogical LOCが100行超えないが）
確かに複雑そうに見える。

**循環的複雑度** · 2013/06/19(水) 02:38:00.03

>>439
メモ

**仕様書無しさん** · 2013/06/19(水) 02:58:17.82

>>439
こんなん見習いたいわ...

**仕様書無しさん** · 2013/06/19(水) 16:37:46.62

>>439
ajax関数って聞いた瞬間納得したわ

**仕様書無しさん** · 2013/06/19(水) 17:02:53.47

>>439
そのツール駄目駄目だわ。
ぱっと見でもSizzle関連のひどさが全然測定されてない。
anonymousとかでぶつ切りになってて、数値が低く出てるだけ。

**仕様書無しさん** · 2013/06/20(木) 07:45:17.73

>>443
ぶつ切り（小さな関数）にすることが
複雑度を低減する方法だから。

**仕様書無しさん** · 2013/06/20(木) 07:50:18.19

anonymousといっても、すべてのanonymousが
一つにまとまっているわけじゃないな。

anonymousは名前の無い関数ってだけで
名前つければ普通の関数なわけで
別々に計測されているのだから問題ないのでは？

**仕様書無しさん** · 2013/06/23(日) 02:25:38.82

TDDってどうやって学べばええんや...

**仕様書無しさん** · 2013/06/23(日) 08:12:46.98

>>446
http://www.pej-hed.jp/washo/473.html

**仕様書無しさん** · 2013/06/23(日) 09:13:33.90

ケント・ベックのTDD本からもう10年経つのか。
月日が流れるのが速すぎる。

**仕様書無しさん** · 2013/06/23(日) 16:23:00.81

ttp://objectclub.jp/technicaldoc/testing/stack_tdd.pdf/view

**仕様書無しさん** · 2013/06/23(日) 16:23:53.08

学習が目的ならペアプロ+TDDとてもいい

**仕様書無しさん** · 2013/06/23(日) 17:24:45.01

低レベル同士のペアプロ
新人同士のペアプロ

↑これはやっても効果はない。

上級者同士のペアプロ（相互コードレビュー）

もしくは

上級者と低レベル・新人のペアプロ（コードレビュー＋教育）

これが意味がある。

**仕様書無しさん** · 2013/06/23(日) 19:28:06.42

スキルギャップを平準化する効果があるから
新人同士でも意味が無いとは言い切れないがな。

**仕様書無しさん** · 2013/06/23(日) 21:40:42.26

ペアプロのローテーションに上級者入れときゃ新人同士でもいいんじゃね
ペアプロなんかやったことないけど

**仕様書無しさん** · 2013/06/23(日) 23:59:33.38

ペアプロ自体が受け入れられない事も多いし
どのくらい実例があるのか疑問ではあるよな。

個人的にはコードの共有化がすすむので取り入れたいが
反対意見が出ると反論が難しいという現状。

**仕様書無しさん** · 2013/06/24(月) 03:09:52.07

宗教争いが起きないように、事前にフォーマットルールとかコードスタイル系をある程度設定しておいたほうが良いと思う

**仕様書無しさん** · 2013/06/24(月) 20:42:54.98

かわいい子とペアプロがしたい
そして罵られたい

**仕様書無しさん** · 2013/06/24(月) 21:41:52.85

ペロペロしたい

**おじゃばさま** ◆mpgYduuqtA · 2013/06/25(火) 00:02:45.97

テスト駆動開発なんて初心者には勧められない。
開発技法と呼べるような確立した物でないし、
何となくでもモジュール分割出来るようでないと、
簡単に破綻する。

ペアプログラミングでモジュール設計
を覚えさせるのは、非効率だ。
スキルのある人間がサンプルコードを書くか、
コードを修正してやった方がいい。

ペアプログラミングでは、IDEやツールの
使い方を覚えさせるのにいい。
ただ最初に少し自力でやらせて、
苦労させた方が、興味を持つだろう。

**仕様書無しさん** · 2013/06/25(火) 02:31:11.77

！？

**仕様書無しさん** · 2013/06/25(火) 06:19:05.50

ちゃんとお風呂に入ってほしい

**仕様書無しさん** · 2013/06/25(火) 19:38:26.39

乾燥ワカメ大量に食って緑のゲロを吐かない

**仕様書無しさん** · 2013/06/26(水) 18:42:52.33

なによりもまず先に自分が無能であり無能であり続ける存在である事を思い知って下さい