他人が作ったプログラムを修正する時の絶望感

他人が作った素性の知れないプログラムを修正する時の絶望感を一般の人に理解してもらえる例えを考えてみまえんか？

私が考えたのは↓です

「お前、明日からライバルのラーメン屋にいって、その店のいつもの同じ味のラーメンを作れ。レシピは残ってる生ゴミや残飯から自力で調べろ。もちろん前任者への質問は禁止だ」

20年この商売をやっているが、絶望感を感じた事はない。
確かに馬鹿なPGが少なくないことは感じるが、対処できない事はない。

もしそう思うのであれば、まずは自分の能力を疑う事をお勧めする。

＞　みまえんか？



↑やっちまった･･･　Orz

標準ヘッダ読み込んでもエラーがでるようなコードにはさすがにウンザリだ

もとからあったバグまで俺のせいにされて徹夜で直してる時とか、
絶望感しかないよな。

>>5
しかも、ラ管(=人力CVS)の履歴を調べたら、エンバグした犯人が、俺のバグのせいだと
会議で吊るし上げた張本人だと判明した時とか。

三菱MDISの無能なE.Zaitsu、お前のことだ!

いつも思うこと。。

俺はソフトを組むたびにドキュメントをちゃんとしろだのソフト仕様書を作れだの
コメントをちゃんと書けだのうるさいこといわれてるのに、
他人が作ったプログラムにはまずそういうものがない！
一体どういうっちゃぁ！！(怒

え？
俺は楽しいけどなぁ、

変態コードであれば尚良し。

責任持たなくていいんなら楽しいよｗ

責任なんて、仕様通りの範囲で動く限りは正常って以外無いだろw

>>10
そんな大きな責任負いたくないわw

↑プロ失格乙ｗ

そもそも仕様が不明。

思いっきり書き換えていいならともかく、ソースがあるから短期間で平気だよね
とか言われるのがかなり嫌だな。　元コードを読む分とそれを現有の仕様書と
すりあわせる、更に追加分の仕様を混ぜるとかなるとね、、、

それ以前に作らない人ってのはコード読んで理解する時間とか全く考えない
よな。ノータイムで読めると思っているというかなんというか、、、

バカの作ったコードは絶対に引き継ぎたくないな。
正常系しか動かなくて、異常系を流すと取り返しがつかないほどの
ダメージを与えるっていう。
レアケースならともかく、入力データをちょっとミスっただけで人が5000万人死ぬ

電力系の制御システムに派遣で逝かされた時、そんな案件テンコ盛りだったなぁ…
「お前には月単価120万以上払ってるんやぞ!」って言われたが、手取り10万切ってたしな。

プロパーから残業代払うから残業しろ・休日出勤しろと言われても、
俺には残業代出ないんだけどっていうのもよくあるな。

そもそも

馬鹿が書いたコードが読みづらいっていったって限度があるでしょ
オブジェクトごとに事細かに分割して
名前がローマ字や英単語なら分かるとおもうんだけど

馬鹿がそんな綺麗なコード書くと思ってるのか。

>>19　←コイツ馬鹿な上に世間知らず。

グラマな知り合いなんていないし

他人が作ったかどうかより、仕様が全て表に見えてるかどうかの方が重要だな。
意味不明な変数の加算処理が、実はまったく関係無い機能の為の前処理だったとか、実際に出くわした事があるんだけど、それを知らずに適当に同じ処理加えて行ったら、とんでもない所で不具合が出やがった。
さすがに殺意覚えたなぁ

コメントが1行も入ってないアプリケーションの修正頼まれたことあったなぁ。
まさに他人に読まれることを怖れているかのようにコメントが1行も書いていない。
なんの関数なのかもコードを読んでいかないといけない。
膨大な時間がかかった。

NetBSDのソースコードなんて、著作権フリーの説明以外、一切、一行たりとも
コメントが入ってないソースなんてテンコ盛りだが、とても読み易いよ。
いちいちコメントを必要とするソースを書くのはプログラマとして低能。

変数名や関数名とかの「リテラル」に分かり易い命名しとけば、コメント不要。
むしろ邪魔。

まあ、関数名が機能をまんま表してるとか、変数名が目的そのまんまとか
コメントなんて飾りです。　むしろ嘘コメントで紛らわしいので排除してください。

バカがマネするから何のための関数なのかと、引数に入れてもいい値くらいは書いとけ。

まさに飾りのコメントにだまされた

...True/Falseの意味が字面と逆だと分かったときのガッカリ缶orz

それってコメントの有無の必要性とは全然別の次元の話だよね？
ホントにコメントが1行も必要ないと思ってるのは学生と個人企業でこじんまりやってるマぐらいのもんだぜ。

ちなみにxBSDはコミッタが管理してるから破綻するこたぁねーんだよ。
このスレで取り上げられてるような市井のどこの馬の骨が書いたか知らんようなクソプログラムといっしょにすんな。

言っても無駄。
コイツらコメント無しのコード判読で泣きそうな思いしてない坊やばっかだから
ごちゃごちゃの意味不明なコードに遭遇して一度でも死にそうな思いしてりゃ「コメント必要ない」なんてゆとりかましてられないっての。

>>26<-いかにも金とってないって感じのゆとり

>>31
残念ながら、金取って仕事してるんだなｗ
しかもドキュメントは別料金でｗ

どうせ100行程度のちっこい便利ツール程度だろ。
「もう納期過ぎちゃっててさぁ、担当者は今韓国に缶詰で定時連絡のみだから・・・、
カネはいくらでも払うから（←嘘）明後日までにおながいします。」とか言われて
1万行以上の超ごちゃごちゃなソースをコメント無しで渡されてみろよ。（実話）
それでもそんな涼しい顔ででるわけ無かろう。

一人でやってるようなのはコメントなんかかかないよ。

３０後半あたりでコードの内容覚えきれなくなって破綻すると思うが

>>34
ツールとして使われてるのは大抵そこからスタートする
そして気がつけば課内に正式展開されて
不具合対応や機能拡張をさせられる羽目に

その頃には初期verを書いた張本人は既に退職してたりする

>>24
最初から作ったほうが早いじゃん

ま、実際のところ、
赤の他人が作ったしょーもないノーコメントのソースを修正するなら、
｢しめた！｣と喜ぶくらいじゃないとフリーじゃやっていけんよね

いかんせん仕事あってのフリーだからね。

元ソースの品質を工数に盛り込むことが出来ないからな
ひどいソースを書いても、そんなソースを受け入れても
本人は痛くも痒くもなくてリスクは全部修正者に押し付けるだもんな

i=1; /* iに1を代入する */

こんなコメントはいちいち要らないんだよ >某三菱MDIS
目的は何の為にそんな代入するのか? "1"というmagic numberの意味を書けよ。
それでコメント率25%以上とかコーディングルール決めても、欠陥システムの
オンパレードなんだろうが!?

ジョークとしか思えないなw

>>38
言っちゃ悪いけどｗ

お前が選んだ職業なわけであって。　ゴミみたいな仕事やってんのが悪いんじゃね？



>>39
あるある
ソースコード中にマジックナンバーをただのひとつでも入れる奴は、AUTO

けど君もゴミみたいな仕事やってんのがわるいよね

ゴミみたいな仕事にもありつけないニート君が何言っても…

>>42
>ニート
↓
>>41
>ただのひとつでも入れる奴は、AUTO

オートかよｗ

一個の長い関数内部で順にいろんな処理を行なう場合は、大まかな流れぐらいコメント入れとけ。
でないと他人はその関数内から呼んでる関数の飛び先をひとつひとつ読んでいかないと全貌を把握できない。

/* 複数の選択をキーにDBを検索*/

/* 結果からバイアス計算 */

/* パラメータをセットして試験実行 */
　/* 試験1（オフライン） */
　/* 試験2（オンライン/サーバートリガ）*/
　/* 試験3（オンライン/ユーザートリガ）*/

/* 結果判定 */

/* 収集したデータを各所へ書き込み（書式加工） */
/* ローカル */
/* サーバ */

// よくわからないけどとりあえず動いてるんでこのままとする
↑
こんなコメント書くなｗｗｗｗｗ

/* 以降の処理は動作は保証しない（不具合は自力で解決してください） */

i=1; // 何故か2回実行しないと正しく動作しない時が有る
i=1; // 何故か2回実行しないと正しく動作しない時が有る

…volatile宣言すべきなんじゃないの?

>>43
アウトをAUTOと表記するのは最近時々見かけるスラング
とはいってもこの子の場合はマジで書いてる気がするが
kardだし

アウトだったのか
マ板だけに普通にautoと読んで自動変数がなんの比喩なんだと悩んだ

いや、こいつはVIPPERだからこういう書き方する
AUTO自体はかなり前から使われている

>>51
常日頃からそういう唯我独尊なコードの書き方してんだろ。
コメント入れろって書いてあんのに修正箇所にコメント一言も入れなかったり、
{}の記述が　
kansuumei(){

}
で書かれたプログラムを自分のスタイルを押し通して以下のように書いたり
kansuumei
(　void　)
{

}

>>52
餌やり禁止

kusakabe(void){
　　　　return NULL;
}

>>47
それ、あちこちで書いてるのオマエじゃね？

他人でも１人で書いたコードを見る分には
癖や統一感があるから、まだいい
統一感も無く１０人くらいが、個々自由に書いてるコードを修正するときの
脳の疲労は半端ないｗ

個々自由に書いてるコードなら、自分も自由に書けるから楽だな。
他人の癖を真似する方が疲れる。

ニンゲンの書いたコードならまだましだが、Excelから自動生成しました的なコードを
その自動生成ツールなしで解析・修正しないといけないときとか、どんな刑罰だよと思う。

>>57
バグ潰し専門だから
俺は１０人の癖を真似して書いてるぞｗ

>>58
COSMOSとか、新幹線の制御システムがソレだったな。
RATFORだか何だか知らないが、FORTRANから機械的に変換してて、
関数名とか変数名とか、全部英数6文字の組合せ。

>どんな刑罰だよと思う。
電力とか鉄道関係の仕事は、金輪際、お断りすることにした。
自社内の人間で開発しろよな。

>>60
最初からFORTRAN走らせればいいじゃない。
って思った。

>>1
「ソースを解析するツール」でも作れば？
うまく作れば、見たくないソースの自動修正なんていうのも、有りかと...。

>>62
>うまく作れば
「よくわかんないけど想像だけで書きました」みたいなﾚｽは結構。

最初のCOSMOSのころはまだ77規格すら無かったしな。
英数6文字ってのはRatforのじゃなくてFORTRANの制限だよ。
新幹線のシステムをスクラッチからリプレースする、
なんて奇跡のような予算がどっかから出ない限り
Ratforのソースをメンテせにゃなるまい。
新規分までそれで書くのはよしたい気持ちはすごーくわかるが。

うっかり違う文字コードで開いて上書きしちゃったw
２バイト文字が全部化けて、
コメントが意味をなさなくなったよ

他人のコードを解析するときこそ評価を得るチャンスじゃないか！

この仕事は他人との評価の比較が難しくて
時には仕事できなくても残業時間だけで評価されたりしやがるけどｗ
こういうときこそ実力の違いを見せ付けるチャンスだと思う

そんなんで評価しねーよ。
そもそもソースあるんだから、いちから作るより楽だろ？

一から作った方が楽な場合もあるだろ。元のコードが
あまりにも酷い場合は。

それはPGの立場で見た場合の評価であって、
評価をする側の人間の立場で見たときには >>67で書いたとおり。

前派遣で行った会社で
言語PHPなのにforeachも録に使えないようなアルバイトが
「これを参考にして作ってください！」
って言って渡してきたソースを見たときは絶望した…

しかも、
「サンプルがあるから早くできますよね！」
とか異常に出来上がりをせっついてきてたけど
修正するのに時間かかって早くできるどころの騒ぎじゃなかった

レベル低いヤツって持ち出す実例もレベル低いんだな
糞派遣（藁）
日本語から出来てねぇ

>>71
レベルたっけぇ〜www

>>66
そんなんが評価されるなら、他人との評価の比較が難しいにならん

>>70
急かすようなところだからクソみたいなソースが散乱するんだよね
それこそクソみたいなソースコードを取り合えず早く出すのはやればできるし

構造化されてないCOBOLのコードを渡されたときは泣きそうになった

>そもそもソースあるんだから、いちから作るより楽だろ？
↑
ど素人乙
いちから作った方が楽な場合なんていくらでもある。

>>75
だったら穴だらけの低能Windowsをちゃちゃっと1から作り直しちゃってくださいよ。

いちから作った方が楽な場合なんて無いよ。
そう思うのは勝手だけど、どんな系でもどこかに複雑さが隠れてる。
つうか、テスト仕様書とか試験結果報告書とか全部作るの考えたら、少しの修正だけで済ませたいと思うよ。

自分が書いたソースならば、な。
スタレの通り「他人」がそれも低レベル文系君が書いたソースなら、>>75 さんの
言う通り。ってか人口的に、国公立情報系なんかより私立文系出の似非グラマの
方が圧倒的に多くて、捨てて1から作り直した方がdiffもCVSもスリムに成るケース
の方が多い。
>>77 みたいな「勘違い」をMDISも二言目には言ってたが、アノザマ。
結果が全てを物語ってる。

>>78
おまいそんな事言っても、上は予算出してくれんの？
いちから書き直した方がマシなんてのは実務上無いんだよ。　素人君。

採算が合うならやると思うよ。

いまだにPC9801シリーズが現役で稼働してるとか、奴らマの意見なんざ完全無視だろ。

>>78
現実問題としてそういうソースが存在するところでは
一から作り直したほうが早いというのは大体ありえない
そういうところは
・仕様書が残ってない
・テストは修正した処理しかやらない
・細かいログ出力や潜在してる不具合も含めて完全再現が必要
・一から作り直しにゴーサイン出す人に取って作り直しのメリット0
ってなってるから無理

そして三菱MDISの二の舞ww

ソフトウェアってのは過去の資産を使いまわすというのがビジネスの基本なんだよ。
何故インテル＋マイクロソフトの糞コンビがいまだに幅を利かせてるのかを考えれば分かるだろ。
作り変えが許されるなら、ハードの下位互換性なんて誰も気にもしないだろｗ

はあ？

リファクタリングは何度も繰り返してるが…
そもそも人手が足りないからといって、畑違いの文系君にプログラミングさせる
狂った国は、日本だけじゃないの?

発展途上国から出稼ぎに来てるPGだって、一応情報系の大学出てるからなぁ。

>>84
じゃあ使い回せないもん作ったヤツはクビでいいな

使いまわせるものって何？
オブジェクトとヘッダとreadme？

再利用とはいうけど、使い回すにも使い方覚えるためのコストがかかるしな。
使いこなせるまでの平均的学習時間でも記載されてれば別だけど、そうでなきゃリスク買う事になるよな。

>>88
使い回せるかどうかは、使う側の裁量次第だけどな。

使い回さない前提の設計が流れてくることも多い
拡張性皆無の設計仕様作るSEが絶滅するだけで、開発効率は数倍はねあがるだろうと

妙に汎用的に作ると逆に苦しむことにならないか？

>>91
使い回しにくいものを使い回す側の裁量でうまく使い回したことを評価されるといいけど
実際は使い回しにくいかどうかが評価の対象になるというのは聞いたこと無い
使い回して早く直したかどうかのみで評価される
だからこういうスレの流れになる

>>93
それは、汎用性が無いからだろ。

万能関数と汎用的な関数とは、全くの別物だからな。

汎用性のあるものってやっぱり効率化とは逆の道だよね
コードの長さ的に

>>97
そんなことないぞ。
複数プラットフォーム対応でコード量増えるとかの例外はあるけど。

「汎用」という名の元になんでも詰め込むやつがいるけど、それはダメだ。
むしろ、どこに持っていってもうまく嵌るように、汎用的じゃないコードは
削ぎ落とした小さなコードになることの方が多い。

追記

UNIXの哲学にもあるけど「一つのことを、うまくやる」コードをたくさん書いておけば、
それらを組み合わせて使うのは比較的楽。

つまり、抽象化と一般化をどれだけ出来るかって事だね。

小さいコードはテストしやすいっていう側面もあるから品質を上げるというのにもよい。
ただ、機能を満たした小さいコードを作るのは結構難しいんだけどね。

プリミティブな関数を沢山作ると綺麗で便利だけれど、プログラマ個人の定義した名前が増えてソースをたぐるのが大変で困る

>>102
それは処理を関数に分割するセンスがないから

関数の実装の詳細をいちいち追いかけないと読めないコードはクソ

つまり予期しない動作をするコードは全てクソであり、大抵のプログラムはクソだらけである

糞ならマシ。
実はスパゲッティ。

>>103
読む側のセンスがゼロだとそうもいかない
コーディング経験の無いSEとかが絡んでくると
そいつのへの説明に>>102みたいな問題になる

>>84
これは全くそのとおり
特に組み込みだと、ＣＰＵが変わったときにデバイスを変えることは大変
その点ハード屋さんは同じようなものだから簡単にできると考えるから困る(怒)

資産箱のみかんがくさってても、上からべつのみかんつんで隠すだけだからな

出来うる限りのリファクタリングはするようにしてるけど、
他人が書いた糞コードまで面倒見切れないってのが正直なところだろうし
そもそも、自分の書いたコードのリファクタリングすらできない人がかなり多い

自分のコードを評価してもらったり、他人のコードを評価したり、みたいなことを
日ごろから行えるような環境でもない限り、ちゃんとしたソースにするのは難しいと思う

>>97
ちゃんと抽象化され機能が集約してると、修正に強いよ

ただ、あっちこっちに飛ぶコードになると、
一本まっすぐな流れでしか理解できない層に対する難易度が上がる

あと、うまく処理全体を見通せる人がコーディングしてないと、
無駄処理が増えてたり、修正が面倒になってたり、いいことない場合もあるから、にんともかんとも

>>46 のコメントは、実に有用なコメントだと思う。
まさにコメントとはこうあるべき。

>>108
>ただ、あっちこっちに飛ぶコードになると、
>一本まっすぐな流れでしか理解できない層に対する難易度が上がる
デバドラとか、割込み駆動で、しかも割込み要因次第であっちこっちに分岐する
割込みベクトルのハンドラ・ディスパッチャとかどうすべ?

>>110
そういうのを、あっちこっちに分岐してないように見せて
シンプルな形に表現するのが設計という物。

あっちこっちに分岐するから、あっちこっちに書かないとだめなんですって
コードがごちゃごちゃする奴は、行き当たりばったりのコードを書いてるだけで
設計ができていない。

あっちこっちに飛ぶって言っても、同一ファイル内の前方参照もしくは後方参照に限るなら普通じゃね？
これが外部参照されてるファイルの中に唐突にポツリと書かれてるとかなら問題だけどな。

言うはヤス氏

その「ファイル」とやらを扱う「デバドラ」は誰がどう書くの?

Youはヤス氏

俺は貧乏フリーだからｗとにかく仕事がほすい！

他人が作ったどーしょーもないプログラムの修正を依頼されると
正直、にんまりだなｗ

酷いコードに限って掴まされる、、まさに絶望。

そりゃだって、良いコードなら他人に頼む必要無いしぃ…

今追いかけなきゃいけないプログラム、ヘッダコメントがまったくない。
全てのソースファイルにない。泣きたい。

>>118
そうそうｗそのとおりｗ
オマエは世の中をよく知っている。

>>119
コメントだあ？それはオマエがこれから創造するんだよ！

怪しいコメントよりもないほうがましだろｗそう考えろ！

何だよ！
iだのjだなkなんてグローバル変数使ってる奴は
氏ね

>119
良かったな
嘘が一切無いって事だ

>>119
>>121,123の言う通りだ。回り道が大分減ってるじゃないか

ああぁぁあー、最初っから作り直したい、、、

>>125
コストダウン効果を定量的に示してもらえるなら、作り直してもいいですよ＾＾

結局経費が倍以上かかるから作り直して良い事なんて無いぞw

倍とは言わないけど他人の謎プログラムの仕様がはっきりしてないと
作り直しって意外とコストかかるんだよね〜

アホ上司が無数のファイルをgotoで八艘跳びして効率化とか再利用とかぬかす馬鹿なんだが
震災の暇なときに書き直したら機能追加も修正も1%の時間ですむようになった
残業のマッチポンプしやがって...

残業代いっぱいあげたいがために

機能追加を設定ファイルの変更だけで終わらすと、プログラムの修正して
無いのになんでこんなにテストが必要なんだとかいう人いるでしょ？
結構すごいことなのに仕事してないように見られるし、金にならないし。

前任者が作っていたのがコレね。と言われ、exeファイルを渡された...orz

そういやニートだから分からないけど
委託開発ってソースコードも渡すの？
まぁ普通に考えたら渡すだろうけど

>>133
契約による。
でも、メンテナンス考えるとソース渡さない契約はあり得ない。

>>132
バイナリを解析して割り込みを入れろってことか、いろんな意味でハードだな。

昔8bitの頃、後で処理が変わりそうな箇所は、3ByteのNOP入れたりしてたな。

>>136
NOPってバイナリでFFだっけ?
ROM焼きしてもビットを落とすことは出来るから良くやったわ。
3ByteあればJUMP出来るし。

石によるだろ。
00な石だってあるし。

6502 EA
6800 01
8080 00
8086 90

86 の NOP の並びを Shift JIS で見ると, 瑞の字が並んで何かめでたい気がする

修正するより「新しい関数つくって」と
言われて数行の関数作る方が悲しくなる。
同じ機能の関数はどっかにありそうだけど誰も知らない。

落ちたプログラムのリストを出してフローを追っているところへその作者が転勤先からやってきて

「なんだ貴様ら、俺の書いたプログラムが駄目だというのか!?　原因はほかにあるはずだ！」

落ちた場所が原因である可能性は高いけど
呼び出してる方に問題がある可能性の方がもっと高いぞw

ここじゃないと思ってるところほどバグってる。

こっそり0から作り直して進捗報告は適当にやってちゃんと動くもの作るとかは出来ないの？
総工数考えたらどっちもどっちなんじゃ？

>>145
そこの部署だけで完結してるような小規模なら良いけどなw
もっと大きなプロジェクトの一部だと、そんな事しようもんなら信用問題だわw

>145
得てしてちゃんと動かないから、勝手に資産変更しやがって糞がと重大問題扱いされて、
管理が厳しくなって

皆不幸

社内システムの外国人が作ったグチャグチャのソース＆一切のドキュメント無しってな
Webアプリのバグ取りしたときは悲惨だったな
アレなら１から仕様書作って開発し直した方がまだ楽だった

>>142
臍の作者ってなんだろうと考えたオレはもうダメぽ

この業界来て一番クソだと思ったのは他人のソース触らせられることだった。
もう辞めたい。
もうソースは本人以外永久に改変してはならないと法律で決めたほうがいい。
そうすれば一度書けば修正来るたびに仕事が来るので食うに困る奴がいなくなる。

他人が作ったソースがクソであることは多分にあることだが、
他人のソースを触るだけでクソと思うのは、単にアンタが無能だからだな。

死んだら終わり？

>>151
自分にとっちゃ自分で作ったソース以外全部クソだろ。
絶対的にクソじゃないソースとかいうもんがあるとでも思ってんのか。
そういうもんが定義できるのなら人間が書かなくてもいいわｗ

他人のソースどうこうの前に、自分で書いたソースみて悶絶したことある奴は俺だけじゃないはずだ。

つうか、>151とかは典型的な議論のできない日本人だな。
俺が無能かどうかなんて関係ないし
無能なら無能なりの意見があって当然だし
大体、俺は別にそんなことで無能とか言われてもどうでもいいんだよね。
他人のソース読む能力なんて羨ましいとも思わないし
この業界ガヤだっていってるのだから
もはやこの業界でのヒエラルキーに興味がない明白だろうが。
向いてないからやめろとかいうアドバイスのつもりなんだろうが。
俺は辞めたいって言ってるし
俺がすでにいっていることをドヤ顔して痛いとこついたつもりで言い返してるだけ。
頭悪すぎる。

結局。ただ単に「俺のほうが能力高い」って言いたいだけか？
お前の能力なんか知るかよ。

低能が必死。

まあそう怒るな
技術を磨くのを怠らなければ
他人のソースもコントロールできるようになるよ

そんなに他人の書いたソースが読める奴が妬ましいか？ん？

無能の分際で、俺の書いたソース最高！それ以外糞！とか言ってんの？
お前のソース、さぞ他人から糞と思われているんだろうな。
刺されないよに注意しろよ。

こんなコード書けねぇって、思うレベルかこんなクソコードって思うかダケじゃね？w

クソなコード、高度なコードの区別は確かにあるけど
本当にクソかどうか見極める力量も必要。

良く判ってない人は両者を単に「難しいコード」と言う。

半年後の自分は、赤の他人。

俺、こんなコード書いたっけ?www って思うことがしばしば有る。

ひどいときには、他人にコーディングしてもらうために作った設計書のミスを指摘されて、
俺、こんな設計してたっけ？って思うことがあるw

睡眠不足→スレタイ→絶望

難解なコードを追っかけるのは面白いから嫌いじゃないなー

他人、特にあんま理解してない人が作ったものを追っかけるのが苦痛だな

・やりたいことが読み取れない。必要最低限のコメントやjavadocのようなドキュメントの不足
・もっとスマートな書き方ができる箇所でも、無駄なことしてる
・IDEで出る警告をことごとく無視していたり、コーディングルール違反を当たり前のように行う
・例外、nullなどをを考慮していないことに起因する潜在バグ
・Exceptionを補足し投げる。最初だけtry最後にcatchみたいないい加減な実装

みたいな、直したくなる部分がいっぱいあったりして、見てるとストレスがたまりまくり…！

>>165
やりたいことが読み取れる、かつ難解なソースコードなんかあるのか
そういうソースを書こうと思えば書けるのはわかるが現実問題として

でもさ、
この業界で一番困ってるのは不具合出たけど元の担当者がいないってパターンじゃね？
だとしたら他人のコード読む力があれば充分フリーでも食ってけるってことじゃん？

>>167
そんな事で困ってる企業なんて、どこにも無いぞw

他人のコード読んでも、仕様がわかるわけじゃないから。
何年も引き継がれたコードなんて「ここは以前のままでいいから」っていう理由で
仕様書もない状態で開発が続けられるのが普通。

>>169
それも無いw

「このモジュールの仕様書はどこですか？」って聞いたら
「ないよ」って普通に答える大手メーカは何社か経験したな。

せめて仕様書でもあればいいのだが、
１人でやってたみたいなので何も無いｗｗｗ
ソースにもコメントほとんど付いてないし
死ねよもう・・・

>>171
「無いから、ソースコードから逆に作れ」って三菱に言われた。
新幹線の制御ソフトでコノザマ。日本は中国のことをとやかく言う資格無いよ。
しかも多重派遣だらけで人を集めてるだけの三菱なんて、893と変わらない。

>>172
仕様変更の過程でコメントも大嘘になってる事もあるから
いっそ無い方が余計な混乱を産まない場合も有る
動いてるソースだけしか信じられん

うん。だからソースコード上の情報を残すような
言語を選ぶべきなんだよ。

動的型付け言語なんて大規模には使いものにならない。

>>168
オマエは経験が浅いか世間知らずなだけ。いくらでもあると思うが

つかいつも思うんだが・・
俺が開発するときはうるさくドキュメント書けといわれてきっちり作るのに
他人のプログラムのときはなぜかいつもまともなのがないんだなｗ
こんな矛盾感じてる奴いるよね？

>>177
当てつけで自発的に書いてるけど
周りの書かなさっぷりに心が折れそうになる

ソースが残ってるだけでもマシだよ・・・
俺なんて実行ファイルしか残されてなかったことがあった
修正するときイチから作り直したわ

>>177
まともなもの書いたら「そんなのいらないから」って言われた。

仕様書作らない奴の気持ちも分かる。
だって仕様書は納品するものじゃないしな。
作ったって利益にならんもん。

納品物に、そもそもプログラムすら含まれてなくて、「勤怠表」が納品物に指定されて
たことも有った。上に出てるのと同じかもだけど三菱MDIS。
どう見ても偽装請負逃れです。本当にありがとうございました。

>>181
作ったヤツが永遠に面倒みるなら要らないw

ドキュメント作るのは構わないのだが、それが工数に入ってないとかザラだからな。

ウォーターフォール型の開発だと最初にドキュメント作っていても、すぐに不具合
対応しなければならない場合、現場でゴニョゴニョってしてまともにドキュメントに
反映させることさせてくれないことはよくある。

>>177
ドキュメントをきっちり作る
　→そっちにリソースを振ったせいで、
　　　ソフトは糞で再利用されない
ドキュメントを書く暇も与えられない
　→もちろんソフトを書き直す機会も与えられず、
　　　ソフトは糞でも無理やり最利用され続ける

２５年前の円高、アメリカから市場開放要求のあった
中曽根首相のときの日本をフィクションで描いています。
バブル経済前夜でした。
これが小泉首相のときの竹中平蔵による改革へとつながり、
今の円高、野田首相の進めるＴＰＰとも通じています。
気分転換にどうぞ。アバター利用のコミュニティゲームの情報もあります。

１９８６年の残照
http://ronkokuunovel.seesaa.net/

ドキュメント書くと仕事が他に流れるからなぁ

書かなさすぎると強制的に外されるから、バランスが大事だな

確かにソフト改造のときドキュメントがないとむかつくけど、
あったらあったで内容にウソがあると困るからあまり読まないんだなｗ

画面レイアウトが現行版と似ても似つかない構造だったり

困るのは担当者で、企業は困らないさw

>>190
本気でそんな考えの社員ばかりだとしたらその企業はだめ

あたりまえのことだが担当者が困るってことは、問題が解決しなければ
企業が困るってことだろ！ｗ

あたりまえのこと言ってドヤ顏っすか
あたドヤっすか

はあ？
同僚が失敗して出世競争楽になるから喜ぶだろ。

出世は他人任せかよｗ
そんなネガティブ志向で出世できるわけねーだろｗ

たかだか企業内で出世競争とか、小さ過ぎて笑っちゃいます

とニートが言う

企業内で一番いいのは何もしない事。
業績も上がらないけど、大損害も与えない。

正直関数の頭に何する機能かだけコメント書いてくれれば十分なのに。
酷いソースは色々詰め込みすぎて何する関数かも書けないという。

>>198
普通は関数名が機能表してるから、あんまし気にしないなぁ

>>199
関数そのものの機能だけじゃなく、引数の説明とか、戻り値の説明とかが
きちんと書いてあるとないとじゃ大違い。
内部でチェックしてあることは当たり前のことだけど、引数がNULL可なのか
不可なのかとか、負の値もとるのかとか、0〜xの範囲を想定してるとか。
戻り値も同じで0、非0が返りますとかでなく、もうちょっと説明がある方が
よかったりする。

JavaなんかだとJavadocで書いておけばIDEの補完機能でその場で確認
出来たりするからそこまで書いてあると無いとじゃ結構違ってくる。

javascriptになると「コメント？　何それおいしいの？」状態だからな。

今やってるのなんか
//画面遷移
function hoge(){
　...
}
みたいなコメントしか無いっていうかあればまだマシな方

>>199
だね。

アセンブラなんだがラベル名が･･･

L000
L001
L003
･･･

L+連番ならまだ許せるが
たまにL001BとかL01T9とか無理矢理増設したようななラベルが出てくる
最悪なのが「L0O1」オーだと気づくまで30分近くハマった

Do

　　MessageBox.Show("絶望")

　　If 退職 Then
　　　　MessageBox.Show("希望")
　　　　Exit Do
　　End If

Loop

' 次の人生
MessageBox.Show("落胆")

'人生
End

Exit 現実

他人がつくった仕様の間違いを指摘して受け入れてもらえない
徒労感よりはましじゃないか？ > スレタイ

vbかよ

検索エンジンGoogleで「インターネットテレビ 朝鮮総連 少頭劣一族 デンソー サトウ 電気」の検索を。
元 大臣の野田氏の実兄。（フィリピン）

日本人と名乗る朝鮮人は やはり日本人では無いと分かる。人情味が無く、高みの見物で人助けをしようともしない。

日本国内で 世界中から拉致、監禁された
人質が足枷で出られない状況が一年以上だ。
無視は加担。

クーデターは大正に終わり、日本中が国際法の適用となる。

Elena Oda Vintevecom（BECKHAM）
テト＝テイトのエリナ（エレナ）
帝徒＝織田繪璃奈＝啓北商業の野島はマイクロソフト社

新たな条約の確認は報道機関で。

>>208
すげーわかる。こっちのがきつい…。
しかも、嫌がらせまでされる

８月頃直したASMのソフトなんだけど、変数定義にDSを一切使わないで、
LDA　800Ah　　STA　800Ch　みたいに、全てコード中に絶対番地で書いてあった。

当然、変数名が存在しないので、この番地の情報は何のためのものかという
推測の一覧表を作ることから始めなきゃいけなかった。
いろいろ我の強いコードは出会ったが、これは最強クラスだったよ。

>>199
コメントつけてないやつにつけさせたけど、コメント見ても意味不明…
ソース解析の前に暗号解析から入らんとって状態だわ

>>213
コメントの追加とかｗ　今動いてる検証済みのソースに１バイトたりとも手を加えちゃったら検証しなおしだろうにｗ
いくらコメント行の追加でも、最低限objバイナリの一致という保証でもない限りやらせるもんじゃねえｗ

>>214
こいつ病気か？

コメント入れると何故かnopが挿入される
某クソアセンブラで酷い目に遭った人じゃね？
物凄くニッチだけど

今動いている検証済みのソースって前提がおかしい

>>214
コンパイルした結果を比較すればいいだけなのに。。

ｸﾞﾗﾏは早寝だな…

ソフトボートのＨ８用アセンブラで、module文のモジュール名の後にコメントを書くと
LINKでエラー７８になったなあ・・・コンパイルした結果は正常だったが。
因果関係に気がつくまで３日ぐらいかかったよ。

新人にコメント追加とかｗ
コメントの仕方間違えてて、ゴッソリ必要なコードが死んでたり、おまいら経験ないん？

既存ソース改修の仕事だと稀に>>214みたいなことを言う奴を見かけるけど、
そのソースやバイナリに対してまともなテストや検証が行われていないことが殆どで、
こちらで改めて条件網羅のテストをすると潜在バグ大杉で嫌になる。

条件チェックに引っかかった分だけエラーメッセージを出すという処理で

code = check();
if(code==2){
　msg="エラー1";
}else if(code==3){
　msg="エラー2";
}else if(code==5){
　msg="エラー1¥nエラー2";
}else if(code==7){
　msg="エラー3";
}else if(code==9){
　msg="エラー1¥nエラー3";
}else if(code==11){
　msg="エラー4";
}else if(code==25){
　msg="エラー5";
}
// 一部省略したけどメッセージ５種の組み合わせパターンを全て網羅してる

で、エンハンス作業の中にここにエラー条件を２つ追加してくれというのがあったんだけど
こんな工数でやってられるかとぶっちゃけた（やや誇張）
そもそもその数字は何を基準に割り出したし

>221
書かせる練習だけして、捨てるか参考資料にするもんだと思ったが

難解なソースコードでも別に構わないけどよ、
どうみても手抜き、やっつけが見て取れると（ｒｙ

>>223
2,3,7,11,25 ってどういう思想で振ったコードなんだ？

>>226
各番号に対応するエラーコードを単純に足しあわせても
全ての組み合わせでコードが被らないようになっている。
つまり一対一対応なのでこれを単純なビットパターンに変換するのは
マならそれほど難しくはないだろう。
その手の関数が用意されているのに書いてるやつが知らないとか？

>>227
2と3を足したら5だが？

> if(code==2){
> 　msg="エラー1";
> }else if(code==3){
> 　msg="エラー2";
> }else if(code==5){

>>227
単純に足してもっていう話なら
コードは1、2、4、8・・・だろ。

お前素人か？

>>228
説明が悪かったかな
エラーコードはエラー番号に対応する値のつもりで言った
エラー1 : 2
エラー2 : 3
エラー1 & エラー2 : 5 = 2 + 3
エラー1とエラー3の組み合わせも同様

>>229の言うとおり単純なビットの組み合わせのほうが合理的。
これはおそらく保守だの改修だのと称して顧客から金をむしり取り続けるためのトリックなんだろうね。
check()が返す基本的なコードの値をいじるだけでロジックは変わらないのに
>>223のようなif文の羅列で記述するのが適当であるかのように装うことができ、
エラー条件の追加によってコード量が幾何級数的に増加するのでLOCも稼げるというわけ。

>>230
仕事楽しいかい？

このプログラムで確認すれば被ってないことが分かる。
単射であって全射でないので一対一というのは誤りだった。
#include <stdio.h>
int main()
{
int code[] = { 2, 3, 7, 11, 25 }, flag, sum;
for( int i=1; i<32; ++i ) {
sum = 0;
for( int j=0; j<5; ++j ) {
flag = ( i & ( 1 << j ) ) > 0 ? 1 : 0;
if( flag ) printf("%sError%d", sum ? " & " : "", j+1 );
sum += flag ? code[ j ] : 0;
}
printf(" : %d\n", sum );
}
return 0;
}

>>232
ｗｗｗｗｗ
学生丸出しなコードだなおいｗ

ソース自体を暗号化するのが最近のトレンドなのか

>>232
なにこの絶望的な初心者コード

>>234
最近というか、ステップ数で金がもらえていたよき時代の名残だろう

このスレのタイトル
「他人が作ったプログラムを修正する時の絶望感」
これくらい短ければいいけど長くなったら投げ出すな

>>236
契約内容にもよるけど変換する関数を書けばビットマスクであっさり終わる仕事
>>223は儲け損ねたな

これだけでも相当にアレだが
>#define FOO_CODE_1 1
>#define FOO_CODE_2 2
>#define FOO_CODE_3 3
>#define FOO_CODE_4 4
>#define FOO_CODE_5 5

こんなんとか
>#define BAR_CODE_1 1
>#define BAR_CODE_2 2
>#define BAR_CODE_3 3
>#define BAR_CODE_4 12
>#define BAR_CODE_5 5

こんなのとか
>//インデックスのずれを修正
>#define FOOBAR_CODE_1 2
>#define FOOBAR_CODE_2 3
>#define FOOBAR_CODE_3 4
>#define FOOBAR_CODE_4 5
>#define FOOBAR_CODE_5 6

その手の1,2,3,4とか見るだけでウンザリしてくるっす。
定数の意味なくなくなくね？って感じで定義した当事者に尋問すると
「そうなんですよね」とか返ってきて、解っててやってる節があって、「え？」って感じなんすけど。

仕様書ありきだからそうなるんだろ。

＞意味なくなくなくね？
こんな喋り方する奴とは仕事もしたくないし一緒に飲むのも嫌だ

>>242
なんかトラウマでもあるのか

>>236
アルゴリズム変えて行数減ったら怒られるってあれですか?

>>242
女の子にカタブツ君キモイって言われたトラウマでも？
キャバクラ行っても相手されなくて乙ってそうな雰囲気醸し出してるね。

コーディング規約に即値禁止が唱われてる組織は多いよね。
１回しか使われない数値の場合、EQU(define)と参照で行数は２倍になる。
俺はシステム構成にかかわる数値は頭に集めてEQUするが、１回だけとか
ハード固有の都合みたいな単発数値は堂々と中に書いてた。

>>246のような自分のことしか考えてない奴が書いたコードは臭い。
１回しか使ってないって、単に「今のコードでは」そうなってるだけだろw

某機器の25ｘ80の液晶に表示するコードを書いた時は直値で書いたな
GotoXY( 10, 12 ) を GotoXY( COL_10, ROW_12 ) みたいに書くのはアホとしか思えなかったから

>>243
>>245
必死すぎｗ

>>248
> GotoXY( COL_10, ROW_12 )
センスなさすぎｗ

GotoXY( FOO_X, FOO_Y )
みたいにしておけ。

マジックナンバーについては減らす努力をするべきだろ

０になれば優勝ですね

>>250
表示項目毎の定義にするとメンテが面倒なだけだよ
複数ページ有るから定義数も多くなるし FOO_X_OF_PAGE_1 みたいな定義になるぞ

定義数が多いなら、外部ファイルで調整できるようにするなぁ。
値取得用のI/F作って。

んな機器のROMにファイルシステムなんてねーよ

ビルド時に外部ファイルから与えればいいだけ。

何がマジックナンバーか、マジックナンバーの何が悪いのか、
そんな基礎的なことがわかってない奴がいるのかｗ

マジックナンバーという言葉が悪いのかねぇ。マジックナンバーは数字だけとは限らない。
COL_10とか数字じゃないけど、これは本質的にマジックナンバーと同等のもの。
やってはいけない定数だ。

マジックナンバーは名前が付けられるものを数値で書くのがダメってことだよ。
それが分かっているのなら、どこを定数にするか分かりそうなもんだが。
GotoXY( 10, 12 ) とか10や12はなんだ？
タイトルを表示する座標なら、TITLE_X、TITLE_Yになるだろ。
タイトルと同じX座標でYが違う場所に、コメントを置きたければ、
COMMENT_XとCOMMENT_Yになる。たとえTITLE_XとCOMMENT_Xが同じでも
同じ定数にしてはいけない。

今さらナニ言ってんだアンタw

今更も何も解ってない奴の多いこと多いこと。
俺や俺に関わる連中も様々なプロジェクトで言われて来たのに、
俺の見るソースは何故だかセオリー違反ばかり。

セオリー外れててもいまさら直せないよな
改修のどさくさにまぎれて修正するのもきびしくなってきてるし

重要なのは良くも悪くも品質の保証が取れてるバイナリであって、動いてるもんのソースなんざわざわざ弄るだけアホなのさ。

いじる必要が出てくるんだよ。作ってから２０年も経って、当時採用したICが製造中止
似たような機能の別のICに付け替え、なんて理由で。>>216のコードはその時の奴。
割り算をするのに、ｃの除算ルーチンをコールする事すら知らず、３バイトのBCDを
作り、１０進数の100を１バイトずつ繰り下がり付きの引き算するやり方で割り算を
実現していた。３画面分ぐらいの範囲でループしてるこれが 「割り算」 だと気づく
までに３日かかった。

コメントを書いていないのが悪いってだけの問題だなそれはｗ

コメントはけっこうついてたんだよ。64hを引いてキャリーが出なければジャンプとか（ｗ
そのブロックの頭とか全体に、割り算／除算という言葉は一言も無かった。

>>264
使えないコメントは無いのと同じ

つうか、コメントなんて無くても、割り算だと気付かない方がアホだろ
情報処理試験に同じような設問出ても文句言えるのか？

>>262 ご愁傷さま
> １０進数の100を１バイトずつ繰り下がり付きの引き算する
常識的に考えて、こんな割り算やんねぇだろ、フツー
つか、首にされるぞ、こんなことやってたら

>>267
馬鹿はお前。

ARMには除算命令がないの知ってる？

>>267
シフトしたりとか 色々手を考えるだろ？
8080とかz80にも乗除命令はなかったわい

>>269
その手の一つだろ。

シフトつかって÷10を実装するより、
割り算は割る数を何回引けるかです。
の方がよっぽどわかりやすいぞ。

小学生の頃にやっただろ？

>>270
かりにも(コンピュータ|ソフトウェア)エンジニアって名前の職業で飯を食ってるんだったら
そんなお子様みたいなことするなよってのが >>267 の主張じゃないのかw

>>270
最近の小学校では、筆算による割り算習わないのか。。

シフトによる除算は筆算の手法の２進数版ですよね。262のコードはまさに小学生
の原理で除算をしてて、金貰って書くコードにそれはないだろうと思ったのです。

他にも、３人で書いたらしく、ORIGINが 0000〜 2000〜 5000〜 と分けてあって、
全く同じ文字定数のテーブル2KBぐらいを全部にincludeしてあった＝外部参照を
知らないで作っていた、とか。　変数に名前をつけず絶対番地で LD/ST したことと
合わせて、よっぽどASMを知らない人が書いたのかな。

自分がなおしたときに、BCDの引き算をやめて、２進数にしてシフトとマスクで除算
したら、150行→20行ぐらいに減って、ラベルも関数名だけにできた。

そして2進数演算による誤差が発生して損害賠償問題に発展するのであったｗ

そんな底辺の仕事は選ばない

除算だけ気を付ければいいんだ。

整数除算だから誤差は発生しません。

いやいや、丸め誤差って奴がな、(ry

除算で丸めって・・・きっちり商と余りを出す手法でしたよ。

String hoge
=
null
;


くたばれステップ至上主義者共

そういうプロジェクトで、完成してから所定ステップ数に合うように、
{
} を入れまくってたことがあったなあ。

行数を増やす努力＞減らす努力　と評価されるなんてどこか間違ってると思った。
そんな時代を経て、行数は工数の評価には使わないようになってきたのだが、
今度は　簡潔に＝読みやすく　書くという気配りが失われていった。

他人が作ったフローチャートのデバッグやらされてる
デバッグが必要になるぐらいでかいフローチャート書くな
フローチャートでもコメントは入れろ
客はこんな意味の無い資料を要求するな

フローチャートってデバッグするんじゃねーの？

フローチャートなんて歴史的な資料、最近見た事無いわｗ

>>282 どんなチェックするの？　行き先が無いとか、ループが終わらないとか？
コーディングしたときこんな不都合が・・・とか？

今いじくってるシステムにZIONGって名前のクラスがあって
まあ何かの用語だろうなと思ってたら
ZakRelloって名前のクラスまで出てきた

よく通ったなこんなネーミング

自分で作ったんだけど、xxxrwrt と xxxnwrt って関数名にしたら、エディタで見ると
ほとんど同じに見えて、後悔した。 xxxRwrt と xxxNwrt にしとけばよかった。

なんだよそのきもい関数名ww

関数名の変更なんてリファクタツールで一瞬じゃね？

てか、エディターの全ファイル一括置換だけのような。。。

>>287
お前は子音クソ野郎か

"wrt"って表記を見るとなぜか息苦しくなる。
無意識のうちに字面通りに発音しようとしてしまうからかも知れない。
wurst（ドイツソーセージ）を思い出すこともある

>>289
それができるのは静的型付け言語だけ。

PerlとかRubyとかPHPとかじゃ無理。
絶対に関係ないところまで書き換わる。

人の作ったACCESSのツールの機能拡張頼まれてorz

関係無い所まで書き換わったところで、何の影響があるのか分からない。

シンボル８文字時代に育った者で、つい短い名前にしちゃうんですよ。
メーカー提供の標準モジュールがJIKIO010とかだったりしてました。

もう2012年だし関数やメソッド名はちゃんと動詞でかこうぜ

そ〜ですね〜、今なら PLL_N_write PLL_R_write にしとけば良かったと思います。
リリースして１０年以上経ってるし、勝手にいじれませんからね〜

ちょうどその辺直す機会がやってきたので、pllNwrite pllRwrite にしました。

ぷるるんライト＆ぷるるるライト

PLLのこと全く知らないんだが、NとRって何？

特定の周波数を出させるために、Ｎ値とＲ値という値をシリアル書き込みするんです。
私もハード知らないんですが、分周比＋半端みたいな数のことだと思ってます。

>>281
今やってるプロジェクトがそういう展開になりそうだ

コードブロックにローカルルールってある？
void hoge()
{
　　for()
　　{
　　}
}
から、
void hoge() {
　　for() {
　　}
}
にした。
後者の方が縦に収まりやすくて見やすいんだよね。

オラ、K＆R式が好きだ！

言語の標準に合わせて書く事が多い。
C系も言語によって文化が色々ちがうからね。

そんな事きにしてたら関数型とかアセンブラとか絶対読めないから、要は慣れだよね。

ていうかね、他人のは絶対やりたくないw

>>301
> 分周比＋半端みたいな数のことだと思ってます。
MとRが逆かもだけど 「PLLの出力周波数/元になる発振周波数 = M/R」 だよ
N、Rは、まともなPLLだと
「PLLの出力周波数/元になる発振周波数」 を、規約分数にすると求まる
(分子と分母を最大公約数で割る)。
だめなやつは補正が必要(Rは2以上じゃないとだめとか)

簡単に修正できるような行儀の良いプログラムなら頼まないで自分で修正するわな

日本国外に連絡して 日本の現状を聞いて下さい。
立て籠り 華喃人のサイバーテロで 世界中のデジタルが破壊されています。
インターネットも携帯もイエデンも サイバー攻撃されました。
繋がらなければ 家や会社の電話ならＮＴＴの番号案内。
携帯電話なら 携帯会社の故障や問合せ番号に電話して繋ぐしか無い。
役所（公務員）や企業は確実に狙われている。
検索エンジンのGoogleで
インターネットテレビ 朝鮮総連 立て籠 人質 名前
を 続けて検索して 世界的に有名な名前が並んでいたら サイバー攻撃の被害は受けていない証拠。
閲覧出来ない人には 画面コピーをメールに貼付して送信してあげて下さい。
宜しくお願いします。
Arena_Oda_V_Lanc_St.
Micro Soft社 横濱えり
モバゲーの☆葵雷恩☆＝元 八犬伝
Micro Soft の新しい携帯電話とcarrozzeriaと業務提携の新型パソコンの発売に御期待下さい。
ガンダム携帯はドメインも!
宜しくお願いします。
m(__)m

>>308
ゴミ収集のように人の嫌がる仕事は高級が基本なのに、プログラマは嫌がる仕事を薄給でやらされるw

ハードのversionを参照してPLLに書き込む波形を変える修整やったのですが、
DATとCLKとLEという端子の性質考えたら、何もパルル数を別々にしなくても、
「多いほうに合わせておけば」 両方に通用するんじゃ？と考えて、ハード屋さんに
そう聞いたら、「う〜ん、たしかにそうなんだけど・・・間違った波形は出さないもの
なんですよ」 と歯切れが悪かった。この辺は組織の伝統みたいなもんですね。

ってかまだ関数名キモイなあ
pllNwriteってのがそういう意味だとして、PLL::setN(),PLL::setR()みたいなメソッドになってるとわかりやすいのに
関数名で、さらにwriteって動詞使いたいならwritePllNと書くべきじゃないですか？

「プログラム書法」にあるように、発音しやすい変数名にせい。
wrtとか論外。
pllNwrt？そんなバカと仕事したくねえ。pllNwriteでもいまいち。pll_N_writeなら合格だ。

これは酷い…

uwarite

recv()のことはもういじめないであげて

自分でアプリ開発してるけど
クラスが１０００戸になってしまって
もう分けが判らないし、自分のコードなのに理解できない所が出てきてさあ大変な状態ですわ

整理整頓しろって、子供の頃教わらなかったのか

新しくクラス作る前に今までのクラスをリファクタリングしたほうがいいぞ

>>317
あなたのそのクラス、本当に必要ですか？
メソッドじゃ駄目なんですか？

クラスが1000超えようと、相互間で直接扱うクラスなんて数個しか無いだろ。
むしろ直接扱うクラスが３っつ以上になったら、設計ミスを疑え。

何でもクラスにしたがる奴も居るしなぁ
継承で一生懸命やってるけど、共用体の方がスマートじゃね？
と思う時がある

共用体？ まだそんなへんな機能をもった言語があるのかｗ

いや役割が少ないクラスはインライン化したほうがいい時もあるって話でしょ

いいえ、誰がなんと言おうと共用体です。

そ、そうですか

（´；ω；`）

>>303
絶対前者
｛｝の間違いが一瞬で分かるが、後者は見落とす事がある

>>328
どちらも複雑になったら同じ。

メモ帳でも無い限りは、今日日のプログラム言語にある程度対応したエディタだと
対応する括弧の強調表示どころか、対応する括弧内のテキストを選択する機能
くらうは付いているからな。

目視でいえば、1画面を超えるようなのだとあまり意味がないと思う。

>>328
そんなつまらんことはエディタやコンパイラに任せて、
他のことに心を砕いたほうがいいぜ。

どっちでもいいと思うけどどっちかに統一しないと気持ち悪い
インデントにタブと半角スペース混ぜたりとか
というかプログラミング用エディタの勝手にインデントがうざい

カッコ悪いだけだし、問題無く動くんでしょ？　どうでもいいよ。

細かい事にこだわってると物事の本質が見えなくなるよ

わかりにくいコードのままだと他の人が見えなくなるじゃん
一人でやるにしても次見たとき思い出すのに時間かかる

それを含めて鮮明に思い出せるから無問題。

鮮明に思い出せるとは
どのくらい鮮明なの？

スペースの数ぐらい？

その頃付き合ってた彼女の陰毛の数まで連鎖的に思い出せるだろ。JK

>>333
お前それ>>280みたいなコードを延々と見せつけられて
メンテしろって言われても同じこと言えんの？

他人が作った仕様に従ってプログラムを作るのもプチ絶望感ある

>>339
>>333じゃないが言える...金さえ貰えれば

>>341
多分他のことやったほうがもっと金貰える
大体こんなもんメンテさせられる立場の人間より
無縁でいられる人間のほうが収入が多い

スケジュール出せだ？
こんな糞の調査にスケジュールなんか出るかよ

修正履歴として当該コードのコメントアウトと日付＋理由を残す
これはまあ判らなくもないが
その前のコメントにこれまでのあらすじを書かされる方針なのがきつい
yy/mmの会議で決定したがyy/mmに誰それから仕様変更があり〜みたいな。
コメントだらけのソース読むほうもきついが書く方もストレスが半端ない
ソースの７割コメントってどうなんだ

こないだメンテしたC++のコード、「変更前のコードは全てコメントアウトして残す、
変更した日付と名前をコメントに書く」って規則があって、最大4500行程のメソッドがあった
変更前のコードを削除すると1500行くらい、さらに無駄を省いたり条件分岐を最適化して
200行弱までになった

ソースは製品なわけだから修正履歴書く場所じゃねえよな
Git使えと

>>346
あのねぇ、Gitがないところで修正されたり、第三者がGitのないところで見たり、
Gitを使ってない会社にソース毎引き継いだりするのよ

>>347
リポジトリごと渡せばいいやん。

GitでもSubversionでもVisual SourceSafeでも何でもいいけど、
バージョン管理ツールすら使っていない会社って、技術レベルを疑う。

>>347が言うシチュエーションも実際にはある話だけど、それが使って
いない理由ってのはちょっといただけないなぁ。

バージョン管理システム使ってても、>>345のような運用をしているところはよく見かける。

きっとつかってなかった頃の名残なんだろうね。で、誰もその運用に
疑問を持っていないんだろう。

ファイル比較ツールで変更点をチェックしたりするときに見づらくて
しょうがないと思うんだが。

使ってるところでも、ブランチ切るのはご法度な会社なら知ってるぞ

修正行の前後一行程度なら別にいいと思うが

おまいら、情報を分割する危うさってもんを分かってない。

おまいら、
　　　　　　　　( ﾟдﾟ)　情報　を
　　　　　　　　(＼／＼／

　　　　 　　情　　 ( ﾟдﾟ)　　報
　　　　　　　＼／|　y |＼／

　　　　　　　　　分断する

　　　　　　危うさ
　　　　　　　　　(ﾟдﾟ )
　　　　　　　　(|　y |)

　　　　　　わかってない
　　　　　　　　(ﾟдﾟ )
　　　　　　　　(|　y |)

まあある程度の基礎知識があって、
金出す側がある程度情状酌量してくれるなら
単に勉強になるだけだな

若干フラストレーションはたまるが

大量の設定ファイルってどうやって理解する？
なんかxmlファイルいっぱいあんのよ・・・

うわ最悪だなそれ
想像もしたくないわ

>>349
自社ではもちろん使ってるが、発注元が使ってないので>>345のようなこと強要されるという話なんだが。

その職場はvssを使ってたんだがw

考古学で、古代の何語とも分からない文字で書かれた碑文のようなものを
解読する作業ってあるんだが、それに比べたら他人の書いたソースなんか
簡単過ぎる話ではある。

要は、その解読に許される時間の長さが問題なんだよな。
あせってしまうとオツムが混乱し、ますますドツボにはまる。
でも、いちど理解の糸口が掴めると、ドンドンと解読が進む。

分からないままに修正すると、トンデモないバグを作りこむ怖さも
あるから、やっぱ腹くくってじっくりと理解できるまで解読を進めるか
はたまた機能を理解したうえで、いちから全部作り直しが正解かもな。

古代文字なんて、解読間違ってても誰にも怒られないじゃないか。

古代文字を読み間違えて起きる不具合と、他人のプログラムを読み間違えて
起きる不具合を考えたら、時間云々なんて言ってられないだろ。

typedef、defineマクロだらけのコード解読に本当に苦労した

ポインタとか配列をエイリアスするのはマジやめろ

マクロは100害あって１利しかないからなぁｗ

>>361
当時の事情を考えるとそう書くのが妥当であれば
解読が困難でもストレスはたまらない

>>360
ヴィジュアルソースセーフってダメなん？

>367
便利機能は大体封印。全員が使い方熟知してるわけじゃねーし
履歴管理とdiff取るためにしか使わない

>>368
高度なプロジェクトだな
うちでは最新版の取得以外の使い方出来る人いない

ファイル管理はぱーふぉーすつこうとる

アメリカ人はCVSとか神ツールの如くマンセーしてたからな
今見ると笑える

その頃日本人はプロジェクトリーダが日付ディレクトリを使って管理してた。

#define BEGIN {
#define END }
#define var
...

>>367
vssがダメってんじゃなくて、バージョン管理ツールを使ってるのに
>345みたいな規則を決めてるのがダメってこと

>>359
いいんじゃない？ｗｗｗ
発注元が他社でメンテさせようにもメンテできないくらい難解にしとけば
そのソースが手を入れながら使われる限り>>359の会社に頼るしかなくなるｗｗ。

メンテする側としてはたまったもんじゃないが。

修正前のコードが歴代残っていると、過去に同じ仕様で同じ事してるモデルがあったとか出てきて参考になるんだよな。

そしてコード重複へ・・・

>>377
そんな事、変なオブジェクト指向が流行ってた頃は、隠蔽当たり前で、同じコードどころか基本関数すら重複の嵐だったろｗ

関数は1クラス1つだけ、コードは基準になるソースからコピーして改修すること
みたいな規約のプロジェクトがあったな
後に聞いた話ではやっぱり大赤字プロジェクトになったみたいだが

ああああ、重複する処理が幾ケ所にもあるのに、全部非公開関数だから使えねえとかなｗ

>>379
メンバメソッドを追加するたびに派生クラスを作るのか？
クラス名を考えるのが大変だ

>>381
派生させたらメソッド2つになっちゃうじゃないですかやだー

全部のページでフレームを使わずメニューを組み込んでて
そのメニューに大幅な変更がかかって
しかもそれをテキストエディタでやれと

orz

自分のノルマこなした上で、お手伝い残業で修正するのはちょっと楽しかったかも。

>>383
亀だが、マクロついてるエディタならある程度型が近い文字列の置換は楽じゃね

判断を必要とする作業をやらせたら必ず「時限爆弾」を仕込む奴、いるよな？
絶対に設計を任せてはいけない

>>384
プレッシャーがない分には楽しいよな
過去語られてきたトンデモプロジェクトも、ちょっと触ってみたいと思うもんｗ

ちょっとでも触るといずれ巻き込まれることになるんだぞｗ

ちょっとでも触った＝担当者、だよな普通。

うん。コメント一行削っただけでも未来永劫担当者扱いされる。

>>1
このプログラムは約3万8千通りの挙動を全て暗記できなければ修正できません。
とか、かなぁ。

「正直、直すのしんどい」という理由だけで別人氏から1関数5000行のコードがやってきたときは
さすがに絶望した。
ifがMAX12段とか、ifのネストの合間合間にまたif挟まってたり、軽く芸術。

他人のどころか自分の作ったものだって数ヶ月すれば修正する時は絶望だよ

修正っておもしろくないよね

>>393
そう？ 時間がない中、バグをクイックハックで
修正する作業は、コードの量は増えるし、
見通しも悪くなるし、複雑になるだけでつまらないけど、
コードをよりよい形に修正する作業は楽しいよ。

オリジナル作者に罵声を浴びせながら修正するのは．．．結構楽しいｗ

あるある

>>394
部分的によりよい形にされてしまって
他との整合性がとれてないコードのデバグで泣きそうになったことがある

あるある

たいがいにしとけよ
糞コード書いたのが今ではその会社の役員様かも知れんぞ

前任あっての後任だからな。糞コードに支えられて飯食わしてもらってるって事だ。

早く糞コードを切り捨てないとなｗ

開発規模の小さい社内ユーティリティレベルだと最初から書き直したほうがはやいｎｊ

UFOコンタクトの新手法を考えたのでアンケート協力してちょ(´・ω・｀)(全４問)

http://www.dounano.net/answer/kUv9X7106.html

システム移行って、コーディングルールまで移行するものだと初めて知った

『元のシステム製作者(全員辞めてるし顔を知る人も大半がやめてる)が
　理解できないからクラスは作るな、関数も作るな、すべてmainだけで完結しろ』
俺「mainだけって……まさかgoto使えとか」
『お前若いのによく解ってるな。しかし最近はなんで行番号がないんだ云々』

ハード屋の図面みたいな標準仕様がコーディングにもあれば
もっと仕事が楽になるんだが無理だろうなｗ
絵を描くようなもんだから。

字面だけ統一したってコード全体が良くなるわけじゃないんだけどなあ
見えるところだから手を付けやすいんだろうね

クラスとメソッドが日本語なんだけど作った本人はどや顔してんだけどコード補完しづらいわ。コメントとの見分けがつくづらいはですっごく読みづらいしストレスたまる。

メモ帳やviでコーディングしてる英語圏の人は凄いとも言える

英語圏とか関係あんの

予約語やコメントに色が付かない

コメントが小学生の日記レベル以下。
「なぜか」「よくわからないけど」などなどがいっぱい。
お前だよI○Bのブタ附秀介死ねカス。

変数名とおりの値が入ってなかったことあって吹いた覚えある

例えば”売り上げ”っていう変数名なのに中身単価だったり・・・
嫌がらせすんじゃねぇよ・・・

スパゲッティ、では、ない
が、
思ったことをやろうとすると、途端に血が吹きだす

たとえるなら、そう、
障子紙を破って無数の手が伸びてくる
そんなかんじ？

VB化石はきついぞ

なぜ未だにVBしかできない新人が大卒で入ってくるんだ?

>>415
大学で習うのは理論だからなぁ
幾ら英単語知ってても英文小説書けないのと一緒さね。

考古学で古代文字を暗号解読するなんて
ロマンがあって楽しいぞ。　それに比べれば
下手ッピが作った汚いプログラムを理解して
修正するなんざ、優し過ぎて涙が出るわ。

問題は時間がかればタダ働きとなり、徒労感で
入院し、さらに医療費がかかって、ガックり来ることか。

古代文字は、書いた本人がもう死んでいるからなあ

プログラムは、書いた本人に死んで欲しくなるからなあ

#defineの定数定義のひとつのヘッダファイルに集約…
静的グローバル変数で済むようにできるものまでご丁寧にひとつのファイルでグローバル変数に…
どこから手をつけよう…というか心が折れてます

>>420
すなおにグローバルの定数にしては？

何故わざわざ変数にするのか分からない。

１．ビルド時のエラーを解釈しやすくなる可能性があるから
２．デバッグのときに変数名を参照できるから

>>422
昨今は#defineを廃してconst intとかにするのが流行りらしい

昔のプログラムに比べて全てにおいて優れているものを作り上げると達成感がある。

>>424
そうか、#defineマクロは弊害大杉だから、それも手か。

名著「Effective C++」で推奨されてるやり方だな。

近い将来、「左定数条件式」みたいに小僧に馬鹿にされるスタイルになるんだろうな

中国が作った粗大ゴミを使えるゴミに直す作業が苦痛すぎる。
廃棄処分して作り直した方がいいのに、コウスウガーとか言い出す馬鹿PMに辟易するわ。

どうせPMなんて粗大ゴミの中身を見てないんだから、知らんフリして書き直せば良いじゃん
俺はそうしてたよｗ

>>429
支那ＰＧは、安かろう悪かろうの典型例なんだよな

支那人は
品質の一つに保守性があることを
想像すらしていない

何なんだ、あのコメント書かない教、ドキュメント作らない教の信者が
作成したかのようなシロモノは

修正できないから
顧客からの不満が山のように積みあがっていく

一行もコメントがないソースに遭遇した
出来ないって言えたらどんなに楽か

そんなのは日常茶飯事