07/08/21 17:37:02
訳が許されるのはアセンブラまでだよね～
101:仕様書無しさん
07/08/21 18:55:45
コボラの執念は異常
102:仕様書無しさん
07/08/21 21:11:59
怨念だろ...
103:仕様書無しさん
07/08/21 21:30:03
上司「新しい案件の話なんだが、某社にてコボルで作成された古いシステムがある」
俺「（あー、リプレースか・・・）」
上司「で、そいつが寿命と言う事もあり、リプレースの時期にある。」
俺「（流行でJavaでWEBとか言うんだろうな、糞）」
上司「そこで、新しくコボルでリプレースする事になった」
・・・・は？
俺「いや、自分も周りもコボル使える人なんていないんですが・・・」
上司「大丈夫。俺でも読める」
辞めるかな、この会社。
って辞めたくなった上司の一言のネタだな、こりゃ
104:仕様書無しさん
07/08/21 21:37:29
>>103
COBOLでWEBだな。
105:仕様書無しさん
07/08/21 21:42:58
COBOL ON RAILS
106:仕様書無しさん
07/08/21 22:09:21
>>103
…ウチは PL/I→COBOL だよ
107:仕様書無しさん
07/08/21 22:26:03
ACAX
108:仕様書無しさん
07/08/21 23:11:18
皆大文字使うんだな、流石だ。
109:仕様書無しさん
07/08/21 23:28:33
>106
逆行しとるがなｗ
110:仕様書無しさん
07/08/22 00:13:37
C言語において、、、
ヘッダファイルにグローバル変数が"定義"してある。(externはなく、staticでもない)
そのヘッダは #ifndef XXX_H の様な記述は無く、多重includeの対策は無い。
標準ライブラリで定義済の変数を、何故か自分で定義している。
バグがあり、症状も現れている。(テストしてないだろてめぇぇぇ)
潜在バグも既に発見されている。(ローカル配列のポインタを返すなど)
必要も無いのに、全レコードを読み込んで保持する。(reallocを繰り返す)
そのreallocは ptr = realloc(ptr, size);
文字列リテラルの連結 "AAAA" "BBBB" をいちいち、strcatなどで連結する。
一つめのifで確定した条件をネストしたifでもう一度聞いている。
関数一つが数百行。
ifやfor/whileのネストは８段階くらい。
コメントアウトされた部分が、実際に生きているコードより長い。
原則１プログラム１ソースファイル。
など。
111:仕様書無しさん
07/08/22 00:18:02
>>92
＞catch(Exception e){}
ん、これ何か問題が？
112:仕様書無しさん
07/08/22 00:18:55
＞ヘッダファイルにグローバル変数が"定義"してある。(externはなく、staticでもない)
gccなんだろうかねぇ・・・。
113:仕様書無しさん
07/08/22 00:21:13
>>111
例外の握りつぶしは犯罪
１００歩ゆずってもログに吐け、なにが起きたか解らないだろ・・・
114:仕様書無しさん
07/08/22 00:23:07
「全盛期の糞コード」スレみたいな
･あまりにコンパイルエラーが出るからエラーでもバイナリ生成
･ソースファイルを保存しただけでOSがフリーズした
115:仕様書無しさん
07/08/22 00:23:47
>>113
再スローすれば握り潰しにはならないぞ。
エクセプションは例外の種類別に処理するのが望ましいというだけで・・・。
オマエの発言は厨臭いな。
116:仕様書無しさん
07/08/22 00:24:59
>>115
> catch(Exception e){}
このコードのどこが再スローしてるんだよｗ
117:仕様書無しさん
07/08/22 00:25:34
情報漏えい対策とかで、爆弾みたいなツールを導入された
なにかやる度に動き始めて、PCの起動に約１０分
ソースは全て暗号化されているから、都度解凍しなくてはならない
パスワードも凝っていてフザケンナ
で、ソースも暗号なんですよｗ
118:仕様書無しさん
07/08/22 00:26:17
>>115
＞catch(Exception e){}
ブロックの中身を省略してレスしたわけじゃなくて、
ホントに何の処理もしないcatchが入ってるってことじゃないか？
119:仕様書無しさん
07/08/22 00:26:30
>>115
> catch(Exception e){} ←
跡形もなく握りつぶしてますがなｗ
120:仕様書無しさん
07/08/22 00:27:58
> catch(Exception e){}
の時点で糞だろ
再スローしたとしても、throws Exception と記述するハメになる
121:仕様書無しさん
07/08/22 00:28:08
シェルスクリプトにて、
複数あるシェルスクリプトの共通的な環境変数も、いちいち其々に書く。
テンポラリファイルを消さない。(消すJOBを別定義してある)
変数を必要もないのに環境変数化にする。
必要もないのにawkなどを使いたがる。
引数かリダイレクトで済むのに、なぜか cat file | grep ..など
シェルスクリプトを「シェル」と(ry
122:仕様書無しさん
07/08/22 00:29:50
>>116
あぁ。すまんな。
このスレでは過去から何度も(Exception e)について議題に上がってたんだよ。
もう、ずっと前の過去スレから。
そんなトコにツッコミ入れるとは思いもよらなかったよ。
123:仕様書無しさん
07/08/22 00:41:32
>>122
思い込みでソース書きそう。
しかも自分の思い込みが常に正しいと思ってるな。
一緒に仕事したくないタイプ。
と思い込みにより断定してみた。
124:仕様書無しさん
07/08/22 00:43:45
禿同
125:仕様書無しさん
07/08/22 00:43:51
>>123
自己紹介乙。
126:仕様書無しさん
07/08/22 00:49:47
>>109
それがさ、情報処理試験の選択肢から
PL/I が既に消えてるからって理由らしいんだよ…
確かに COBOL はまだある…あるけどさ…？
127:仕様書無しさん
07/08/22 01:04:52
>>122
なにこの上から目線ｗｗｗ
128:仕様書無しさん
07/08/22 01:07:16
>>127
オマエのようなバカで厨にはちょうどいいんだよ。
129:仕様書無しさん
07/08/22 01:12:00
catch(Throwable e){}
130:仕様書無しさん
07/08/22 01:19:51
そこまでやればもう拍手をやりたいなｗ
131:仕様書無しさん
07/08/22 09:35:59
>>113
会社に握り潰しどころか、正常値返して何事もなかったかのように振る舞うソース書くツワモノが……
でも、返す値が出鱈目だから、結局駄目なんだけど
132:仕様書無しさん
07/08/22 10:16:09
>>131
それは正常値を捏造してんじゃなくて、
エラーの時はエラーコードを返すって
懐かしい習慣を今の世に伝えようと
しているんではないかと。
で、コメントにエラーコードとエラー内容の
対応が書いてあったりしてなあ。
133:仕様書無しさん
07/08/22 10:16:43
>>131
返り値捏造はスゴイと思うです。
134:仕様書無しさん
07/08/22 10:37:54
>>132
いや、理解しがたいかもしれないがマヂ
例外起きるとDBの値を適当に持ってきてやがった
orz
135:仕様書無しさん
07/08/22 11:20:30
>>110
> そのreallocは ptr = realloc(ptr, size);
何か問題が? realloc ってそういうもんだよね。
reallocならmemcpyもしてくれるし。
memcpyが要らない場合でも、memcpy は普通無視できる程度の時間しかかからないし。
> 文字列リテラルの連結 "AAAA" "BBBB" をいちいち、strcatなどで連結する。
場合によってはそういうのもアリじゃないか?
目くじら立てるほどとは思えん。
もちろん、バッファ境界を気にしてなくてバッファオーバーフローが起きるなら別だが。
俺C++使いだが、stream に連続して << 操作したり、
std::basic_string<T> に連続して += したりするぞ?
その方が意味が明確になる場合もあるからな。
136:仕様書無しさん
07/08/22 11:25:00
>>135
realloc() が失敗したら漏れる。
137:仕様書無しさん
07/08/22 11:26:49
>>135
文字列リテラルは並べて書くだけで連結できる。
138:仕様書無しさん
07/08/22 11:45:23
>>134
それ、プログラマーとしてってより
人間として失格だよ！
139:仕様書無しさん
07/08/22 13:17:21
>>136
reallocが失敗するような状況で、それが何の問題が？
140:仕様書無しさん
07/08/22 13:41:37
ptr1 = realloc( ptr, size );
if( ptr1 ) {
ptr = ptr1;
}
else {
// ptr に有る情報は何かに使う
}
とか？
もっとも malloc() がコケた以上先の処理がまともに動くとも思えんけど
しかし１レコード読むごとに realloc() してたら殺したくなるな
141:仕様書無しさん
07/08/22 13:54:58
>>110のようなソースの修正やってて文句言いながらやってたら
リーダーに「人のソースにいちいち腹が立つような人は要らない。他にも人間はいる」
とかいわれて別チームに振りなおされた漏れ
まさかそのソース、お前が書いたのか？
142:仕様書無しさん
07/08/22 14:02:10
出来ることって、せいぜい free して、
アプリケーションを終了するくらいだな
キャッシュとかのためにメモリバカ食い設計になっているプログラムなら、
キャッシュを解放して再挑戦する価値はあるかもしれないが、
それでもフラグメンテーションがすごそうだからやっぱり何も出来ないかもしれないな
143:仕様書無しさん
07/08/22 14:40:56
/* ここから先は見ちゃイヤン */
ってコメントがついた、そりゃーもうすんばらしい若気の至り満載な関数がorz
144:仕様書無しさん
07/08/22 14:50:57
>>142
>free して、
>アプリケーションを終了
やめとけ。
(以下、例のループ)
145:仕様書無しさん
07/08/22 15:40:09
さぁ、fjに行こうかｗ
146:仕様書無しさん
07/08/22 20:08:21
>>120
int a = 10; // default value
try {
a = Integer.parseInt(aStr);
} catch (NumberFormatException e) {}
はやるなぁ。
147:110
07/08/22 20:19:19
realloc と文字列連結の話は、>>136,>>137の通りです。
mallocで最初に150MB程度確保、その後reallocで25MBずつ拡張、最終的に350-400MB程度まで確保です。
reallocで失敗したらすぐ終了してるんですが、reallocとかmallocで確保した領域は、
freeしなくても、プログラムの終了時に自動解放される(または場合が多い)、
との事ですが実際のところどうなんでしょうね？
>>141
あなたを苦労させているのは、私じゃありませんよ。
私も(心の中で)グチりながらやってます。
148:仕様書無しさん
07/08/22 20:30:31
>>146
場合によるけど起こりえないならRuntimeExceptionでラップして投げとく方がいいし、入力側でチェックしたり先に変換しておくほうがベターだろ
149:仕様書無しさん
07/08/22 20:50:04
>>148
その入力時チェックと、NG時の値の設定を同時にやりたいんだろう。
と言うか俺もやるよこれ。楽で。
もちろん、すごい回数やるような時には使わないが。
150:仕様書無しさん
07/08/22 20:58:38
全角通っちゃうけど
151:仕様書無しさん
07/08/22 21:02:04
職場じゃないし議論しても意味はないけど
例えば「２０」と間違えて全角で入れてしまった場合、ユーザーには何の警告も出さずにデフォルトの１０に設定されてしまうが、それでいいの？
152:仕様書無しさん
07/08/22 21:13:10
いい。
指示されてない以上それでまったく問題ない。
気を利かせて作ってあげてもまったく感謝しないのだから、そこは追加料金貰う。
それが業界標準。
153:仕様書無しさん
07/08/22 21:25:47
そりゃ、そんな会社は辞めたくなるな
154:仕様書無しさん
07/08/22 21:28:25
知識も技術もない奴が書いたならば仕方ないとも思うが、解っていて書くのマとしてどうよ？
155:仕様書無しさん
07/08/22 21:29:25
>>147
fj.lang.c malloc free でぐぐる。
156:仕様書無しさん
07/08/22 21:42:16
>>149
にしてもちょっと判りにくい。
catchの中で10を入れてもらった方が
やりたい事が素直に伝わる。
157:仕様書無しさん
07/08/22 23:10:24
ユーザーは間違いを指摘されると苛つくもんだ。
黙ってデフォルト値のほうがマシなケースも多い。
金とか命がかかってるなら別だけどね。
158:仕様書無しさん
07/08/22 23:12:09
でもデフォルト値に変更されたことを報知する仕組みはあったほうがいいよな
159:仕様書無しさん
07/08/22 23:24:12
間違いを指摘されて苛立つと文句くるくらいなら入力させなきゃいいんじゃねｗ
160:仕様書無しさん
07/08/22 23:29:01
一般的なユーザ
↓
ヤダャダー!
〃〃∩ _,,_
⊂⌒( `Д´)
`ヽ_つ⊂ノ
間違いを指摘されるのは
_,,_
〃〃(`Д´∩
⊂ (
ヽ∩ つ
でも黙って
デフォルト値を入れられるのもいや
〃〃∩ _,,_
⊂⌒(つД´)
`ヽ_ノ⊂ノ
可愛い彼女も欲しい …
∩
⊂⌒( _,,_)
`ヽ_つ⊂ノ
... ...
zzz…
∩
⊂⌒( _,,_)
`ヽ_つ⊂ノ
161:仕様書無しさん
07/08/22 23:35:19
＞でも黙って
＞デフォルト値を入れられるのもいや
＞〃〃∩ _,,_
＞ ⊂⌒(つД´)
＞ `ヽ_ノ⊂ノ
大丈夫だよ、君は気づかないｗ
＞可愛い彼女も欲しい
禿同
162:147
07/08/23 00:29:06
>>155 ありがとう。
URLﾘﾝｸ(www.mk.ecei.tohoku.ac.jp)
の 7.24にありました。やはり、当てにしない方が無難ですね。
163:仕様書無しさん
07/08/23 00:58:40
>>162
釣り? またループしたいの?
あなたの使おうとしているOSや処理系のマニュアルを読みなさい。
Cの規格をいくら読んでも無駄。
164:仕様書無しさん
07/08/23 14:06:12
「fj行こう」＝「富士の樹海行こう」だと思った
165:仕様書無しさん
07/08/23 14:27:05
え？違うの？
166:仕様書無しさん
07/08/24 11:53:53
そんな貴方に
uwarite
167:仕様書無しさん
07/08/24 20:56:34
うわらば
168:仕様書無しさん
07/08/24 21:09:06
>>164
「富士通に行こう」かと思った。
意味は>>164と変わらんが。
169:仕様書無しさん
07/08/24 23:29:50
少しは関数名を考えろと思った
int fuck()
{
//何かのチェック処理
}
170:仕様書無しさん
07/08/24 23:35:57
func
fund
fune
funf
fung
funh
連番にするなと言っておいたら、こんなん書かれた事ある。
書いた奴はぶん殴ったのは１０年以上前の思い出
171:仕様書無しさん
07/08/24 23:45:57
「funeです。来週のサザエさんは、funf, fung, funh の三本です。」
172:仕様書無しさん
07/08/24 23:49:44
俺だったら褒めてやるけどなｗｗｗ
173:仕様書無しさん
07/08/25 00:26:41
どんだけ天邪鬼ｗ
174:仕様書無しさん
07/08/25 00:39:01
for (int i = 0; i < nSize; i ++)
{
//設定値読み込み
Dokjinoyomikomikansuu(); //正式名称は忘れた
//処理・・・
}
ってのを見たことがある。同じ設定を何度も何度も、ループで読んでる。
しかも、そのループ自体が別の関数からループで呼ばれている……
設定情報って一度だけ読めばよかったんじゃないのか？
175:仕様書無しさん
07/08/25 00:39:40
ちなみに、設定値読み込みはファイルから読み込んでいる。
176:仕様書無しさん
07/08/25 00:48:44
>>174-175
システム次第なんでなんとも言えんなぁ。
177:仕様書無しさん
07/08/25 01:47:25
別スレッドで設定が更新される可能性があるんでしょ。ないんだろうけど。
178:仕様書無しさん
07/08/25 09:34:47
>>171
来週もまた、見てくださいねー！
fungっfunf
179:仕様書無しさん
07/08/26 01:27:45
会社の業務システムの年号が昭和。
印刷すると伝票が昭和で出てきて、みんな修正テープで手修正。
直すように俺が投入されたが・・・スパゲッティだし・・・
180:仕様書無しさん
07/08/26 01:32:52
２０年近く放置かよｗｗｗｗ
181:仕様書無しさん
07/08/26 01:33:13
出力直前に63引いて平成にするだけってことでなんとか・・・・
182:仕様書無しさん
07/08/26 01:36:02
それ「だけ」のことすら簡単にいかないのが
スパゲティのスパゲティたる所以かも。
183:仕様書無しさん
07/08/26 01:39:26
>>179
それって最近の話？もう平成19年なんですが...
古いシステムでソースも見にくいものに限って、仕様書／設計書もない。
ってパターンかな、、、
184:仕様書無しさん
07/08/26 01:39:42
だろうな。
印刷した紙の隅っこに昭和と平成の変換式を出力汁
185:仕様書無しさん
07/08/26 01:43:39
いやもう、印刷だけの処理なら、新しく書き直しちゃった方が早いかもね。
186:仕様書無しさん
07/08/26 01:50:08
>185
印刷だけで1実行モジュール? 何を呑気な
まず間違いなく入力参照更新印刷、全部1つに詰め込まれてるだろうさ。
昭和時代のスパゲッティにMVC分離なんて念仏にもならんよorz
187:仕様書無しさん
07/08/26 01:59:06
だろうなー
大丈夫だろうと６３引いてみたらば、予期せぬ所で計算が狂うとか確実に出そうだ
188:仕様書無しさん
07/08/26 03:47:18
年をループカウンターに使ったりとかあったりしてなw
189:仕様書無しさん
07/08/26 04:11:40
夢は膨らむなｗ
190:仕様書無しさん
07/08/26 05:03:34
悪夢だな…
191:仕様書無しさん
07/08/26 07:07:56
どうせなら西暦に直せよ。
4桁にするのは無理っぽいかも知れんがな…。
年号だとまた変わるぞ。
192:仕様書無しさん
07/08/26 07:15:37
そんなに長く使われると思わなかったんだろうな
Javaの2億9千万年問題も夢物語だが意外と起こるかもしれんなあ
URLﾘﾝｸ(ja.wikipedia.org)
193:仕様書無しさん
07/08/26 09:52:35
>>187
その - 63 を書くべき場所が、1ヶ所ならいいけど
194:仕様書無しさん
07/08/26 10:02:36
どうしてみんな元号が好きなのかよくわからん。
規定かなんかあったっけ？
195:仕様書無しさん
07/08/26 10:42:40
官公庁の風習
196:仕様書無しさん
07/08/26 12:59:43
JCLの印刷機に対応したDD文をファイルに変更。
そのファイルを読み込み、昭和=>平成変換プログラムに通す！
197:仕様書無しさん
07/08/26 14:17:25
>>194
使わないと街宣車がやって来る。
198:仕様書無しさん
07/08/26 15:04:15
キリスト教国でもないのに
キリスト暦を使うわけにもいかんだろ
199:仕様書無しさん
07/08/26 15:08:29
ここはユリウス通日で通すしかないな。
200:仕様書無しさん
07/08/26 15:40:55
神武紀元があろう
201:仕様書無しさん
07/08/26 16:42:21
防衛庁納入では必須だよ
202:仕様書無しさん
07/08/26 16:43:49
URLﾘﾝｸ(ja.wikipedia.org)
安田生命保険（今の明治安田生命保険）は1970年代に個人情報管理のシステムを構築することになった。
その際システムの担当者は、20数年後に生じるであろう2000年問題を予測していた。
そこで、年号の下2桁にグレゴリオ暦や元号ではなく神武暦（グレゴリオ暦－40年）を使用した。
そのことにより、安田生命保険は2000年問題を40年先送りした。
203:仕様書無しさん
07/08/26 16:54:22
unixタイムでいいよ
204:仕様書無しさん
07/08/26 17:13:06
わかってたらもっとマシな回避方法を取れとｗ
変換が増えて面倒そうだし
205:仕様書無しさん
07/08/26 17:13:30
>>202
予測しておきながらそんな解決方法を取るってのはアホだな。
206:仕様書無しさん
07/08/26 17:14:38
>>204,>>205
思ったとおりの反応。そして俺も同意。
207:仕様書無しさん
07/08/26 18:56:22
分かってて何もしないのよりもよっぽどマシだと思うがこれは酷いｗｗ
208:仕様書無しさん
07/08/26 19:21:46
一瞬「2038年問題よりも先まで耐えられる分マシじゃん」と思ったが、
time_tもそろそろ64ビット以上で定義するのが当たり前になってきてるんかな。
209:仕様書無しさん
07/08/26 19:33:00
>>204
>>205
>>206
さすがにストレージがここまで値段が下がるとは予測できなかったと思われ。
210:仕様書無しさん
07/08/26 21:48:03
いくらなんでもこのシステムやコードはリプレースされてるのでは？
1970年代だし…
211:仕様書無しさん
07/08/26 22:09:20
そういって動き続けているコードがどれだけあることやら
212:仕様書無しさん
07/08/26 22:34:41
#include "stdafx.h"
class f{public:void oO(char*c){printf(c);return;}};
int main(){
f(O_O);
(O_O).oO("定時まであと1時間半、どうやって潰そう・・・。")
;for(;;);return 0;
}
仕事しろ仕事。
213:仕様書無しさん
07/08/26 22:37:13
>>211
ボイジャー2号は1977年打ち上げ
それ以前に起動完了して未だに動いてるのは知らね。
214:仕様書無しさん
07/08/27 10:19:19
ボイジャーとかはレアケースだろとかいわれそうだけど
普通の業務システムで30年以上動いてる相手に
仕事したよ。
足りない機能をJavaで作ったんだけど、なんかMQとかで
つないでるらしい。
リプレースすりゃいいじゃんって話にはなかなかならないって。
215:仕様書無しさん
07/08/27 18:15:25
「動いてるものは下手にいじくるな」つーのが鉄則だし
216:仕様書無しさん
07/08/27 19:25:36
そして手遅れになる
217:仕様書無しさん
07/08/27 23:01:58
派遣だが、思いっきり派遣先に内緒でソースコード全部書き換えたよ。
あまりにも糞過ぎるコードなんだもん……期限は特に切られてなかったし、
少々時間かかっても、ソースコードが書き換わって、試験成績書と設計書（もちろん、なかった）
が添付されてればOKだよな？ 別に全部書き換えるなとは言われてなかったし。
たかだか、2,3万行のプログラムだったし……
218:仕様書無しさん
07/08/27 23:15:11
>>217
世間一般ではたぶんNGだな
219:仕様書無しさん
07/08/27 23:30:40
相談もなしってのはなぁ
220:仕様書無しさん
07/08/27 23:34:52
信頼され具合とか仕事の任され具合とか会社の文化とか
他にも色々と絡んで来るだろうけど
一般論だとNGだろうなぁ。
221:仕様書無しさん
07/08/27 23:42:14
どこかに話通さないと大変そうだなぁ
222:仕様書無しさん
07/08/27 23:45:30
内緒ってのはマズいよなぁ。
223:仕様書無しさん
07/08/27 23:48:26
話通そうとしても絶対NG返ってくるだろうしなぁ
224:仕様書無しさん
07/08/27 23:52:01
あ、言っておくが指示そのものが曖昧だったんだぞ。
おまけに、結果論だが改修よりも工数がかからなかった。
さらに、バグも減りまくった。
ついでに言うと、改修要求のうち一つがかなり深い部分までプログラムを書き換えないといけないところだったために、
全改修でなくても、どのみち、同じぐらいの改修は必要になっていたよ。
まぁ、でも相談は必要だったろうな……
225:仕様書無しさん
07/08/27 23:53:52
まあ、相談せずにやっておいて、承認でたら置き換えて終了ってのはよくやる。
指示が曖昧で何も決まらず時間だけが過ぎているから、とりあえず改修してしまっておくのは仕方ないわ
226:仕様書無しさん
07/08/28 03:48:58
まぁ味方になってくれそうな上司に前のものと新しい設計書渡して｢こんなんどうですか？｣
とか聞いて、説得して、｢実わ出来てるんですが｣とか
227:仕様書無しさん
07/08/28 07:37:08
>>224
> さらに、バグも減りまくった。
減りまくってもゼロじゃない限り、何か起きたときに責任問題になる。
「以前のソースを改修すればこのバグは無かったんじゃないのか？」とかとか...
相談しておかないと結局は痛い目を見る事になる。
揚げ足取る奴はどこにでも居るからな。
228:仕様書無しさん
07/08/28 09:37:39
> さらに、バグも減りまくった。
この言い回しで程度が知れるな。
229:仕様書無しさん
07/08/28 10:40:13
ソースコード云々より、まず給料が出ないので、、、
230:226
07/08/28 12:50:00
これさ当人以外に、｢問題なし｣と思っているやつはいるのか？
231:仕様書無しさん
07/08/28 13:08:30
「問題なし」は知らんが「やむなし」はいそう
232:仕様書無しさん
07/08/28 13:10:40
勝手に修正し後日別料金請求して
「おまいは悪徳リフォーム屋か」
と褒めて欲しかっただけじゃないかなと思ってる
233:仕様書無しさん
07/08/28 13:44:02
>｢実わ出来てるんですが｣
馬鹿？
234:仕様書無しさん
07/08/28 18:56:15
既存プログラムの修正：如何に少ない修正で所望の変更を行うかに全力を注ぐ
新規プログラム(既存に類似機能あり)：如何に少ない追加で所望の機能を得られるかに全力を注ぐ
新規プログラム(既存に類似機能なし)：如何に似せたソースコードで所望の機能を得られるかに全力を注ぐ
新規プロジェクト：好きなだけ新しい手法・コーディング・クラス設計その他をぶっこんで、決まったルールに従い好きなようにコーディングする
以上俺ルール
235:仕様書無しさん
07/08/28 19:01:23
やむなしはあるな、どうやっても直せなそうなコードってあるだろ、あべし製とか
236:仕様書無しさん
07/08/28 21:31:19
>既存プログラムの修正：如何に少ない修正で所望の変更を行うかに全力を注ぐ
>新規プログラム(既存に類似機能あり)：如何に少ない追加で所望の機能を得られるかに全力を注ぐ
典型的な失敗プロジェクト
237:仕様書無しさん
07/08/29 00:38:51
>234
漏れなら設計、実装(修正)、試験、（客や上司・メンバーへの）説明、
のトータルコストで考える。
238:仕様書無しさん
07/08/29 00:45:12
あべし(ノ∀`)
239:仕様書無しさん
07/08/29 05:54:25
>>234
>既存プログラムの修正：如何に少ない修正で所望の変更を行うかに全力を注ぐ
悲しいかな、漏れもそれを考えてやってるだ。
コードの修正箇所増＝ドキュメント増＆確認工数増とかって理由でな。
理想をいうと、所望の変更ってのが当初から与えられていたとしたときに書くコードを、
修正のときにも書くべきだと思ってるんだが。
理想と現実のギャップが大きすぎるなあ。
240:仕様書無しさん
07/08/29 13:27:23
>>234
めっちゃリアルやな。
ソースレビューやってソース管理して技術者を萎縮させてるNECや日立がやりそうなこと
241:仕様書無しさん
07/08/29 13:32:36
>>235
「直せる人、手を挙げて～」ってやって誰も手を挙げなかったから、リーダーが折れて
作り直しになったことがあるな…。既に玉砕者が2人くらい出てたし。
読むだけで狂いそうになるくらい、糞なコードだった。
242:仕様書無しさん
07/08/29 15:13:21
> ソースレビューやってソース管理して
これが技術者を萎縮させるのか・・・？
243:仕様書無しさん
07/08/29 15:28:41
ソースレビュー＆管理は必要だと思うんだが、
ソース読まない（読めない）人にレビューさせると、うるさくてかなわんと思うことはあるかな。
244:仕様書無しさん
07/08/29 17:49:23
異常なソース管理するとうんざりだなｗ
245:仕様書無しさん
07/08/29 19:01:27
異常な「ソース管理」？
「異常なソース」管理？
246:仕様書無しさん
07/08/29 19:59:57
修正箇所は「修正begin/end」のコメントで囲む。
元のソースはコメントとして残す。
diffも残す。
なんて管理があったな。
svn使っているのにヽ(`Д´)ノ
247:仕様書無しさん
07/08/29 21:28:35
マイクロソフトにもメンテあきらめたコードがなかったっけ？
Java関係のIEモジュールかなんかで。
第一人者の大学教授に開発してもらったけど、他のプログラマがメンテできないコードなので、
サポート終了することにしたって話。
248:仕様書無しさん
07/08/29 22:20:19
それがどうした？
249:仕様書無しさん
07/08/29 22:32:33
過去ソースの復旧作業で納期前の１週間を潰した俺が通りますね
250:仕様書無しさん
07/08/29 23:21:44
Hoge val;
val = new Hoge();
if(hogeDict.TryGetValue("a", out val))
{
val = HogeDict["a"];
...
}
251:仕様書無しさん
07/08/30 21:45:59
だってvalが好きなんだもん！ほっといてくれよ！
252:仕様書無しさん
07/08/30 23:21:36
>>250
何言語か分からんけど、察するに、
アウトパラメータなのに、直前にインスタンスをわざわざ作ってる。
ってあたりが嫌なのだと見た。
そして成功したら多分、valには既に HogeDict["a"]が入っているので、
if内 val = HogeDict["a"]が不要。
憶測ですがあってる？
253:仕様書無しさん
07/08/30 23:32:09
bufなアナタはC/C++派。
tmpなアナタはVB派。
foo/barなアナタはPerl派。
ローマ字なアナタはCOBOL派。
254:仕様書無しさん
07/08/31 10:51:54
>>253
ローマ字以外当てはまる私は何派でしょう？
255:仕様書無しさん
07/08/31 12:01:46
ごった煮派
256:仕様書無しさん
07/08/31 13:07:48
カオス派
257:仕様書無しさん
07/08/31 13:21:29
ファンタジーと呼ばれるものをするよ派
258:仕様書無しさん
07/08/31 13:48:10
ビューティを紡ぎ奏でるよ派
259:仕様書無しさん
07/08/31 20:36:27
>>257-258
狼へ帰れｗ
260:仕様書無しさん
07/08/31 23:41:31
懐かしいなｗ
で、結局するの？
261:仕様書無しさん
07/08/31 23:54:04
$url="doc_root";
$url="doc_root"."img/game";
$url="doc_root"."img/game"."/m";
$url="index.php";
header(Location : $url);
262:仕様書無しさん
07/09/01 00:13:34
まて下から2行目は書き損じじゃないんだな? 本当にこの通りなんだな?
263:仕様書無しさん
07/09/01 02:51:55
>>246
「だって印刷したときに履歴が追えないじゃないか。」
（cvsやsvn＝ソース共有ツールという認識っぽい）
中には、納品物が揃って初めてコミットなんてプロジェクトも…
そうしないとCVSのリビジョン番号が揃わないからだってさ。
264:仕様書無しさん
07/09/01 03:20:27
>>263
うちはもっと緩いから良いのかも知れないけど、
時々CVSとかにコメント無しでコミットする人を見ると
粉炉したくなる．．．
と言うか、氏ね と思わないこともない。
実行もしないし、思わないんだけどね！
265:仕様書無しさん
07/09/01 03:47:51
>>263
なるほどリビジョンをタグがわりに使うわけか。
新しい。
266:仕様書無しさん
07/09/01 04:08:48
あーでも次のリリースは
どうせリビジョンそろわないじゃん。
267:仕様書無しさん
07/09/01 10:49:24
どっかにスペースでも入れて、本質的に変わらんモンをcommitしなおしたりすんじゃねーの？
268:仕様書無しさん
07/09/01 11:36:05
インデント調整とか本質は変わらんでも、意味がある修正もあるがな
269:仕様書無しさん
07/09/01 12:29:01
リビジョンが1つ上がることに、空行のスペースが1個ずつ増えるんだよ
270:仕様書無しさん
07/09/01 13:44:05
>>269
どっかのメールソフトみたいだな。
「 Re:Re:Re:Re:Re:Re:」
271:仕様書無しさん
07/09/01 20:04:09
「印刷したとき」のために
プログラムとして必要なく、可読性を下げるコードを残すのか┐(´･∀･`；)┌
272:仕様書無しさん
07/09/04 02:41:20
関数のヘッダーコメントに
「関数内で呼び出してる関数（標準関数とかは除く）の名前と機能を書け」
って指示がプログラム完成後に出た。
俺以外の人が書いたソースは1関数500行以上とかなんで
それぐらいたいしたことないね、みたいな感じなんだけど
ある程度真面目に関数分割した俺はすごくガッカリ
俺だけ量多すぎて手伝ってもらうことになったんだけど
「なんでこんな手間のかかる書き方するんだよ。
センスないんじゃないの？」
って言われた。手伝ってもらってる手前、反論もできなかった
まさか自分が書いたソースコードがきっかけで会社辞めようと思うことなるとは
273:仕様書無しさん
07/09/04 02:58:15
かわいそす
274:仕様書無しさん
07/09/04 03:00:10
>>272
>1関数500行
これ後で読む人もかわうそす
275:仕様書無しさん
07/09/04 05:50:13
>>272
その指示の意図が全く解らん
上司も1関数500行タイプで嫌がらせされたとしか...
276:仕様書無しさん
07/09/04 07:59:50
>>275
1関数500行だから、何やっているのかわからなくて
レビューできなかったんじゃないか？
277:仕様書無しさん
07/09/04 09:39:35
長文読んでいただきありがとうございます
指示の大元は客
1関数500行を苦にするのは俺ぐらいで他の人は全員平気
なんで
>>274
かわいそうなのは俺ぐらい
新人もこういう書き方がプロなんだと思って育つ
>>275
意図は多分なし
少なくとも俺個人攻撃はなさそう
>>276
レビューなんかしない職場
仮にレビューなんかやったら
「お前のソースはあちこちに処理が飛ぶから読みにくい」
って俺が吊るし上げ食らうだろうけど
278:仕様書無しさん
07/09/04 09:49:48
職場を変えるか変わるかどっちかにしなきゃ。
まぁとりあえず頑張れ。
279:仕様書無しさん
07/09/04 09:54:37
頑張っては駄目だ
280:仕様書無しさん
07/09/04 10:00:11
だいたい完成後にコメントとはいえソースの変更を易々と受け入れるようなところは話にならない
281:仕様書無しさん
07/09/04 10:17:12
その話にならない会社が多いから話になる訳で･･･
282:仕様書無しさん
07/09/04 12:55:04
コメントの条件が
「そのコメントを見て同等の関数をかけること」
なら、>>272 が圧倒的有利なんだけど、
そういう理想論は残念ながら(業務の世界では)現実には即していないからな……。
500行の関数とかだと、関数名から動作の推定は厳しいだろうし
コメントも内容を全然表していないだろうしな…。
283:仕様書無しさん
07/09/04 13:23:35
#define IF if(
#define THEN ){
#define ELSE } else {
#define ELIF } else if (
#define FI ;}
#define BEGIN {
#define END }
#define SWITCH switch(
#define IN ){
#define ENDSW }
#define FOR for(
#define WHILE while(
#define DO ){
#define OD ;}
#define REP do_lbr
#define PER }while(
#define DONE );
#define LOOP for(;;){
#define POOL }
284:仕様書無しさん
07/09/04 13:27:47
ﾜﾗﾀ
285:仕様書無しさん
07/09/04 14:16:59
むりくり違う言語にしようとしてるのかｗｗｗ
286:仕様書無しさん
07/09/04 16:46:02
Steve Bourne キタコレ
287:仕様書無しさん
07/09/04 17:10:52
>>283
ベル研究所の人ですか?
288:283
07/09/04 17:32:23
ちっ、ばれちまったか。
289:仕様書無しさん
07/09/04 17:45:03
これか～。
URLﾘﾝｸ(www.kaimei.org)
Algolなんだね。みんな物知りだな。
290:仕様書無しさん
07/09/04 17:49:23
ん？もしかして、このプリプロセッサ使って
sh書いたの？うわー。
291:仕様書無しさん
07/09/04 20:28:15
>>283
こんな感じでC言語モドキのソースが大量生産されている職場とか普通にあるから困るw
292:仕様書無しさん
07/09/04 23:50:57
懐かしいな、このホンどこいっちゃったかな。
293:仕様書無しさん
07/09/05 00:04:42
#define MOD(M, N) (M-(int)(M/N)*N)
#define RAND(N) MOD(rand(), N)
#if 0
#define randn RAND
#else // MODが直るまでこっちを使え
int randn(int n)
{
int x;
do { x = RAND(n); } while (x >= n);
return x;
}
#endif
294:仕様書無しさん
07/09/05 01:15:00
>>293
直るまでといっても、randnの中でMODが使われてる気配。
295:仕様書無しさん
07/09/05 03:40:21
#defineの引数がかっこで囲まれてないから
優先順位が低い演算子がきたら項が分断されて、あぼん。
296:仕様書無しさん
07/09/05 12:31:57
MODなんて自作する必要あるん？
％じゃだめなんだろうか
297:仕様書無しさん
07/09/05 12:44:26
だめなんですよ。
298:仕様書無しさん
07/09/05 12:47:03
シェフのこだわりである。
299:仕様書無しさん
07/09/05 12:47:07
なぜに？
300:仕様書無しさん
07/09/05 14:54:02
レポーターはそう尋ねた。
301:仕様書無しさん
07/09/05 16:18:42
なぜに？ってベル研究所の人にも
いってやりたいよなw
302:仕様書無しさん
07/09/05 21:50:48
>>296
小数以下が欲しいんじゃない？
303:仕様書無しさん
07/09/05 21:59:58
modで少数以下？
304:仕様書無しさん
07/09/05 22:26:33
MODで小数って新しい概念だなぁ
305:仕様書無しさん
07/09/05 22:37:13
少数の何が新しいのかわからん俺に詳しく。
3.5 mod 2 = 1.5 とか普通だろ？
306:仕様書無しさん
07/09/05 22:52:39
>>305
VB6だと0が返ってくるんだぜ
307:仕様書無しさん
07/09/05 23:08:57
>305
それを小数以下というのか･･･
何だかなぁ(｡-_-｡)
308:仕様書無しさん
07/09/05 23:14:51
java で試したら、 3.5 % 2 == 1.5 だったよ。
309:仕様書無しさん
07/09/05 23:59:46
とはいえ、近似値である小数の剰余って使いにくそう
310:仕様書無しさん
07/09/06 00:32:45
mod本来の意味から外れててなんだか気持ち悪いです
311:仕様書無しさん
07/09/06 00:57:26
>>307
説明よろ
312:仕様書無しさん
07/09/06 05:49:43
小数点以下ならfmodでいいんじゃ？
313:仕様書無しさん
07/09/06 07:58:19
>>311
素直に「間違えました」って言えよｗ
314:仕様書無しさん
07/09/06 12:31:20
会社を辞めたいとは思わなかったが…
ある案件の障害対応で、カバレッジを通そうとした時、用意されたテストケースで
どうしても通らないところがあって、実際には業務的に通らないと判明した時、泣きたくなった。
更に、もう１個の修正対象ソースはそのソースのコピペな上に、今度はテストケースがコピペ。
おまけに、今度は通らなかったロジックを通す必要がある。
不審に思って以前にテストした担当者に聞いてみたら、
丸々のコピペだからかたっぽはテストしていないと判明orz
ええ、泣きながらテストケース作り直して全部通しましたとも。
あん時、顔は笑っていたけど、目に殺意が入っていたかも・・・
315:仕様書無しさん
07/09/06 15:47:36
>>313
316:仕様書無しさん
07/09/06 19:53:05
>>314
丸ごとコピペって。
鉄拳制裁したれ。
317:仕様書無しさん
07/09/06 20:25:19
>>316
そんなんで鉄拳制裁していた手がいくつあっても足りないな、うちの会社の場合。orz
318:仕様書無しさん
07/09/06 20:35:46
クロスカウンター方式を提案します。
一定期間ごとに実施すれば各期間で必要な手は最大でも一つでとても経済的です。
導入されてはいかがですか？
319:仕様書無しさん
07/09/06 22:03:32
テストケース
～～であることを確認する ○ ←レッツコピペ！！
～～
～～
～～
～～
320:仕様書無しさん
07/09/06 22:53:39
○×は面倒だからどうしてもコピペになっちゃうな
まだOKNGのほうがいい
321:仕様書無しさん
07/09/06 23:33:28
システム全体がフランケンシュタインを髣髴とさせるコピペばかりのソース
もちろんドキュメント一式も上記怪物の生まれ変わりのよう
現在も増改築の真っ最中
322:仕様書無しさん
07/09/07 00:27:31
で、ある日突然崩壊する。
323:仕様書無しさん
07/09/07 01:01:11
if (a == 0) hoge(); みたいなコードがあったら、
条件:a == 0 → 結果:hoge()をコールする
のように、コードそのまんまのテストケースを書くように指示されていたので、
言われたままに書いていたけど、バグの数も基準があって、バグが0だとまずいといわれた。
こんなテスト仕様書で、どうやってバグをだすんだよ。
324:仕様書無しさん
07/09/07 01:13:51
俺が昔やった方法を教えてやろう。
つ テスト仕様書にバグを含める
バグの発生率が２～５％程度にならないと、充分に試験ができていない、と見なす某大手
325:仕様書無しさん
07/09/07 01:19:45
>>324
>>323は、テスト仕様書も、コードと突き合わせながらレビューをして、それでOKをもらう必要があるので、
そのワザは使えません。
仕切ってる人が、単体テストの意味を取り違えてるとしか思えない…
326:仕様書無しさん
07/09/07 01:55:36
そういう事なら、その仕切ってる人がバグだな
327:仕様書無しさん
07/09/07 01:58:40
>>325
出来上がった成果物を信用していないというか、
ソースコード自体を信じてないみたいなテスト仕様書だな
328:仕様書無しさん
07/09/07 02:11:23
ソースコードをじゃなくてコンパイラとか言語そのものを信じてないんだと思うよ。
>>323じゃないけど
hoge = "test";
で「hoge変数に test という文字列が格納されていること」
みたいな試験項目を見たことあるから分かる
329:仕様書無しさん
07/09/07 05:44:10
ちょっとつきあった某社：「コンパイラを信じてなにかあったらどうするんだ？」って、
未だにASMオンリー。 しかもそれがルネサスとかじゃなく、LSIC80でさえも。
親分がJRじゃなければとっくにつぶれてるぞ。
330:仕様書無しさん
07/09/07 07:10:26
そこまで言うなら、
「アセンブラを信じてどうするんだ？ハンドアセンブルだろ....」
って言い返せよ。
331:仕様書無しさん
07/09/07 07:52:49
多分最適化でおかしくなっちゃうコードでも書いてるんだろ
332:仕様書無しさん
07/09/07 07:53:07
「機械を信じてどうするんだ！手で計算しろ！」
333:仕様書無しさん
07/09/07 08:15:09
ICなんか信用ならん
タイガーを使え！
334:仕様書無しさん
07/09/07 08:56:36
他人なんか信用するな！
頼れるのは己の力のみ！
335:仕様書無しさん
07/09/07 11:16:24
そこ、開発成果のリリースまでどれくらいかかってるんだろ？>>329
RADを要求される案件が多いので、VBやC#にどっぷりの漏れ。
ASMでどれほどのRADができるのか知りたい。
336:仕様書無しさん
07/09/07 11:27:54
どんな開発環境で作ってもプログラムは最終的に機械語になるわけで、
既存の開発環境でできる事は機械語と1対1対応できるアセンブラにできない事はない
337:仕様書無しさん
07/09/07 11:32:23
マ板でコスト無視な発言はイタイですよ
338:仕様書無しさん
07/09/07 20:57:07
どの板でもネタにマジレスは痛いんだぜ
339:仕様書無しさん
07/09/07 21:03:23
>>335
そんな馬鹿丸出しのことを言っているのは上の方だけで、現場では普通に
Cで開発、上には -S したアセンブリソースしか見せない、みたいな予感。
340:仕様書無しさん
07/09/07 21:24:07
>>327
そもそもそのソースが本当に仕様を満たしてるかどうかがわからんのに
なんでソースを中心にテストを作るのか
341:仕様書無しさん
07/09/07 21:52:59
きっと辞めたくなる会社の上司だな
342:仕様書無しさん
07/09/08 01:57:07
>323
どーしよーもない場合は
「テストケースを想定して、そこで見つかるようにわざとバグらせておく」
もうちょっと前向きな意図で、「ベバッグ」と称してそういうことをすることがある、らしい。201の鉄則本にあった。
この場合は……hoge();の前に;でも入れておくかな。
343:仕様書無しさん
07/09/08 02:46:38
それはコンパイル通らんような気が
344:仕様書無しさん
07/09/08 02:57:35
テストを別の人がする時には、テストする人をテストするバグを混ぜることもあるよね
境界条件の以下と未満を置きかえるような、まともにテストすれば必ず見つけられる簡単なバグ
ただ、バグを入れたことを忘れる俺のバグが問題なんだよな
345:仕様書無しさん
07/09/08 02:59:37
>>343
346:仕様書無しさん
07/09/08 03:10:31
>>344
故意バグ一覧.xls
作ろうぜ
347:仕様書無しさん
07/09/08 03:22:41
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| この 故意バグ一覧.xlsとはなにかね？
＼
￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣
∧＿∧ ／￣￣￣￣￣￣￣￣￣
（ ・ハ・） ∧ ∧ ＜ あ・・・いや・・・・
（ ⊃ ） (ﾟДﾟ；) ＼＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿
￣￣￣日∇￣＼|>>346 |＼
￣ ======= ＼
348:仕様書無しさん
07/09/08 03:55:38
仕様の正に要の部分がバグってる（別の案件のテスト中に見つけた）のに、
1年以上も、バグのまま動いてるプログラムがある。
テスト実績はすべてOKで残っている。
実質、業務では使っていない項目ということで、放置したままだ。。
349:仕様書無しさん
07/09/08 04:03:25
でもバグ一覧は作っておいたほうがいいな
報告済みかそうでないか分かるだけでも安心感が増す
350:仕様書無しさん
07/09/08 07:17:40
>>349
作るな！
バグ・トラッキング・システムを使え！
351:仕様書無しさん
07/09/08 09:21:30
おれ、バグ見つけるのも再現させるのも、そしてそれを直すのも得意なんだけど、
何故かみんなから嫌われてる...orz
352:仕様書無しさん
07/09/08 10:01:40
人には「自分とは異質なもの（自分に出来ないことをやっちゃう奴・
自分には理解できない話をする奴・自分の知らないことを知ってる奴）
を嫌ったり排除したりする」傾向があるからな...しかも馬鹿な野郎ほどその傾向が強い。
353:仕様書無しさん
07/09/08 10:07:29
その傾向に陥ってないか自問自答するのは容易じゃないよね．
354:仕様書無しさん
07/09/08 10:11:13
351じゃないけど、
バグ出しを続けた結果、そのシステムは作らなかったことになったことがあるな。
一つ直させると二つ壊れてくるというゴールドラッシュだったな。
355:仕様書無しさん
07/09/08 10:13:50
１つで２つならば少ないんじゃない？
少しでもいじるとシステムが動かなくなるのがデフォってのもあるわけで・・・
356:仕様書無しさん
07/09/08 12:10:28
>>350
開発部署で用意されてるBTSに入れてるんだけどさ、見てくれないし全部スルーされちゃうんだよね
357:仕様書無しさん
07/09/08 13:44:29
>>356
それはきっと
バグ
たっぷりで
際限が無い
からだよ
358:仕様書無しさん
07/09/09 00:46:34
>>350
でも結局報告するときは結局BTSからバグ一覧を作成することになる場合が多い希ガス。
csvとかで。
359:仕様書無しさん
07/09/09 01:12:28
>>358
なるよな。。
なんか紙で出てこないと不安らしい。
我慢できる限界がエクセルの一覧表。
しょうがないから、BTSのxmlからcsv吐き出すスクリプト組んだよ。。
余計な仕事させやがって。
360:仕様書無しさん
07/09/09 21:24:20
/*
if いふ
else えるす
while わほいる？
do どー
fopen ふぉーぷん
fread ふれっど
fwrite ふうらいと
fclose ふくろーず
*/
なにこのカンペ……
361:仕様書無しさん
07/09/09 21:34:42
>>360
答えが間違ってるカンペって・・・
362:仕様書無しさん
07/09/09 21:44:18
「わほいる？」に萌えた
語感がかわいい
わほいる
363:仕様書無しさん
07/09/09 21:52:48
微笑ましいが・・・・他所でやって欲しいな
364:仕様書無しさん
07/09/09 21:57:06
/* */
ってVC2005だと
行選択時の//の一括付加・削除のときに巻き込まれて /* → * になったりするから使いづらい
ゲイツ死ね
365:仕様書無しさん
07/09/09 22:11:42
/*横綱.c/*
#include <朝青龍.h>
366:仕様書無しさん
07/09/09 23:04:45
>>360
do どー
fclose ふくろーず (梟？)
がチョット好き
>>365
/* 横綱.c/* これコメントとして間違ってない？
下の行もコメントアウトしてるのか。
367:仕様書無しさん
07/09/09 23:10:27
どう見ても間違ってますw
368:仕様書無しさん
07/09/09 23:11:25
>>360
ふくろーずってバンドの名前みたいだなw
369:仕様書無しさん
07/09/09 23:15:17
きっと甲本ヒロト。
370:仕様書無しさん
07/09/10 08:52:15
ギリギリガガンガン
371:仕様書無しさん
07/09/10 20:03:31
ソースというよりmakefileなんだけど、
依存関係が間違ってるとか、は当然のごとくあり。
今日見たのは、
CFLAGS=
としてオプションも消しているのを見た。
コメント化してデフォルトを有効にすると、警告がでるわでるわ。
コンパイラを誤魔化すためにやってるんじゃないかと思った。
もともとバグのあるソースだし、表面的にでも動くように、見なかったことにしました。
(ほんとはバグも表面化してるけどw)
372:仕様書無しさん
07/09/10 20:45:49
今更だけど、なんで日本のソフトウェア業界ってこんなに壊滅的なの？
373:仕様書無しさん
07/09/10 20:52:39
どこの国も変わらんと思うぞ。
派手さでいえば米国の方が上だし。
374:仕様書無しさん
07/09/10 21:49:17
C言語で作ってあったプログラムで、makefileでヘッダの依存関係が無かったので
depend追加したら毎回全てのソースがコンパイルされるようになった。
なんでかな～、と思って調べてみたら、依存関係のトップにあるヘッダが
make時に毎回自動生成されてやがる。
こんなmake環境にした開発者、氏ね。
375:仕様書無しさん
07/09/11 00:24:58
>>373
米国の場合は、それを埋め合わせるセンスがあるんじゃないかと思ってる。
着眼点や、機能のまとめかたやUIの作りなどのセンス。
これがスマートだと、バグが判明しても、使い続けざるを得ないという気になってしまう。
376:仕様書無しさん
07/09/11 01:02:33
使い物にならない奴が志望してくるのがいかん。
大学で切り落とせ。
アホに単位をやるな。
377:仕様書無しさん
07/09/11 01:11:47
未経験者をいきなり実戦投入するとひどいのが出来上がる。
俺自身「今ならもっと上手く書けるのに」「あの時これを知ってれば」って思い出すことがある。
そんな自分と比べても、酷すぎるのが今の職場...orz
378:仕様書無しさん
07/09/11 01:36:06
>376
そこでFizzBuzzですよ
379:仕様書無しさん
07/09/11 01:36:10
新人が使えないのは仕方ないが
使えないベテランが沢山いる、不思議なこの業界
380:仕様書無しさん
07/09/11 02:01:54
>379
「ベテラン」というのが履歴書に書かれた経験年数に基づく呼称でないのなら
確かに不思議だが
381:仕様書無しさん
07/09/11 02:20:30
使えない奴は派遣するってことで
382:仕様書無しさん
07/09/11 03:57:18
>>374
正直makefileって規模でかいとよく分からなくなるのがデフォというか
新たな仕様にしてほしいぐらいだ
383:仕様書無しさん
07/09/11 07:23:02
>>382
ant使え、
384:仕様書無しさん
07/09/11 08:14:37
今のパソコンなら速いから、全コンパイルのbatでもすぐ終わるでしょ。
俺はmakeとbatと両方用意して、「makeを知らない保守者はbatでいいよ」と書き添えてる。
385:仕様書無しさん
07/09/11 08:15:57
扱うファイルが、100個ぐらいとか、依存関係がシンプルなものだけなら、makefile もまだ手軽で良いけどね。
それ以上で makefile 使ってるプロジェクトに関わると眩暈がするな。
世の中、もうちょっとマシなものが、いくらでもあるのによりによって makefile かよって。
386:仕様書無しさん
07/09/11 10:57:02
>>384
んなもん、規模や開発環境によるだろ
うちのプロジェクトはフルコンかけると2時間くらいかかるぞ
重要なヘッダが更新されると、すぐにフル逝っちまう orz
387:仕様書無しさん
07/09/11 12:20:57
ヘッダの切り分けがおかしいんだろ
388:仕様書無しさん
07/09/11 14:25:27
フルコン2時間って携帯？
規模に対して環境が貧相な現場って他に浮かばないんだけど
昔、入った携帯の現場で warning が10000超えたのは笑ろた
389:仕様書無しさん
07/09/11 18:31:45
少ねえ少ねえ
390:仕様書無しさん
07/09/11 21:10:04
コンパイルのバグか何かで、6万後半あたりでwarningの数が一旦0になったこともあったな。
391:仕様書無しさん
07/09/11 21:13:54
臨海値65535か 16bit unsigned
392:仕様書無しさん
07/09/11 21:19:13
コンパイラをバグらせるとは・・・
コンパイラ「想定の範囲外です・・・」
393:仕様書無しさん
07/09/11 21:19:35
臨海値
394:仕様書無しさん
07/09/11 21:20:05
むしろfloatで
395:仕様書無しさん
07/09/11 21:38:24
今はlong long があるじゃまいか！
396:仕様書無しさん
07/09/11 21:48:18
遊戯、もうやめて！
コンパイラの示す warning は既に臨海値よ！！
397:仕様書無しさん
07/09/11 21:59:07
const TYPE const*const&;
398:仕様書無しさん
07/09/11 22:33:15
/* index.html */
#html
head()
{
style;style.css
}
body()
{
test.
}
#html
399:仕様書無しさん
07/09/11 22:44:26
これは新しい言語
400:仕様書無しさん
07/09/12 03:34:02
#define head nanntoka
#define style kanntoka
#define css kanntoka
#define body foo
#define test bar
#include "index.html"
401:仕様書無しさん
07/09/12 09:09:54
#include "mychtml.h"
int main() {
html(
head(title("Test Page")),
body("Hello, world !!!<BR>\n")
);
}
402:仕様書無しさん
07/09/12 22:56:12
Const Arr = "a,b,c,d"
function aaa()
for i = lbound(split(arr,",")) to ubound(split(arr,","))
if split(arr,",")(i) = "a" then
aaa = split(arr,",")
end if
next
end function
こんなん
403:仕様書無しさん
07/09/12 23:09:30
>>402
splitやり過ぎってヤツですか。
404:仕様書無しさん
07/09/12 23:15:26
ソースコードがスパゲッティ！でもそんなの関係ねぇ！
405:仕様書無しさん
07/09/12 23:33:39
>>402
んんん！？なんだか見覚えがあるw
406:仕様書無しさん
07/09/12 23:50:26
>>402
これは素晴らしい無駄関数ですね
407:仕様書無しさん
07/09/13 00:26:45
これはあれだ、きっとsplit呼び出しの結果が全て同じだと判断して、
自動的に一回の呼び出しに纏めてくれる、素晴らしいコンパイラが存在するんだよ！
408:仕様書無しさん
07/09/13 00:29:07
それでも最適化なら・・・最適化ならきっとなんとかしてくれる・・・！！
409:仕様書無しさん
07/09/13 00:31:24
探すと本当にあるから困る
410:仕様書無しさん
07/09/13 00:33:19
最適化? こんぱいる?
くっふふふ
VBScriptというものは
ひとたび構文木にさえ解析されてしまえば
二度とは
二度とは
411:仕様書無しさん
07/09/13 00:56:55
スパゲティと申したか
412:仕様書無しさん
07/09/19 19:03:16
#ifndef Hoge
typedef struct tag_Hoge {
(略)
} Hoge;
#endif
え～っと。
413:仕様書無しさん
07/09/19 19:52:58
・・・きっとCは初めてなんだよ。
先週入門書を読み終わったばかりなんだ。
きっと、きっと・・・
414:仕様書無しさん
07/09/20 00:24:54
ifndefが嫌いだ
なんでifnodefじゃねぇんだ ややこしいよ
#if !definedのほうがマシだ。 どうせ多重防止とかだったらpragma onceで事足りるからいいけど
415:仕様書無しさん
07/09/20 16:09:26
>>412
そのソースの意図がさっぱりわからない。
#define と typedef を混同したのだろうか…
416:仕様書無しさん
07/09/20 18:13:33
>>414
リリース版を表すNDEBUGの方が…
標準に従うと、デバッグ版のみ有効にするのに
#ifndef NDEBUG
...
#endif
と否定が２回来て嫌な感じだ
結局可読性とかで _DEBUG が使うんだけどな
って脱線しすぎか。
417:仕様書無しさん
07/09/20 18:42:13
NDEBUGは<assert.h>が見るんだっけか。
418:仕様書無しさん
07/09/20 18:55:12
>>415
FAQ級の落とし穴らしい。
URLﾘﾝｸ(www.kouno.jp)
419:仕様書無しさん
07/09/20 19:52:18
そういうレベルが普通なのか？
420:仕様書無しさん
07/09/20 23:51:55
>>415,418
？？。何をやろうとしてるのかすらさっぱりわからんのだが・・。
421:仕様書無しさん
07/09/21 00:14:14
>>420
たぶん>>415の言うとおり#defineとtypedefを混同してるんだと思う。
・・・typedefを何回も呼ぶつもりなのか???
後から呼んだ方が有効になるなら、実害はなさそうだけど・・・
と思って試してみたら、さすがに名前が衝突してるってエラーが出た。
422:仕様書無しさん
07/09/21 00:19:15
「Hoge」がまだ定義されてなければtag_Hoge型の構造体としてHogeを定義、ってことだろう
何をしたいと思ったかは分かっても何に使うはさっぱりわからんw
423:仕様書無しさん
07/09/21 00:40:31
Hogeが定義済みだったときにどんな動作をするんだろうな
424:仕様書無しさん
07/09/21 03:36:09
なるほど、こういうレベルが普通なんだな……
425:仕様書無しさん
07/09/21 13:07:19
public String getErrorMessage() {
// TODO 自動生成されたメソッド・スタブ
return null;
}
426:仕様書無しさん
07/09/21 13:13:55
Cで継承とかしようってことかな。
#include "FooExt.h"
#ifndef FOO
#define FOO
typedef strcut foo{
method1,
method2,
}Foo;
#endif
で、FooExt.hとかで
typedef strcut foo{
method1,
method2,
method3,
}Foo;
#define FOO
とか。。
考え過ぎか？。
427:仕様書無しさん
07/09/21 21:15:10
>>425
？？？
・・・catchしたいのかなぁ・・・
428:仕様書無しさん
07/09/21 22:00:54
>>425 が何を言いたいのかさっぱりわからない
これってIDE(eclipse,netbeans,etc)で自動生成されたメソッドでしょ？
納品されたソースにこんなのがあったら嫌だけど、開発中なら腐る程あるよ
429:仕様書無しさん
07/09/21 22:20:59
private String errorMessage;
から自動生成されたのは分かるが戻り値がぬるぽ
430:仕様書無しさん
07/09/21 23:33:24
もう辞めた会社のソースだけど、何年も運用を続けてきたシステムの仕様変更があるからと、
俺も参加することになったときに、一月に現行処理のバグを200くらい報告したことがある。
仕様変更自体よりバグとりの時間の方が長い位だった。
そのためだけに一月くらい時間をもらえたのが幸運だったけど。
あと今の現場。JSPのソースが全部スクリプトレット。全部 out.println とかで書いてありやがる。
ほとんどCGI気分だっ。
431:仕様書無しさん
07/09/21 23:34:52
>>428
保守するコードを開いてみたらTODOだらけってのはよくある話。
432:仕様書無しさん
07/09/21 23:56:00
藤堂さんのおおいしょくばなんだね…
433:仕様書無しさん
07/09/23 01:39:37
手順書はsudoさんだらけだしな
434:仕様書無しさん
07/09/23 02:07:31
作業始めたら安藤さんのお世話になりっぱなしだ
435:仕様書無しさん
07/09/23 02:28:45
うちには後藤さんが多いから困る
436:仕様書無しさん
07/09/23 02:34:01
んなこたー知らねーよ
437:仕様書無しさん
07/09/23 02:48:43
三木だったり後藤だったりする
438:仕様書無しさん
07/09/23 02:53:17
// クローズ処理
if(rs != null){
rs.close();
rs = null;
}
（；＾ω＾）・・・
439:仕様書無しさん
07/09/23 02:59:31
>>438
あるいは正しいような気すらしてくる
440:仕様書無しさん
07/09/23 03:04:50
旧VBっぽいアレだな
441:仕様書無しさん
07/09/23 09:12:56
もうやめたけど前の会社
面接でC++が出来るかどうか聞かれて、出来ますと答えて入社。
引き継いだコードの cout を printf で書き直したらただの C になった。
442:仕様書無しさん
07/09/23 12:02:26
>>438
これはwindowsのリソース関係の処理？
windowsはよく知らないけど、きっと delete this; してるんだよ。そう願いたい。
443:仕様書無しさん
07/09/23 12:26:43
>>438
javaではよく見るな。
優先的にGCの対象にするためにわざと参照を外しているらしい
444:仕様書無しさん
07/09/23 12:42:49
>>443
インスタンス変数に持つとかアホな状況でなければ、変らないけどなー
445:仕様書無しさん
07/09/23 12:54:05
そうなんだけど、今のプロジェクトでは
必要でなくなった変数にはnullを入れるというコーディング規約
さらにハンガリアン記法も強制
定数名が60文字以上ある状態なのに80文字で折り返し強制
ほか多数
バカ（というか時代遅れ？）が上に立つとろくな事にならんという見本
446:仕様書無しさん
07/09/23 13:08:40
長くても分かりやすい名前をつけろというけどさ、
その上でコードは80文字で折り返せって言うのも訳が分からん話だな。
447:仕様書無しさん
07/09/23 13:22:07
>>445
なるほど、改善提案もできないコミュニケーション能力の欠如した引っ込み思案の自分を
棚上げしてこんなところで文句を垂れる君はバカではないんだw
448:仕様書無しさん
07/09/23 13:33:44
60文字の定数のどこが分かりやすいんだ？
449:仕様書無しさん
07/09/23 14:01:15
>>447
くされ基盤チーム乙ｗ
450:仕様書無しさん
07/09/23 14:06:28
>>447
お前はまずスレタイ読んだ方がいいな。
451:仕様書無しさん
07/09/23 14:32:22
CHogeClass::CHogeClass()
{
delete m_pPtr;
...
}
いきなりdelete。
リリースモードだと奇跡的に動くがデバッグモードだと動かない。
そこで、コードを修正するのではなく全員リリースモードだけで開発し始めた。
当然数ヵ月後僕はその会社にいなかった。
452:仕様書無しさん
07/09/23 14:40:01
>>451 直せよw
453:438
07/09/23 14:56:56
>>439 >>442 >>443 >>445
438です。
コメント部分が冗長すぎただけで、処理事態は問題はないです。
rs に null を入れるのは メモリ使用量の多いオブジェクトを、
早めにガーベージコレクションの対象にするためで
間違ってはいないと思います。
ただそれだけでした＞＜
454:仕様書無しさん
07/09/23 15:04:54
>>451-452
ﾜﾛﾀ
455:仕様書無しさん
07/09/23 15:06:41
>>453
コメントも別に冗長じゃないけど。
他の処理との兼ね合いで書いているだけでしょう？
//ここでクローズ処理してます。ガベコレ対策でnullいれとります。
//なにか問題でも？
とか書いてあったら冗長だけどな。
456:仕様書無しさん
07/09/23 15:10:16
無意味なコメントはよくあるよな。
// ストリームを開く。
public OutputStream openStream() {
...;
}
アホか。
457:仕様書無しさん
07/09/23 15:16:15
>>456
コメントを抽出するソフトとかあるんだけど、それは知らない？
458:仕様書無しさん
07/09/23 15:18:24
よーし、修正しちゃうぞ。
//! ストリームを開く。
public OutputStream openStream() {
...;
}
459:仕様書無しさん
07/09/23 15:34:48
>>455 >>457
SUNが提唱している、
「Java Code Conventions」
URLﾘﾝｸ(www.tcct.zaq.ne.jp)
＞コードの中に既に含まれている情報やコードから自明であるような情報を重複させることは避ける
に記載されているように、冗長なコメントは書くべきではないと私は考えます。
コメント自体は書けば書くほど可読性を下げます。
コメント無しで理解できるコードを目指すのがベストだと思っています。
（と、いってもまったくコメント無しでのコードを書くのも不可能でしょうけど）
ちなみにドキュメンテーションはまた別ですが。
460:仕様書無しさん
07/09/23 15:36:08
>>457
抽出して削除＆書き直しするの？
僕のばあいは、もともとソフト会社じゃないから、Delphi、shのスクリプト、C、C++、C#、JavaScript、MATLAB
、WindowsScriptとか、あとNastran等々みんな適当なコードが残ってる。
「お前出来るだろ」ってほとんどコメント無しでの糞コードでくるから、リファクタリングとかだけでも
「無理っす。無理っす。無理っす。」を連発してる。
てか、いろいろ言葉が通じない。みんな言葉が通じるだけましだよ。
461:仕様書無しさん
07/09/23 15:51:28
>>459
それは奢りだと思うよ。
誰でもコード読めるわけじゃないしね。
「このブロックでは、○○の処理をしています」って書いてある事で
とりあえず数十行が簡単に読み飛ばせるなら、その方が効率がいいのは自明。
あなたの理想は以心伝心っと同じで、まあある種ありえない理想だと思うよ。
それ言ったらドキュメントも折衝も要らないからね。
全ては「ソースみろ」で済む。
実際はそうあいかないよ。
462:仕様書無しさん
07/09/23 15:53:25
>>460
抽出してドキュメントを作る参考にするんだよ。
それで処理のサマリーが分かれば、読むときに楽でしょ？
仮に明日全く知らない言語の修正依頼が来たらどう？
適切なコメントがあったら、楽だと思わない？
言語の勉強をゼロから初めて、それからソース読むよりはさ。
463:仕様書無しさん
07/09/23 16:08:29
日本人で>>459を実践したい人には
「なでしこ」
ちょーお奨めです。
464:仕様書無しさん
07/09/23 16:09:36
>>437
「三木」って何？
465:仕様書無しさん
07/09/23 16:16:52
>>462
書いてること正しいと思うけど、
”言語を全く知らない人”を想定してコメントを書くって作業は（個人的に）勘弁して欲しい。
466:仕様書無しさん
07/09/23 16:22:27
>>465
だから、それがセンスとバランスなんだって。
//ファイルオープン
//読み込み
//整形
//出力
とかブロックごとにあったら、知らなくても概要は理解できるし、
知っている人にも（余程無能でなければ）邪魔にもならないでしょ。
全く知らない人に完璧に理解させるのは無理でも、手助けにはなる。
VBAとかExcelマクロも数えると、過去にやった言語は20くらいになるし、
極端に多いとも思わない。
ちょっとしたマクロの手直しのために、一からその言語の勉強やるのは厳しいしね。
コメント要らないなら、そもそも、除去なんて簡単にできるしね。
無いコメントを生成はできないけど。
467:459
07/09/23 16:22:30
>>461
私も、コメント無しで完全に理解できるコードは不可能だと思っています。
ただし、
「処理フローが明らかであるのにコメントを付けては、
品質が下がるだけでメリットがない」
ということを言いたかっただけです。
＞コメントは，コードの概観と，
＞コード自体からは読み取ることのできない付加的な情報を与えるものであるべきである．
この考えが伝わるつもりでレスしましたが、
文章が至らず誤解させてしまったようです。申し訳なかった。
468:仕様書無しさん
07/09/23 16:24:56
>>467
書いた側と読む側が非常に優秀ならコメントなしでも読めるよ。
そんで俺の言ってる必要なコードは、あなたの言っている「コードの概観」の話だしね。
「コメントがあるほど可読性さがる」ってのが間違いだって言うなら別にいんだけど。
469:仕様書無しさん
07/09/23 16:26:32
>>466
センスとバランスとかＳＥとは思えないアバウトな表現。
ＪＡＶＡ言語を知っているというのは、コードを読む上では必須でしょ。
言語を理解した上で
「スパゲティコードだからコメントつけないとわからん」
というならわかるけど。
君の理論だと、コメントの統一性が保たれない。
プロジェクトが始まる前に
このメソッドを使うときは コメントを付ける、つけないとか
全てのクラスに対して説明しなければいけない。
470:仕様書無しさん
07/09/23 16:31:33
こんなコードはコメントが必須（実話）
// foo に bar を代入し、計算結果をDBに格納する
public getPoo() {
// ながーいコード
}
471:仕様書無しさん
07/09/23 16:31:47
まぁ、見た限りだと
「ＪＡＶＡ初心者のためにコメントをつけて仕事を早く回す」か
「品質のために冗長なコメントはつけない」 の意見がわかれてるだけでしょ。
前者も後者も言い分はわかるけどね。
そもそも2人の目的からして違ってるから結論でないでしょ。
472:仕様書無しさん
07/09/23 16:32:42
おっと訂正。
// foo に bar を代入し、計算結果をDBに格納する
public void getPoo() {
// ながーいコード
}
473:仕様書無しさん
07/09/23 16:36:29
中小企業なら前者の考え（コーディングを早く終わらせてコスト削減）
大企業なら後者の考え （早く終わらせるよりも品質確保）
でいいじゃん。
474:仕様書無しさん
07/09/23 16:41:36
>>472
// foo に bar を代入し、計算結果をDBに格納する
public void getPoo() {
}
どこが get してるんだよｗｗ
475:仕様書無しさん
07/09/23 16:52:11
>>471
いや、その場合品質って何？って話だと思うけど。
よっぽど冗長じゃなきゃ読み飛ばせばすむコメントで品質さがるかな？
そこまでストイックに減らすのって正直自己満足の世界だと思うんだけど。
//このブロックで、先頭の不要行を削除
で10行さらっと読み飛ばせるコメントをつけないメリットの方が
大きいとは思えないな。
476:仕様書無しさん
07/09/23 16:54:34
別につけたくないならつけないでいいけどさ。
もっとも害なのは変なこだわりとか自己満足をおしつけて
「俺はこれが正しいと思う。だから全員これをやれ。
これ以外はクオリティが下がるのでダメだ」って奴だと思う。
真面目な話。
そしてそういう奴は大抵「いや、あんたそれ以前にマシなコード書いてよ」
って奴なんだよな。
自己満足と自己肯定ばっかりで、「いや、もしかしたらこっちの方がいいのかも」
とは少しも考えない。
俺は人に押しつけまではしないけどね。
477:仕様書無しさん
07/09/23 16:58:07
>>475
＞よっぽど冗長じゃなきゃ読み飛ばせばすむコメントで品質さがるかな？
下がるわ。コメント範囲の大小は関係ない。
478:仕様書無しさん
07/09/23 16:58:19
>>475に同意。
三行ごとにコメントがついてるとかの極端な話じゃなければ、ついてて良いと思う。
何事もないよりある方がマシ。
479:仕様書無しさん
07/09/23 16:58:59
>>476
だから、自己満足じゃなくて、Sunの規約に準じてるだけでしょ？
そこを無視するとかプログラム的にはありえんわ
480:仕様書無しさん
07/09/23 17:00:31
ま、sunの言う通りにやればいいんじゃないの？
とにかくsunが言うんだから間違いないよねぇｗ
481:仕様書無しさん
07/09/23 17:02:38
なでしこ使うんだ。
なでしこなら冗長なコメントなんか付けなくなる。
482:仕様書無しさん
07/09/23 17:02:47
ちなみにCOBOLでコード書く場合もsunの規約に従う必要あんのかな？
Java限定の話だったっけ？
483:仕様書無しさん
07/09/23 17:03:37
自分の理論で「これはこうあるべき」って書くから駄目なんでしょ。
自己流コーディングはよくないよ。
Sunの規約として用意されてるなら使うべきだし、
そのプロジェクトの規約として別な方法が記載されていたらそっちを優先すべき。
484:仕様書無しさん
07/09/23 17:04:43
>>483
プロジェクトの規約も使用言語も一切無視して、とにかく「コメントは少ない方がいい。
sunがいうんだから間違いない！！」ってキチガイさんに言ってやってくださいｗ
485:仕様書無しさん
07/09/23 17:05:51
>>482
COBOLはその言語に適した規約があるでしょ。
言語によって保守や拡張性に対する考え方も違うしね。
486:仕様書無しさん
07/09/23 17:07:07
>>485
だよね。
それを無視して「コメントは少ない方がいい！」ってほえてるのって馬鹿過ぎだよね。
いつからJavaの話になったんだか。
487:仕様書無しさん
07/09/23 17:07:19
>>479
488:仕様書無しさん
07/09/23 17:08:08
>>484
だからさ・・・
「プロジェクトの規約として別な方法が記載されていたらそっちを優先すべき」
って言ってるでしょ。
そりゃクライアントがそういう風に指定したらそっちを使うのが当たり前っしょ。
わざわざ指定されてるのに別な書き方してたら訴えられるそ。
おまえはどんなプロジェクトだろうと自己流コードをかいてりゃいいさ
489:仕様書無しさん
07/09/23 17:08:38
>>482
sunのガイドラインがどうこう言う前に、コボルは旧コードをコメントアウトして残すのを辞めれ。
490:仕様書無しさん
07/09/23 17:08:44
MSのハンガリアンマンセーに従ってた奴乙
491:仕様書無しさん
07/09/23 17:09:44
>>488
＞ だからさ・・・
＞ 「プロジェクトの規約として別な方法が記載されていたらそっちを優先すべき」
うん。
だから言っている内容を変更したわけだよね？
それって後付けだよね？
だとしたら、最初に言った「コメントは少ない方がいい」って間違えたんだよね？
492:仕様書無しさん
07/09/23 17:10:15
>>486
いや、>>485は君と対立してた俺なんだけど・・・
Javaの話してたんじゃないの？
そういうことならすまんかったわ。
あくまで俺のはJava限定の話ね。
493:仕様書無しさん
07/09/23 17:11:12
自分がコメントあったほうが読みやすいから、そうしてる
規約でダメなら渡すときにコメント全削除してやるからいいよ
494:仕様書無しさん
07/09/23 17:11:20
>>469
495:仕様書無しさん
07/09/23 17:11:50
>>492
そうか。
Java限定なんて前提は初めてだけど、君が前提を間違えていたと言う事ね。
なら仕方ない。
もっともJava限定でも当初の「コメントは少ない方が良い」って間違えているけどね。
プロジェクト規約の方が優先度高いんだから。
ま、今は理解したらしいけど、少なくとも最初は間違えて書いたのは事実だよ。
気をつけてねｗ
496:仕様書無しさん
07/09/23 17:12:43
>>493
天才児あらわるｗ
>>494
その前からJava前提で書いているよ。
そんな話どこにもなかったのにね。
497:仕様書無しさん
07/09/23 17:14:35
>>495
プロジェクトの規約に従うのは前提条件でしょ？
後付けで、
「プロジェクトとしてまったく異なる規約が存在しているとしたら？」
と言われても困るわ
そりゃ、どんな間違った書き方でも仕様でも、客が指定してきたら従うよ。
その点については君と同意。
ただし、特に指定されてないならSun準拠にしとけば間違いないでしょ。
ちなみに俺もいちいちほかの人の書いたものを指摘はしないけどね。
お金くれるなら別だけど。
498:仕様書無しさん
07/09/23 17:16:33
>>497
煩いバカだな。
499:発端
07/09/23 17:27:12
>>438 >>453 >>459 です。
私の書いたことが原因でスレが荒れてしまい申し訳ないです。
みなさんそれぞれの意見が聞けたことで大変勉強になりました。
このスレは好きなスレの一つなので、
上記の件については終わりということでお願いしますm(__)m
500:仕様書無しさん
07/09/23 17:30:40
流れていたときにリアルタイムで読んでなかったのでタイミングを逃したけど。
>>461
>誰でもコード読めるわけじゃないしね。
>「このブロックでは、○○の処理をしています」って書いてある事で
>とりあえず数十行が簡単に読み飛ばせるなら、その方が効率がいいのは自明。
○○を名前にしたメソッドに切り出す。
というのが定石で、Sunのなんたらってのも、そういうコーディングが前提かと。
まあ、我々はネイティブではないので
メソッド名でわかるコードを書くというのは現実的には敷居が高いが、
Javadoc をちゃんと書けばそれほど無茶な話でもないと思われ。
501:仕様書無しさん
07/09/23 17:31:25
悪いコメントの例 言語はC
int wrk_COUNTER1; /* カウンタ1 */
具体的な文言はともかくこのレベルのコメントが実在した。
どんな言語だろうとコレはさすがに....ていうか変数名からしてヤバい。
しかもコレグローバル変数なんだぜ！
ほかにも /*ファイルを開く */ /* 変数をインクリメント */
納品するソースを練習台にするなよorz
502:仕様書無しさん
07/09/23 17:45:08
ステートメントレベルコメントの問題は
・コードとコメントを同期させて管理していくのが手間
・コメントを付ける基準の統一が難しく、個々のコーダー任せになる
かな。
前者は関数レベルでも同じじゃないかと思うかもしれないけど、
関数レベルというのは設計段階で fix されているべきもので (少なくとも理屈では)
そこが頻繁に更新されるというのは、コメント以前に別の問題がある。
503:仕様書無しさん
07/09/23 18:48:23
コードの方をわけ分からなくすれば解決だぜ!
// ストリームを開く。
public T0000 F0000() {
...;
}
504:仕様書無しさん
07/09/23 19:25:43
>>503
天才
505:仕様書無しさん
07/09/23 19:28:41
>>503
本気であるので困る
// 検索結果を取得する
public D001_0012 F001_0012(I001_001 arg0) {
}
当然、Excelの管理台帳（笑）で管理される
506:仕様書無しさん
07/09/23 19:30:52
これはひどい・・・
507:仕様書無しさん
07/09/23 19:37:47
ちなみにサーバーサイドJavaだったんだが、表示するJSPも G001_002U.jspとかだぜ。
あわせてG001_002U.jsがそれぞれセットになっているからカオスすぐる
で、Gなんだが良く解らないから聞いてみたんだ。
「画面のGだろ、そんなことも解らないのか？」と怒られた(´・ω・`)
508:507
07/09/23 19:43:19
思い出せばもっと色々あったぞ。
・変数は全て文字列（当然DBも）
・親会社のバグだらけの怪しいフレームワーク強制
で、オチだったんだが、中国へのオフショア（笑）で夜逃げされた。
509:仕様書無しさん
07/09/23 19:44:07
なんというコボル脳…。
510:仕様書無しさん
07/09/23 19:44:49
画面のGとか凄すぎるﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
511:仕様書無しさん
07/09/23 19:51:09
printf("HelloWorld!!ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ\n");
512:507
07/09/23 19:51:11
もっと晒すぜ、ﾋｬﾎｰ
データ構造定義（笑）はこんな感じ
データ構造定義ID D001_0012
項目ID 長さ （中略） 備考
D001_0012_001 18 （中略） 商品ID（9桁）
513:仕様書無しさん
07/09/23 19:53:02
まぁアレだろ。Fだろ。
514:仕様書無しさん
07/09/23 19:55:53
Gって言ったらゴキブ
ぅゎぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁ
515:仕様書無しさん
07/09/23 19:56:44
>>513
残念。 N系
516:仕様書無しさん
07/09/23 19:57:23
誤： printf("HelloWorld!!ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ\n");
正： printf("HelloWorld!!\n");ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
517:仕様書無しさん
07/09/23 19:58:23
寿司食いたいﾌﾌﾌﾌﾌﾌﾌ
518:仕様書無しさん
07/09/23 20:04:09
printf(buf);
buf内に%sが入って死亡・・・・・・
519:仕様書無しさん
07/09/23 20:13:51
祭りに乗り遅れた・・・
520:仕様書無しさん
07/09/23 20:18:52
// ずっと俺のターン
while (1)
printf'("ﾌ");
521:仕様書無しさん
07/09/23 20:34:35
ガリでも食ってろﾌﾌﾌﾌﾌﾌﾌ
522:仕様書無しさん
07/09/24 02:20:45
G001_001？？？ってのは、
画面ＩＤをそのまま名前にしてるんなら保守はしやすいのかもしれん。
もちろん画面ＩＤがきっちり管理できてるのが前提だけど。
523:仕様書無しさん
07/09/24 02:33:26
>>522
おまえは設計するなよ！約束だぞ！
524:仕様書無しさん
07/09/24 02:40:18
ID項目それぞれに対する説明の文書なりpdfがあるんじゃないの
それなら分かる
525:仕様書無しさん
07/09/24 06:57:17
>>524
わかりやすい命名になってればその文書自体不要になるか、
大幅に簡略化できる。
なまじ素直な性格だと、
「業界の先輩たちが長いことやってることだから、なにかよいことがあるんだろう」
って思っちゃうんだよなあ…
昔々、ディレクトリというものが無く、
データ領域につける名前に大文字と数字6文字とか8文字とかしか
使えなかった時代の習慣を引きずってるだけなんだが。
526:仕様書無しさん
07/09/24 07:19:10
コボルのコメントってどう書くんだっけ。さすがに３８年も書いてないと忘れた。
527:仕様書無しさん
07/09/24 07:42:33
*
528:仕様書無しさん
07/09/24 09:31:28
きたねえ穴だな
529:仕様書無しさん
07/09/24 11:29:14
>>522
氏ね
せめて、ItemList_02.jsp とかある程度はまとめた上での連番にするべきだろ
530:仕様書無しさん
07/09/24 11:31:49
>526
行番号の直後の桁にアスタリスク
531:仕様書無しさん
07/09/24 11:57:25
>>530
きたねえ穴だな
532:仕様書無しさん
07/09/24 12:07:51
>>530
きたねえ穴だな // じつは入れたいと思っている気持ちの裏返しの発言
533:仕様書無しさん
07/09/24 12:48:06
// キーボードの状態を取得する
bool getKeyboardStatus()
{
//キーボードの状態がおかしい
if (status_ == RESPONSE_ERROR) {
// 投げる
throwKeyboard();
}
return status_;
}
みたいな名前と処理が一致しない関数が
山ほどあって気が抜けない (´Д｀;)
534:仕様書無しさん
07/09/24 12:49:29
>>533の返り値は気にしないで・・・。
535:仕様書無しさん
07/09/24 13:17:56
while (1)
{
int nRet;
nRet = 仕事();
if (nRet == ERROR)
{
int nMood = Get今の気持ち();
if (nMood == BUTIKIRE)
{
throwMouse();
throwKeyboard();
beatNeighbor();
quitJob();
break();
}
}
}
536:仕様書無しさん
07/09/24 13:47:47
while(辞めない) {
while (1)
{
int nRet;
nRet = 仕事();
if (nRet == ERROR)
{
int nMood = Get今の気持ち();
if (nMood == BUTIKIRE)
{
throwMouse();
throwKeyboard();
beatNeighbor();
quitJob();
break();
}
}
}
}
537:仕様書無しさん
07/09/24 14:02:06
>>536
＼ ∩─ｰ､
＼／ ● ､_ ｀ヽ
/ ＼( ● ● |つ
| X_入__ノ ミ 俺は釣られないクマ ･･･
､ (＿／ ノ
＼＿＿＿ノﾞ
／ 丶' ⌒ヽ:::
/ ヽ / /:::
/ /へ ヘ/ /:::
/ ＼ ヾミ /|:::
（__／| ＼___ノ/:::
538:526
07/09/24 17:28:31
>>530 ありがとです。
539:仕様書無しさん
07/09/24 17:30:27
プログラミングが上達するコツ
ｽﾚﾘﾝｸ(tech板)
540:仕様書無しさん
07/09/24 19:11:26
int mind;
mind = kokoro()
while (1)
{
mind -= 1;
if (mind < 0)
{
takeMedicine();
goHospital();
if (mind < 0)
{
quitJob;
break();
}
}
}
541:仕様書無しさん
07/09/24 20:42:13
>>540
これバグってるだろｗｗ
仕事してないのになんで mind-=1 なんだよ。
仕事しろ仕事ｗ
542:仕様書無しさん
07/09/24 20:50:48
>>540
Jobインターフェースが実装されてません。
java.neet.helloworkパッケージからインポートして実装してください
543:仕様書無しさん
07/09/24 21:02:35
NoSuchMethod : kokoro()
544:仕様書無しさん
07/09/24 21:14:18
今システムテストしてるソース群みてびっくりしたよ、
ぜんぜんエラーハンドリングしてないの
最近の奴らは戻り値とか関係なしか?
545:仕様書無しさん
07/09/24 21:21:29
俺は自分がデバッグする時楽するために
必ず戻り値のチェック入れてる
546:仕様書無しさん
07/09/24 21:21:51
レスをスルー
例外もスルー
547:仕様書無しさん
07/09/24 21:54:30
「この子画面処理中に異常が発生したらどうすべきか」全く書いてないから実装してあげませんw
548:仕様書無しさん
07/09/24 22:34:12
レスをスロー
例外もスロー
549:仕様書無しさん
07/09/24 23:26:52
まぁ、なんでもかんでもCatchすりゃいいって考えるのは厨だね。
本来どっかでバグがあってこけることでそのバグを見つけるかもしれないってのに
Catchして適当な処理したら、何年たっても見つからない可能性がある。
550:仕様書無しさん
07/09/24 23:27:57
catch 厨
551:仕様書無しさん
07/09/25 00:14:56
>>549
戻り値を監視しながら処理を進めるのが普通だと思ってたが
転職先ではエラー処理は書かないのが基本だった…
郷に入れ歯
552:仕様書無しさん
07/09/25 00:21:51
C系だとアサーションは入れるけど
結局リリース時には素通りだったりするよね
553:仕様書無しさん
07/09/25 00:22:00
>>551
お前が正しい。
554:仕様書無しさん
07/09/25 01:44:59
>>552
だったりと言うかリリースならアサーションはスルーされて当然じゃ？
555:仕様書無しさん
07/09/25 01:46:41
>>554
開発・テスト時に異常にならなければそれでOKじゃね？とエラー処理入れないままなパターン。
556:仕様書無しさん
07/09/25 02:02:11
たまに実行時エラーにアサーション入れたりする奴がいるから困る。
つか、リリースモードでリリースする、
っていう確約が何も無いのにアサーション入れたりする奴がいるけど、
全くもって正気かどうか疑いたくなる。
557:仕様書無しさん
07/09/25 02:37:16
>>556
リリース版で最終テストしてリリースするっていうのは、
ものすごく基本的な話なんじゃないのか?
世の中には、
『デバック版でしか動かないからそのままリリース』
という輩も居るらしいが…
558:仕様書無しさん
07/09/25 04:05:27
msvcrtd.dll（デバッグ版Cランタイム）は再配布禁止…らしいな。
559:仕様書無しさん
07/09/25 11:05:02
FILE1 とか RET2 とか…ソレは何のファイルなのか、どんな戻り値なのか。
辞めようとまでは思わないけどさ。
560:仕様書無しさん
07/09/25 14:13:53
ABAPで例外を拾おうとあくせくした日々が懐かしい。
そもそもまともに例外を拾う気の無いツールでそんなことするのは無駄だった。
561:仕様書無しさん
07/09/25 17:23:02
スレ無いから聞いてみるけど、"QAC"ってどうなの？
そこそこ使えるようだが俺的には hoge==TRUE を問題として検出しないツールはあまり信用できない。
(ほかにも=と==の間違い疑惑を指摘しなかったりとか）
で、うちの会社アホみたいにこのツールの出力結果を信奉している。
相当投資したみたいだから盲信したくなるのはわからないこともないがね。
562:仕様書無しさん
07/09/25 17:36:06
TRUE==hogeを俺は認めないぞ
可読性が著しく低下する。
そんなソースは書いたことがないぞ。
563:仕様書無しさん
07/09/25 18:11:03
TRUE==hogeってことは…TRUE値と、他の真の値を区別したい場合だよな、きっと？
564:仕様書無しさん
07/09/25 18:28:11
もしも真実がホゲだったなら...どうする!?
565:仕様書無しさん
07/09/25 19:03:55
QACを参考に修正したことなど一度も無いな。
開発内テストが終わった後にかけるので意味が無い。
というかこれユーザインタフェースが終わってる。
使いづらいったらありゃしない。
566:仕様書無しさん
07/09/25 21:14:29
・副作用がある
・定数として評価できる
567:仕様書無しさん
07/09/25 21:45:14
「hoge==TRUE」よか「=と==の間違い疑惑」のほうが重要じゃね？
後者に引っかからなくていいから前者に引っかかって欲しいの？
変数同士になっても有効なのは後者じゃ？
ま、どっちでもええか
568:仕様書無しさん
07/09/25 22:23:30
>>561
たぶん検出のための設定があると思うぞ。
569:仕様書無しさん
07/09/25 22:40:20
bool check(hoge){
bool TRUE;
if (hoge >= 0 && hoge <= 100){
TRUE = true;
} else {
TRUE = false;
}
return TRUE;
}
570:仕様書無しさん
07/09/25 22:41:03
うわすっげえむずむずするコード
571:仕様書無しさん
07/09/25 22:46:42
>>569
きもちわりぃｗ
定数左派の人って範囲チェックのときはどうかくの？
( 0 < hoge && 100 > hoge )ってなるのかな？
==の時だけ定数左？
572:仕様書無しさん
07/09/25 22:56:49
>>571のいる会社は大変だな
573:仕様書無しさん
07/09/25 22:59:25
for文書くときもやっぱ
for(int i=0;10>i;i++)
みたいに書くんだろうか？
574:仕様書無しさん
07/09/25 23:13:54
>>573
そういう人もいるよ。
575:仕様書無しさん
07/09/25 23:13:57
gccで動かしててC99仕様で書いてる。
QACにかけるとエラーだらけ。。
576:仕様書無しさん
07/09/25 23:19:08
C99はできる子。
577:仕様書無しさん
07/09/25 23:28:36
>>572
周りに定数左派がいないもんで、ちょいと疑問に思っただけなんだ。
578:仕様書無しさん
07/09/26 01:08:52
気分で左右を入れ替える俺は駄目人間だぜ
579:仕様書無しさん
07/09/26 01:20:07
統一感が無いのはいかんな
580:仕様書無しさん
07/09/26 05:33:49
i++ でも ++i でもいいときに
++i を使う人ってどれくらいいるかな
581:仕様書無しさん
07/09/26 07:40:44
そもそも++i 自体使わなければならない場面はゼロに近いし・・・
わんらいなー気取りで可読性を低くしているのに気付かないだけ
582:仕様書無しさん
07/09/26 08:31:40
「間」なんかは数学では ( 0<x<100 ) とか書くでしょ。だからｃでも ( 0<x && x<100 ) って書く。
583:仕様書無しさん
07/09/26 08:35:28
iteratorを進めるときは使うなぁ、++i。
584:仕様書無しさん
07/09/26 09:32:02
普通の組み込み型等なら後置、イテレータだったりオーバーロードされテルものだったら前置
585:仕様書無しさん
07/09/26 10:13:58
これはイテレータとか、区別するのも性能劣化も嫌だから、
どちらでも良いときは常に前置。
586:仕様書無しさん
07/09/26 10:19:44
同じく無駄な性能劣化は嫌だし、区別するのも面倒だから前置
最近の賢いコンパイラなら後置でも最適化で一時オブジェクトつくらずにやってくれるかもしれんが
587:仕様書無しさん
07/09/26 10:21:11
>そもそも++i 自体使わなければならない場面はゼロに近いし・・・
for (int i = 0; i < N; ++i) なんて頻出じゃないのか？
C#やJavaのforeach(相当)構文や、C++のgenericを使いまくるんなら別だが。
それでも数値インデックスが必要な場合は結構あると思うけど。
588:仕様書無しさん
07/09/26 10:30:55
性能劣化のは ++i より i++ が遅いってやつ？
589:仕様書無しさん
07/09/26 10:45:49
i++ はもとの i を返すために operator++ 内で一時オブジェクトを作るからな
int 程度だったら無視しても構わない劣化に過ぎないだろうが、
オブジェクト(よく使うのは iterator)のコピーなんてさせたらどれだけ劣化するか。
それが最適な構文なら、富豪的プログラムの観点からは問題無いんだが
i++ と ++i ってソースの可読性上は大した違いは無いから、
必要以上に自ら望んで劣化させる必要も無かろうと。
個人的には後置++ はあまり必要ないんだよな。
int j = i++;
とか書かれると一瞬思考が止まる。
漏れのアホな頭ではどうにも評価順が自然に解釈できないらしい。
590:仕様書無しさん
07/09/26 11:39:18
どうしても後置がいいっていうのは
array[ index++ ] = x;
みたいなときだな
591:仕様書無しさん
07/09/26 15:46:27
>>589
なるほど。
普段からjava使ってるから operator オーバライドの影響は頭から飛んでたわ。
++i 派から i++ に矯正された身でやんす。
592:仕様書無しさん
07/09/26 16:17:47
do {
} while( (++n)<(sizeof hoge) ) なんてよく書くから、けっこう使うな。
593:仕様書無しさん
07/09/26 16:22:29
for文でやれ
594:仕様書無しさん
07/09/26 17:10:37
forだと初期化のあとケツの判定に飛ぶのがｲﾔﾝ。初期化のあとに１回判定が入る展開もあったり。
do whileだと静的にも動的にもキレイ。
595:仕様書無しさん
07/09/26 23:39:18
なぜか俺の教育係だった人はfor文を嫌っていた。
俺が下についていたとき、ほとんどのループ処理をwhileで書いてた。
コメントを見ると”とりあえず”って言葉が多くて大丈夫かいな？って思ってた。
596:仕様書無しさん
07/09/26 23:45:22
そういわれるとforって異質かなという気がしてくる。
( ; ; )セミコロンが気に入らんとか？ｗ
597:仕様書無しさん
07/09/26 23:51:42
>>595
「とりあえず」は俺もよく使う。
検索とかに使うキーワードというか、いわばタグ的に。
統合開発環境のブックマーク機能を使えという話もあるが
作業ファイルをクリーンすると飛んでしまうこともあるから、と言い張って
俺様専用的に使わせてもらってる。
598:仕様書無しさん
07/09/26 23:54:47
「せっかくだから」とか使おうかしら
599:仕様書無しさん
07/09/27 00:11:19
某IDEに毒されたか、VBでも「' TODO:」ってやっちまう最近の俺
600:595
07/09/27 00:33:01
>>596
いやーなんでだろうね。いまだにわかんない。
今は管理役（≠管理職）になってるからコード書かなくなったから、
一緒に仕事することもほとんどないし。
そうそう、if文とかwhile文の後ろが処理1つで済むとき(nNum++とか)は
スコープは絶対につけないというこだわりも持ってた。
こんなことを新人の頃のコードレビューで何度指摘されたことか。。。
601:仕様書無しさん
07/09/27 00:34:02
なるべくforよりforeachを使うぜ！
perlはお呼びでない？そんな……
602:595
07/09/27 00:43:30
>>597
"とりあえず"ってコメントは､今となっては俺も使っちゃうんだけど､
今一緒に仕事してる人から
「問題見つけたときに直す気なのかなって思うと指摘しづらいし､
勝手に直していいのかもわからないからやめて」
っていわれたよ。
うちは検索キーワードはプロジェクト始まるときに､
各機能ごとに決められてそれ以外使えなくなるよ。
603:仕様書無しさん
07/09/27 01:22:17
"とりあえず"
"取り急ぎ"
"おそらくこれでOK"
"暫定"
604:仕様書無しさん
07/09/27 01:33:51
"やらなきゃいけない"
おまえがやれ
605:仕様書無しさん
07/09/27 02:39:57
"なぜか動くのでこのまま"
606:仕様書無しさん
07/09/27 02:43:33
"ここでぬるぽ発生の可能性あり"
607:仕様書無しさん
07/09/27 04:16:17
"後で書き直す"
…いつ？
608:仕様書無しさん
07/09/27 05:38:39
"怒涛のごとく改変"
609:仕様書無しさん
07/09/27 07:40:25
>>603
w
言われてみれば確かに使う
ずーっといつまでも「とりあえず」のままだなｗ