循環的複雑度
思う存分議論してください。
----------------------------------------------------------------------------------------------------------------------------------------
循環的複雑度（英: Cyclomatic complexity）とは、ソフトウェア測定法の一種である。Thomas McCabe が開発したもので、プログラムの複雑度を測るのに使われる。
プログラムのソースコードから、線形的に独立した経路の数を直接数える。
循環的複雑度は、プログラムの制御フローをグラフとして描くことで計算される。グラフのノードはプログラムのコマンドに相当する。
2つのノードを結ぶ有向エッジは、第一のコマンドを実行後、次に第二のコマンドが実行される可能性があることを示している。
M = E - N + 2P
ここで
M = 循環的複雑度
E = グラフのエッジ数
N = グラフのノード数
P = 連結されたコンポーネントの数
----------------------------------------------------------------------------------------------------------------------------------------
循環的複雑度（英: Cyclomatic complexity）とは、ソフトウェア測定法の一種である。Thomas McCabe が開発したもので、プログラムの複雑度を測るのに使われる。
プログラムのソースコードから、線形的に独立した経路の数を直接数える。
循環的複雑度は、プログラムの制御フローをグラフとして描くことで計算される。グラフのノードはプログラムのコマンドに相当する。
2つのノードを結ぶ有向エッジは、第一のコマンドを実行後、次に第二のコマンドが実行される可能性があることを示している。
M = E - N + 2P
ここで
M = 循環的複雑度
E = グラフのエッジ数
N = グラフのノード数
P = 連結されたコンポーネントの数
|
|
|
1371301844
13が２つで４が２つか
７があるように見えるが
13で挟まれてるから無しだし。
> 44.44
行き着く先は死か
13が２つで４が２つか
７があるように見えるが
13で挟まれてるから無しだし。
> 44.44
行き着く先は死か
>>2
循環的複雑度の話題は「これからコードを書く人に絶対やって欲しいこと」に関連がありません
循環的複雑度の話題は「これからコードを書く人に絶対やって欲しいこと」に関連がありません
良い設計なら、循環的複雑度が大抵低い。
テストが書きやすいメソッドは、大抵循環的複雑度が低い。
これは正しい。
だからといって、
循環的複雑度が低ければ良い設計であるとは言えず、
循環的複雑度が低ければテストが書きやすいとも言えない。
テストが書きやすいメソッドは、大抵循環的複雑度が低い。
これは正しい。
だからといって、
循環的複雑度が低ければ良い設計であるとは言えず、
循環的複雑度が低ければテストが書きやすいとも言えない。
テストケースが多い関数・クラス
テストケースを作るのが困難な関数・クラス。
そういうのは循環的複雑度が高くなる。
（そういう計算式だから）
ってことで、循環的複雑度が高ければ
クソコードでいいんじゃないかな？
低くてもクソなコードはあるけど
高ければ（30を超えるぐらい）例外なくクソでしょうね。
テストケースを作るのが困難な関数・クラス。
そういうのは循環的複雑度が高くなる。
（そういう計算式だから）
ってことで、循環的複雑度が高ければ
クソコードでいいんじゃないかな？
低くてもクソなコードはあるけど
高ければ（30を超えるぐらい）例外なくクソでしょうね。
循環的複雑度が低くてもテストしづらい例：
・メソッド内で直接現在時刻を取得し、その時刻に基づいて判断している場合
・メソッド内で直接物理デバイスをオープンしている
・メソッド内でConcrete Classをインスタンス化している
・マルチスレッドのテスト
等々。
循環的複雑度が高いコードをリファクタリングすれば以前よりテストはしやすなるのは
その通りだが、必要十分条件のように言われると、それは違うと言わざるを得ない。
・メソッド内で直接現在時刻を取得し、その時刻に基づいて判断している場合
・メソッド内で直接物理デバイスをオープンしている
・メソッド内でConcrete Classをインスタンス化している
・マルチスレッドのテスト
等々。
循環的複雑度が高いコードをリファクタリングすれば以前よりテストはしやすなるのは
その通りだが、必要十分条件のように言われると、それは違うと言わざるを得ない。
さっきから俺の発言ばかりコピペされてるなw
こんな糞スレどうでもいけど。
こんな糞スレどうでもいけど。
まあここに書かれてることが真理だと思うけどな。
向こうはなんであんなに荒れてんのかな。
向こうはなんであんなに荒れてんのかな。
マンセーさんがボッチなのに強引だからだね
分割が適当でテストしやすいメソッドなら、意識する必要ないんじゃないの
そもそも循環的複雑度なんて言葉、あのスレ見て初めて知ったわ
そもそも循環的複雑度なんて言葉、あのスレ見て初めて知ったわ
循環的複雑度なんて、他人のコードを評価するときくらいしか見ないわ。
>>12
仕事でやってれば大抵が「他人のコード」じゃないのか？
仕事でやってれば大抵が「他人のコード」じゃないのか？
そりゃ初心者に対してはそうだろｗ
まあ、新人君が書いた糞コードをrejectする理由として、「循環的複雑度が30越えてるからだめー」と
やるのに使うにはいいツールだよ。
やるのに使うにはいいツールだよ。
18 ：仕様書無しさん：2013/06/16(日) 13:17:12.06
WinMain()は下げられなくね？
メッセージループやリアルタイム処理系は難しいだろうね
下手に偽装工作加えたら、むしろややこしくなる
下手に偽装工作加えたら、むしろややこしくなる
399 結局どのくらいの数値だと高いの？
└402
> ttp://www.slideshare.net/MoriharuOhzu/ss-9224836
> 5以下 単純な構造
> 10以下 良い構造
> 30以上 構造に疑問
> 50以上 テスト、デバッグ困難
> 75以上 変更時に誤修正を生む原因を作る
>
>
> 32を超えているとバグを含んでいる確率が高くなる by IBM
└402
> ttp://www.slideshare.net/MoriharuOhzu/ss-9224836
> 5以下 単純な構造
> 10以下 良い構造
> 30以上 構造に疑問
> 50以上 テスト、デバッグ困難
> 75以上 変更時に誤修正を生む原因を作る
>
>
> 32を超えているとバグを含んでいる確率が高くなる by IBM
381 必要なテストの数が膨れ上がってしまう。
└386 その認識が間違ってね？
└394
> コードカバレッジ(コード網羅率)のC2網羅（条件網羅、経路網羅)って試験をするとそうなるよ。
> だから、循環的複雑度が高いコード⊆テストが複雑なコード、となる。
>
> C2網羅でないとチェック漏れしうる現象というのはあるにはあるがC1のそれより少ないし、
> C2網羅でも完璧ではないしC2コストも高いことからC2自体省略されることも少なくなかったり。
> しかし循環的複雑度が低いならばC2のコストも下がるわけで、それでC2すれば品質に繋がる。
> 363の様なコードがC1網羅で十分かを一々考えて合理的にC2除外を決めるのもナンセンスだしな。
393 コード書いてる本人はそんなの計測しなくても複雑かどうかわかるだろ。 いらんわ。
└394
> 「計測しなくても複雑かどうかわかる」は同感だが、意識に留めておくとかプロジェクト管理の一助にするのはアリだと思う。
> 「それを問題とも思わない奴の書いた無意味に複雑度の高いコード」が見つけやすくなるだろうから。
└386 その認識が間違ってね？
└394
> コードカバレッジ(コード網羅率)のC2網羅（条件網羅、経路網羅)って試験をするとそうなるよ。
> だから、循環的複雑度が高いコード⊆テストが複雑なコード、となる。
>
> C2網羅でないとチェック漏れしうる現象というのはあるにはあるがC1のそれより少ないし、
> C2網羅でも完璧ではないしC2コストも高いことからC2自体省略されることも少なくなかったり。
> しかし循環的複雑度が低いならばC2のコストも下がるわけで、それでC2すれば品質に繋がる。
> 363の様なコードがC1網羅で十分かを一々考えて合理的にC2除外を決めるのもナンセンスだしな。
393 コード書いてる本人はそんなの計測しなくても複雑かどうかわかるだろ。 いらんわ。
└394
> 「計測しなくても複雑かどうかわかる」は同感だが、意識に留めておくとかプロジェクト管理の一助にするのはアリだと思う。
> 「それを問題とも思わない奴の書いた無意味に複雑度の高いコード」が見つけやすくなるだろうから。
407
> 循環的複雑度は、ソフトウェアメトリクスの一指標に過ぎず、他にも重要な指標として
> クラス内メソッド数やfan-in/fan-out、各メソッドの実効行数など様々なものがある。
> だがそれらは、ソフトウェアの品質を客観的に判断する必要があるときには重宝するが、
> 設計やコーディング中にはそれらの数値を気にしてもしかたがない。
> まずは、構造化設計手法を学ぶべきだね。OOPをやる場合でも。
> 循環的複雑度は、ソフトウェアメトリクスの一指標に過ぎず、他にも重要な指標として
> クラス内メソッド数やfan-in/fan-out、各メソッドの実効行数など様々なものがある。
> だがそれらは、ソフトウェアの品質を客観的に判断する必要があるときには重宝するが、
> 設計やコーディング中にはそれらの数値を気にしてもしかたがない。
> まずは、構造化設計手法を学ぶべきだね。OOPをやる場合でも。
気持ち悪
http://monoist.atmarkit.co.jp/mn/articles/1101/19/news089.html
「また、ソフトウェア・メトリクスには、『ソフトウェア・サイエンス（software science）』の『呪縛』もある。
ソフトウェア・サイエンスとは、計算機界のパイオニア、Murray Halsteadが、ソフトウェア工学の基本
的な科学となることを狙って提案したもので、計測する項目と計測方法を厳密に定義した。当時は、
それらしく見え、メトリクスのゴールと思われた。いろいろな研究者が、この技法で測定した数値を分
析したところ、実測値とソフトウェア・サイエンスのデータの間には、相関関係がないか、負の相関関
係があることが分かった。中には、占星術と関連付ける人もいた。プロジェクトの『科学的』なデータ
は、汚名にまみれ、大部分はゴミ箱いきとなった。ソフトウェア・サイエンスが崩壊した状況を知って
いる人は、ソフトウェア・メトリクスすべてを同類と見なし、葬り去ろうとした」
――（『ソフトウェア開発 55の真実と10のウソ』／日経BP出版センター刊、2004年）の第5章より
「また、ソフトウェア・メトリクスには、『ソフトウェア・サイエンス（software science）』の『呪縛』もある。
ソフトウェア・サイエンスとは、計算機界のパイオニア、Murray Halsteadが、ソフトウェア工学の基本
的な科学となることを狙って提案したもので、計測する項目と計測方法を厳密に定義した。当時は、
それらしく見え、メトリクスのゴールと思われた。いろいろな研究者が、この技法で測定した数値を分
析したところ、実測値とソフトウェア・サイエンスのデータの間には、相関関係がないか、負の相関関
係があることが分かった。中には、占星術と関連付ける人もいた。プロジェクトの『科学的』なデータ
は、汚名にまみれ、大部分はゴミ箱いきとなった。ソフトウェア・サイエンスが崩壊した状況を知って
いる人は、ソフトウェア・メトリクスすべてを同類と見なし、葬り去ろうとした」
――（『ソフトウェア開発 55の真実と10のウソ』／日経BP出版センター刊、2004年）の第5章より
>>25の続き
> 確かに、アメリカ人の年配のプログラマとソフトウェア・メトリクスの話をすると、
> までも、不快な顔をする人がいます。おそらく、ソフトウェア・サイエンスと混同していると思うのですが、
> たかだかソフトウェアの1つの技術なのに、そこまで嫌悪感を催すことに大きな感銘を受けた覚えがあります。
> ソフトウェア・サイエンスが、ソフトウェア開発のプロセス改善の切り札になると信じていたのに、
> 裏切られた……。かわいさ余って憎さ100倍というところです。
必死で、循環的複雑度を否定している人もこの仲間っぽいなｗ
さらに続き
> テーマ その3：メトリクスの意味
>
> ソフトウェア・メトリクスの数値は何を表現するのか？ これについても、いろいろな人が議論しました。
> まず、「循環的複雑度は、1つのプログラム・モジュールの複雑性を表している」というところからはじまり、
>「では、ソフトウェア全体の複雑度を求めるには、すべての構成モジュールの複雑度の総和を計算すればよい」と進みました。
そうそう、ここまでは良い。
>問題はここからです。
>
>「複雑度ではなく、ソフトウェアの品質そのものを計測したい」という“大きな欲”が出まし
>た。ある意味、必然的な流れなのですが、これが大紛糾のもとになったのです……。
もう二度とそこまで行かないようにしないとな。
> こぢんまりと複雑性を計測していたうちはよかったのですが、話が「ソフトウェアの品質測定」
> まで大きくなった途端、挫折したのです。これも、ソフトウェア・メトリクスにとって、
> 不幸の1つと思えてなりません。
循環的複雑度は正しく使いましょうという話。
> 確かに、アメリカ人の年配のプログラマとソフトウェア・メトリクスの話をすると、
> までも、不快な顔をする人がいます。おそらく、ソフトウェア・サイエンスと混同していると思うのですが、
> たかだかソフトウェアの1つの技術なのに、そこまで嫌悪感を催すことに大きな感銘を受けた覚えがあります。
> ソフトウェア・サイエンスが、ソフトウェア開発のプロセス改善の切り札になると信じていたのに、
> 裏切られた……。かわいさ余って憎さ100倍というところです。
必死で、循環的複雑度を否定している人もこの仲間っぽいなｗ
さらに続き
> テーマ その3：メトリクスの意味
>
> ソフトウェア・メトリクスの数値は何を表現するのか？ これについても、いろいろな人が議論しました。
> まず、「循環的複雑度は、1つのプログラム・モジュールの複雑性を表している」というところからはじまり、
>「では、ソフトウェア全体の複雑度を求めるには、すべての構成モジュールの複雑度の総和を計算すればよい」と進みました。
そうそう、ここまでは良い。
>問題はここからです。
>
>「複雑度ではなく、ソフトウェアの品質そのものを計測したい」という“大きな欲”が出まし
>た。ある意味、必然的な流れなのですが、これが大紛糾のもとになったのです……。
もう二度とそこまで行かないようにしないとな。
> こぢんまりと複雑性を計測していたうちはよかったのですが、話が「ソフトウェアの品質測定」
> まで大きくなった途端、挫折したのです。これも、ソフトウェア・メトリクスにとって、
> 不幸の1つと思えてなりません。
循環的複雑度は正しく使いましょうという話。
27 ：今は「反抗期」を乗り越えて「成熟・定着期」です：2013/06/20(木) 22:55:15.44
さらに続き
> はじめは、「ソフトウェア開発を定量的に制御して管理できる」と期待され、前途洋々だったソフトウェア・メトリクスですが、
>以上の4つのテーマに対する大論争を経て、大混乱し、気が付けば反抗期へと突入していたのです……。
>
> 次回は、ソフトウェア・メトリクスの反抗期の後半、および、安定期について解説します。（次回に続く）
流行したスイーツとソフトウェア・メトリクス
http://monoist.atmarkit.co.jp/mn/articles/1102/16/news009.html
> 本コラムでは、図1のようにソフトウェア・メトリクスの歴史を「混乱期」「胎動期」「活動期」「反抗期」
>「成熟・定着期」に分割し、前回活動期の後半と反抗期の前半を取り上げました。
> 今回は、反抗期の後半と成熟・定着期について述べます。
> 次に待っていたのは、「メトリクスは役に立たない」という反抗期でした。
>今回は、反抗期（の後半）から成熟・定着期について解説します。
> 成熟・定着期
>
> 1990年代の前半から、ソフトウェア・メトリクスは成熟・定着期に入り、現在へ至っています。
> 40年前の混乱期に戻った感がありますが、一部の組織ではメトリクスが定着しました。
> この状況は、日本での“スイーツの流行”に似ています。
> メトリクスもこのスイーツと同じ道をたどりました。メトリクスに夢破れた会社が多かったのですが、
> 流行していた間にメトリクスの意義や効果に目覚め、自社内に定着させたところも少なからずありました。
> そんな会社では、ソースコードの行数（LOC）と発生バグ数を軸に、各社独自のメトリクスを開拓して、
> ソフトウェア開発に役立てているのです。独自メトリクスの例として、以下のものがあります。
> アメリカでは、航空宇宙局や国防総省のように、高品質ソフトウェアを大量に開発しなければならない
> 政府機関がメトリクスの研究も進め、その結果を公表しています。うらやましい限りです。
> はじめは、「ソフトウェア開発を定量的に制御して管理できる」と期待され、前途洋々だったソフトウェア・メトリクスですが、
>以上の4つのテーマに対する大論争を経て、大混乱し、気が付けば反抗期へと突入していたのです……。
>
> 次回は、ソフトウェア・メトリクスの反抗期の後半、および、安定期について解説します。（次回に続く）
流行したスイーツとソフトウェア・メトリクス
http://monoist.atmarkit.co.jp/mn/articles/1102/16/news009.html
> 本コラムでは、図1のようにソフトウェア・メトリクスの歴史を「混乱期」「胎動期」「活動期」「反抗期」
>「成熟・定着期」に分割し、前回活動期の後半と反抗期の前半を取り上げました。
> 今回は、反抗期の後半と成熟・定着期について述べます。
> 次に待っていたのは、「メトリクスは役に立たない」という反抗期でした。
>今回は、反抗期（の後半）から成熟・定着期について解説します。
> 成熟・定着期
>
> 1990年代の前半から、ソフトウェア・メトリクスは成熟・定着期に入り、現在へ至っています。
> 40年前の混乱期に戻った感がありますが、一部の組織ではメトリクスが定着しました。
> この状況は、日本での“スイーツの流行”に似ています。
> メトリクスもこのスイーツと同じ道をたどりました。メトリクスに夢破れた会社が多かったのですが、
> 流行していた間にメトリクスの意義や効果に目覚め、自社内に定着させたところも少なからずありました。
> そんな会社では、ソースコードの行数（LOC）と発生バグ数を軸に、各社独自のメトリクスを開拓して、
> ソフトウェア開発に役立てているのです。独自メトリクスの例として、以下のものがあります。
> アメリカでは、航空宇宙局や国防総省のように、高品質ソフトウェアを大量に開発しなければならない
> 政府機関がメトリクスの研究も進め、その結果を公表しています。うらやましい限りです。
馬鹿と鋏は使いよう
便利な道具でも、使い方を間違ってたら役立てるのは難しい
便利な道具でも、使い方を間違ってたら役立てるのは難しい
29 ：仕様書無しさん：
>>2
クソワロタ
クソワロタ