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

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

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

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

**仕様書無しさん** · 2013/06/12(水) 00:09:31.90

>>207
糞コテ。このスレ的には、スレでオナニーJava講義をおっぱじめてた馬鹿。
やってほしいことは俺の講義でを学ぶこと→ここに書くべきは俺のJava講義。
講義内容は…偉そうな勘違いJava土方の自慰行為と言った感じ。
講義の全部が全部間違ってるわけではないが、まじめに聞く価値はないだろうな。

**仕様書無しさん** · 2013/06/12(水) 00:54:24.24

>>198
それ最悪だなｗただのグローバル変数

**おじゃばさま** ◆mpgYduuqtA · 2013/06/12(水) 01:15:28.87

オブジェクト指向の基礎も理解していないのに、
DIコンテナだのデザインパターンだの
言っている人がいたから、
ソースコード付きで基礎を教えて
あげたんだよ。

**おじゃばさま** ◆mpgYduuqtA · 2013/06/12(水) 01:43:41.91

循環的複雑度をリファクタリングの
目安にすると言っているのか？
素人考えだな。
行が増えたから関数分割すると
いうのと変わらない。
初心者のうちは仕方ないが、
オブジェクト指向なら、複数の機能
（オブジェクト要素）が混じって
いないかで判断するべきだ。

**仕様書無しさん** · 2013/06/12(水) 01:52:42.10

久しぶりだなハゲ！
基礎できてないのに応用を覚えろって言うのはバカだけど、あの時はお前も結構会話かみ合ってなくて酷かったぞｗｗｗ

複雑度高いと多機能な関数になってること多いから、あながい間違いでもないと思うんだが。
数値下げるために分割したら目的見失ってるけどな。

**仕様書無しさん** · 2013/06/12(水) 01:57:28.89

>>208
サンクス。どのスレにも持論押しつけるバカはいるもんだな。

**仕様書無しさん** · 2013/06/12(水) 02:01:01.59

あ気付かなかった、この人かｗ
オナニーJavaであだ名がおじゃばかと思ったらそのものコテなのか。
ホント悪い、聞くのやめといた方が良かったみたいだ。

**仕様書無しさん** · 2013/06/12(水) 02:47:14.88

どうせ遅かれ早かれ湧いたんじゃねぇかな
ここまでレスしてなかった(コテつけ忘れてた)事が不思議な位

**仕様書無しさん** · 2013/06/12(水) 03:19:16.48

NG推奨

**仕様書無しさん** · 2013/06/12(水) 08:32:24.63

オナニーJavawww

**仕様書無しさん** · 2013/06/12(水) 10:26:59.50

呼んでないのに来ちゃったー
他のスレ散々荒らしてんだからそこで満足してくれよorz

**仕様書無しさん** · 2013/06/12(水) 10:29:22.66

おじゃばの話は何故か最後まで読んでしまう
1行目にトンチンカンなことが書いてなかったりするから

ただ最後まで読むと「で！？」ってなる

**仕様書無しさん** · 2013/06/12(水) 10:34:28.90

コード打つ時はオーケストラを流す

**仕様書無しさん** · 2013/06/12(水) 11:08:10.77

循環的複雑度を計測するソフトの導入が現実的ではない
循環的複雑度が低くなるように処理が分割された詳細設計書は
これじゃ全体的な動きがよくわからんで却下されるし
当然コーダーの裁量で仕様書にない関数を作るのもありえない

**仕様書無しさん** · 2013/06/12(水) 12:02:22.50

>>221
そういう環境にいる人は人間コードジェネレータなんだから
品質とか余計なことは考えなくていいんだよ
だから循環的複雑度の導入を検討する必要はないし、興味をもつ必要もない
プログラマじゃないんだからマ板に書き込むのも板違い

**仕様書無しさん** · 2013/06/12(水) 13:52:52.23

そういう完全にコーディングだけ！って人は黙って社畜になれよ
自分で設計してコーディングする開発者も増えてるんだから

**仕様書無しさん** · 2013/06/12(水) 14:45:24.16

くだらない数値測って悦に浸ってないで
最初から疎結合にしてドキュメントに書け糞コーダ―

**仕様書無しさん** · 2013/06/12(水) 20:30:29.25

>>209
それで内部の状態変わるんだよ。
いまどきシングルスレッドなんてそんなに無いからさ……

**仕様書無しさん** · 2013/06/12(水) 21:23:49.34

>>221
> 循環的複雑度を計測するソフトの導入が現実的ではない

なんで？ Perl、Ruby、JavaScriptは
それぞれその言語用のパッケージシステムから
普通にインストールするだけ。perlだったらcpan。

それだけでコマンドが使えるようになる。

Javaの場合はEclipseのプラグインを入れるだけ。
NetBeansを使ってるなら知らないが。

**仕様書無しさん** · 2013/06/12(水) 21:26:23.09

やっぱりどうあっても、循環的複雑度の計測に
反対する人がいるんだね。

循環的複雑度を計測することは、メリットになっても
デメリットになることは何一つ無いのに。

**仕様書無しさん** · 2013/06/12(水) 21:40:33.25

計られると困るんだろ?

**仕様書無しさん** · 2013/06/12(水) 22:14:08.92

プロジェクト全体において、循環的複雑度が高い関数が
多数存在するが、そのすべてが綺麗なコードだった場合に、
やらなくてもいい修正が発生するデメリットが有る。

んなことはまず有り得ねーよｗ

**仕様書無しさん** · 2013/06/12(水) 23:43:47.26

>>227
計測せずとも一目瞭然な糞コードが山になってるから、
計測するだけ時間の無駄ってケースはあるかも。

循環的複雑度的糞コードは目視でも直ぐそれとわかるしな。

**仕様書無しさん** · 2013/06/13(木) 00:15:18.62

まぁ、ぱっと見でゴチャゴチャしてる関数はバグるから、小綺麗になおせってだけの話なんだけどな。
その指数に名前をつけると拒絶反応起こす奴がいると言う。

**仕様書無しさん** · 2013/06/13(木) 00:22:29.48

>>230
一目でプロジェクト全体の関数が
どうかなんてわかるわけ無いじゃん。

**仕様書無しさん** · 2013/06/13(木) 00:41:30.51

229と同じく反対理由が合理的なケースを考えてみただけで、これは片っ端から全部糞ってケースの話。
比較的良質なコードの中の不味そうな部分を探すとか、そういう用途を否定する気はないよ。

複雑度を計ったらゴミばっかりで、複雑度が低い関数もゴミだらけ、ときたら計るだけ無駄と言う他無い。

**仕様書無しさん** · 2013/06/13(木) 01:21:16.44

同じ処理で循環的複雑度の高いソースと低いソースがあれば一目瞭然かもな。
まず関数分割とか論外な方法を使ってないこと前提。
当然一方はif連続、一方は正規表現みたいなわざとらしいのも論外。
動的関数名も言語依存があるので、あまり好ましくない。
なるべくプレーンなソースで。

循環的複雑度の人、頼む。

**仕様書無しさん** · 2013/06/13(木) 01:54:23.14

>>225
うわあ
聞いただけで吐き気してくる

**仕様書無しさん** · 2013/06/13(木) 02:29:54.53

このなんというかおじゃばくさい流れはやめよう
これ以上循環的複雑度について(このスレ的な意味で)語るべきことってないよ

循環的複雑度の流れってことで、リファクタリングのポイントとか、そういうのはどうだろう
過去にも結構出てると思うけど

**仕様書無しさん** · 2013/06/13(木) 02:31:41.31

>>234
> 当然一方はif連続、一方は正規表現みたいなわざとらしいのも論外。

そうはいうがな。実際にそういうコードが有るのだよ。

if ($v eq 'aaa' or $v eq 'bbb' or $v eq 'ccc’ or $v eq 'ddd') {}

こういうのとかな。

if ($v =~ /^(aaa|bbb|ccc|ddd)$/) {}

**仕様書無しさん** · 2013/06/13(木) 02:38:18.95

>>234
> まず関数分割とか論外な方法を使ってないこと前提。
関数分割が何を言ってるのかしら無いが、
まず、長い関数を前後二つに分割するなんてことは当然しない。

だけど、中にある一部の処理に名前をつけて関数にするということはよくやる。
というか循環的複雑度を下げる一番重要な方法。

コードの簡単な書き換えでも減ることはあるけど、
それは減らすというか削るみたいなもの。

一番重要なのは、関数に分けることだよ。
なぜならそれがコードを正しく修正する方法でしょ？

※循環的複雑度を下げるのが目的ではない
コードを正しく修正することで、結果循環的複雑度が下がる。

**仕様書無しさん** · 2013/06/13(木) 02:47:22.59

おいおい、IDが出ないのをいいことに連投するのはやめようぜ

**仕様書無しさん** · 2013/06/13(木) 02:49:05.83

複雑すぎるコードというのは
処理が多いだけではなく、コードの書き方も冗長なことが多い。

基本的に技術力が低いから、複雑なコードを生み出すので
そういう人が書いたコードが冗長になるのは当たり前といえよう。

その結果複雑で長くなったコードは
>>238のいう「削る」ことで循環的複雑度を下げていくことで
見通しを良くしていくということもよくある。

**仕様書無しさん** · 2013/06/13(木) 02:50:01.84

>>239
連投されたくなければ、間にお前がなんかレスしろよｗ
そんなくだらないレスじゃなく、ちゃんと会話になっているレスな。

**仕様書無しさん** · 2013/06/13(木) 04:24:17.01

循環的複雑度を計測することには意味がないという仮想敵を作って、
長々と意味のないレスを繰り返す。

**仕様書無しさん** · 2013/06/13(木) 08:12:12.82

>>237-238
でもこのマ板にいるプログラマは>>234は当然クリアしている。
必要に応じて適度に関数を分割し、正規表現が好ましい箇所は
それを利用する。当然人が読みやすいコーディングも心がけている。
サポートに堪えないコーディングは自身の首を絞めるだけだから。

その上で循環的複雑度が高いソースはある。
そういう例を上げて欲しいんだよ。

**仕様書無しさん** · 2013/06/13(木) 08:28:17.34

>>241
やっぱり一人で暴れてたのか…
大人げない

**仕様書無しさん** · 2013/06/13(木) 08:37:00.80

>>238
関数を真っ二つにするという発想が飛び出てくるのがまずおかしい。コメディアンすぎるｗ

処理の関数化は有用だしマなら皆当たり前にやってることだが、
何事もやりすぎればただ追いにくくなるだけで本末転倒、てことも皆知っている。

ということで、循環的複雑度君のいう綺麗なソースと汚いソースがどんなものなのかよく見えないから
実際のソースを見比べて確かめたいんだ。サンプルならいっぱい持ってるでしょ？

**仕様書無しさん** · 2013/06/13(木) 08:43:18.87

手段が目的化してるってこういうのを言うのか。

**仕様書無しさん** · 2013/06/13(木) 09:40:30.69

お前らまだこの話続けてんのかよ。
だから、そもそも使い方が間違ってるんだって。

開発段階で複雑度を出すのはいいけどな、そこで複雑度が高いメソッドだけに
注目して複雑度を下げようとか、高くても綺麗なコードだとか言っても無意味だって。
第一、そんなもの数値で出すまでもなく、開発担当者にとっては一目瞭然だからな。

本来は、あくまでも全体の傾向を見るための道具。
PDCAサイクルでいうCheckの段階で使うものな。そのためにはまず平均値だ。

道具としての使い方を間違った上で、まぬけな議論をかわしてるから
アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。

**仕様書無しさん** · 2013/06/13(木) 10:20:45.29

逃げたｗ
別人のふりをするのが下手ックソな多重人格君は嫌いじゃない

**仕様書無しさん** · 2013/06/13(木) 10:38:09.06

>>245
そう言うが、処理ぶつ切り関数とか、副作用のあるなしを考えずにやる細切れ関数とか、何度も見た俺からすると、
純粋に>>238の言う様な基礎の基礎をみんなに守らせる事こそ、コード全体の質の底上げに繋がると思う。

関数の分割で処理が追いにくくなるのは、機能分割と命名が下手だから。
恥ずかしい自己紹介になってるぞ。

あと、マならあたり前だからこそ、初心者に伝えるべきなんじゃねーの？
お前いちゃもんつける態度こそスレ違いだと思うんだが。

**仕様書無しさん** · 2013/06/13(木) 10:57:13.00

>>247
> アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。

え？あるでしょ。
凝集度が低いとか、結合度が高いとか。

**仕様書無しさん** · 2013/06/13(木) 11:08:19.44

>>247
> PDCAサイクルでいうCheckの段階で使うものな。そのためにはまず平均値だ。

まだ言ってるの？
循環的複雑度が100のメソッドが10個、5のメソッドが1000個ある場合と、
6のメソッドが1000個ある場合では平均値は同じ。
よって平均値に意味は無い。

はい、論破。

**仕様書無しさん** · 2013/06/13(木) 11:25:40.18

平均値馬鹿はほんとあきらめないな

**仕様書無しさん** · 2013/06/13(木) 13:50:12.20

また循環的複雑度だけで、何百レスも消費するつもり？

**仕様書無しさん** · 2013/06/13(木) 14:24:33.04

おい、複雑度スレ立ててそっちでやれ
スレタイ読めないのか頭が致命的に悪いのかどっちなんだ

**仕様書無しさん** · 2013/06/13(木) 14:37:31.04

ツールや指標があってもそれが何を意味するのか分かっていないと何の役にも立たない。
それどころか狂った方針を立ててプロジェクトを引っ掻き回す。

だから数学は必要。

**仕様書無しさん** · 2013/06/13(木) 16:30:09.88

コード書く前に中学校卒業しろってこと?

**仕様書無しさん** · 2013/06/13(木) 19:34:38.97

おまえらＮＧ登録しやすいようにちゃんと「循環的複雑度」って書いてからレスしろよ。

**仕様書無しさん** · 2013/06/13(木) 21:16:55.81

>>250
あるというのなら、
出せばいいだけだと思うんだが？

複雑度が低くても糞なコード。

そしたら、それが改善のネタにもなる。
さあどうぞ。証明してくれ。

**仕様書無しさん** · 2013/06/13(木) 21:19:36.71

>>258
は?
凝集度が低いとか結合度が高いで通じないの？

**仕様書無しさん** · 2013/06/13(木) 21:33:17.11

>>259
意味は通じる。

だが証拠は別の話。
その人が証拠をだせる能力を
持っているのか試している。

どんなに偉そうなことを言っても
その人に力がなければ説得力はうまれない。

**仕様書無しさん** · 2013/06/13(木) 21:37:47.21

ttp://d13n9ry8xcpemi.cloudfront.net/photo/odai/400/debb710822534507b5695c886af49184_400.jpg

**仕様書無しさん** · 2013/06/13(木) 21:45:03.22

>>261は「だまれ」の看板。

はい、話し続行。

**仕様書無しさん** · 2013/06/13(木) 21:50:53.08

看板じゃなくて標識な

**循環的複雑度** · 2013/06/13(木) 22:10:21.08

void hukuzatudohikui()｛doya()；｝

**仕様書無しさん** · 2013/06/13(木) 22:44:16.20

コードが複雑になるのって、コードの分け方を知らないからだよ。
関数の分割で処理が追いにくくなるのも同じ。分け方を知らないからそうなる。

まず最初のアプローチとしては、関数の中を追わなくてわかる関数を作ること。
いい例が各言語についている標準ライブラリ。
あれは関数の中を追わなくてもコードが追えるでしょ？
まずそういうのを作る。

まあたいていは標準・非標準のライブラリで事足りるのだが、それでも足りないものはある。
それを汎用関数にして、関数の中を追わなくてもわかるようにする。

循環的複雑度で良いとされる10以下のコードってほとんどはすごく短いコードなんだよ。
ほんの数個ifやforがあるだけで10なんて簡単に超えるからね。本質的なコード行数で言えば十数行程度だろう。
そんな短いコードで関数にしてもいいんだってことに気づくことが重要。

よくあるのが、この程度だから関数の中にそのまま書いちゃえってやつ。
長いコードというのは、これの積み重ねでどんどん長くなる。
10行のコードでも10回埋め込めば100行だからね。
次第にこれが複雑に絡み合ってくる。

**仕様書無しさん** · 2013/06/13(木) 22:45:36.30

次にやるべきなのがコードを各層にわけるということ。
データベースを扱う層や、UIを扱う層みたいに
そして各層では決められたことしかしない。

コードが複雑になってるのは、全ての処理を一つの層でやろうとしているから。
一つの関数でやってる仕事の種類が多くなってしまうから複雑になる。

まとめると一つの関数で複数の仕事を関数を使わないで処理するから複雑になる。

凝集度が低いとか、結合度が高いというのは言い換えると関数の分け方を知らないわけで、
つまりは関数を分けずに長ったらしく書くので必然的に循環的複雑度はあがる。

意図的に変なコードを書かない限り、凝集度が低い・結合度が高い（クソコード）なのに
循環的複雑度が低いというのは矛盾するんだよ。

**仕様書無しさん** · 2013/06/13(木) 23:27:59.62

>>266
凝集度が低いか結合度が高いコードは、循環的複雑度が高いと？
ご冗談を。
ム板に嬉々として数十行くらいのコードを貼る奴のコードは、
大抵、凝集度が低いか結合度が高いか、あるいは別の原因で糞コードに
なってる場合が多いが、循環的複雑度は大抵低い。

**仕様書無しさん** · 2013/06/13(木) 23:30:47.04

前スレのおじゃばのコードは、メソッド内の行数も少なく、循環的複雑度も低いが糞コードだった。

はい、論破。

**仕様書無しさん** · 2013/06/13(木) 23:34:18.99

>>267
> 凝集度が低いか結合度が高いコードは、循環的複雑度が高いと？

はい、そうです。

なぜならば結合度が高いコードは、多くのコードが結合しているわけで、
コードが多いならば循環的複雑度も高くなる傾向にあります。

凝集度が低い場合も、凝集度が低い＝コードがあちこちに分散している。＝処理を行うには
あちこちのコードを結合しないといけない。結果多くのコードが必要なります。

コードの行数が増えれば必然的に循環的複雑度も高くなります。

**仕様書無しさん** · 2013/06/13(木) 23:38:09.98

えっと、循環的複雑度ってメソッド単位なんだが・・・

**仕様書無しさん** · 2013/06/13(木) 23:41:04.19

そのメソッドで他の関数呼び出すでしょ？

**仕様書無しさん** · 2013/06/13(木) 23:43:38.45

>>269
まず、結合度が何かを調べてから出直してくれないかな。

**仕様書無しさん** · 2013/06/13(木) 23:44:40.99

結合度が低ければ、ある関数から呼び出す、他のモジュールも少なくなる（結合してないから）
よってモジュールを組合わせるコードも減る＝循環的複雑度も下がる。

凝集度が低ければ、ある関数で処理を行うために、いくつものモジュールを
組み合わせなくてはいけなくなる。その分のコードが増える＝循環的複雑度は高くなる。

**仕様書無しさん** · 2013/06/13(木) 23:46:19.60

>>272
結合度が高いってことは、ある処理でAとBとCとDとEに依存しているわけですよ。
AとBとCとDとEに依存しているってことは、AとBとCとDとEを組み合わせて使ってるってこと。
組み合わせるにはコードが必要。結果コード量が多くなる。循環的複雑度も高くなる。

**仕様書無しさん** · 2013/06/13(木) 23:51:51.82

>>271
呼び出すかどうかはメソッドによるだろうけど、そのことと循環的複雑度がメソッド単位である
ということにどんな関係があると言うんだ？

**仕様書無しさん** · 2013/06/13(木) 23:54:33.38

>>274
循環的複雑度がとても高いメソッドをA, B, C, D, Eに分割したら、それぞれの循環的複雑度は下がるのだが。

**仕様書無しさん** · 2013/06/13(木) 23:56:44.62

>>276
わかってないね。
結合度が高いというのは、分割できないということ。
分割してしまえば、結合度は下がる。

**仕様書無しさん** · 2013/06/13(木) 23:58:12.40

>>274
おいおい、結合度って呼び出すかどうかで0と1とかそういう話じゃないぞ。
ググってから出直せ。

**仕様書無しさん** · 2013/06/13(木) 23:58:32.29

>>258
複雑度が低くても糞なコードの作り方
1、適当な関数を1個持ってくる
2、細切れにして関数を分割し続ける
「int main(){std::cout<<"Hello, world!"<<std::endl;return 0;}」の変換例
std::ostream& getOutputStream(){return std::cout;}
char* getHelloWorldString(){return "Hello, world!";}
std::ostream& getHelloWorldStringOutputStream(){return getOutputStream();}
std::ostream& getEndLineOutputStream(){return getOutputStream();}
void putHelloWorldStringToOutputStream(std::ostream& stream){stream<<getHelloWorldString();}
void putEndLineToOutputStream(std::ostream& stream){stream<<std::endl;}
void putHelloWorldString(){putHelloWorldStringToOutputStream(getHelloWorldStringOutputStream());}
void putEndLine(){putEndLineToOutputStream(getEndLineOutputStream());}
void putHelloWorldLine(){putHelloWorldString();putEndLine();}
int main(){putHelloWorldLine();return 0;}

**仕様書無しさん** · 2013/06/13(木) 23:59:55.02

>>277
ちょっともう何を言ってるのかさっぱりわからんわ。

**仕様書無しさん** · 2013/06/14(金) 00:05:33.14

>>279
典型的なわざとらしいコードだね。

フォーマッターにかければ解決するようなもの
何の問題にもならんわ。

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

循環的複雑度の低いメソッド同士が内容結合してると、それは糞コード。

はい、論破。

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

>>280
わからないことがあるのなら、努力したまえ。

**仕様書無しさん** · 2013/06/14(金) 00:08:56.89

ひょっとしてあれか、循環的複雑度の定義も理解しないまま平均平均言ってたのか？

**仕様書無しさん** · 2013/06/14(金) 00:12:22.03

>>265-266
途中までまともだったのに、最後の二段落で台無し。

**仕様書無しさん** · 2013/06/14(金) 00:16:25.05

ム板の宿題スレとVBAスレで、外部コード共有サービス使ってコード貼ってる奴の
コードを見れば、循環的複雑度が低いのに糞コードな例を思う存分堪能できます。

**仕様書無しさん** · 2013/06/14(金) 00:17:34.86

>>285
じゃあ最後の二段以外に、いいレスって言えばいいよ。
その他は間違ってないんだからさ。

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

>>286
じゃあ堪能したコードを教えて下さい。
そのコードの循環的複雑度はもっと下がるでしょうから。

**仕様書無しさん** · 2013/06/14(金) 00:20:31.99

>>287
最後の二段落以外もそれほど良い内容ではない。

**仕様書無しさん** · 2013/06/14(金) 00:20:53.60

ああ、自分が読めないコードが糞コードの人か

**仕様書無しさん** · 2013/06/14(金) 00:21:23.66

>>288
自分で見に行けよ

**仕様書無しさん** · 2013/06/14(金) 00:22:34.55

承認要求が強すぎる困ったちゃん

**仕様書無しさん** · 2013/06/14(金) 00:25:12.69

循環的複雑度に凝集度と結合度が加わって、この話題で500までは行くかな。
スレ全部食い尽くすかもしれん。

**仕様書無しさん** · 2013/06/14(金) 00:28:23.50

ほらな。
結局、コード出せといっても
だせない。

あ、わざとらしいコードはいらんよ。

**仕様書無しさん** · 2013/06/14(金) 00:32:16.63

なにがほらなだよ。
まず結合度をググってこい、アホ。

**仕様書無しさん** · 2013/06/14(金) 00:35:39.54

論破されまくってるのに気づかない馬鹿

**仕様書無しさん** · 2013/06/14(金) 00:38:03.29

凝集度の話が出てるようなので、
今度は循環的複雑度ではなく、LCOM、計測してますか？ｗ

http://www.itmedia.co.jp/im/articles/0510/07/news106.html

LCOMってのは言語によって計測しづらいんだよな。
参照しているメソッドやフィールドの数で計算するから
動的型付け言語だと、何を参照しているか（実行時に決まるので）わからない。

Javaだったらこの記事のようにプラグインがあるんだが。

**仕様書無しさん** · 2013/06/14(金) 00:39:55.94

>>281
わざとらしかろうがクソには違いあるまい。
実際には良かれと思って分割されたり抽象化されたりした関数やクラスが山と連なる、とかだろうけど。

で、細切れにされた関数をインライン展開とかで復元できるフォーマッタってあんの？
レス行数考慮して改行は潰したが、そこは本題じゃないし。
これの健全化は自動処理できたとしてもフォーマッタの仕事じゃないだろ。
リファクタリングツールの仕事で、つまり糞コードの改修という仕事。

**仕様書無しさん** · 2013/06/14(金) 00:43:13.04

>>297
LCOMは初めて知ったな。

そのリンクの前編の頃にツール名がでてたけど、ほとんどJava用ばっかりだな。
ウェブ系でよく使われる言語ののツールって無いんだろうか？

**仕様書無しさん** · 2013/06/14(金) 00:47:03.73

>>299
> ウェブ系でよく使われる言語ののツールって無いんだろうか？

しらない。ぶっちゃけウェブ系の言語（だいたいが動的型付け言語）では
厳密な計測は不可能だと思ってるけどね。

こういうメトリクス計測ってのはソースコードを静的に解析する。
つまり静的に情報がわかれば計測できるが
そうでなければ計測できない。

だから、動的型付け言語の発展に将来はないと思っているが
それはまた別の話だな。

**仕様書無しさん** · 2013/06/14(金) 00:48:51.67

どんなメトリクスでも共通して言えることは、あるコードがそのメトリクスで良い数値を
出しているからといって、必ずしも良いコードではないということ。

メトリクスを収集する目的は、悪い数値を出す悪いコードを検出するのと、そのコードを
改善したときの進行具合を測るのに止めるのが良い。

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

>>300
動的型付け言語でも静的解析はできるでしょ

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

>>301
> どんなメトリクスでも共通して言えることは、あるコードがそのメトリクスで良い数値を
> 出しているからといって、必ずしも良いコードではないということ。
誰も違うとは言ってないのに、なぜかここだけゴリ押しする馬鹿
言わなきゃ困る理由でもあるのかね？

**仕様書無しさん** · 2013/06/14(金) 00:59:29.44

>>302
出来るできないの二元論ではなく
どれだけできるかという話。

どれだけ静的解析できるかの話をすれば
動的型付け言語は、静的型付け言語に比べて
圧倒的に少ないと言わざるをえない。

LCOMの計算式を見ればわかるが、
・着目しているクラスのj番目のメンバ変数
・着目しているクラスのメンバ変数の個数
・着目しているクラスのメソッドの個数
・メンバ変数Ajにアクセスしているメソッドの個数

こういう値を変数として利用する。
だが動的型付け言語では、着目しているクラスが
動的に決定されるので、着目しているクラスの情報が得られない。

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

>>303
>>258

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

>>290
これは言えてると思う
英語に拒絶反応示す人だと、簡単なメソッド名すら理解できなくて
実装のほうにジャンプして中確認しないといけないことに文句言ったりする
メソッド名見るだけで意味はわかるのに、それができないってやつ

実際の職場とかだと糞いメソッド名な事もあるけど、このスレで出てるのって、そういうレベルの話ではないしな

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

このコード出せうんたらの流れ、前スレでも見たな
その時はコテついてたけど