今までみた絶望的なソースコード [転載禁止]©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/10/21(水) 23:31:28.17

returnが増えるほど可読性は下がる、という文化もある

**デフォルトの名無しさん** · 2015/10/22(木) 00:05:08.39

可読性というか、一見上から下に素直に流れる関数のように見えて実は
文の最後にちょろっとreturnがあるのを見落とす、なんてのはあるね。

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

ねーよｗ

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

いや、俺はあるw

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

その理屈だと、そのreturnと同じ位置にi++とかあった場合、
それを見落とすんだろうなｗ

**デフォルトの名無しさん** · 2015/10/22(木) 07:19:28.30

>>326
減らないけど、記載するマトリックスは減るんだよ。
通るifとかswitchを列挙して、真の場合偽の場合を分けないといかんから、
頭でフラグ持ったとしても、通過する限り「処理なし」と書く必要がある。
処理なしと書く限り、処理なしのエビデンス取らなきゃならん。
それが嫌なら、通過もしないようネストを深くしなきゃならん。

>>328
可読性ももちろん上がるな。対応する括弧を追う必要も無いし。

**デフォルトの名無しさん** · 2015/10/22(木) 07:45:32.98

俺はすぐにreturnしちゃうけど、可読性は上がるよね
I/Fの仕様が変わった場合、戻り値の変更漏れとかたまにあるけど

**デフォルトの名無しさん** · 2015/10/22(木) 07:58:12.26

>>336

if (...) {
}
// 関数の終わり

だと管理しなきゃならなくて if (...) return; だと書かなくていいの？妙な規則だね。
ひとごとながら、if (...) return 関数(); とか大丈夫なのかと思ってしまった。

**デフォルトの名無しさん** · 2015/10/22(木) 08:03:40.68

MISRA準拠のときに困るからreturnは複数書かないな

**デフォルトの名無しさん** · 2015/10/22(木) 08:41:43.01

(関数){
hage
}
と
(関数)
{
hage
}
だとどっちがいいの？

**デフォルトの名無しさん** · 2015/10/22(木) 08:50:50.09

コーディングルールにある通りでいい
なければ多数派に合わせるようにコーディングルールを決めてしまえばいい

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

>>338
一つならどちらでも書く必要があるよ。

条件1と条件2と条件3がある場合、
if 条件1
　処理1
else
　不処理フラグ
endif
if !不処理フラグ、条件2
　処理2
else
　　不処理フラグ
endif
if !不処理フラグ、条件3
　処理3
endif
なら管理必要。

if 条件1
　処理1
　if 条件2
　　処理2
　　if 条件3
　　　処理3
　　endif
　endif
endif
は、パターンは減るけど可読性悪すぎ。

**デフォルトの名無しさん** · 2015/10/22(木) 09:49:22.97

>>325
コードレビューしないことじゃなく、コードレビューして
「成長可能かもしれない奴が周りにいる」という
環境が幸せなんだよ…

**デフォルトの名無しさん** · 2015/10/22(木) 09:59:20.88

>>342
それ（後半のコード）を早期returnパターンにすると更にわかりやすくなる。

if ! 条件1
　return
endif

処理1
if ! 条件2
　return
endif

処理2
if ! 条件3
　return
endif

処理3

言語によっては、更に短くすることができる。わかりやすさがぜんぜん違うね。

unless 条件1 then return
処理1
unless 条件2 then return
処理2
unless 条件3 then return
処理3

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

>>344
そうそう。だから割と俺は早期リターンでネスト深めずに処理出来るものはしたいんだよね。

**デフォルトの名無しさん** · 2015/10/22(木) 22:05:36.79

>>342
等価なのは後者なんだからやっぱりテストパターンは関係ないでしょ。
あとマトリクスと言ってるけど、もしかして前者の形で書いた場合は処理1を通過せずに
処理2を実行するケースも考慮しないとならないとか？

ツール使わずに手作業でC1カバレッジ管理しなきゃならないプロジェクトなんて
やったことないからよくわからないけど、大変だねw

**デフォルトの名無しさん** · 2015/10/22(木) 23:53:09.22

>>344
こっちの方が絶望的なコードに見える

**デフォルトの名無しさん** · 2015/10/23(金) 00:40:43.08

>>347
お前の目が腐ってるのでは？

**デフォルトの名無しさん** · 2015/10/23(金) 00:41:38.26

基本的に腐ってる人っていうのは
ルールで決まってるから、そうなんだ。みたいに
ルールのためのルールを愛する。
自分で考える脳を持たない。

**デフォルトの名無しさん** · 2015/10/23(金) 01:25:49.95

>>346
だから後者はネスト深くて嫌いなの。
当たり前だろ。
通る限り、例え結果がわかりきってようがその分のパターンも書かなきゃならんし、
スタック壊れた時のことも考えにゃならん。

ツールがどうのとかMISRAがどうのいってるお偉方には意味ないの。
机の上で紙でデバッグできなければ意味がない、検算は手計算、の人らだよ。

**デフォルトの名無しさん** · 2015/10/23(金) 02:16:55.96

こういう派閥争いの結果、複数の形式が混ざった糞コードが生まれるのであった

**デフォルトの名無しさん** · 2015/10/23(金) 06:14:19.52

モーゼ<俺は中道を行くぞー！ﾊﾞﾘﾊﾞﾘﾔﾒﾃ！>

**デフォルトの名無しさん** · 2015/10/23(金) 07:59:46.43

>>350
じゃあまとめると、>>323で途中returnを使わないとテストパターンが増えるかのように書いて
いたのは、おまえが深いネストが嫌い+おまえのところの妙な管理の合わせ技ってことね。

**デフォルトの名無しさん** · 2015/10/23(金) 08:50:27.33

#define HOGE 128

**デフォルトの名無しさん** · 2015/10/23(金) 09:44:51.05

>>353
何に噛み付いてるかわからんけど、増えるよ。

**デフォルトの名無しさん** · 2015/10/23(金) 10:06:04.43

>>351
この問題に関して言えば、どっちがいいかは
ツールで計測可能なので、それ持ち出せば一発だよｗ

**デフォルトの名無しさん** · 2015/10/23(金) 12:07:57.91

>>356
必要、だから、文書化されてたらノーカンだよ。そういう意味では本来。

**デフォルトの名無しさん** · 2015/10/24(土) 01:19:57.16

>>344
だせーから1行でretunrnできねーならガード使うな

**デフォルトの名無しさん** · 2015/10/24(土) 02:07:32.78

意外と盛り上がってて吹いた

if文のネストを減らすためにマトリクスで何がくるか特定して分岐させる

switch(state){

**デフォルトの名無しさん** · 2015/10/24(土) 02:11:21.79

書き損じた
a => 1 または 0
b => 2 または 0
c => 4 または 0
d => 8 または 0
として
state = a | b | c ・・・;
switch(state){
：
}
ってやつね
これでif文が綺麗に消えてくれる(ことが多い)

**デフォルトの名無しさん** · 2015/10/24(土) 02:15:24.10

んでここがちょっと言いたかったことだけど
このstate switchは当然状態の数だけ関数も長くなるんだが
この場合いくら長くなっても可読性は全く落ちないという特性がある
みんなで使って幸せになろう

**デフォルトの名無しさん** · 2015/10/24(土) 02:18:17.66

この場合エラー処理もえらい単純化できる
つまりdefault:に来たもの＝エラーということ
最初に状態設計をきっちり行えばこの方法が今のところ最も効率が良いと
言ってしまおうかな

**デフォルトの名無しさん** · 2015/10/24(土) 02:24:39.55

>>361
ifの代わりにswtchになってるだけじゃねーか。

こういうのは関数テーブル使えばいいんだよ。

**デフォルトの名無しさん** · 2015/10/24(土) 02:59:11.22

そいうことを言いたいわけじゃないんだがなあ
上でエビデンスの話が出たが
まさにswitch内で定義した状態の数だけパターンを取ればいいって単純化の話なんだよ
たとえばifで
if(a) x
if(b) y
と書くと2^2の4パターンだけど
この調子で増やしていくとどんな状態があるのか目視では見落としやすい

state swichなら以下の通りテストパターンと完全に一致する
state = a | b;
swich(state)
case a0b0: break;
case a0b1: break;
case a1b0: break;
case a1b1: break;
default: /*error*/ break;
}
つーかテストパターンを同時にを書いていく前提なら上で挙がってたコードは全部論外だろう

**デフォルトの名無しさん** · 2015/10/24(土) 03:08:51.12

そして関数テーブルにすると

1テストパターン　= 1関数になるので
もっと単純化できるという話。

**デフォルトの名無しさん** · 2015/10/24(土) 03:14:15.86

関数テーブル覚えたての人なのかなあ
そういう言語機能寄りの話は今してないの判んないかな

**デフォルトの名無しさん** · 2015/10/24(土) 03:29:27.06

この方法は見ての通りコードレビューも短期間で終わるのが判ってもらえると思う
状態が一箇所にまとまってる
状態によって必要になる処理が一箇所にまとまってる
どういう条件でエラーになるか簡単に調べられる

設計書やテストパターンとも一致させやすい
全て一箇所にまとまってるのがポイント
結局これ以上の物はできないんじゃないかな

**デフォルトの名無しさん** · 2015/10/24(土) 08:06:55.53

テストケース数に合わせる為にロジックを分かりにくく記述する本末転倒手法

**デフォルトの名無しさん** · 2015/10/24(土) 09:12:17.67

手段と目的をはき違える典型

**デフォルトの名無しさん** · 2015/10/24(土) 09:20:03.81

>>354
良く見るな。
括弧を章する俺かっけーってな奴。

**デフォルトの名無しさん** · 2015/10/24(土) 09:22:43.39

テストファーストならそれもありだろ。ブラックボックスでいいんだから。

**デフォルトの名無しさん** · 2015/10/24(土) 10:30:44.28

ネストが増えるのは問題だけど
returnパスが増えるのは問題じゃないのかな

**デフォルトの名無しさん** · 2015/10/24(土) 11:49:30.75

returnパスが増えるのが問題だと思うのなら
returnの代わりに関数の最後にgotoしていると考えればいい。

if (...) return
hoge
hoge
return

↓

if (...) goto last
hoge
hoge
last:
return

goto使うのが駄目ならbreakにすればいい。

do {
　if (...) break
　hoge
　hoge
} while(0)
return

見ての通りreturnは一つである。
これで解決する程度のことを問題視することに何の意味があるのか？

**デフォルトの名無しさん** · 2015/10/24(土) 11:55:22.07

>>364
なんで意味ないことするの？
同じもんを外に抜き出してるだけじゃん。

そもそも入出力のパターンはテストで確認すりゃいいんだから、コードをパターンと一致させるのは無駄としか言いようがない

**デフォルトの名無しさん** · 2015/10/24(土) 20:55:59.55

>>373
それで解決するなら最初からそう書いてればいいんじゃないの

**デフォルトの名無しさん** · 2015/10/24(土) 21:00:18.64

>>375
いや、解らない？

returnを一つにするというのはこれらと同じように、
無意味なことだって言ってるんだよ。

**デフォルトの名無しさん** · 2015/10/25(日) 07:35:45.91

return複数あったらレビュー通らないじゃん

**デフォルトの名無しさん** · 2015/10/25(日) 07:48:44.18

コーディング規約って、一種類しか無いとでも？

ゆとりって面倒臭いな。

**デフォルトの名無しさん** · 2015/10/25(日) 10:47:02.39

コーディング規約の為のコードじゃなくて、なんのためのコーディング規約かを考えろよ
そんなだからクソコード量産するんだよ

**デフォルトの名無しさん** · 2015/10/25(日) 11:28:29.91

性能が必要ないカテゴリでは性能を低下させるコードでも許容されるだけ
性能が必要なカテゴリではレビューでもreturnパスどうのより、そのコードが
速いかどうかだけが吟味される。

**デフォルトの名無しさん** · 2015/10/25(日) 11:55:36.82

基本は可読性高いコードが評価高い
それでパフォーマンス悪くてもボトルネック部分の速度を改善すればいい
しかし速度重視の難解コードはクソソースと呼ばれ後ろ指さされる
速度はアーキテクチャで解決していくのがベストだわな

**デフォルトの名無しさん** · 2015/10/25(日) 12:38:39.93

だから、それを待てるカテゴリは、元々性能が問題になるようなカテゴリじゃ
なかったというだけ、「次がある(ｷﾘｯ」「後がある(ｷﾘｯ」なんて言ってられる
生温いとこじゃないものも沢山ある。

**デフォルトの名無しさん** · 2015/10/25(日) 12:56:40.32

>>377
こっちには、return複数あったらだめなんて言う
意味のないレビューをする人はいないんでねｗ

**デフォルトの名無しさん** · 2015/10/25(日) 12:59:23.67

>>381
> しかし速度重視の難解コードはクソソースと呼ばれ後ろ指さされる

いつも思うんだが、速度重視したらなんで難解なコードになるのかわからん。

速度が速いコードっていうのは無駄がないコードなわけで、
普通は可読性が高いんだよ。

速度を速くするアルゴリズムがある場合で、そのアルゴリズムが
複雑な場合に限って、速度を重視したら難解になるんだが。

**デフォルトの名無しさん** · 2015/10/25(日) 13:27:45.84

> しかし速度重視の難解コードはクソソースと呼ばれ後ろ指さされる

非プログラマか初心者が抱きがちな想像やな

>>384
それな

**デフォルトの名無しさん** · 2015/10/25(日) 13:36:24.73

速度自体が無駄ｗ
なんで初心者って無駄に速度にこだわるのｗ

**デフォルトの名無しさん** · 2015/10/25(日) 13:58:48.56

皆、自分の意見こそが正しく正義であると信じ、
他者を必要以上に攻撃する傾向がみられる
なるほどこれが宗教ってやつか
世界から戦争が無くならない訳だ

**デフォルトの名無しさん** · 2015/10/25(日) 14:06:03.46

>>384
例えば時間のかかるデータ取得が100個あるとする
速度重視の場合早い時点でスレッド作って先行処理しておく
実際値使う箇所では中でスレッド待ちしていてなんでわけわからないことやってるんだと言われる
データなんてGet回すだけだろと

アルゴリズム難解といえば自前のHashMapは最初わからんかった
文字列足しこんでへんなビット演算やって
コメントもなかったからあれはなかなか理解されない

**デフォルトの名無しさん** · 2015/10/25(日) 14:19:23.12

>>388
スレッド使えるなんて羨ましい
こっちは標準Cライブラリどころかcrtすら使わせて貰えないから
RAMをクリアしてmain関数を自分で起こすところから書かなきゃいけない絶望的な状況

**デフォルトの名無しさん** · 2015/10/25(日) 14:28:46.60

>>389
組み込み系？
クラスも使えずレジスタがどうだとかリソース最小限に留めるとか無理だわ
基本は作りやすさ重視で必要に応じてチューニングが1番仕事しやすい

**デフォルトの名無しさん** · 2015/10/25(日) 14:44:38.49

>>388
だからそれ、アルゴリズム変わってるじゃん。
馬鹿なの？

**デフォルトの名無しさん** · 2015/10/25(日) 14:46:27.63

クソソース書いといてその言い訳に速度重視とかザコ過ぎない？
お前が速度なんて語るの百年早いのはそのクソソースに丸出しなわけで
よくあんなクソソース書いててそんな態度取れるなっていう不思議な子知ってる

**デフォルトの名無しさん** · 2015/10/25(日) 14:50:33.48

>>386
おまえは一生ソートに可読性の高いバブルソートでも使ってろよ

**デフォルトの名無しさん** · 2015/10/25(日) 14:51:52.18

>>391
アルゴリズム同一でと言った覚えないんだが？
むしろアルゴリズム同一で速度が飛躍的に上げれるならマジで教えて欲しいが

**デフォルトの名無しさん** · 2015/10/25(日) 14:52:32.88

16進数やビット演算とか使ってるコードは見にくいからクソソースでいいですか？

**デフォルトの名無しさん** · 2015/10/25(日) 14:57:39.09

>>395
マクロ被せれば見やすくなる

**デフォルトの名無しさん** · 2015/10/25(日) 16:48:51.96

マスクをtypedefしとけば良いんじゃないの。

**デフォルトの名無しさん** · 2015/10/25(日) 17:17:54.69

>>395
何進数だろうが関数内にマジックナンバーは入れちゃダメだろうね
定数かマクロにして実行部とは分けて宣言・定義するようにしてるよ

**デフォルトの名無しさん** · 2015/10/25(日) 21:29:44.35

じゃあ何進数だったらマジックナンバー使っていいんだよ！

**デフォルトの名無しさん** · 2015/10/26(月) 14:29:54.04

「定数は定義して使え」に対して

#define value_1 (1)
#define value_2 (2)

とかいう馬鹿もいるんだよな

**デフォルトの名無しさん** · 2015/10/26(月) 14:33:27.86

#define value_one (1)
#define value_two (2)

これなら大丈夫(ｷﾘｯ

**デフォルトの名無しさん** · 2015/10/26(月) 17:54:07.18

#define ZERO 1
はGNUで見たことある。

**デフォルトの名無しさん** · 2015/10/26(月) 18:15:12.01

マジックナンバーは基本だが定数を使った判定をあちこちに書かないことも重要
例えばファイルの存在チェックでファイルのビットフラグ立ってないことで判定
しかしフォルダも除外したい等仕様変更が予想される
その度多数の修正を入れるのは危険
isExist()などでラップして判定処理は1箇所にすると変更に強くテストも楽

**デフォルトの名無しさん** · 2015/10/26(月) 23:04:21.65

マジックナンバーは必要悪でしょ。
周知されてて、全体で統一されてたら何も文句無いけどな。
日時未定を29991231で持ってるシステムに関わってたけど。

特定のビットが立ってないことと、ファイルの有無と、ディレクトリであるか否かはまた別問題ではないのだろうか。
isExistなのに、ディレクトリ除外しちゃうの？ライブラリなのに外から見た挙動変えちゃうの？って不安のほうが大きい。
そんなもんで判定せずに、判定箇所で切り分けるか、旧関数自体をassertで殺す方がマシ。
その度に多数の修正は躊躇なく入れるべき。

挙動を変えるのに、変えた意識が無い方が、
あり得ないくらい誰も原因に気づかない、どハマりする障害を起こす元。

**デフォルトの名無しさん** · 2015/10/27(火) 01:11:27.89

>>404
例が悪かったからマイナンバー導入を例にする
従来は同一判定をequal()で中身は住所と指名で判定してたとしよう
この場合マイナンバー対応は中身をID比較にすればそれだけで対応完了
これが比較箇所に直接住所と氏名の比較を行っていた場合修正は時間がかかる
修正ソース毎にドキュメント書かないといけないプロジェクトでは発狂もの
言いたいのはやりたいことを外に出して実現手段は中に閉じ込めろってこと
要はカプセル化だが簡単なものだと忘れられることがよくある

**デフォルトの名無しさん** · 2015/10/27(火) 07:32:20.87

>>405
ダメ。
名前と住所で比較するロジックと、
マイナンバーで比較するロジックは別物。
それだけで対応完了にならないよ。
それでは、既存の比較するロジック全部洗って、それ呼んでる所を全部テストせなならん。
普通は、呼び出し側ソース修正と同じかそれ以上になるんだよ、ライブラリの挙動変更に対するドキュメントとテストって。
やりたい事をカプセル化するライブラリの、内部挙動が変わったらそれは最早カプセル化されてないとしか言いようが無い。

名前と住所ってのは、ユニークになるとは限らない情報だし、逆に歴なんか持ってたら2つ以上のレコードが一つを指すかもしれないレコードになるでしょ。
今まで同じだったけど今回からは違う人(田中一郎さんが昔住んでて、引っ越した後、今は別の田中一郎さんが住んでる)、や
今まで違う人だったけど、今回からは同じ人(同じ住所だけど、結婚して姓が変わってる)が出る改修はカプセル化失敗としか言えない。

まさにそういうシステム作ってたけど、「同一人物っぽい人」としか言えないから、警告しか出してない。

内部発番のシリアルのIDを比較していた所を、マイナンバーでひっかけるようにする、位の変更くらいじゃないの？その変更が通用するのは。
それでもパターンテストは必要。
呼び出し側を修正して、きちんと新しい関数が呼ばれている所からがテストのスタート地点。

修正ソース毎にドキュメントなんか普通作るよね。
波及コードだけどローレベルで担保されてるから大丈夫。は通用しない。

現実手段を閉じ込めるのは、同じ動きをする事が大前提。

**デフォルトの名無しさん** · 2015/10/27(火) 07:44:38.08

>>406
理想はそうだけど現実解じゃないよそれ。

**デフォルトの名無しさん** · 2015/10/27(火) 07:55:35.31

いつのまに絶望的なコーディング論を紹介するスレになったのか

**デフォルトの名無しさん** · 2015/10/27(火) 08:09:05.01

>>404
#define DATE_UNDEFINED 29991231
みたいな感じにマクロ化してあればいいだけじゃん？
マジックナンバーで許されるのは0と1くらいだと思う

**デフォルトの名無しさん** · 2015/10/27(火) 08:17:38.90

括弧位つけろ

**デフォルトの名無しさん** · 2015/10/27(火) 08:41:24.34

>>407
実際にこのルールでやってるよ。

**デフォルトの名無しさん** · 2015/10/27(火) 08:55:24.16

UNREFFERENCE_PARAM(hCurInst)とかいう無意味マクロまーじ

**デフォルトの名無しさん** · 2015/10/27(火) 09:39:20.90

>>406
また言葉足らずだったが話の前提として住所と氏名でユニークキーになる場合の話
勿論結果が修正前と異なるようなら別のメソッドにしたり置き換えたりが必要
あとソース修正毎にドキュメント作るのは金融くらいしか聞かない
テスト自動化してればシナリオ流して終わり
必要以上に金かけるよりほぼ間違いないでコスト削減が今の主流だと思う
スマホゲームでメンテ後に即メンテとかよくあるだろw

**デフォルトの名無しさん** · 2015/10/27(火) 10:38:11.22

>>413
医療だけど、特殊例だったのか。
だとすると、医療でそういう運用してても出る障害考えたら、世の中のプログラマは一体どんな気持ちでプログラムしてるかわからんな。
必要以上に金かけずにコスト削減して、障害出したら、それは必要な金だったんじゃねーかなぁ。

**デフォルトの名無しさん** · 2015/10/27(火) 11:41:33.67

>>414
なるほど医療か
医療は周りにいなかったからわからなかった
医療だと慎重にならざるを得ないがバグ出ても修正すれば問題ない分野はそんなにテストに時間をかけない
毎回手動テストしてリリースするより自動テストでバグ出たら修正のほうがトータルコストはかからない
リリース優先か品質優先かは分野で全く異なる
ゲームで慎重なテストで時間使ってたら首飛ぶし逆もまた然り

**デフォルトの名無しさん** · 2015/10/27(火) 11:52:03.16

あと金の話だけどリリース時期は作る前から決まってる
そこがずらせないとなればバグのリスクとってもリリースを優先しないといけない
もしくは機能のそぎ落とし
3末リリースが遅れると決算への影響が大きいとかいろいろ事情がある
バグは出るものだからリリース後に改修すればいい
なかなか思ったとおりに仕事できないのは世の中の常w

**デフォルトの名無しさん** · 2015/10/27(火) 13:00:39.45

自動車とか産業機械とか医療は厳しいよね。
バグ流出したら普通に人が死ぬからなあ。

**デフォルトの名無しさん** · 2015/10/27(火) 20:49:01.37

工作機械の制御も簡単に死人出るからなぁ…。

**デフォルトの名無しさん** · 2015/10/27(火) 20:58:17.64

絶望的なソースコードか～
俺のソースコードは、いつでもスパゲッティになってるな～

**デフォルトの名無しさん** · 2015/10/27(火) 20:58:59.55

FXのツールとかで時限で誤動作爆発させたら大量に電車に飛び込みそう

**デフォルトの名無しさん** · 2015/10/28(水) 00:18:14.32

糞みたいなコードにはもれなく言い訳がついて来る
もし本気を出せば綺麗なコードが書けるかのような

**デフォルトの名無しさん** · 2015/10/28(水) 07:34:37.69

つまり全てのコードにはもれなく言い訳がついて来る

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

最近JavaScriptのswitch(true)イディオムを知ったが
do { ... } while(false)と同じような邪悪さを感じた

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

でもどこが邪悪なのか言えない？

**デフォルトの名無しさん** · 2015/10/29(木) 13:15:18.74

>>423
>do { ... } while(false)

これ最適化でdoの中に入ってこないイカしたコンパイラに昔遭遇して
発狂したことがある

**デフォルトの名無しさん** · 2015/10/29(木) 14:23:06.65

それは最適化じゃなくてバグだろ

**デフォルトの名無しさん** · 2015/10/29(木) 18:25:23.55

マイナンバークラスから氏名クラスへの変換関数が存在した場合の問題点。

**デフォルトの名無しさん** · 2015/10/29(木) 19:45:11.73

適用日付も引数にほしい

**デフォルトの名無しさん** · 2015/10/29(木) 20:06:17.64

期間持つのと、変換日時を任意に設定出来ることが最低条件かな。
変換ではなく、取得クラスになるだろうけど。

**デフォルトの名無しさん** · 2015/10/30(金) 16:02:41.19

>>409
0すら定数定義させられた事があったわー