今までみた絶望的なソースコード [転載禁止]©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 ループ変数がグローバルにおいてあって、
そのループ変数を使った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++を使う人だけ気を付ければ良いんじゃないだろかね。 >>680 >>682 に書いてあることの意味が分からない奴が、現役でプログラマしてるって事が恐ろしい… >>685
>それともAとBとCの単体テストだけやっておしまいって話?
だったらお前はその上層と下層を全て含めた
ABCDEFGHIJKLMN…
の全てのケースを含んだテストを一生かけてやってろ。
ユニットテストのしかたもする意味もわかってない馬鹿。 単体テストのやり方がわかっていないからといって馬鹿とは限らない。
アインシュタインは単体テストのやり方を知っていただろうか。 単体テストのやり方がわかっていないから馬鹿だといってるのではない。
馬鹿だから単体テストのやり方がわかっていないと言っている。 AのバグとCのバグを合わせた結果、テストケースでは見かけ上正しい出力がされてグリーンになってしまいました、
ABとCが分けてなかったらどうやって隠れた問題を検出するんだ。 そもそも全てのプログラマがユニットテスト書くわけでもないしね(技術的にも仕様的にも) ユニットテスト出来ない奴がいる事と、理想的なコード自体の書き方と、何の関係があるんだよ。
何がそもそもだ、ばーーーーーーーーーーーか! >>1
RPGツクール2000 , RPGツクールMV https://tkool.jp/mv/ ( JavaScript 採用 )
WOLF RPGエディター http://www.silversecond.com/WolfRPGEditor/
デュエル・マスターズ Android版 ,i-OS版、公式 http://dm.takaratomy.co.jp/extra/dmapp/entrygate_ds/
デュエル・マスターズ対戦CGI ex
https://web.archive.org/web/20150809154946/http://www53.atwiki.jp/dmsuishinparty/pages/314.html
デュエル・マスターズ(デュエマ)DM ONLINE 1.8a / VanGuard ONLINE 1.5a
https://web.archive.org/web/20150809160254/http://uhyohyohyo.sak ura.ne.jp/hsp.html
ヴァンガード専用ネット対戦ツール【 VanGuard Online 】
https://web.archive.org/web/20150809155032/http://kiimaa.jugem.jp/?eid=61
「カードファイト!!ヴァンガード」のネット対戦ができる公式オンラインゲーム「Cardfight!! Online」 2015年冬スタート
https://web.archive.org/web/20150809153724/http://supersolenoid.blog63.fc2.com/blog-entry-6886.html
遊戯王 Automatic Dueling System
https://web.archive.org/web/20150809164855/http://www3.atwiki.jp/ads-wiki/pages/20.html
遊戯王 デュエル・オンライン
https://web.archive.org/web/20150809171527/http://www31.atwiki.jp/vipdo/pages/15.html
https://web.archive.org/web/20140628005202/http://do.yugioh-portal.net/
ウィクロス( WIXOSS ) WEBXOSS http://webxoss.com/about_en.html http://webxoss.com/DeckEditor/
BG(ボードゲーム)Engine https://web.archive.org/web/20151209080842/https://bgengine.net/
https://web.archive.org/web/20151209172205/http://14owl.hateblo.jp/entry/2015/12/09/011234
アプレンティス マジック:ザ・ギャザリング(MtG)オンライン化 http://homepage1.nifty.com/Q_Q/ap.html
https://web.archive.org/web/20151202202725/http://homepage1.nifty.com/Q_Q/ap.html 【 オンラインTCGエディター 】 >>1,>>697
デュエル・マスターズ的な非電源TCGの 《 オンライン化ツクール系ソフト 》 制作の企画。
例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト(エディター)。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
デュエマ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、旧ガンダム・ウォー、ライブオン、ディメンション・ゼロ、シャーマン・キング、カードヒーローなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書け。
マジック:ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ!って部分のみリクエストしろ。
個vs個、多数乱戦、チームvsチーム、個vsチームを実現し、P2P通信対戦プラグイン有り。
設計思想は 《 RPGツクール 》 が良いかな? 他に、優れたエディター有ったら挙げてみろ。
個人や企業などのベンダーが提示する開発費(見積もり)で折り合えば、発注する。
↓
エディター群から基本コンセプトを絞り込む(もちろんオリジナルで優れた新ネタが有れば導入する)。
↓
遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
バトスピ、ヴァンガ、デュエマなど発売済みゲームソフトが存在してるTCGはベンダーに研究させる。
↓
各社TCGを再現するテストプレイ ⇒ 更に改良や修正 + コード記述の仕様書(設計書)を作成。
↓
機能制限した下位版を制作しても原則として発売せず + 上位版デュエリ−グ用でサーバー稼動。
↑
下位版を仮に発売した場合の改造および商用利用には、別途で当社との契約が必要。
さ〜て、インド人ベンダーと日本人の翻訳担当SEを見つけよっと!ww
http://wc2014.2ch.net/test/read.cgi/entrance2/1451262577/-16 ■ このスレッドは過去ログ倉庫に格納されています