今までみた絶望的なソースコード [転載禁止]©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/11/26(木) 21:17:07.03

なんかいきなり原発の話しだしてきワロタｗ

それとはぜんぜん違うだろう。

**デフォルトの名無しさん** · 2015/11/26(木) 21:26:25.45

コストを削った代償の話で何も的を外してない
二重の安全策を怠った最も悲惨な事例だよ
高台に電源装置置いとけば事故は防げたんだから
過信といえばまだ二十年もたってないがアップルが経営危機に陥っていた時期に誰が10数年先にマイクロソフト抜いて世界一の企業になると予測できたか？
世の中本当に何が起こるかわからないよ

**デフォルトの名無しさん** · 2015/11/26(木) 21:36:45.91

大きく的はずれだね。
必要ないと思っているものを削減するのと
必要あるものを削減するのとではぜんぜん違う。

また今度は関係ないアップルの話しだすし。
次はISISが戦争を始めるとかいいだしそうだ

**デフォルトの名無しさん** · 2015/11/26(木) 21:55:52.71

原発おじさんはVCSの謎の突然死よりも
部下がこのスレに書き込んでいないかを心配した方が良いと思う

**デフォルトの名無しさん** · 2015/11/26(木) 21:58:43.37

言いたいのは未来を予測できない以上二重以上の策を提供すべきということ
その必要かどうかはこの先ソースを保守する人間が判断するのであって今の人間が決めれることじゃない
20年前のプロジェクトの修正履歴見れるか試みたらすぐわかる話

**デフォルトの名無しさん** · 2015/11/26(木) 22:23:35.43

サンプルでないコーディングで
foo だ bar だ hoge だのと

**デフォルトの名無しさん** · 2015/11/26(木) 22:40:27.99

>>512
うち、20年前のはコメントでの変更履歴がまだあるわww
未だ動いてるのが凄いんだけど。

**デフォルトの名無しさん** · 2015/11/26(木) 23:09:16.39

>>519
うちもコメントやifdef等で残ってるのがある
修正入る部分にこれがあると何となく当時の背景が見えてくるから助かってる
バージョン管理は次々鞍替えして数年分しかない
どこが早く履歴の標準規格化してくれたらもっと分かりやすく差分や経緯を見れるんだけどな

**デフォルトの名無しさん** · 2015/11/27(金) 07:13:44.65

> 修正入る部分にこれがあると何となく当時の背景が見えてくるから助かってる

過去のバージョン見ればいいだけでは？
コミットログを見れば、何をしたのかもわかるし。

**デフォルトの名無しさん** · 2015/11/27(金) 07:14:59.83

> どこが早く履歴の標準規格化してくれたらもっと分かりやすく差分や経緯を見れるんだけどな

差分の見方とコミットログの書き方を勉強しようよｗ

一体、何を標準化しろと言ってるのかわかんね。
お前なら、どういう規格を作るのか言ってみなさい。

**デフォルトの名無しさん** · 2015/11/27(金) 07:29:24.45

>>521
もちろん過去のバージョンと台帳と突き合わせて見ればいいんだろうけど、
そこに変更が入っている事、がソース変更時に読めるのはわかりやすいよ。
今でもチケット番号だけ書いてる。
チケット番号書いとけば、コミット時に拾ってくれて、チケットに対象として載るしね。

**デフォルトの名無しさん** · 2015/11/27(金) 07:45:03.01

> そこに変更が入っている事、がソース変更時に読めるのはわかりやすいよ。
ほぼすべての行に変更は入る。最初から何万行というコードが一気に出来上がるわけじゃない。

> 今でもチケット番号だけ書いてる。

ソースコードには、コードの意味ではなくてなぜそうしているか？を書く。

変更の理由という形ではなくて、なぜそうしたのか？を書かなければいけないほど
重要なことであれば、その理由を書いた上でチケット番号に関連付けるのは普通。

その場合は、コメント（チケット番号）は変更した理由という履歴ではく、
現在の姿として、なぜそうしているかという形で書けばいい。

変更したものを全部残すという考え方をしていると、現在のコードではなく
過去に存在し今は存在してないコードに対しての履歴まで残ってしまうだろ。
不要な履歴コメントは消すべきだ。

**デフォルトの名無しさん** · 2015/11/27(金) 08:24:51.55

>>524
何が言いたいかわからん。
関数の頭のブロックにもチケット番号列挙してあるんだけど、
古すぎるコメントはチケット番号だけ残して消せば良いんだよ。

何故そうしているか、はコーダさん用のコメントだよね。
それらは本来、変更仕様書に書いてあるべき内容。
重要なことも何も、ソース改修はすべて重要な事だからチケット切って文書化すべき。

何故そうしているか、だけでは片手落ちも良い所。
○○年度○月○○法改正により計算方法が変更になり、下記の計算方法で計算する必要がある
　以下計算式　資料　No.xxxxx Pp y-z及び…
なんて完璧にコメント書いてくのも、文書の方に書けと言いたくなる。

一切残さない、もありなくらい。

**デフォルトの名無しさん** · 2015/11/27(金) 08:44:05.48

1998年度○月○○法改正により計算方法が変更になり、下記の計算方法で計算する必要がある
　以下計算式　資料　No.xxxxx Pp y-z及び…

これは消していいだろう？

**デフォルトの名無しさん** · 2015/11/27(金) 08:47:54.68

>>525
> 何が言いたいかわからん。

ソースコードに余計なコメントを書くな。
変更履歴も書くなって話だよ。

仕様は仕様書に書いてあるんだから、
documentディレクトリの○○テキスト参照って書けばいい。
仕様が新しくなったら、新しい仕様のファイル名に書き直すだけ。

修正のたびに行を増やす必要はなくなる。

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

>>526
1998年度以前のデータが二度と確実に入って来ないのであれば消しても良いと思うけど、基本は残すべきだと思う。もちろん文書に。
コメントとして処理内容を書くのであれば、これくらい書かないと片手落ち。
不足のあるコメントは余計なコメントに等しいよ。

>>527
だから、チケット番号で良いって言ってるんだけど。
文書載せられないようなトラッキングシステム使ってたらすまん。

**デフォルトの名無しさん** · 2015/11/27(金) 12:04:27.10

そもそもチケットがない

**デフォルトの名無しさん** · 2015/11/27(金) 16:09:25.59

>>523
ソースコードに書かれたチケット番号をBTSが拾ってくれるの？
というか拾って何になるのか判らないけど

**デフォルトの名無しさん** · 2015/11/27(金) 16:31:27.16

チケット＝作業、作業が終わるタイミング＝コミットなのだから、
チケット番号（≒Issue番号）はコミットログにつけるもんだと思うが？
特に重要な事に関しては、Issueに対してソースコードで注釈入れるけどな。

Issue駆動で開発すると

1. 新たなIssue（バグ報告や機能追加など）を作成する
2. それに対してのプルリクエストを作る
3. そのプルリクエストに1つまたは複数のコミットが含まれる。
4. そのプルリクエストをマージするとIssueが閉じられる。

という流れになる。

またプルリクエストっていうのは（Issueもだけど）、掲示板みたいなもので
それに関しての情報を時系列に会話するように記録できる。

最終的な修正内容をプルリクエスト（会話部分じゃなくて主文）に書いてそれをコミットすれば、
ソースコードのコミットログとして修正内容がバージョン管理される。
あとから修正を追いかけたいときはコミットログを見れば修正内容がわかる。
リンクも記録されてるから、コミットログからプルリクエストにもIssueにたどり着けるって寸法

これがgithubを使った主な開発のワークフローね。

**デフォルトの名無しさん** · 2015/11/27(金) 17:35:57.29

>>530
拾ってくれるよ。コミット時に。
ソース管理もバグトラックも出てくる帳票も全部連携してる。
コミット時にも書けるけどね。
どの関数に手を入れたかわざわざ手で書かなくても良くなってるのと、
ソースとリリースノートだけ読んでもある程度わかるように。

あと、逆にリリース用チェックアウトした時にリビジョン等のスタンプも押される。

**デフォルトの名無しさん** · 2015/11/27(金) 18:19:01.79

手動でソースコードに変更履歴書いて
古いコードを残す文化とまるで違うｗ

**デフォルトの名無しさん** · 2015/11/27(金) 18:29:07.73

>>532
チケット番号←→コミットログ←→変更ファイルで芋づる式に取り出せる情報なのに
人間が変更ファイルをマーキングして周ってるのか
本人が言ってるならそうなんだろうけど随分変なやり方してるね

**デフォルトの名無しさん** · 2015/11/27(金) 20:07:14.94

>>534
正確には変更ファイルにマーキングしてる訳じゃないよ。
変更箇所にマーキング入れてるだけ。

いつでもdiff取れるわけではないからね。

**デフォルトの名無しさん** · 2015/11/27(金) 20:15:00.15

> いつでもdiff取れるわけではないからね。

いつでもdiff取れるようにしなさいよｗ
あほだなぁ。

**デフォルトの名無しさん** · 2015/11/27(金) 20:41:52.19

>>535
納得した
そういうやり方ならありかもね

つってもソースコードから参照されてるチケットが陳腐化してないか
一々管理しなきゃならない不毛さを思うと
その時間でコメントを真面目に書けよって思うけどねｗ

**デフォルトの名無しさん** · 2015/11/27(金) 21:17:32.03

>>521
その時コミットログ見れればそれでベストだが環境移行等で見れなくなった時の話
>>522
差分やコミットログをどんな環境でも見れるためのファイルフォーマットだよ
ファイル仕様が決まれば別のバージョン管理ソフトも必ず対応するからOS変わろうがツール変わろうが将来見ることができるだろう
コードが理解不能になって作り直しってのはよくあるからな

**デフォルトの名無しさん** · 2015/11/27(金) 21:34:46.43

> その時コミットログ見れればそれでベストだが環境移行等で見れなくなった時の話
見れなくならないように、ちゃんと環境移行すればいいだけ

> 差分やコミットログをどんな環境でも見れるためのファイルフォーマットだよ
差分はgit diffでテキスト形式に変換される。
gitじゃなくてもすべてテキスト形式に変換できる。
テキスト形式が見れない環境など無い。

**デフォルトの名無しさん** · 2015/11/27(金) 21:59:12.67

>>539
同じところにも存在してればなんとかなるかもしれんが配置変わったり消したりするのは普通に発生する
その時見れないのでは話にならない
古いプロジェクトやったことある人間ならわかると思うが修正履歴が完全に残ってすぐ見れるなんて夢物語
ドキュメントなんてないしあっても嘘八百
ソース=仕様ってのしかお目にかかったことないわ
10年くらい放置されてて突然手を加えるとなったときには開発環境が動かせないとかなw

**デフォルトの名無しさん** · 2015/11/27(金) 22:03:24.34

>>536
そりゃまあ、もちろんそうだけどね。それが実現するなら構わんけど。
地震が起きて、停電は起きるわ、窓ガラスは割れるわ、
支社とネットワークが上がらないわ、端末の何割かが壊れるわ、
なんやかんやで大変な事になっても
「今差分取れないし履歴も読めないのでわかりません、復旧まで待ってね」って投げちゃえるなら全部電子媒体で持ってて、必要な時に必要な分を随時取り出してもいいだろうね。

**デフォルトの名無しさん** · 2015/11/27(金) 22:07:56.50

>>541
火事になって会社焼けたら困るなら、
別の所にあるHDDとコンピュータを使えばいいのでは？

**デフォルトの名無しさん** · 2015/11/27(金) 22:09:31.08

紙媒体だと、燃えたら全損だからな。
バックアップも取れないだろうし。

**デフォルトの名無しさん** · 2015/11/27(金) 22:10:31.74

>>540
だから、デジタルで記録された、現在動いている
ソースコード以外役に立たないんだよｗ．
いくら紙の資料があっても、それが最新とは限らないからね。

**デフォルトの名無しさん** · 2015/11/27(金) 22:11:26.12

>>540
> 古いプロジェクトやったことある人間ならわかると思うが修正履歴が完全に残ってすぐ見れるなんて夢物語

古いプロジェクトからずっとバージョン管理してるわｗ

修正履歴が残ってないのは、バージョン管理していない頃と、
紙媒体で履歴を保存していたものだけ。

**デフォルトの名無しさん** · 2015/11/27(金) 22:14:12.17

地震でてんやわんやですが、
「差分取れるし、履歴も読めます。ただ、沢山の紙の資料の中から
探すのに時間がかかるのでちょっと待ってください。
パソコンを直すよりも時間がかかりますがねｗｗｗ」

**デフォルトの名無しさん** · 2015/11/27(金) 22:16:58.51

俺なら、地震で仕事にならないなら、
別の場所に支社があるんだろう？
そこに仕事まわすだろうな。

デジタルデータなら共有も簡単なので、そっちで差分見ればいい。
紙に保存した資料に頼ってるから、余計大変なことになってるわけで。

命の危険もある中で、地震で散らかっている倉庫を探しまわって
仕事をする必要はない。優先順位を考えれば当然そうなる。

**デフォルトの名無しさん** · 2015/11/27(金) 22:28:38.44

>>545
紙で履歴保存してた頃にソース記述しとけば今でも見れたわけよ
俺は履歴は現行ソースと同等レベルで重要と思ってる
履歴がなくてコメントもろくにない中データ保存に分割してよくわからん計算してる理由わかるやつなんかそうそういないわ
わかった時には脱帽したよフロッピー先輩w
履歴あればすぐにわかったんだろうがな
今の時代にデータ保存にそんなことしない無理すぎた

**デフォルトの名無しさん** · 2015/11/27(金) 22:47:37.06

つランプ型秘密分散法

**デフォルトの名無しさん** · 2015/11/27(金) 23:01:18.56

>>542
火事になっても大丈夫なように複写は他の所にも保管はしてあるよ。

>>543
お前コピー機も知らないの？

>>544
それは管理の仕方次第

>>546
探さなくても台帳、リリースノート、変更仕様書、等々キングファイルに綴じてあるからすぐ見つかるよ。

>>547
サブシステム毎に担当わかれてるからね。
こっちの命の危険なんか関係ないよ。
客先にはどんどん怪我人搬送されてたり、自家発電切れそうで縮退運転始まったり、
それこそこっちが一人二人死んだ位どうという事は無いよ。ただの労災。
命を預かる物作ってるのに、その責任に自分の命を代えられないほど情けない人間でもない。

**デフォルトの名無しさん** · 2015/11/28(土) 00:28:53.24

支社があるような会社の運用ではないように見えるのだが

**デフォルトの名無しさん** · 2015/11/28(土) 08:03:00.10

老害ってほんとうに嫌なものだ。

**デフォルトの名無しさん** · 2015/11/28(土) 12:25:04.44

>>551
平時とは違うよ。
それこそ電子化されたもの見りゃいいからね。
電話が復帰したら関西に投げたし。
当日翌日があんな状態になってもちゃんと回っただけいい方だと思うけど。

>>552
古い物を知らん奴が、解決策も無く古い物は良くないと言ってもなんの説得力も無い。
中学生の政治への憤りみたいに見える。

**デフォルトの名無しさん** · 2015/11/28(土) 17:31:18.96

資産を異なるメディアでバックアップする事と
ソースコードからドキュメントを自動生成する事は完全に別問題なんだけどね
今後者のアプローチとして突っ込みが入ってるのに
なんで災害を強調するの？

**デフォルトの名無しさん** · 2015/11/28(土) 19:20:09.38

災害だと体験した人が少ない。

それは「俺にはわかるがお前らにはわからんだろ」
という上から目線をいうことができるということを意味する。

わからんと思うことなら説明するのが筋なんだが、
説明ができないので、別の方法で代用する。

それが「お前らにはわからんだろ」という言葉で
圧力をかけること。そのために災害を強調している。

**デフォルトの名無しさん** · 2015/11/28(土) 22:46:57.94

何の根拠もなしに、古いものを知らないと断定出来る才能自体が老害だとは思う。

**デフォルトの名無しさん** · 2015/11/28(土) 22:57:48.59

>>555はこういう喩え話でも説明できる。

あるとき若者が戦争についてあれこれ議論しているとする。
戦争について興味が無い人が多い世の中で素晴らしいことだが
そこで老人が現れて一言言う。

「戦争を実体験していないお前らに何がわかる？」

これでもう議論は止まってしまう。わからないのは事実だし
それはどうしようもないこと。その老人に勝つことは出来ない。

これは老人が正しいことを意味するわけじゃない。
例え老人の言うことが100%間違っていたとしても、
「お前らに何がわかる？」と言われれば反論できない。

議論の内容ではなく、その外側から圧力をかけて
黙らせているだけにすぎない。実に便利で姑息な手段だよ。

**デフォルトの名無しさん** · 2015/11/28(土) 23:14:55.87

姑息か？

**デフォルトの名無しさん** · 2015/11/28(土) 23:19:08.72

ジジイに叱られて黙る奴ｗ

**デフォルトの名無しさん** · 2015/11/29(日) 01:31:27.76

ここまで構成管理という言葉なし。

レベル低すぎ。

**デフォルトの名無しさん** · 2015/11/29(日) 08:50:40.60

何で、発作のようにはねっかえって来てるのかわからん。
システムも、アナログな管理でも、管理さえ出来てれば良いよね、ただの運用のための道具、手段だから。
ってだけの話でしょ。

よほどなんか負い目あるの？

**デフォルトの名無しさん** · 2015/11/29(日) 09:27:52.62

無駄な労力を使わせているのが問題かと。

**デフォルトの名無しさん** · 2015/11/29(日) 13:49:38.76

無駄じゃ無いじゃん

**デフォルトの名無しさん** · 2015/11/30(月) 15:53:15.93

おっ　無駄か無駄じゃないかの水掛け論か？

**デフォルトの名無しさん** · 2015/11/30(月) 16:31:16.32

ほんとね、理由言わずに無駄っていうやつ、何なんだろうねｗ
水掛け論始めたいのかってな。

**デフォルトの名無しさん** · 2015/11/30(月) 16:33:31.10

>>561
> システムも、アナログな管理でも、管理さえ出来てれば良いよね、

管理できるのは最低限で、効率的に管理して
コスト削減するのが、システム化の目的の全てでは？

当たり前すぎて、これだけで論破（笑）出来てしまう気がするが。

**デフォルトの名無しさん** · 2015/11/30(月) 17:26:53.50

>>566
その、最低限が業種によって違うよね。
って話してるのに、何言ってるの？
コスト削減、無駄の排除とそれは相反しないよ。
たとえれば、命綱はかける手間が無駄だから省略、作業場所に敷くマットは高いので敷かない、すべてロボットで窓ガラス拭きます！なんて話だよ。

その上で窓ガラス拭くならロボットで良いし、拭けないなら拭けるまで待っても死人が出ないからそれでいいね、って話だし、
災害時用の電波塔なら、拭けないなら拭けるまで待つなんて出来ないんだからいざという時は人が作業できるように体制は保持しようね、って話なんじゃん。

全然ソースコード関係ないけど。

**デフォルトの名無しさん** · 2015/11/30(月) 17:37:12.45

>>567
じゃあ文句言う対象は俺じゃねーだろ。

「無駄」と言った奴に対して、
最低限は業種によって違う。
無駄じゃないかもしれないだろって
説教たれろよ。

一般論でしか無いし全く無意味な説教だがな。

**デフォルトの名無しさん** · 2015/11/30(月) 17:50:09.32

管理さえできていればいいよね・・・そこで思考停止
管理できるのは当たり前で、効率的に管理するのが重要・・・思考停止していない。

**デフォルトの名無しさん** · 2015/11/30(月) 19:42:10.76

>>568
何をそんなにいきり立ってるの？
明後日のカイゼンかなんかを提案して怒られて拗らせてるの？

>>569
管理さえ出来ていれば良いとしか言いようがないでしょ。
もしアホ揃いで紙運用回す能力もないなら、それは「紙では運用管理出来ない」んだから、管理出来ていない≒何らかのソフトで運用しなければならない、だよね。
まんま同じで、システムだけでは回らないのであれば、それは「システムでは運用管理出来ない」なんだから、紙モノも残さんといかんな、って話じゃん。
何も否定してないのに、アホなの？

全部手段で道具で、目的は「満足に管理して業務を回すこと」だよね。
思考停止でも何でもないよ。

**デフォルトの名無しさん** · 2015/11/30(月) 19:44:53.23

>>570
> 何をそんなにいきり立ってるの？

俺に言うべきじゃないことを俺に言うからじゃん。

> 明後日のカイゼンかなんかを提案して怒られて拗らせてるの？
お前の思い込みって、ほんと面白いよなｗそんなの実経験から思いつくの？ｗ

**デフォルトの名無しさん** · 2015/11/30(月) 19:45:36.33

>>570
だから管理できるのは最低限だって。

ここから更に効率が良くてコストも低い方法に変えていくの。

**デフォルトの名無しさん** · 2015/11/30(月) 21:27:42.17

>>571
俺に言うべきこととかどうでもいいよ。
よっぽど自己評価高いのな。

実体験から思いつくよ。よくこの類のダメ出しはするから。

>>572
何言われてるか理解できなければいいよ。
結果論として無駄に効率が悪くて無駄にコストがかかる運用なんて、その最低限を満たして無いよね、って話。

**デフォルトの名無しさん** · 2015/11/30(月) 22:55:34.80

VCS標準化おじさんに原発おじさんに
面白い人がよく集まるスレですね

**デフォルトの名無しさん** · 2015/12/01(火) 09:43:08.58

導入コストっつーか慣熟期間に一時的に落ちる効率が
導入後に取り返せる見込みがない場合ってあるよな。
太陽光発電システムを数年スパンで丸ごと入れ替える
みたいな、全然元が取れてないパターン。

**デフォルトの名無しさん** · 2015/12/01(火) 17:07:22.23

俺が正しい
俺だけが理解している
俺の意見が理解できないやつはクソ

という論調の書き込みは読むに値しない
例え正しいことが書いてあったとしてもな

**デフォルトの名無しさん** · 2015/12/01(火) 17:55:19.70

>>576
それで、その意見は正しいのかね？

**デフォルトの名無しさん** · 2015/12/01(火) 18:18:42.51

>>577
正しくないぜ
当然じゃないかハハハ( ´∀`)

**デフォルトの名無しさん** · 2015/12/03(木) 15:32:59.30

hoge[1] = 89123;
hoge[2] = 123;
hoge[3] = 1234;
hoge[4] = 14323;
hoge[5] = 1123;
hoge[6] = 15623;
hoge[7] = 3123;
hoge[8] = 1323;
hoge[9] = 1223;
hoge[10] = 1234;

**デフォルトの名無しさん** · 2015/12/03(木) 15:33:33.33

hoge[1] = 89123;
hoge[2] = 123;
hoge[3] = 1234;
hoge[4] = 14323;
hoge[5] = 1123;
hoge[6] = 15623;
hoge[7] = 3123;
hoge[8] = 1323;
hoge[9] = 1223;
hoge[10] = 1234;

**デフォルトの名無しさん** · 2015/12/03(木) 18:06:22.96

あー、これ系のソース書いたことあるわ。
バイナリファイル中のファイル位置、サイズだったか、
固定長電文のフィールド位置だったか。

**デフォルトの名無しさん** · 2015/12/03(木) 18:20:54.04

データセットを DataGridView に表示するのに、バインドせずにループで回して代入。

**デフォルトの名無しさん** · 2015/12/04(金) 09:44:59.80

>>582
ループしてるならまだ絶望的じゃないな

**デフォルトの名無しさん** · 2015/12/04(金) 10:54:45.80

データバインドとかここ10年くらいのものだろ

**デフォルトの名無しさん** · 2015/12/04(金) 15:17:07.67

>>582-583
バインドなしループなしを見たことがある

**デフォルトの名無しさん** · 2015/12/04(金) 16:01:55.05

>>584
> データバインドとかここ10年くらいのものだろ
いつが最初かしらないけど、Visual Basic 4.0の時代にはあったよ。
1995年発売だから20年前だね。

http://windowsitpro.com/windows/visual-basic-40
http://windowsitpro.com/site-files/windowsitpro.com/files/archive/windowsitpro.com/content/content/2494/screen_01.gif

古くてちゃんとした情報は見つけづらいけど、MSRDC、RDO、DAO、DBGridあたりの
キーワードで調べれば断片的に見つかるはず。

ウェブのGUI技術なんて20年前の歴史を辿ってるだけだからさ。

**デフォルトの名無しさん** · 2015/12/04(金) 16:14:52.25

そうだね

**デフォルトの名無しさん** · 2015/12/04(金) 23:55:01.31

#define zero 1

**デフォルトの名無しさん** · 2015/12/05(土) 00:48:19.55

0=Off, 1=On を表すパラメータと、0=On, 1=Off なパラメータが混在していて
どっちがどっちかは列挙型の名前で区別するようになっているのだが
その名前付けが間違っている

enum FLAG_0_IS_OFF { OFF = 0, ON = 1 };
enum FLAG_1_IS_ON { ON = 0, OFF = 1 };

**デフォルトの名無しさん** · 2015/12/05(土) 11:26:47.51

#define TRUE 1
...
if(hoge == TRUE){...}

**デフォルトの名無しさん** · 2015/12/05(土) 12:16:35.79

>>590
if((hoge == hoge) == TRUE)

**デフォルトの名無しさん** · 2015/12/05(土) 12:17:21.84

なにかを召喚しようとしているとみた。

**デフォルトの名無しさん** · 2015/12/06(日) 11:01:47.05

A4紙ペラ1枚の仕様書兼設計書しかないのに、10万行のソースコード。

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

昔、偽装請...派遣でいった会社で
ありとあらゆる引数が

const boost::shared_ptr<XXX> &val

となっている現場があった。
何かが、狂っていた。

**デフォルトの名無しさん** · 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

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

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

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

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