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

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

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

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

**仕様書無しさん** · 2013/06/14(金) 01:40:07.65

>>258って平均君でしょ。
平均理論が認められないもんだから暴れてる。

**仕様書無しさん** · 2013/06/14(金) 01:52:25.97

循環的複雑度の人が言う循環的複雑度の低いソースと高いソースを
俺らにサンプルとして出すよう言ってから24時間経ってるのに出てないのね。
なんか書き込みはすごいことになってるけど。

**仕様書無しさん** · 2013/06/14(金) 01:56:08.87

>>319
俺もこのあたりで諦めようかと。203の一覧には
5，1～4の何れかの存在を認めない馬鹿
ってのを追加しないとだな。

**仕様書無しさん** · 2013/06/14(金) 02:27:07.14

レスする価値があるような相手、内容であるか見極めてからスレに投稿する、ということを、
これからコードを書く人には絶対にやって欲しいな。

**仕様書無しさん** · 2013/06/14(金) 03:54:22.34

途中全く読んでないけど、レスが50も増えたと思ったらまだやってたのか
たぶん名無しで書いてるけど中身はおじゃばだな…

このスレも終わったな

**仕様書無しさん** · 2013/06/14(金) 04:33:31.11

読めば判るが、おじゃばはさらに斜め上に飛んでるから多分別口だ。

**仕様書無しさん** · 2013/06/14(金) 09:27:56.97

ここに書かれてるのは量産型おじゃばか

**仕様書無しさん** · 2013/06/14(金) 13:14:40.54

絶対やって欲しいこと
スルー能力を鍛えて欲しい。

**仕様書無しさん** · 2013/06/14(金) 15:34:58.73

Warning とか Exception はスルーしないでほしい。

**仕様書無しさん** · 2013/06/14(金) 18:19:36.66

>>328
それに付け加えて、静的解析ツールが出力するError/Warningも極力取って欲しいよね。
自分では問題無いと分かってる場合でも、他人がツールを使うと、それらが問題あるかどうかなんてわからないから。

htmllintで-100点とか出してて、<div>の対応がおかしいことに気づかない奴とか良くいるし（Webアプリを
引き継いでlintかけると大量のメッセージが出る場合多し）。

**仕様書無しさん** · 2013/06/14(金) 18:34:57.16

(スルー力鍛錬中)

**循環的複雑度** · 2013/06/14(金) 22:17:56.64

おじゃば降臨祭り実施中

**おじゃばさま** ◆mpgYduuqtA · 2013/06/15(土) 01:46:33.40

単体試験の基本も知らずに、試験の自動化を勧める人。
オブジェクト指向の基本も知らずに、
DIコンテナやデザインパターンを勧めるの人。
今度はモジュール分割の基本も知らずに、
複雑度測定ツールを勧める人か？

何で基礎が欠落してるのに、高度な
事に詳しいのだ？
ニセコンサルか、提灯記者か？

**仕様書無しさん** · 2013/06/15(土) 02:37:57.52

>>328-329
警告無視する奴結構多いよなぁ
必要な無視もあるけど、そういうのはプロジェクトの設定の見直しとかも考えればいいのに
ただひたすら無視して警告出したままソース管理にコミットしてくるオッサンとかめっちゃいる

IDEの出してる警告が気にならない人間がどうも理解できないわ
これからコード書く人は、警告は問題がある可能性の通知だから
どうか無視せず適切な対処をとるようにしてほしいな

**循環的複雑度** · 2013/06/15(土) 04:14:22.02

煽っていくスタイル

**循環的複雑度** · 2013/06/15(土) 04:14:57.96

>>333
マーカー発動

**仕様書無しさん** · 2013/06/15(土) 08:39:41.32

プログラマに最も向かないのは、意外にも神経質すぎる奴だったりする

**仕様書無しさん** · 2013/06/15(土) 08:43:50.39

というより神経質になるべき箇所を正しくコントロールできる
無能なやつは全てに於いて神経質、要するに根っからの性格だな

**仕様書無しさん** · 2013/06/15(土) 11:08:04.74

未熟なプログラマは経験豊富なプログラマへの対抗心が常にあり、身の丈も考えず背伸びをしようとする。
未熟ゆえ、ググった情報が正しいのか間違っているのか判断が付かず鵜呑みにして、もはや洗脳状態に。
なので理解してるふりをして間違った解釈で人に伝える、致命的な伝言ミスを実務でもやらかすことが多い。
対抗できないと悟ってもプライドが許さず、何かしらで蹴落とすことを考えはじめる。

経験が豊富なプログラマは、あまりハマることもなくスムーズに仕事を遂行できる。
わからないことがあっても、割と素早く正しい情報だけを検索できる。
未熟なプログラマにあれこれ教えるのは好きだが、背伸びしてくる人間には容赦ない。

だから仕事を教えて欲しかったら、本当の自分を隠すなってことだな。

**仕様書無しさん** · 2013/06/15(土) 11:09:38.23

ごくごくまれにバケモノじみた能力のプログラマがいるけど、そういうのは別次元。
興味範囲が広く、一度興味を持つととことん追求するから知識が広いだけでなく深い。
ダビンチのようなオールラウンダータイプに多い、ここまでくると天性の領域。
成功経験だけじゃなくあらゆる失敗も自ら試して経験にする。
発想が自由自在で時々人が考えつかないようなアイデアを実行する。
自由かつ正しく組み合わせられるため、とにかく仕事が尋常じゃなく早い。
まさにプログラマをやるために生まれてきたような人間。

但し納得いくまで追求しきると熱が一気に冷めるので、飽きっぽく見える。
仕事のことしか興味がなく、なにも考えてない時間が勿体なさすぎるので
切羽詰まってるわけでもないのにメシを食べながら仕事したり常に何かを考えてる感じ。
なので普通の人には付き合いにくいイメージがある。

**仕様書無しさん** · 2013/06/15(土) 11:11:19.26

> 未熟なプログラマにあれこれ教えるのは好きだが、背伸びしてくる人間には容赦ない。
これは人間的な意味でレベル低いタイプじゃ
先に書いてる奴と同類じゃね

**仕様書無しさん** · 2013/06/15(土) 11:38:10.09

できるプログラマーはこんなスレで人間性的な物を語ったりはしない、かな

**仕様書無しさん** · 2013/06/15(土) 12:53:32.67

>>340
仕事教えても覚えようとしなかったり
教わったことをさも独学で身につけたように持ち込むタイプの人間に
ずっと寛大でいられる人は、たしかに尊敬できる

>>341
できないプログラマーは冷静に性格分析されるのを嫌う、よね

**仕様書無しさん** · 2013/06/15(土) 15:02:16.18

スレタイくらい読み解ける日本語力を身につけて欲しい。

**仕様書無しさん** · 2013/06/15(土) 20:57:16.84

>>339
これはまさに天才だったころの俺。
飽きっぽく見えるというか実際飽きる。

> なので普通の人には付き合いにくいイメージがある。
上手に付き合えばいいのに仲間内だけでしか付き合わないからそう見えるんだよな。

>>340
>>176
> レベルが低い奴は、レベルが低いということすら自覚できない。
> 循環的複雑度を計測するのは簡単だから、とりあえずやってみろと言うしか無い。
> 自分らのレベルが低いとか高いとかどうでもいい、とりあえずやってみて、その結果を受け入れろ。

循環的複雑度を計測した結果を受け入れろとか意味わからんし。

機械語レベルの命令を組み合わせれば長くなるけど
高機能な言語では短くなる。
だから言語やライブラリが違うのに単純比較はできないはずだが。

**仕様書無しさん** · 2013/06/15(土) 21:10:43.52

>>344
お前のほうが意味わからん。

誰も機械語の話なんかしていないし、
言語やライブラリが違う場合の話もしていない。

仮に機械語や言語やライブラリが違っていたとしても一緒。
単純比較できる。

なぜなら、「言語によってシンプルに書ける」ということは実際にありえる話だし、
「ライブラリを使った結果シンプルになる」というのも実際にありえる。

最終的には複雑なのをシンプルにする＝テストが簡単になるようにすることが目的なので
ライブラリを使って、シンプルにしてテストが簡単になるのは卑怯でもなんでもない。
それが現実的な開発で用いられている手段。

**仕様書無しさん** · 2013/06/15(土) 21:11:08.74

飽きるのが悪いかというと、そんな悪いことでもない。
無駄に頭を使わないことは重要だ。

頭の悪いやつに頭のことを言っても分からないから運動で例えるといい。
早く走れるからと言って一日中走っていられるのかと。
がんばればいくらでも早く走れるのかと。
短距離で走れる速さで長距離は走れない。

だけど、使う筋肉の違う運動なら続けて出来る。

今朝の番組でボディビルダーが出てた。
週５で鍛えていると言ってた。
筋肉をつけるには程よい運動と養生が必要だ。
無駄に負荷をかけ続けても壊れるだけ。

だから睡眠時間を削らせてまで働かせるやつは殺人鬼。

**仕様書無しさん** · 2013/06/15(土) 21:13:01.18

循環的複雑度が低くても、テストしやすいとは限らないよ。

って、何回言わせるんだよ。

**仕様書無しさん** · 2013/06/15(土) 21:22:10.27

>>347
それを具体的なコードで示せって、何回も言われてるだろ。

そのコードも複雑度を減らして、もっとテストしやすくしてやるから。

**仕様書無しさん** · 2013/06/15(土) 21:29:04.13

複雑度が高い関数ってのは
一つの関数で複数の仕事をしているから。

例えば二つの仕事（n、m）をしている関数では、
そのテストの組み合わせはn×mになる。

これを単純な二つの関数nと関数mに分けることで
テストの数もn+mになる。

**仕様書無しさん** · 2013/06/15(土) 21:48:52.16

同一の値に対し境界値の異なるメソッドを副作用を含む形で呼んでるとか、
複雑度の低いメソッドが複雑度が高い外部のメソッドを呼んでる場合とか、
そういう事情でテストの複雑さがメソッドの複雑さに比例しない事はあるかな。
ただ、比例しないからといって相関がないわけではない。
循環的複雑度が高いコード⊆テストが複雑なコード。

そもそも、循環的複雑度は悪いコードを見つける一助であって、
テストの複雑さを推定する指標でもなければ、
良いコードを規定する唯一の指標でもない。

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

まだ具体的なコード出てないな。
やっぱり逃げたか。

**仕様書無しさん** · 2013/06/15(土) 22:11:56.16

続きはこちらへ↓

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

**仕様書無しさん** · 2013/06/15(土) 22:13:43.20

戻って参りました！

**仕様書無しさん** · 2013/06/15(土) 22:17:09.35

循環的複雑度の計測っていうのは、
これからコードを書く人に絶対やってほしいことだもんな。
このスレであってるよ。

**仕様書無しさん** · 2013/06/15(土) 22:20:22.62

計測することにデメリットはないしな。
確固たる自信があって数値のほうが間違ってるといえるのなら
そうなんじゃない？

でも高い数値を出す人は、たいてい技術力が低いから
そんな自信は勘違い以外ではありえない。

まあ、いいからとりあえず計測しな。
話はそれからだ。

その数値とコードを示せば、正しい解釈をしてあげよう。
まあ殆どがコードが汚いという結果だろうけどね。

**仕様書無しさん** · 2013/06/15(土) 22:21:23.90

計測してどうすんの？
無理やり行単位で分割すんの？

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

>>356
正しい方法で修正するんですよ。
あたりまえじゃないですかｗ

**仕様書無しさん** · 2013/06/15(土) 22:29:28.69

>>357
正しい方法って何を基準にするの？　循環的複雑度？

**仕様書無しさん** · 2013/06/15(土) 22:39:10.96

>>358
えーとね。循環的複雑度は単に複雑度を図るだけ。
正しい方法ってのは、コードがやってることをの意味を考え
正しい場所にコードを配置すること。
何が正しいかは設計によるが、処理の責務を考えれば答えが出る。

計測して高い数値が出た＝一つの関数で複数の責務を持っているってことだから
正しい所にコードを配置する＝複数の責務を分割するから
自ずと循環的複雑度は下がる。

**仕様書無しさん** · 2013/06/15(土) 22:41:05.19

続きはこちらへ↓

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

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

>>359
> 計測して高い数値が出た＝一つの関数で複数の責務を持っている

ふーんたとえば？

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

よくあるのが

function foo() {
　// ○○の処理
　　：

　// △△の処理
　　：

　// □□の処理
　　：
}

みたいなもの。
コメントからわかるように、処理が内部で分かれているのに
それを一つの関数でやろうとしている。

こういうのが、ひとつの関数で複数の責務を持っているし、
もちろん複雑度はそれぞれの処理の合算になるから計測して高い値が出る。

こっからは、なんとかの処理をするなんてコメントを書きたくなったら、
それは関数にすべきと考えたほうがいい。

**仕様書無しさん** · 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

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