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
言われてみれば確かに使う
ずーっといつまでも「とりあえず」のままだなｗ
610:仕様書無しさん
07/09/27 08:24:59
"適当に埋めてみた"
書いた奴を土に埋めたくなる……
611:仕様書無しさん
07/09/27 09:18:24
コメントスレになっとるｗ
そういや、笑ったコメント晒すスレ落ちちゃったね
612:仕様書無しさん
07/09/27 10:39:22
建てようとしたら規制かかってたorz
613:仕様書無しさん
07/09/27 12:28:48
"俺はもうだめだ・・・あとは・・・頼む・・・ぞ・・・・"
614:仕様書無しさん
07/09/27 13:07:36
コメントスレ需要有るんなら立てよっか
615:仕様書無しさん
07/09/27 13:10:00
立てた
コメント関係はこっちでよろ
ｽﾚﾘﾝｸ(prog板)
616:仕様書無しさん
07/09/27 23:19:45
c++でさ。メンバ変数ってどれぐらい公開する？
１） 全て非公開private or protected
２） 状況によりけり
３） 全て公開 public
俺は今まで、３は有り得ないと思ってたんだけど、
どのソースも３ばっかなんだ。誰か何とかしてくれ……
617:仕様書無しさん
07/09/27 23:21:24
(1)のつもりで作る
流動的に(2)へ移行することもある
618:仕様書無しさん
07/09/27 23:22:55
C++じゃgetメソッドいっぱい作っても使いにくいだけだし
619:仕様書無しさん
07/09/27 23:30:41
俺のいる職場のjavaでかかれたコードは
public static だらけだよ。
public final static String sShopNo = "ShopNo"; とか言うのがズラーっと並んでて、
文字列連結の + でつないでSQL文をつくってる。
620:仕様書無しさん
07/09/27 23:32:50
(1)だろ
(2)だって可能な限り避ける
(3)は確かに辞めたくなる...
621:仕様書無しさん
07/09/27 23:35:14
全部公開ってstructじゃん
622:616
07/09/27 23:42:58
やっぱそうか……色々といいたいことはあるコードばっかなんだが、やっぱりそうなんだな。
あと、もう一つ気になるところがある。
この会社では、同じ処理を書くときに、一から書き直す風習があるんだわ。
これもどうかなぁ……って思ってしまうよ。
623:仕様書無しさん
07/09/27 23:45:38
コピペじゃなくて新しく書くってこと？
624:仕様書無しさん
07/09/27 23:58:18
>>623
イエス。全く処理内容が同じなのに、新しく書き起こしている。
理由がさっぱり分からん。
625:仕様書無しさん
07/09/28 00:02:08
ステップ数(笑)稼ぎ
626:仕様書無しさん
07/09/28 00:10:24
>624
版管理とは別な意味でソースコード管理が下手なのかも。
「自社のコード」を蓄積しないで、「顧客に納めるコード」ばかり書いていて
結果、別PJで書いたコードは流用できないから毎回フルスクラッチとか……
627:仕様書無しさん
07/09/28 00:23:02
>>624
元のコードに問題が見つかったとか。
少しでも改善出来る部分があったとか。
新人の練習台にしてるとか。
そうでもしないと余る人員がいるとか。
628:仕様書無しさん
07/09/28 00:23:09
>>626
正解かも……
あれだ。顧客に納めるで思ったんだが、ソース納品な案件があれば少しは変わるような気がしてきた。
まぁ、あんなコードは外部に見せられないけど……
629:仕様書無しさん
07/09/28 00:25:05
>>627
そういうんじゃないんだよ。
例えば、ログ出力処理があったとするだろ。
そしたら、ある場合はグローバル関数にかかれてたり、ある場合はクラス化されてたり、
ある場合はダイアログクラスのメンバ関数に埋め込まれていたり。DLLになってたり……
いや、全部同じ処理なんだぜ。全く……何回読んでもこぴぺで良いじゃんって思えるコードなんだぜ……
630:仕様書無しさん
07/09/28 00:26:39
おっと、途中で投げてしまった。
そんなだから、人員が余る・新人の練習以外は全て違うんだよ。
ちなみに、中途採用ばかりで新人もいない会社だから、その理由で新人の練習という理由もない。
いつも人員不足で悩んでるところだから、人員が余るもない。
631:仕様書無しさん
07/09/28 00:27:58
>>629
いや、そこはコピペじゃなくてＤＬＬでいいじゃんとかクラスでいいじゃんじゃないのか？
632:仕様書無しさん
07/09/28 00:31:53
>>631
そうなんだけどね。要はつまり、とにもかくにも再利用しないとこだと言いたかった。
633:仕様書無しさん
07/09/28 00:37:49
カプセル化って大原則だと思ってたが
案外、世の中には浸透してないのか？
カプセル化されてないソースを読むなんて神業だろ。
634:仕様書無しさん
07/09/28 00:45:24
>638
日本は神の国で八百万の神が、ってのはあながち嘘でもないってことか
あれを読む程度で神と言えるのなら……
635:仕様書無しさん
07/09/28 00:47:10
八百万ステップなら神
636:仕様書無しさん
07/09/28 00:50:19
ロギング処理がダイアログのメンバ関数。
プログラミングできない連中麦価なんじゃないか？ 単純に
637:仕様書無しさん
07/09/28 01:31:18
ダイアログごとにロガーがあるのか？
638:仕様書無しさん
07/09/28 01:33:21
ぬるぽ
639:仕様書無しさん
07/09/28 01:34:43
>>634はこの３文字からあれだけの情報量を読み取ったのか
640:仕様書無しさん
07/09/28 01:41:22
妄想が激しすぎるな
641:仕様書無しさん
07/09/28 02:01:37
上司 『こんなところでレス返してる暇があったら、もっとステップを稼げッ』
642:仕様書無しさん
07/09/28 02:50:46
ステップ♪ステップ♪ランランラン♪
643:仕様書無しさん
07/09/28 02:54:57
また1名旅立たれたようです
644:仕様書無しさん
07/09/28 21:49:46
「来週あたり各自宅のPCの検査いくんで」
これはない
645:仕様書無しさん
07/09/28 23:48:48
void reduce(int*number, int*denom){int a,b,tmp; a=abs(*numer);
b=abs(*denom); /*a>=bとなるように入れ替える*/ if(a<b){tmp=a; a=b;
b=tmp;} /*互除法で最大公約数を求める*/ do{tmp=a%b; a=b; b=tmp;}
while(b!=0); /*約分する*/ if(a>1){*numer/=a; *denom/=a;}}
実際は途中改行なしで1行1関数
最初見たときプロトタイプ宣言が並んでるのかと思ったら
関数定義だからびっくりしたわ
646:仕様書無しさん
07/09/29 00:06:49
そして、それらは全てコメントアウトされていた。ってオチとか
647:仕様書無しさん
07/09/29 00:33:46
>>644
winny関連？家庭訪問みたいでやだなｗ
648:仕様書無しさん
07/09/29 00:37:12
>>644
それは上司の自宅へも行くのか？
649:仕様書無しさん
07/09/29 02:17:23
hoge.asdf(fuga);
x
piyo.method();
果たして彼は x と書いてある行にあった文字列を切り取り出来たのであろうか・・・・。
650:仕様書無しさん
07/09/29 02:39:46
辞めようとは思わないソースだけどｗ
ってかコンパイル通らなくね？defineされてるとか？
651:仕様書無しさん
07/09/29 02:43:04
>>645 改行がアレだけど、中身は以外と、まともっぽい。
652:仕様書無しさん
07/09/29 03:12:53
>>557
亀レスだが、
Xbox360のバグまみれソフトだった、カ○ドセプトサー○がそうだったらしい。
なにしろ、Releaseビルドだと、起動すらしなかったとか。
冗談だろ・・・って言ったら、冗談じゃねぇ・・・と言われたときはさすがにあきれたねぇ。
ちなみに聞いた奴はあのバグまみれ騒動以来会社辞めたらしい。(そりゃそーだ)
653:仕様書無しさん
07/09/29 08:51:25
>>633
うちの職場でもそうなんだけど
世の中はカプセル化を否定する方向に向かっているよ
URLﾘﾝｸ(www.arclamp.jp)
654:仕様書無しさん
07/09/29 09:53:22
カプセル化不要な方向に進んでいるのはあるけど、データの分離は別の話だと思うが？
しかし、プログラマのレベルが低すぎるからこそカプセル化が必要なんだと思われ。
655:仕様書無しさん
07/09/29 10:57:57
>>653
世の中もなにもその記事だけじゃん。
URLﾘﾝｸ(capsctrl.que.jp)
656:仕様書無しさん
07/09/29 13:06:17
>>653
…つまらん。
657:仕様書無しさん
07/09/29 21:46:25
VBだが文字列の切り出しに何でもかんでもMid使ってる
Mid(str, 1, 1)……ってLeft知らんのかこいつは……
658:仕様書無しさん
07/09/29 21:51:13
てか、VBの場合ついLeft$, Mid$, Right$, String$って書いてしまうのは漏れだけか？
659:仕様書無しさん
07/09/29 22:08:31
ロートル
660:仕様書無しさん
07/09/29 22:44:57
>658
｢1｣が変数なら間違いとは思わんが、直値なら･･･
まぁいいか、VBならｗ
661:仕様書無しさん
07/09/29 22:51:57
$つけないとVariant型が返ってくるぜ
662:仕様書無しさん
07/09/29 23:02:41
>658
ﾉｼ
……でも元ソースが全体に$なしがはびこってたり
そもそも、「そんなに文字列と数値をごたまぜで扱いたいならPerlで書けよ」
って言いたくなるよーなのだと諦めて$なしで書くorz
String型で計算の時だけCCurかましてずーーーーっと数値保持してるのを見たときなんてもうね(つ´д｀;)
663:仕様書無しさん
07/09/29 23:02:59
今調べたんだけど Mid てステートメントもあるんだね。
664:仕様書無しさん
07/09/29 23:08:37
>>657
Leftって文字列を扱うクラス以外にもあったから
VB6みたいにLeft()って書いてもエラーになる
名前空間とクラス名を指定しないとダメだから
そいつは使えないと判断したんじゃね
665:仕様書無しさん
07/09/29 23:38:15
えーっと VB.NET？
666:仕様書無しさん
07/09/30 01:34:01
microsoft.visualbasicはいらんぜよ
667:仕様書無しさん
07/09/30 01:36:03
VS2005は無料版があるけど、インストールがﾏﾝﾄﾞｸｾｰから試してねぇな
仕事で使ったことも無いな
668:仕様書無しさん
07/09/30 02:00:25
VC6のときのPlatformSDKがほしい
669:仕様書無しさん
07/09/30 02:08:42
VSEE2008インスコしたけど・・・どうなの？
670:仕様書無しさん
07/09/30 02:45:19
>668
CD取り寄せできるお
Feb 2003がVS6対応最後のPlatformSDK
めりけんからの送料掛かるけどなorz
671:仕様書無しさん
07/09/30 09:23:37
>>662
VB6の本質はVariantだった。
それが理解できずに普通の型チェックを期待して四苦八苦した時期がありました・・・
672:仕様書無しさん
07/09/30 10:32:47
単発ならLeft$使うけど
周囲にMid$があるなら敢えてMid$統一しておく
VB6の案件は厨や新人にお鉢が回るかもしれんから
673:仕様書無しさん
07/09/30 10:42:44
>>657
そのレベルだとどっちでもいいと思うが・・・
どっちかってとあとは本人の好みの問題。
674:仕様書無しさん
07/09/30 13:18:33
Midが周囲で使われてるからって、leftをmidに直しても、何もいいことないだろ?
675:仕様書無しさん
07/09/30 13:54:25
可読性があがる
VBで開発する以上、低スキルな保守要員が宛てがわれる可能性は考えとくべきじゃね？
昨日HelloWorldした新人でも違いが解りやすいじゃん
676:仕様書無しさん
07/09/30 14:10:24
Mid(str, 1, 1) なんて書いてあると、何か意味があるのかと悩んでしまうな。
意味がわかるような関数を使おう。
似たような事例で、PEARに登録されているPHPのライブラリのひとつだが、
こんなん書いてあって意味がわからなかった。
substr_replace('string', 'replace', 0, 0);
関数の意味は名前のとおり、第三引数はstart、第四引数はlength
実際のコードは第一引数は文字列の配列だった。
677:仕様書無しさん
07/09/30 14:20:44
何か意味があるのかと悩む理由が解らんな
自作関数ならともかく。
678:仕様書無しさん
07/09/30 14:21:35
それはお前が何も考えて無いからだなｗ 低脳コーダー乙
679:仕様書無しさん
07/09/30 14:30:49
新人でも文字列操作関数ぐらい全部わかるだろｗ
680:仕様書無しさん
07/09/30 14:32:07
動けばどっちでもいいと思うけど。
くだらん
681:仕様書無しさん
07/09/30 14:52:47
>>644
ありえねぇーｗｗｗｗ
んなこと言うような企業は間違いなくDQN
682:仕様書無しさん
07/09/30 15:04:22
>>644
言われても嫌だが、ソースコードに書いてあっても嫌だな...
683:仕様書無しさん
07/09/30 15:30:55
>>680
仕事なら、動くだけじゃだめだろ。
684:仕様書無しさん
07/09/30 16:05:16
>>683
仕事なのに「動けばいい」「スパゲティだからってゼロから作り直すのは駄目」とか
それなのに「機能追加しろ」とか言われ、選手交代になった派遣社員が通りますよ…
685:仕様書無しさん
07/09/30 16:54:10
>>675
いや、可読性下がるんじゃね?
686:仕様書無しさん
07/09/30 16:57:46
leftとmidを混在させないで、midに統一したら読みやすくなるって説は、
leftとmidの機能を思い出しながら読むのが大変って意味か?
687:仕様書無しさん
07/09/30 17:19:45
固定長テキストファイルを読み出すときに、
Left$(str, 10)
Mid$(str, 11, 10)
～
Mid$(str, 101, 10)
とかずらずら書いて、一番上のLeft$をMid$にしたら、
引数の数もそろって綺麗なんじゃね？ って10秒くらい考えたけど、
ばかばかしいのでそのままテストをした覚えはある。
688:仕様書無しさん
07/09/30 17:25:28
あー位置が揃うとか、そういう意味か。
689:仕様書無しさん
07/09/30 17:30:08
この場合だったら
for i = 1 to 10
hoge(i) = mid$(str, i*10+1, 10)
next
とか書けばすっきりじゃね？
690:仕様書無しさん
07/09/30 17:53:27
若人の俺は、VBのファニー文字みたいな奴がよくわからん。
体型立てて勉強しようにも、そういった資料が少なくない？
691:仕様書無しさん
07/09/30 17:56:27
ファニー文字って、$とか%とか?
ヘルプに載ってるんじゃないの?
692:687
07/09/30 18:47:14
>>688
そういう意味で悩んだけど、可読性があがるとは今でも思わないな俺は。
>>689
昔のコードなんで覚えてないからてきとーに書いたんだけど、
文字長ばらばらで、forでまとめるわけには行かなかったと思った。
そうであって欲しい。 そうでなければ悲しすぎる。
693:仕様書無しさん
07/09/30 18:57:52
もし使ってる言語に、midやらsubstring相当の機能しかなかったら、leftやらrightやらって
ルーチンを自作して使う。
機能が限定されてるルーチンのほうが意図が伝わるから。
694:仕様書無しさん
07/09/30 19:19:42
顧客 「開発方法はLyeeとありますが？」
カテナ「はい。Lyeeです。」
顧客 「Lyeeとは何のことですか？」
カテナ「理論です。」
顧客 「え、理論？」
カテナ「はい。理論です。開発期間が従来の5分の1～10分の1です。」
顧客 「・・・で、そのLyeeは当社での開発で何のメリットがあるとお考えですか？」
カテナ「はい。設計もテストも不要です。」
顧客 「いや、そもそも設計やテストは貴社の担当です。それに設計書が無いのは不安ですね。」
カテナ「でも、業務知識がなくても開発可能ですよ。」
顧客 「いや、可能とかそういう問題じゃなくてですね・・・」
カテナ「ドキュメント量が100分の1ですよ。」
顧客 「ふざけないでください。それに100分の1って何ですか。だいたい…」
カテナ「1%です。保守資料無しとも考えられます。深層心理においては…」
顧客 「聞いてません。帰って下さい。」
カテナ「あれあれ？怒らせていいんですか？使いますよ。Lyee。」
顧客 「いいですよ。使って下さい。Lyeeとやらを。それで満足したら帰って下さい。」
カテナ「運がよかったな。今、撤退を決めたみたいだ。」
顧客 「帰れよ。」
695:仕様書無しさん
07/09/30 20:14:58
>>694
Lyeeでググってみたけど、ＵＭＬからソースコード生成するのと似たようなもん？
完全生成できたとしてもシステムテストとかはするよな、普通。
696:仕様書無しさん
07/09/30 21:58:53
思い出した！
VBで「こうやんないとうまく動かない」みたいな(正確には覚えてないけど)関数名があった。
コメントならまだしも、勘数名でこれとは...
697:仕様書無しさん
07/09/30 23:08:32
>>694
普通はこうなる。
顧客 「開発方法はLyeeとありますが？」
カテナ「はい。Lyeeです。」
顧客 「Lyeeとは何のことですか？」
カテナ「理論です。」
顧客 「え、理論？」
カテナ「はい。理論です。開発期間が従来の5分の1～10分の1です。」
顧客 「つまりその分開発費用も安くなると言うことですか。すばらしい。よし採用。けってーい。」
まあ、Lyeeなんてしらんがなｗ
698:仕様書無しさん
07/10/01 01:06:28
Lyeeって情報システム板でやたらスレが荒れてた記憶があるな。
699:仕様書無しさん
07/10/01 02:31:13
だってあれは・・・良く見てみれば。プリコンパイラにしか過ぎない。
700:仕様書無しさん
07/10/01 03:52:55
てｓｔ
701:仕様書無しさん
07/10/01 12:41:33
>>670
URLﾘﾝｸ(www.microsoft.com)
702:仕様書無しさん
07/10/01 21:10:18
>>670
>>701
スレ違いになってしまったけどサンクス
これでCPANの古めのモジュールがmakeできるかもしれん
703:仕様書無しさん
07/10/02 22:02:30
>>696
そういえばあの関数なぜかうまく動かないからその関数は自分で作ったよ。
傍から見たらライブラリにあるのになんで？って思われるだろうな。
704:仕様書無しさん
07/10/05 01:03:37
Cで関数定義の頭に概要の説明が書いてあるソースがあった。
/* -- 概要
共通ログ出力関数
呼び出し方法: void logfunc(int errcd, char *funcname);
引数:なし
戻り値:0:正常 -1:異常
*/
void outlog(int errcd, char *funcname)
{
...以下定義
もう一つ
/*
呼び出し方法: int func(void)
戻り値:0:正常 -1:異常
*/
void func(){/* 定義 */}
..で実際の呼び出し箇所にいくと
func("XXXX");
1つ2つならまだいいけど、万事がこんな感じ。コメントウソ書きすぎ。
わざとやってるんじゃないかと疑いたくなってくる。
705:仕様書無しさん
07/10/05 02:41:57
「苦肉の策」とか「後で修正しておくこと」とかもう諦めてるんだけど、
「苦肉の策！(笑)」とか「後で修正する必要アリ(´д｀)」とかになってるとマジ辛い。
昨日も昼ごろ似たようなコメント見つけて午後ずっと気分悪かった。
706:仕様書無しさん
07/10/05 09:18:07
気持ちに余裕がないのね
707:仕様書無しさん
07/10/05 09:34:42
URLﾘﾝｸ(www.atmarkit.co.jp)
どれを削除したらいいか判断できないような混沌としたプロジェクト
Ｃ＃ってこんなのが普通なのか？
708:仕様書無しさん
07/10/05 10:51:30
>>707
コーディング規約や開発者のコード管理能力の問題だろ。
C#に限らず、どんな言語を使ったって、混沌とさせる奴はいる。
それを解決できるツールがたまたま（同じ必要性を感じた）先人によって作られているか、
そんなツールを見つけられるかどうかで、問題を糊塗できるかどうかの違いだけだ。