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

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

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

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

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

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

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

>>305
これほど明確な疑問文ですら、自分が何を問われてるかも分からんのか？

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

>>304
俺はLCOMというのは初めて知ったが、説明を読む限りクラス内に閉じたメトリクスなので、
RubyやPHPでも計算できると思うけど。
もちろん、循環的複雑度も計算できる。

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

>>308
言わなきゃ困る場合なんてそうそうない。
普通はただ単に言いたいから言うだけだ。
そして、今回の発言動機は>>258の存在。

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

動的型付け言語が何なのか知らないバカも登場し、ますますスレは混沌となっていくのであった

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

静的解析の静的がわからないんじゃなかろうか

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

>>303 >>308
> 誰も違うとは言ってないのに
247「アホが「複雑度が低くてもクソなコードはある」とか言いだすんだよ。」
すなわち「複雑度の低いクソなコードはない」と言っている
258「あるというのなら、出せばいい」「複雑度が低くても糞なコード。」「さあどうぞ。証明してくれ。」
すなわち「複雑度が低くても糞なコードは出てこない」という前提でレスしている
> 言わなきゃ困る理由
以上のようにバカは何処にでもいるので、蛇足だろうと過信すべきでないという警告は必要である
必要とする者が要る以上、俺はいらないから不要ってだけの理論は通用しないんだよ
既にあるものを不要としたいなら、必要を上回る欠点なりなんなりが無いとね

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

>>310
そうか、ならよかった。
だが、>>258も含めて皆そんな事分かった上での話だから
お前がわざわざでばってきて、ゴリ押しする必要はないよ。
すっこんでいて下さい

**おじゃばさま** ◆mpgYduuqtA · 2013/06/14(金) 01:24:40.63

君達、基本が出来てないな。
循環的複雑度が低い糞コードは
基本の逆をやればいい。
つまりオブジェクト指向で、
処理で分割したり、
構造化で変数のスコープを無視して、
グローバル変数を使いまくったり
すればいい。

循環的複雑度が高くても問題ない
コードは、分岐が多くても
基本に外れてない物ならいい。
つまり、項目数の多い入力チェック
などだ。

誰かも書いていたが、結局モジュール
分割の基本を知らずに循環的複雑度
がどうとか言っているのが問題
なのだろう。

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

あら、また馬鹿がｗ

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

>>314
君が>>258ならそれで良いが、もし違うのなら>>258が俺が言ったことを理解しているとは言い切れないだろう。
そして俺は>>258は、俺が言った程度のことすら理解していないと見える。

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

>>314
258はどう考えてもそんなことすらわかってないだろｗ

同僚に258みたいなのがいて
「わかってて冗談言ってるんだ…きっとそうだ…そうに決まってる…」
とか現実逃避でもしてんのか君

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

おっと、二人称まで同じ似たような発言が・・・。
まあ、俺はまた暫く黙るから安心してくれ。

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

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

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