今までみた絶望的なソースコード [転載禁止]©2ch.net

**デフォルトの名無しさん** · 2015/04/17(金) 23:00:30.63

今井氏：ソースコード公開は、社長のティム（*2）の意向です。彼はバリバリのプログラマーで、初期の「Unreal Engine 1」を
1人で書いた人ですが、若い時に雑誌に載っていたコードを書き写して勉強したそうです。それで今の若い人にも、プロのソー
コードとはこういうものだというのを見せたいという願いがあって、ソースコードを公開しています。本当に今のゲーム業界の
事情を憂いてる1人だと思います。（*2）Epic Gamesの創業者兼CEOであるTim Sweeney氏

出村氏：読みやすいコードですよ。「C++」というのは、黒魔術（高度な計算）が多くなりがちな言語ですが、
そういうこともなく、すっきりしていて目的の機能も探しやすい。解読しやすいコードなので、確かにお手本になると思います。

僕は初代のゲームボーイからプレイステーション 2の頃くらいまでゲームプログラマーだったのですが、ゲームプログラミングでは
必ず数学が出てきます。行列とか三角関数とか。もちろん今でもまったく不要になったわけではありませんが、そういう知識の
重要性は薄れてきていると思います。「Unreal Engine」では特にそうです。
http://game.watch.impress.co.jp/docs/interview/20150417_698349.html

初級者から中級者へ昇格する時期は、ほぼどのようなソースコードでも読める程度にプログラミング言語に精通し、
また偉いプログラマーの提唱したデザインパターンも一通り理解したくらいの時期である。

すると、プログラミング言語の持つあらゆる機能と、偉いプログラマーの提唱するあらゆる技術を使わねばならない
という思い込みが発生する。そしてHello Worldにまで崇高なオブジェクト指向や壮大なデザインパターンを
適用しようとしだすのである。

その結果、
* 大量のクラス
* 迷路のような変数渡し
* 底なしに深いネスト
などといった凄いものが生まれる。また、条件分岐に三項演算子を乱用するなどの症状も多く見受けられる。
最終的には第三者にとって読みにくい保守性の悪いスパゲッティコードが生成されることになる。
http://monobook.org/wiki/%E4%B8%AD%E7%B4%9A%E8%80%85%E7%97%85

**デフォルトの名無しさん** · 2015/12/07(月) 07:56:35.00

開放領域への参照で落ちて地獄のデバッグよりか遥かにまし

**デフォルトの名無しさん** · 2015/12/07(月) 09:53:30.69

C++の世界って相変わらず
ごちゃごちゃしてんのなｗ

動くのに間違いっていうのが多すぎる

**デフォルトの名無しさん** · 2015/12/07(月) 10:15:40.28

>>594
銀行だろ

**デフォルトの名無しさん** · 2015/12/07(月) 15:38:41.09

>動くのに間違い

ほんそれ

**デフォルトの名無しさん** · 2015/12/08(火) 21:57:19.96

ループ変数がグローバルにおいてあって、
そのループ変数を使ったfor文の中から呼び出される
各関数内でループ変数がインクリメント・デクリメントされているコードに絶望した覚えがある

**デフォルトの名無しさん** · 2015/12/08(火) 22:39:43.83

やばいなそれ
それ仕様どおりなん？

**デフォルトの名無しさん** · 2015/12/09(水) 10:07:13.59

再帰処理の中で再帰の深さ調べて云々するプログラムにそんなのあったな

**デフォルトの名無しさん** · 2015/12/09(水) 21:23:43.29

>>600
コードが仕様だ！

コーディングミスの副作用が絡み合い何故か動いているのだが
書いたやつやめたから誰も手が出せない、なんとかしろという展開。

**デフォルトの名無しさん** · 2015/12/09(水) 22:54:35.69

　
配列に間違って一つ余計なデータを加える

　　　＋

ループ回数を間違って最後の一つを処理しない

　　　＝

＿人人人人＿
＞正常動作＜
￣Y^Y^Y^Y￣

**デフォルトの名無しさん** · 2015/12/10(木) 00:26:28.57

境界テストすらしない前提なの

**デフォルトの名無しさん** · 2015/12/10(木) 00:28:09.29

関数内部の境界テストはしないね。

**デフォルトの名無しさん** · 2015/12/10(木) 09:15:52.53

番兵さんを「余計なデータ」と言われた事ならある

**デフォルトの名無しさん** · 2015/12/10(木) 12:17:34.93

>>603
最後にnull終端が(暗黙に)期待されてるバグありコードで
たまたまメモリが0で埋まってて動いてるソフトが世界中に沢山ある

**デフォルトの名無しさん** · 2015/12/10(木) 12:28:09.15

C言語でbssセクションに配置された未初期化変数はzero-fillが保証されている
ことを知らない無能は結構多いよね。

**デフォルトの名無しさん** · 2015/12/10(木) 12:36:25.02

お前知ってる無能だな

**デフォルトの名無しさん** · 2015/12/10(木) 13:00:08.77

>>606
余計なデータだろう。
番兵はあくまでテクニックだ。

**デフォルトの名無しさん** · 2015/12/10(木) 15:44:51.44

>>608
そんなの知らねーが未初期化でReleaseビルドの時だけ発生するバグを埋めるアホはよく見てきた
新人でもはっきり判断できるような可読性高いもの書け
それがプロの最低条件

**デフォルトの名無しさん** · 2015/12/10(木) 15:50:47.73

正確には「新人でも上級者でもわかる可読性が高いコード」な

新人が簡単に分かったとしても、
上級者が苦労するようなコードは本末転倒。

上級者がこっちのほうがわかりやすくシンプルだと思ってるのに
でも新人はこんな高度なテクニックは知りませんからね。
複雑で冗長になりますが、新人でも知ってるテクニックだけ使いますよ。
というのは大間違い。

わかりやすさの基準は上級者が決める

**デフォルトの名無しさん** · 2015/12/10(木) 15:56:11.47

>>608
俺の使ってたCスタートアップは.bssゼロフィルしてなかった
妥当な理由があったからなんだが、何だかモヤモヤした

**デフォルトの名無しさん** · 2015/12/10(木) 16:01:16.70

bssゼロフィルなんてものを前提にコード書く奴は素人
こういうバカはやっかいなバグをしこたま仕込むタイプ

**デフォルトの名無しさん** · 2015/12/10(木) 16:04:42.64

グローバル変数とかスタティック変数は
初期値を入れてなければゼロが初期値ってのは前提でしょ

**デフォルトの名無しさん** · 2015/12/10(木) 16:36:51.55

むしろ初期値が決まってない言語のほうが少ない。

**デフォルトの名無しさん** · 2015/12/10(木) 16:42:29.28

>>613
そういうのは処理系がエラーを吐けば問題ない

**デフォルトの名無しさん** · 2015/12/10(木) 17:32:31.12

前提つーか言語仕様に書いてあるからなあ

**デフォルトの名無しさん** · 2015/12/11(金) 00:36:04.85

言語仕様なんて現実の処理系の前じゃ単なるガイドラインにしか過ぎん

**デフォルトの名無しさん** · 2015/12/13(日) 09:45:48.97

言語仕様としてプラットフォーム依存も定義されてるよ

**デフォルトの名無しさん** · 2015/12/13(日) 20:56:58.02

１クラスが６０００ステップ以上のJavaソースをちらりと見た。
内部クラスを使っているかも知れんが、Javaってもっと細切れに
クラスを作るものかと思っていた。

**デフォルトの名無しさん** · 2015/12/13(日) 20:57:59.03

Javaだけじゃなくて、どんな言語でも、
クラスがある言語なら細切れにクラスを作るよ。

**デフォルトの名無しさん** · 2015/12/13(日) 23:37:51.49

>>621
6000行くらい見ればいいのに。

**デフォルトの名無しさん** · 2015/12/13(日) 23:57:49.37

>>621
ダメな例だな
まとまってるから解析は比較的しやすいがテストとなると内部の状態が多すぎてまともなテストできない
クラスは小さいひとつのことに集中し他とはできるだけ疎結合

**デフォルトの名無しさん** · 2015/12/18(金) 21:22:05.47

>>621
クラスの責務があやふやなんやな

**デフォルトの名無しさん** · 2016/01/06(水) 11:59:50.90

中級者はトリッキーはコードを好む
これだけは間違いない

**デフォルトの名無しさん** · 2016/01/06(水) 12:29:20.52

確かに上級者のコードは見やすい。
ロジックは複雑だがコードとしての見やすさ。

**デフォルトの名無しさん** · 2016/01/06(水) 12:30:26.18

トリッキーを好むのは意識高い系の無能やで

**デフォルトの名無しさん** · 2016/01/06(水) 18:08:14.05

中級者と上級者の違いは？

**デフォルトの名無しさん** · 2016/01/06(水) 19:38:59.22

上級者：バカの相手をしない。馬鹿にかかわらない。
中級者：バカがいると頑張る。
初心者：バカをバカと認識出来ない。

**デフォルトの名無しさん** · 2016/01/07(木) 12:52:08.23

バカをコケにして楽しむ天才もいるけど

**デフォルトの名無しさん** · 2016/01/07(木) 16:39:58.08

それは中級者のことだな

**デフォルトの名無しさん** · 2016/01/07(木) 17:03:25.06

上級者は比較的謙虚だよ。
まあ、悟りが入っているからだが。

**デフォルトの名無しさん** · 2016/01/07(木) 19:56:13.36

いろいろいる

**デフォルトの名無しさん** · 2016/01/07(木) 20:47:13.40

上級者をコケにしまくるノイマン

**デフォルトの名無しさん** · 2016/01/08(金) 15:07:08.09

ifもelseも全部一行に詰め込むガイジは死ね
読みにくいんじゃボケ！！！！！！！！！！！！！！

**デフォルトの名無しさん** · 2016/01/08(金) 15:14:42.00

>>636
個人的には、

if(kinoko == stick){

}else{

}

という書き方ではなく、

if(kinoko == stick)
{

}
else
{

}

って書く人は嫌い。

**デフォルトの名無しさん** · 2016/01/08(金) 15:29:13.63

>>637
それが嫌いだと生きていくの辛いだろ

**デフォルトの名無しさん** · 2016/01/08(金) 15:43:23.58

俺はできるだけ改行しないほうが好きだが、コメントの位置が上手くできないのが悩みどころ

// このコメントはOK
if(){

}else{　// このコメントを先頭にしたいけどelseはこの位置が好き

}

**デフォルトの名無しさん** · 2016/01/08(金) 16:04:25.38

こーだろ

if(){
　　// 真の場合は・・・する

}else{
　　// 偽の場合は・・・する

}

**デフォルトの名無しさん** · 2016/01/08(金) 16:48:23.58

>>637
嫌いだけど、　C#ってその形なんだよね

**デフォルトの名無しさん** · 2016/01/08(金) 18:17:24.00

設定で変えられますよ。

**デフォルトの名無しさん** · 2016/01/08(金) 20:08:25.88

つーか、elseはあまり書くべきでない。

if(){
　　// 真の場合は・・・する

}else{
　　// 偽の場合は・・・する

}

ではなく、できるだけ

if(){
　　// 偽の場合は・・・する
　　return;（またはエクセプションをthrow）
}

// 真の処理

という形になるように常に心がける。

if else という書き方が深いネストを作るきっかけになっている事に気づかないと
いつまでたっても、初心者、中級者のまま。

**デフォルトの名無しさん** · 2016/01/08(金) 20:43:14.71

一画面で収まるなら別にネストしてていいや。
それ以上はオブジェクト化するかな

**デフォルトの名無しさん** · 2016/01/08(金) 20:57:13.43

>>643 MISRA を否定するのか。是非とも MISRA の連中を説教してやってくれ

MISRA-C ルール 15.5 推奨関数は、その最後に1つだけの出口を持たなけらばならない

**デフォルトの名無しさん** · 2016/01/08(金) 21:08:22.83

>>643
ifでもelseでも最終的に同じ処理してからリターンしたい場合は？
決め付けるのは自称上級者

途中リターンが見やすいと思った場合は使うしそうでない場合はelseも使う

**デフォルトの名無しさん** · 2016/01/08(金) 21:14:13.17

>>645
C言語ではそっちの方がよかったんかね。
いまって関数単位で単一責務原則を適用して関数が小っちゃくなるから
あまりこだわる必要なさそうだけど。

**デフォルトの名無しさん** · 2016/01/08(金) 21:19:49.24

話ぶった切るけど今まで見た中で最高に頭沸いてると思ったのはこれ

// 前略

/*
* きっとキミは来ない独りきりのcarch anything
* silent kill. do ignore.
*/
} catch (Throwable e) {
assert(true, "来ちゃった♪" + e);
}

書いた人は壊れて辞めたらしい

**デフォルトの名無しさん** · 2016/01/08(金) 21:21:27.58

>>646

あまり書くべきではない　とか　できるだけ心がける
という、超初歩的な日本語の意味を理解できない馬鹿がいるとは…
さすが初心者はプログラムだけでなく日本語も不自由と見える。

そう書くのが妥当なら書けばいいに決まってるじゃないか。

**デフォルトの名無しさん** · 2016/01/08(金) 21:25:13.38

>>645

世の中のコードが全てCで書かれているとは知らなかった。
そんな世の中なら、さぞ住みにくかろう。

**デフォルトの名無しさん** · 2016/01/08(金) 21:38:36.07

客先ですごいお金が絡むシステムがスパゲティコードだったから担当になるまえに怖くて会社辞めた

**デフォルトの名無しさん** · 2016/01/08(金) 21:51:57.46

>>649
常に心がける＝できるだけ心がける？

**デフォルトの名無しさん** · 2016/01/08(金) 22:15:24.88

できるだけ～になるように、常に心がける

なんかおかしいか？
ほんとに日本語不自由な奴ばっかだな。

**デフォルトの名無しさん** · 2016/01/08(金) 23:40:56.27

>>645
> MISRA-C ルール 15.5 推奨関数は、その最後に1つだけの出口を持たなけらばならない

そのルールを守るのは簡単だよ。

途中でreturnしたくなったら、代わりに関数の最後にgotoすればいいｗ

**デフォルトの名無しさん** · 2016/01/08(金) 23:50:27.25

そのMISRAのバカルールはな大昔の最適化が物凄くしょぼかったコンパイラ
で出たコードをこれまたしょぼいデバッガでデバッグするために関数の入り口と出口を
アセンブラレベルで１つずつにするためのものなのだよ
もう完全に時代錯誤

**デフォルトの名無しさん** · 2016/01/08(金) 23:53:53.14

>>654
gotoもダメなんじゃないかな？みすら的に考えて。
みすらそう思う。

**デフォルトの名無しさん** · 2016/01/09(土) 00:43:27.67

>>656
ならwhile(1)してbreakすればいいよｗ

**デフォルトの名無しさん** · 2016/01/09(土) 02:10:42.82

マルチスレッド対応が当たり前になった今クソ長いコードや分岐だらけとか終わってる
シンプル・イズ・ベスト
大きな建造物と同様細かく作業を分けて小さな単位を積み上げていって大きくするのがセオリー

**デフォルトの名無しさん** · 2016/01/09(土) 06:38:25.50

VB系だとよく脱出用の空ループで抜けたりするけどこれはみすら的にはどうなの？
andやorがC言語系の&&や||と違って全部評価されちゃうからifで書いてくしかなくて
それをまともにやるとifがネストになってくんだよね
do
　if not test1 then exit do
　if not test2 then exit do
　if not test3 then exit do
　：
　exit do
loop

上を普通に書くと
if test1 then
　if test2 then
　　if test3 then
　　　：
※各testは最小限で評価したい

**デフォルトの名無しさん** · 2016/01/09(土) 13:39:15.86

客が読みにくいという理由でガード(関数の先頭あたりでリターンする)を
すべて if else に書き直させられたが
何でくだらない仕事を増やすのだろうか

**デフォルトの名無しさん** · 2016/01/09(土) 14:08:32.34

>>660

客の脳みそが腐っているんだからしょうがないんじゃね？

腐っててもお金は払ってくれるんだから、まぁ、ごみ処理だと思えば。

**デフォルトの名無しさん** · 2016/01/09(土) 14:23:51.36

自称上級者とかほざいてた >>646 は、
そろそろ自分の馬鹿さ加減に気づく頃かな。

**デフォルトの名無しさん** · 2016/01/09(土) 14:30:18.07

>>660
else;つけとけばいいだけ
わざわざelse句として書く必要ない

**デフォルトの名無しさん** · 2016/01/09(土) 14:31:17.81

>>662
ケースバイケースってことを言ってるんだと思うよ。
バカだとは思わないけどなあ。

**デフォルトの名無しさん** · 2016/01/09(土) 14:36:03.18

どちらのケースでもやりたいなら呼び出し元にコールさせればいい
分割がなされてないとそうなる

**デフォルトの名無しさん** · 2016/01/09(土) 14:49:14.92

>>664

5：5 くらいでどっちのケースもあると思ってるなら、
お前も>>646も頭に糠味噌つまってるくらい馬鹿だ

**デフォルトの名無しさん** · 2016/01/09(土) 14:51:11.96

>>666
バカっていいたいだけなんじゃないの？
なんかあまり中身がないような・・・。

**デフォルトの名無しさん** · 2016/01/09(土) 14:53:07.96

好みの問題だしなあ。価値観は優劣をつけるためのものじゃないと思うんだよね。
他人の価値観を自分の中に取り込んで自分の世界を広げるためのものなんだよ！！←できる人

**デフォルトの名無しさん** · 2016/01/09(土) 14:53:18.06

>646
>ifでもelseでも最終的に同じ処理してからリターンしたい場合は？

そういう、共通処理っていうのは呼び出し元の処理なんだよ

いい加減に気づけ馬鹿 >>664

**デフォルトの名無しさん** · 2016/01/09(土) 14:54:33.41

>>668

究極に頭おかしい人がきました。
好みの問題だと本当に思っているらしい。そりゃ、世の中クソコードで溢れるわ。

**デフォルトの名無しさん** · 2016/01/09(土) 14:55:22.03

>>667

中身が無いのはお前の頭です。

**デフォルトの名無しさん** · 2016/01/09(土) 14:57:02.55

IDみたら同じやつか。こいつ、本当に糞コード生産マシンだろうな。

**デフォルトの名無しさん** · 2016/01/09(土) 15:04:09.39

>他人の価値観を自分の中に取り込んで自分の世界を広げるためのものなんだよ！！←できる人

"←できる人"って、ばーーーーーーーーーーーーか！

**デフォルトの名無しさん** · 2016/01/09(土) 15:06:12.89

>>673
待って！落ち着いて！いまから私が言うことに耳を傾けて。
びっくりするかもしれないけどホントのこと伝えたいから。
プログラムはケースバイケースなの！！なんでもありなの！！！

**デフォルトの名無しさん** · 2016/01/09(土) 15:14:34.02

ケースバイケースのことはあるが、今回のことは違う。
以上

馬鹿

**デフォルトの名無しさん** · 2016/01/09(土) 15:22:04.43

馬鹿バイ馬鹿のことはある

**デフォルトの名無しさん** · 2016/01/09(土) 15:27:26.70

さーらバイバイさーらバイということもある。

**デフォルトの名無しさん** · 2016/01/09(土) 15:33:15.50

>>669
じゃあif elseがない処理＝呼び出し元の処理ということ？？
関数作る必要ないじゃんｗｗｗ

>>665
呼び出し元が複数あったときにコードが増えるんですがｗ
何のための関数化だよ
せめて関数内で別関数としてコールする形式にしないと無駄が増える

経験的に、後から読むとき、関数最初でのreturnは見やすいけど、
途中でのreturnはelseのほうが見やすかったりする
だからケースバイケース

**デフォルトの名無しさん** · 2016/01/09(土) 15:37:06.74

>>669
関数でローカルに取得したリソースの解放ってのは関数内部の処理だろう。
C++ならRAIIでやるところかもしれんが。

**デフォルトの名無しさん** · 2016/01/09(土) 16:34:28.92

>>678
条件分岐を呼び出してあとに続く処理を実行する方を外から呼び出してもらうようにするだけ
分解すればあとの処理はifの条件にかかわることなく一回でテストが終わる
ダラダラ一つのメソッドに書くとマトリックス的にテストケースが発生し産廃コードが誕生する

**デフォルトの名無しさん** · 2016/01/09(土) 17:46:59.93

>>680
そういう等価な書き換えでテストケースが減るわけがないんだがな。
C0カバレッジしか見てなくて途中returnのケースをテストしてないのかとも思ったが、
ひとつの関数だとマトリクス的にケースが増えるってのが意味不明だな。
どういう基準でテストしてるんだか。

**デフォルトの名無しさん** · 2016/01/09(土) 18:23:22.10

>>681
if
A
else
B
C

Cが別関数になってないとACとBCのテストパターンコードがいる
一方別関数の場合はAとBそれと独立してCで事足りる
これが長いものになると前者は爆発的にパターンが増えていく
関係性がないものは分離する
関係性があっても関係性の部分だけを取り出し分離する
細かくなってればテストコード自動生成も実用性が出てくる

**デフォルトの名無しさん** · 2016/01/09(土) 18:27:33.31

デバッガで見るとreturnで関数の最後に飛んでいるから、
途中でreturnしてもいいんじゃないの？

一方職場でジャンプ関数使う人はいた。
でも1人でやってるプロジェクトなんで見て見ぬふりをしたｗ
自分以外がメンテナンスできないようにする人っているしね…

**デフォルトの名無しさん** · 2016/01/09(土) 18:31:44.58

ジャンプ関数ってまさか
longjmp()とcome_from()？
gotoがましに見えるレベル

**デフォルトの名無しさん** · 2016/01/09(土) 18:54:23.29

>>682
分岐網羅ならどっちにしろACとBCの2ケースになるように見えるが。
それともAとBとCの単体テストだけやっておしまいって話？
ついでに言えば、これがどう>>680の説明になっているのかわからん。

**デフォルトの名無しさん** · 2016/01/09(土) 18:56:50.22

>>685
由緒正しき「継続」という奴だ，まさか，とかいっていいのか？

**デフォルトの名無しさん** · 2016/01/09(土) 19:26:55.42

come_fromって何かと思ったらサンプルコードじゃんｗ
「returnするのが面倒くさいからと」代わりにジャンプ関数使っていたな…
（なんでも手製でツールを揃えないといけない時代で）独立したツールだったから
誰もソースコードチェックしなかったんだろうね。

**デフォルトの名無しさん** · 2016/01/09(土) 20:03:07.47

hdqMNonUの戯言に耳を傾ける馬鹿は+5afeFvRみたいな知恵遅れだけだ。

**デフォルトの名無しさん** · 2016/01/09(土) 20:05:22.39

人命にかかわる部分はたいていC/C++で書かれているから、C/C++を使う人だけ気を付ければ良いんじゃないだろかね。

**デフォルトの名無しさん** · 2016/01/09(土) 20:05:40.84

>>680 >>682　に書いてあることの意味が分からない奴が、現役でプログラマしてるって事が恐ろしい…

**デフォルトの名無しさん** · 2016/01/09(土) 20:13:15.02

>>685
>それともAとBとCの単体テストだけやっておしまいって話？

だったらお前はその上層と下層を全て含めた
ABCDEFGHIJKLMN…
の全てのケースを含んだテストを一生かけてやってろ。

ユニットテストのしかたもする意味もわかってない馬鹿。

**デフォルトの名無しさん** · 2016/01/09(土) 20:18:44.12

単体テストのやり方がわかっていないからといって馬鹿とは限らない。
アインシュタインは単体テストのやり方を知っていただろうか。

**デフォルトの名無しさん** · 2016/01/09(土) 20:32:29.40

単体テストのやり方がわかっていないから馬鹿だといってるのではない。
馬鹿だから単体テストのやり方がわかっていないと言っている。

**デフォルトの名無しさん** · 2016/01/09(土) 20:36:35.31

AのバグとCのバグを合わせた結果、テストケースでは見かけ上正しい出力がされてグリーンになってしまいました、

ABとCが分けてなかったらどうやって隠れた問題を検出するんだ。