今までみた絶望的なソースコード [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
今井氏:ソースコード公開は、社長のティム(*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 #define TRUE 1 ... if(hoge == TRUE){...} >>590 if((hoge == hoge) == TRUE) A4紙ペラ1枚の仕様書兼設計書しかないのに、10万行のソースコード。 昔、偽装請...派遣でいった会社で ありとあらゆる引数が const boost::shared_ptr<XXX> &val となっている現場があった。 何かが、狂っていた。 開放領域への参照で落ちて地獄のデバッグよりか遥かにまし C++の世界って相変わらず ごちゃごちゃしてんのなw 動くのに間違いっていうのが多すぎる ループ変数がグローバルにおいてあって、 そのループ変数を使ったfor文の中から呼び出される 各関数内でループ変数がインクリメント・デクリメントされているコードに絶望した覚えがある 再帰処理の中で再帰の深さ調べて云々するプログラムにそんなのあったな >>600 コードが仕様だ! コーディングミスの副作用が絡み合い何故か動いているのだが 書いたやつやめたから誰も手が出せない、なんとかしろという展開。 配列に間違って一つ余計なデータを加える + ループ回数を間違って最後の一つを処理しない = _人人 人人_ > 正常動作 <  ̄Y^Y^Y^Y ̄ >>603 最後にnull終端が(暗黙に)期待されてるバグありコードで たまたまメモリが0で埋まってて動いてるソフトが世界中に沢山ある C言語でbssセクションに配置された未初期化変数はzero-fillが保証されている ことを知らない無能は結構多いよね。 >>606 余計なデータだろう。 番兵はあくまでテクニックだ。 >>608 そんなの知らねーが未初期化でReleaseビルドの時だけ発生するバグを埋めるアホはよく見てきた 新人でもはっきり判断できるような可読性高いもの書け それがプロの最低条件 正確には「新人でも上級者でもわかる可読性が高いコード」な 新人が簡単に分かったとしても、 上級者が苦労するようなコードは本末転倒。 上級者がこっちのほうがわかりやすくシンプルだと思ってるのに でも新人はこんな高度なテクニックは知りませんからね。 複雑で冗長になりますが、新人でも知ってるテクニックだけ使いますよ。 というのは大間違い。 わかりやすさの基準は上級者が決める >>608 俺の使ってたCスタートアップは.bssゼロフィルしてなかった 妥当な理由があったからなんだが、何だかモヤモヤした bssゼロフィルなんてものを前提にコード書く奴は素人 こういうバカはやっかいなバグをしこたま仕込むタイプ グローバル変数とかスタティック変数は 初期値を入れてなければゼロが初期値ってのは前提でしょ >>613 そういうのは処理系がエラーを吐けば問題ない 言語仕様なんて現実の処理系の前じゃ単なるガイドラインにしか過ぎん 言語仕様としてプラットフォーム依存も定義されてるよ 1クラスが6000ステップ以上のJavaソースをちらりと見た。 内部クラスを使っているかも知れんが、Javaってもっと細切れに クラスを作るものかと思っていた。 Javaだけじゃなくて、どんな言語でも、 クラスがある言語なら細切れにクラスを作るよ。 >>621 ダメな例だな まとまってるから解析は比較的しやすいがテストとなると内部の状態が多すぎてまともなテストできない クラスは小さいひとつのことに集中し他とはできるだけ疎結合 中級者はトリッキーはコードを好む これだけは間違いない 確かに上級者のコードは見やすい。 ロジックは複雑だがコードとしての見やすさ。 上級者:バカの相手をしない。馬鹿にかかわらない。 中級者:バカがいると頑張る。 初心者:バカをバカと認識出来ない。 上級者は比較的謙虚だよ。 まあ、悟りが入っているからだが。 ifもelseも全部一行に詰め込むガイジは死ね 読みにくいんじゃボケ!!!!!!!!!!!!!! >>636 個人的には、 if(kinoko == stick){ }else{ } という書き方ではなく、 if(kinoko == stick) { } else { } って書く人は嫌い。 俺はできるだけ改行しないほうが好きだが、コメントの位置が上手くできないのが悩みどころ // このコメントはOK if(){ }else{ // このコメントを先頭にしたいけどelseはこの位置が好き } こーだろ if(){ // 真の場合は・・・する }else{ // 偽の場合は・・・する } >>637 嫌いだけど、 C#ってその形なんだよね つーか、elseはあまり書くべきでない。 if(){ // 真の場合は・・・する }else{ // 偽の場合は・・・する } ではなく、できるだけ if(){ // 偽の場合は・・・する return;(またはエクセプションをthrow) } // 真の処理 という形になるように常に心がける。 if else という書き方が深いネストを作るきっかけになっている事に気づかないと いつまでたっても、初心者、中級者のまま。 一画面で収まるなら別にネストしてていいや。 それ以上はオブジェクト化するかな >>643 MISRA を否定するのか。是非とも MISRA の連中を説教してやってくれ MISRA-C ルール 15.5 推奨 関数は、その最後に1つだけの出口を持たなけらばならない >>643 ifでもelseでも最終的に同じ処理してからリターンしたい場合は? 決め付けるのは自称上級者 途中リターンが見やすいと思った場合は使うしそうでない場合はelseも使う >>645 C言語ではそっちの方がよかったんかね。 いまって関数単位で単一責務原則を適用して関数が小っちゃくなるから あまりこだわる必要なさそうだけど。 話ぶった切るけど今まで見た中で最高に頭沸いてると思ったのはこれ // 前略 /* * きっとキミは来ない 独りきりのcarch anything * silent kill. do ignore. */ } catch (Throwable e) { assert(true, "来ちゃった♪" + e); } 書いた人は壊れて辞めたらしい >>646 あまり書くべきではない とか できるだけ心がける という、超初歩的な日本語の意味を理解できない馬鹿がいるとは… さすが初心者はプログラムだけでなく日本語も不自由と見える。 そう書くのが妥当なら書けばいいに決まってるじゃないか。 >>645 世の中のコードが全てCで書かれているとは知らなかった。 そんな世の中なら、さぞ住みにくかろう。 客先ですごいお金が絡むシステムがスパゲティコードだったから担当になるまえに怖くて会社辞めた できるだけ〜になるように、常に心がける なんかおかしいか? ほんとに日本語不自由な奴ばっかだな。 >>645 > MISRA-C ルール 15.5 推奨 関数は、その最後に1つだけの出口を持たなけらばならない そのルールを守るのは簡単だよ。 途中でreturnしたくなったら、代わりに関数の最後にgotoすればいいw そのMISRAのバカルールはな大昔の最適化が物凄くしょぼかったコンパイラ で出たコードをこれまたしょぼいデバッガでデバッグするために関数の入り口と出口を アセンブラレベルで1つずつにするためのものなのだよ もう完全に時代錯誤 >>654 gotoもダメなんじゃないかな?みすら的に考えて。 みすらそう思う。 >>656 ならwhile(1)してbreakすればいいよw マルチスレッド対応が当たり前になった今クソ長いコードや分岐だらけとか終わってる シンプル・イズ・ベスト 大きな建造物と同様細かく作業を分けて小さな単位を積み上げていって大きくするのがセオリー 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は最小限で評価したい 客が読みにくいという理由でガード(関数の先頭あたりでリターンする)を すべて if else に書き直させられたが 何でくだらない仕事を増やすのだろうか >>660 客の脳みそが腐っているんだからしょうがないんじゃね? 腐っててもお金は払ってくれるんだから、まぁ、ごみ処理だと思えば。 自称上級者とかほざいてた >>646 は、 そろそろ自分の馬鹿さ加減に気づく頃かな。 >>660 else;つけとけばいいだけ わざわざelse句として書く必要ない >>662 ケースバイケースってことを言ってるんだと思うよ。 バカだとは思わないけどなあ。 どちらのケースでもやりたいなら呼び出し元にコールさせればいい 分割がなされてないとそうなる >>664 5:5 くらいでどっちのケースもあると思ってるなら、 お前も>>646 も頭に糠味噌つまってるくらい馬鹿だ >>666 バカっていいたいだけなんじゃないの? なんかあまり中身がないような・・・。 好みの問題だしなあ。価値観は優劣をつけるためのものじゃないと思うんだよね。 他人の価値観を自分の中に取り込んで自分の世界を広げるためのものなんだよ!!←できる人 >646 >ifでもelseでも最終的に同じ処理してからリターンしたい場合は? そういう、共通処理っていうのは呼び出し元の処理なんだよ いい加減に気づけ馬鹿 >>664 >>668 究極に頭おかしい人がきました。 好みの問題だと本当に思っているらしい。そりゃ、世の中クソコードで溢れるわ。 IDみたら同じやつか。こいつ、本当に糞コード生産マシンだろうな。 >他人の価値観を自分の中に取り込んで自分の世界を広げるためのものなんだよ!!←できる人 "←できる人"って、ばーーーーーーーーーーーーか! >>673 待って!落ち着いて!いまから私が言うことに耳を傾けて。 びっくりするかもしれないけどホントのこと伝えたいから。 プログラムはケースバイケースなの!!なんでもありなの!!! ケースバイケースのことはあるが、今回のことは違う。 以上 馬鹿 >>669 じゃあif elseがない処理=呼び出し元の処理ということ?? 関数作る必要ないじゃんwww >>665 呼び出し元が複数あったときにコードが増えるんですがw 何のための関数化だよ せめて関数内で別関数としてコールする形式にしないと無駄が増える 経験的に、後から読むとき、関数最初でのreturnは見やすいけど、 途中でのreturnはelseのほうが見やすかったりする だからケースバイケース >>669 関数でローカルに取得したリソースの解放ってのは関数内部の処理だろう。 C++ならRAIIでやるところかもしれんが。 >>678 条件分岐を呼び出してあとに続く処理を実行する方を外から呼び出してもらうようにするだけ 分解すればあとの処理はifの条件にかかわることなく一回でテストが終わる ダラダラ一つのメソッドに書くとマトリックス的にテストケースが発生し産廃コードが誕生する >>680 そういう等価な書き換えでテストケースが減るわけがないんだがな。 C0カバレッジしか見てなくて途中returnのケースをテストしてないのかとも思ったが、 ひとつの関数だとマトリクス的にケースが増えるってのが意味不明だな。 どういう基準でテストしてるんだか。 >>681 if A else B C Cが別関数になってないとACとBCのテストパターンコードがいる 一方別関数の場合はAとBそれと独立してCで事足りる これが長いものになると前者は爆発的にパターンが増えていく 関係性がないものは分離する 関係性があっても関係性の部分だけを取り出し分離する 細かくなってればテストコード自動生成も実用性が出てくる デバッガで見るとreturnで関数の最後に飛んでいるから、 途中でreturnしてもいいんじゃないの? 一方職場でジャンプ関数使う人はいた。 でも1人でやってるプロジェクトなんで見て見ぬふりをしたw 自分以外がメンテナンスできないようにする人っているしね… ジャンプ関数ってまさか longjmp()とcome_from()? gotoがましに見えるレベル >>682 分岐網羅ならどっちにしろACとBCの2ケースになるように見えるが。 それともAとBとCの単体テストだけやっておしまいって話? ついでに言えば、これがどう>>680 の説明になっているのかわからん。 >>685 由緒正しき「継続」という奴だ,まさか,とかいっていいのか? come_fromって何かと思ったらサンプルコードじゃんw 「returnするのが面倒くさいからと」代わりにジャンプ関数使っていたな… (なんでも手製でツールを揃えないといけない時代で)独立したツールだったから 誰もソースコードチェックしなかったんだろうね。 hdqMNonUの戯言に耳を傾ける馬鹿は+5afeFvRみたいな知恵遅れだけだ。 人命にかかわる部分はたいていC/C++で書かれているから、C/C++を使う人だけ気を付ければ良いんじゃないだろかね。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる