NEWs保存道場

俺もわけわからんちん

た"れか解説を

た"れか解説を

構造化のない時代からやって来た先輩

スパゲティだろ？ははは・・・

ばらしすぎて本来ＭＡＩＮで処理するコードも分解したのか？
だとしたらやばくないか？

そんな先輩の下で働いてなくて良かったと心底思った…

なんだ先輩のまちがいなだけか？
ご愁傷さま

先輩は一直線のプログラムしか組んだことなかったのか・・・？ｗ
習い始めて1週間目の素人じゃあるまいにｗ

こういうのはスパゲティコードとは言わないな。というか、それ以前のレベル。

例えると…
図も表も段落も箇条書きもない論文、と言えば雰囲気わかるかな。

論文の体を成していない走り書きの酷いメモを、見やすいよう、誤解のないように整理してまとめたら、メモ書きした先輩に怒られた。
「お前これじゃ目次は各章の題名書いてるだけじゃんか！　目次の意味ないだろ！　バカ！」

こんなこと言われたら正直わけわからんわな。

建築で言えば、
土台作って/骨組み組んで/壁作って/外装内装して
とやるべきところを、
家の一番はしから作っていった事。

前者は増改築やメンテナンスが発生した場合は部品ごとにやれば良いから、プログラムとしてはコストパフォーマンスや全体への影響度が無い点で良いとされる。
後者は増改築やメンテナンスが発生した場合に、全体に影響してしまうので、コストパフォーマンスが悪い。

前者がこの文書いた人で、後者が先輩。

あまりにも失敗が多すぎるので、
1800人いた日雇いバイトを解雇して２ｔトラック６台＋運転手と管理者一人の仕事にまとめあげた
翌日1800人雇った元凶である先輩がやってきて
「お前これじゃ管理者は運転手呼んでるだけじゃんか！　管理者の意味ないだろ！　バカ！」と言ってきた

正直わけわからん

メインは関数を呼び出すだけなのが正解。

いわゆる、辞書の索引機能がメインの役割。
Blogに例えるなら左右にある項目別リンクで本文は、該当ページにあればいい。
全文が無秩序に並んでいるBlogは非常に見づらい。
それが元のソースコード。

1800行のコードが最大で見積もっても200行程度に収まる…か。

webデザインでいうと
cssを使っているのか
そうでない長ったらしいhtmlなのか
ですかね

まぁ先輩のは全50巻の漫画が1冊になってたと思えばいい。
見たいとこだけ見るのがメンドイ

現実にあるよな理不尽な話だなｗ

※39134は上手い改変だと思う

ちろっとでも本とか読んで勉強すれば(言語の入門書とかじゃなくね)
こんなアホな展開にならずに済むんだよな。

プログラムが書ける段階で止まっちゃう人は結構多い・・・

その先輩とやらはこれまでちゃんと構造化して書いてれば無用なデバッグ作業をやって残業代を稼いでたわけか・・・

ある種計画的な犯行だったんじゃね？残業代稼ぎのために

これアルファルファかなんかでも取り上げれてて
ここの米欄と同じように意味わからんから解説してって
流れになってたなｗ

だれかドラゴンボールでたとえてくれ

ドラゴンボールで例えると

聞き込み情報だけを頼りにドラゴンボール集めようとしてたから
ドラゴンレーダー作ったら「ドラゴンレーダーなんか位置が分かるだけじゃないか！」と言われた

とかそんな感じ

先輩の作ったコード
→原作通りに幾多の困難に遭遇しつつドラゴンボールを探し願いをかなえる

後輩が直したコード
→ピッコロにもフリーザにも邪魔されずにドラゴンボールを探し願いをかなえる

同じコードを何箇所にも書いてるケースが多いから
やたら小さくなったりするよね。

プログラムの事はわからんが、39134のおかげで把握した

報告書とかで使う言い回しを定型文としていくつかのタイプ作って、
提出する際にその定型文もってきてあてはめるようにしたって事
誤字・脱字は減るし、作成も確認も早く楽にできるよう効率化したってことだぁね

そうしたら「楽すんな！」と怒られました、という話。

家賃や電気代や水道代、携帯電話代やなんやかやをすべて窓口で支払ってた。
あまりに面倒なのですべて自動振り込みにした。
そしたら先輩が「支払う実感がなくて意味ないだろ」って言ってきた。


ということ

デートして、告白して、手を繋いで、キスをして、挿入するところを、
どうせ結果は同じだからと、出会ってスグ挿入したのがこの後輩。

先輩「お前それじゃレイプだろ！バカ！！。。。。好きだったのに。。。。」

自分が考えた「例え」を書き記していくコメント欄になっている。
だけど複数あるこの「例え」もただ一つの例えで表わせるでしょう。
まぁ。そういうこと。

ちょっとこれだと元と近すぎて例えになってないかもしれないけど、こんな感じ。

毎月、給与計算を電卓叩いて一からやっていて効率悪すぎるので、
必要な数値を入れれば明細表を打ち出してくれるエクセルマクロを作ってあげた
翌日、電卓叩いてた先輩がやってきて
「お前これじゃエクセルに数値を入れてるだけじゃんか！　給与計算の意味ないだろ！　バカ！」と言ってきた

※39175
春休みだよねぇ

とりあえず全部読んだけど>>39134が一番わかりやすかった

>>39139
ちょっと違う
各コンテンツごとにCSSを分けたって事だ
メインのCSSファイルには@importで各コンテンツ用のCSSを読み込むだけ
これで、Ａのページの修正が必要な場合は、Ａ用のCSSを触るだけで済む

先輩はジョジョの漫画全巻の解説を索引なしで書きました。
長文、１８００行もの大作です。
ところどころ間違っていて苦情が大量に来ていますが、まず間違いがどこかを探すことが
難しいので、修正を引き継いだ人は困り果てました。

後輩はジョジョの漫画の索引を中心とした解説を書きました。
２００行です。
間違いを探す手間が９分の１になりました。
しかも索引集なので、解説の間違いは索引の参照先を変えるか、索引を修正すれば
簡単に訂正できます。

どなたか解脱を

メイン{
ステージ変数が1の場合{
1面の敵情報をセット{
開始五秒から敵出現……隠しアイテム出現……ボス出現うんぬん；
}
クリアしたらステージ変数+1；
}
ステージ変数が2の場合{
2面の敵情報をセット{
開始十秒から敵出現……中ボス出現……ボス出現うんぬん；
}
クリアしたらステージ変数+1；
}
ステージ変数が3の場合{
3面の敵情報をセット{
開始三秒から敵出現……ボーナスアイテム出現……ボス出現うんぬん；
}
クリアしたらステージ変数+1；
}
ステージ変数が4の場合{
エンディングとスタッフロール
}
}

↓

メイン{
ステージ選択関数を呼ぶ；(それぞれ作業別に関数を分ける)
]
ステージ選択{
ステージ変数が○(数値)ならば{
1の場合敵情報1を呼び出し；
2の場合敵情報2を呼び出し；
3の場合敵情報3を呼び出し；
4の場合エンディング関数呼び出し；
}
}
敵情報{
ステージ1の敵情報(敵出現時間とかうんぬん)；
ステージ2の敵情報(敵出現時間とかうんぬん)；
ステージ3の敵情報(敵出現時間とかうんぬん)；
}
エンディング{
スタッフロールとか；
}

全然自信ないが、こんな感じかな？

ドラクエで例えると
先輩が他の街へ延々と徒歩で移動していたのを
後輩がルーラで直行出来るようにしたら
何故か怒られたって感じでいいのか？

辞書機能使って文章書くか毎回全文書くかくらいの違いだろ

メイン関数は処理流れを統率するもので、
細かい処理は各々の関数にやらせるもの。

メインが発注者で、関数が下請け業者ってことでおｋ？

MCのプログラムを思い出した
先輩はメインに全部ぶっ込んじまったんだな
繰り返すところをサブにすれば管理も修正も楽なんだが

メインですべての作業をやらせようとすると非効率になる上に、ミスが起こりやすく、さらにどこにミスがあるのかがすぐにはわからない
一方で関数に分けてやれば作業が専門化されるから効率もいいし、ミスも見つけやすい

アセンブラ