この会社辞めようと思ったソースコード＃Ｅ

この会社辞めようと思ったソースコード。
プログラマとして幻滅するソースコード。
プログラマを悩ませるソースコード。
ぬるぽ。
をつらつらと綴っていって頂戴。

ちなみにここは質問スレじゃないので
技術的な質問がしたいならム板に逝って gets()。

2 ：仕様書無しさん：04/05/14 19:55

● 過去スレ
1：http://mentai.2ch.net/prog/kako/997/997104873.html
2：http://pc.2ch.net/prog/kako/1001/10010/1001076034.html
3：http://pc.2ch.net/prog/kako/1015/10158/1015861447.html
4：http://pc.2ch.net/prog/kako/1021/10215/1021560641.html
5：http://pc.2ch.net/prog/kako/1029/10291/1029120005.html
6：http://pc.2ch.net/prog/kako/1029/10291/1029120005.html
7：http://pc.2ch.net/prog/kako/1036/10367/1036779521.html
8：http://pc.2ch.net/test/read.cgi/prog/1040451049/ (dat落ち中)
9：http://pc.2ch.net/test/read.cgi/prog/1045401372/ (dat落ち中)
A：http://pc.2ch.net/test/read.cgi/prog/1049973793/ (dat落ち中)
B：http://pc.2ch.net/test/read.cgi/prog/1054362467/ (dat落ち中)
C：http://pc.2ch.net/test/read.cgi/prog/1067794604/ (dat落ち中)
D: http://pc5.2ch.net/test/read.cgi/prog/1077362207/

● 関連
この会社辞めようと思った上司の一言＃Ｆ
http://pc5.2ch.net/test/read.cgi/prog/1080728238/l50

3 ：仕様書無しさん：04/05/14 20:44

>>1　乙～

4 ：名無し＠沢村：04/05/14 20:46

おまいらよ、これ↓を色紙に墨汁で書いて、
社訓として壁に貼ってもらうよう、社長にお願いしろ！！

有名人・大会社社長………一流人
成功者・研究者……………エリート
管理職・渉外職……………できるやつ
ＳＥ・営業マン……………平均的社会人
ＰＧ…………………………ハナクソ厨
フリー・シェア作者………ウンコパンツ
教えて君……………………ウジパンツ

5 ：仕様書無しさん：04/05/14 21:56

>>1
乙～。

>>4
>教えて君……………………ウジパンツ
これは同意。

6 ：仕様書無しさん：04/05/14 22:34

>>1 ｶﾞｯ

7 ：仕様書無しさん：04/05/15 10:25

ある程度規模が大きいプロジェクトだと
クラス名やメソッド名、変数名をコード体系で命名し管理するのは一般的なのでしょうか？
新人のころはカルチャーショックを受けていましたが
たしかに何千ものクラスを扱うにはコード体系のほうが合理的なのかとも感じる。

AAAUp011001, AAAUp012013, AAAEx012999 クラスとか。
システム＋種別＋大分類＋中分類＋小分類で管理。

8 ：仕様書無しさん：04/05/15 10:34

Sunのコーディング規約は読んだか？
パッケージが何のためにあるか理解しとるか？

9 ：仕様書無しさん：04/05/15 10:36

それはインテリジェントコードと呼ばれるコボラ文化。虫唾が走る
名前の衝突を回避すべきなのはクラス名だけ
namespaceを使えば良いだけ

10 ：仕様書無しさん：04/05/15 10:49

>>7です。
>>8,>>9
あっ、これＣ＋＋です。
namespaceもコード体系になっています。

とにかくプロジェクトの規模が巨大で末端のプログラマは全体が見えません。

プロジェクト開始日が２０世紀です。まだ一度もリリースされていません。

11 ：仕様書無しさん：04/05/15 11:42

>>10
>プロジェクト開始日が２０世紀です。まだ一度もリリースされていません。

今までの給料は一体何処から湧いていたんだ？

12 ：仕様書無しさん：04/05/15 12:03

たぶん我々の税金から・・・

13 ：仕様書無しさん：04/05/15 12:22

そんな巨大プロジェクトなら名前バラしても君の正体は分からんから、どんなプロジェクトか言ってみ。

14 ：仕様書無しさん：04/05/15 14:59

5年以上も一度もリリースされることなく続くプロジェクトってありえないだろ。

15 ：仕様書無しさん：04/05/15 15:17

ゲーム開発では知ってるけどな。

16 ：仕様書無しさん：04/05/15 20:50

Σプロジェクト Ver2.0b って感じだな。

17 ：仕様書無しさん：04/05/15 20:50

>15
……雪?

18 ：仕様書無しさん：04/05/15 22:11

>>10
C++になったのに昔のやりかた以外考えられない糞COBOLerが体系決めたんだね
何に対して合理的なのかを冷静に考えよう

19 ：仕様書無しさん：04/05/16 09:11

俺んところもそういう感じ。

「経験豊富なSEが設計段階からきちんとやるんで大丈夫です」
経験豊富なのは旧システムのCOBOLの方で新システムで使うJavaは未経験ですかそうですか。

20 ：仕様書無しさん：04/05/16 22:57

結局はＣＯＢＯＬ。

21 ：仕様書無しさん：04/05/17 07:13

>>20
ﾈﾀだと分かっていても虫唾が走るッ

22 ：仕様書無しさん：04/05/17 13:59

ソースのコメントに、そのときの心境を書かないで下さい。
読んでてつらいです。

ついでに、AAもつけないで下さい。

23 ：仕様書無しさん：04/05/17 15:12

#Define { BEGIN
#Define } END

24 ：仕様書無しさん：04/05/17 17:08

arienai

25 ：仕様書無しさん：04/05/18 00:11

#define INTEGER int
#define CHARACTER char

26 ：仕様書無しさん：04/05/18 21:49

#define PIC9 int
#define PICX char
#define FILLER char

27 ：仕様書無しさん：04/05/18 22:03

#define ENTRY main

28 ：仕様書無しさん：04/05/18 22:19

コピペしてから修正したような類似のコードだらけ。
不必要な処理がいろんなところに入っている。
ひとつのファイルに詰め込んでいる。

でもソースコードだけなら、修正するだけで済むからまだいいほう。
前任者が、ろくに仕様を詰めず、いつまで経ってもできなかったという話しで、
途中でバトンタッチされたソースだから、ほとんどできていないのといっしょの状態。
もっと驚きなのは、その前任者が今もプロジェクトにかかわっていること。

いつ辞めようかいな。この4月に入社したばかりなんだけどね。

29 ：仕様書無しさん：04/05/19 00:12

public:
　　int m_flg;

30 ：仕様書無しさん：04/05/19 00:13

if(m_flg == 0) {
...

31 ：仕様書無しさん：04/05/19 00:25

Defint A-Z

32 ：仕様書無しさん：04/05/19 01:38

>>28
書きなおしを却下されたとき

33 ：仕様書無しさん：04/05/19 09:47

>>28
>前任者が、ろくに仕様を詰めず、いつまで経ってもできなかったという話しで、
>その前任者が今もプロジェクトにかかわっていること

こんな香具師が生き残ってる会社など、ろくな場所じゃない。
だが、今辞めるのは、君の経歴上、あまり得策じゃない。
２～３年がんばってから転職しな。
たぶん、その方が給料も上がる。

糞コードに呑まれないように気を付けてな。(w

34 ：仕様書無しさん：04/05/19 22:06

>>32-33
ありがとお。
でも俺、もうすぐ34歳だから転職は無理かもねｗ

35 ：仕様書無しさん：04/05/19 23:44

>>34 34歳

つ、つらいの～

36 ：仕様書無しさん：04/05/20 01:22

前スレがまだ 20 レス余ってるので埋めてくれ

37 ：仕様書無しさん：04/05/20 01:39

>36
981まで行ったからもうdat落ちしてるよ。

38 ：36：04/05/20 04:12

すまぬ、漏れが見ていたのは IE のキャッシュだったようだ。

39 ：33：04/05/20 10:56

>>34
ΩΩ　Ω＜な、なんだってー！

年下前提で書いていた自分に orz

40 ：仕様書無しさん：04/05/20 15:14

>>39
愚痴のレベルは新人並だからいいじゃん

41 ：32：04/05/20 16:08

どういう愚痴ならベテランレベルなんだか

>>34
よかった。年下だ
仕様を確定した後に、書きなおしをお勧めする。
修正するより書きなおししたほうが早いだろ？

42 ：仕様書無しさん：04/05/20 16:32

歳の差なんて関係ないさ

43 ：仕様書無しさん：04/05/20 17:40

13歳前後がストライクゾーン

44 ：仕様書無しさん：04/05/20 18:04

>>43
（・∀・）人（・∀・）ﾅｶｰﾏ!

45 ：仕様書無しさん：04/05/20 18:50

いや、15～17歳が

46 ：仕様書無しさん：04/05/20 20:45

いまとあるプロジェクトのメンテをしているんだが
定数宣言がいいかげんなんだよ

VB.NETなんだがDBからとってきた値をインデックス指定で取得しているんだが
まったく定数可されていないから激しくわかり難い

そのくせスプレッドのヘッダ文字列とかが変に定数化してあって笑える

SPD_COLUMN_22 = "番号"

みたいな

普通逆だろ

47 ：仕様書無しさん：04/05/20 22:38

病的システムの保守業務の担当者に任命されてしまった。

そのシステムでＲＤＢを使っているのですが異常者が作ったとしか思えない設計。
・テーブルをエクスプロ－ラのフォルダとファイルとして捉えている。
・テーブル管理テーブルを作り、無理矢理テーブルのツリー構造を作っている。
・プログラム内で create/drop table しまくっている。
・１テーブルに１件のデータ。

辞めたい。

48 ：仕様書無しさん：04/05/20 23:12

>>47
芸術的ですな

49 ：仕様書無しさん：04/05/20 23:15

>>47 御愁傷様。。

50 ：仕様書無しさん：04/05/20 23:23

なんかそこまでいくとある意味才能を感じるんだが
どうしてその発揮方法をまちがえてしまうんだろうか。

51 ：仕様書無しさん：04/05/20 23:34

そのシステム、見てみたいぞ

52 ：仕様書無しさん：04/05/20 23:39

> ・プログラム内で create/drop table しまくっている。
> ・１テーブルに１件のデータ。

ｲｲﾖｰｲｲﾖｰ
ｺｳﾊﾞｼｲﾖｰ

53 ：仕様書無しさん：04/05/20 23:44

きっと、前保守担当が心労で入院したか逃げたんだろうな。

54 ：仕様書無しさん：04/05/20 23:59

>>47
「やり過ぎ」を通り越してますなぁ。
すごいとは思うけど、あまり関わりたくない

55 ：仕様書無しさん：04/05/21 00:06

>>47
これが生命維持装置管理システムとかだったら激萌え。

つーか、逃げるしかないとおも。

56 ：仕様書無しさん：04/05/21 00:11

COBOLer が「ファイル設計」と称してRDBのテーブル定義をしているが、
やりたいのは>>47みたいなことなのかもしれない。

余談だがこないだ出てきたテーブル定義書がこんな感じだった。
レベル
01　　キー項目
　02　FooID　X
　02　BarID　X
02　　データ項目
　02　BazValue　9
　02　……

RDBだぞ。「レベル」って何だよ。

57 ：仕様書無しさん：04/05/21 00:42

>56
ちょうど今、それとよく似たテーブルを持つ不治痛製アプリ群をテストしてる。
一部全く動かずテストが進まねぇ…

58 ：仕様書無しさん：04/05/21 00:45

>>47
でもOracle Filesとやらを使うときに流す
Oracle提供スクリプトも
覗いてみるとそれと似たような動きだったぞ

59 ：仕様書無しさん：04/05/21 00:47

RDB側だけで全てをこなそうとしたときに陥りやすい現象ですな。

60 ：仕様書無しさん：04/05/21 01:17

>>56

テーブル一枚に無理やりツリー構造を放り込もうとしていたのでわ。
普通に良くある糞設計。

61 ：仕様書無しさん：04/05/21 01:39

>56
俺も不治痛の仕事でそういうのあったな。
Javaなのにデータ定義にレベルが書いてあって、
意味わからなくてかなり悩んだ。

62 ：仕様書無しさん：04/05/21 10:02

COBOLが生き残ってるのはまぁ良いとして。
COBOLしか理解できないｳﾞｧｶはさっさと氏ねよ。

63 ：仕様書無しさん：04/05/21 11:32

>>56
　　DATA DIVISION.
　　WORKING-STORAGE SECTION.
とか書いてない？ｗ

64 ：仕様書無しさん：04/05/21 21:11

巨大なクラスが１つしかないよ。メンバ変数／関数が大量。そのせいでコードヘルパ機能が重すぎ。

65 ：仕様書無しさん：04/05/21 21:57

常日頃「goto なんてぜってー使いたくねーよな !」といってる人間の
ソースを見た。
そしたら、

while (1) {

　　...

　　if (...) {
　　　　// エラー発生
　　　　break;
　　}

　　...

　　// 正常終了
　　break;
}

っていう記述が山のように...

この人は、goto によって処理の流れが汚くなるのがいやなんじゃなくって、
きっと goto という文字を見るとじんましんかなんかが出るから goto を
使わないようにしてるんだろうなって思った。

66 ：仕様書無しさん：04/05/21 22:04

ム板の「gotoを使う～」のスレを見てればよかったのにな。

67 ：仕様書無しさん：04/05/21 23:12

>>65
同じ香具師はおれの周りでもよく見かけるよ。

カッコイイから言ってるだけかとも疑うのだが、
この前すこしかわった別の言い方してる香具師に出会った。
「ほら！ここにgoto使ってるでしょ！！見てみて！」

見てどうするというのだろうか・・

68 ：仕様書無しさん：04/05/21 23:50

>>65
こんなのならよく書くけどなあ…ダメ？

BOOL result = TRUE;
while(result){
　result = dosomething();
}

...

BOOL dosomething(){
　//...
　if(...){
　　return TRUE;
　}
//...
　return FALSE;
}

69 ：仕様書無しさん：04/05/22 00:01

RESULT dosomething(){
　//...
　if(...){goto error;}
　//...
　if(){goto error;}
　//...
　return OK;

error:
handleError();
return NG;
}

こんなのも良く書くなあ…
goto何が何でもダメっておかしくない？
例えばC++やJavaなら例外使う場面で、gotoよく使うけどなあ･･･

70 ：仕様書無しさん：04/05/22 00:05

うちも while(1)＋break＋continue のスパゲッティプログラムに
悩まされてるよ。＿|￣|○

71 ：仕様書無しさん：04/05/22 00:12

>>69
>goto何が何でもダメっておかしくない？

禿同。
タコな使い方の goto なら「こんな事で goto 使うな！」と言いたくなるが、
使うべき所に使うのは問題ないかと。

72 ：仕様書無しさん：04/05/22 00:23

ダイクストラが「なにもgotoが絶対にダメだというわけじゃない」
と言ったって……みんな知ってるよな? な?

73 ：仕様書無しさん：04/05/22 00:38

do { } while(0); ならたまに使うことがあるな。
C++だと、goto 文の後で non-PODなクラスの自動変数の宣言が
できなかったりするし。

74 ：仕様書無しさん：04/05/22 00:43

getValue()って名前付けたら怒られた。
SYSF001ZA017()ってな感じの名前に書き換えさせられた。

75 ：仕様書無しさん：04/05/22 00:44

深いネストを関数に切り出すのは、リファクタリングの最初のインポ。

76 ：仕様書無しさん：04/05/22 00:49

>>74
(つд｀)･｡ﾟ･｡

77 ：仕様書無しさん：04/05/22 00:51

>>75
単体で使えない関数を無駄に作ってそうだな。

78 ：仕様書無しさん：04/05/22 00:54

>>77
外部に開かれないスコープであれば無問題。privateメソッドなんて
大抵そんなのﾊﾞｯｶ。

79 ：仕様書無しさん：04/05/22 01:08

>75
不能にしちゃダメだろ。

80 ：仕様書無しさん：04/05/22 01:38

>（大なり）と >=（大なりイコール）の使用禁止。
<（小なり）と <=（小なりイコール）で統一。

if (a >= 1 && a <= 100) // だめ！

if (1 <= a && a <= 100) // こう書け！

81 ：仕様書無しさん：04/05/22 01:48

>>80
個人でポリシーもってやるのはいいとして
他人に強制されたくないな。

82 ：仕様書無しさん：04/05/22 01:53

>>80
if (1 <= a && a <= 100)
という主張は何となくわかる気がする。

それよりもちょっと聞いてくれよ、うちで作ってる
自称「カスタマイズ性に優れたDBアクセスルーチン」ですよ。
メソッドが
void insert(String tablename, String key);
void update(String tablename, String columnname, String value);
void delete(String tablename, String key);
これ。例えば

INSERT INTO TheTable
(ID, NAME, INSERTDAY) VALUES
('A0001', 'この会社辞める', '2004/05/22)

を実現するには

insert("TheTable", "A0001");
update("TheTable", "NAME", "この会社辞める");
update("TheTable", "INSERTDAY", "2004/05/22");

こうしろと。ちなみに数値の列に数値扱いできない値を
updateした場合なんかのエラーは、呼んだ側からは
一切判定できないという諸刃の剣。
素人でなくともお勧めできない。

83 ：仕様書無しさん：04/05/22 02:05

>>82
NOT NULL制約が複数あるテーブルが使えないような気がするけど？

84 ：仕様書無しさん：04/05/22 02:45

>83
きっとそんなテーブルは「汎用的でない」から作らないんだよ(つ´д｀;)

85 ：仕様書無しさん：04/05/22 03:22

>>80
その規約作った人の気持ちも分からないではない。

個人的には右辺の値を基準に、
左辺の内容を評価するポリシーでやってるけど
>>80直感的に分かりやすそうだからこっちに変えようかよく悩む。

86 ：仕様書無しさん：04/05/22 08:57

>>80これ、上のほうが見やすいと思う人っているの？
とりあえず他人が見ることを考えたら下にするだろう。

漏れも（変数名が長いとかで）見にくくなる場合以外は下だな。
ただ、規約にまでするのは確かにどうかと思うけど。

87 ：82：04/05/22 09:10

updateは
void update(String tablename, String key, String columnname, String value);
で
update("TheTable", "A0001", "NAME", "この会社辞める");
の間違い。
で、もちろんNOT NULLなんて存在しません。
あと複数列でキーになるようなのも当然だめ。

88 ：仕様書無しさん：04/05/22 09:17

>>80
辞めようと思う程抵抗はないなぁ
言われたら「あーそうっすか気ｨ付けますｳｨｯｽ」ぐらい（←？）

ちなみにSQLerの先輩はbetween(var,min,max)な関数作ってたが
案外正解なのかも

89 ：へ：04/05/22 09:19

DBアクセスするのにいちいち共通関数つくる会社多そうですよね
DBサーバーの負荷は考えずに処理のモジュール化ばかりを考える
あまり長くなく負荷をあげないものならよいのですが
大規模になったらDB負荷でダウンしそうなプログラム
DBのパフォーマンスの勉強はしないのか

90 ：へ：04/05/22 09:33

まあ大規模なシステムを作っている会社なら
DBのパフォーマンスや整合性の方ほうを重視していると
思いますよ

91 ：仕様書無しさん：04/05/22 11:22

javadoc使用禁止。
自社製品のドキュメントジェネレータを使えと。
そのジェネレータが識別するための識別子をクラス名やメソッド名に埋め込めと。
識別子を入れ忘れたソースから生成したドキュメントを開くとコンパネが開く。
privateコンストラクタを使うとジェネレータがハングアップするから使用禁止。

こんなとこか。

92 ：仕様書無しさん：04/05/22 11:25

>91
ｽｹﾞｰ

93 ：仕様書無しさん：04/05/22 12:16

>>91
せめて、ジェネレータを直せよ!!
と、とりあえず突っ込みたくなるな。

94 ：仕様書無しさん：04/05/22 12:45

>>91
>識別子を入れ忘れたソースから生成したドキュメントを開くとコンパネが開く。

なんだよこれ・・・

95 ：仕様書無しさん：04/05/22 12:54

>>91です。
この自社製ドキュメントジェネレータ、Ｊａｖａ版で３３万円！
自社製のドキュメントビューワが付属。というかこれを使わないと見れません。

96 ：仕様書無しさん：04/05/22 14:56

>>82
１つのSQLで済むところを３つのSQLを実行するの？
動作がかなり遅くなるな。

うちみたいにソースの可読性よりも速度を優先するのも
作って保守する人間としては大変だけれど。

97 ：仕様書無しさん：04/05/22 17:11

>>91
>privateコンストラクタを使うとジェネレータがハングアップするから使用禁止。
Mathクラスのような、staticなメソッド群は作るなってことかｗ

98 ：仕様書無しさん：04/05/22 17:47

>>97
メソッドは public void 以外禁止の悪寒w

99 ：仕様書無しさん：04/05/22 18:37

引数の型は String[] の嵐ですか？

100 ：仕様書無しさん：04/05/22 18:43

>>95
そのドキュンメントジェネレーターとやらの売上額が知りたいものだ

101 ：仕様書無しさん：04/05/22 19:50

>>100
しゃないせにょうでそ。

102 ：仕様書無しさん：04/05/23 03:29

>101

>95 には「Java版33万円」と書いてある訳だが、社内専用のソフトに
価格がついているもんなの?
社内のほかの部署に売りつけるのか?
まぁ部署ごとに独立採算制の会社ならわからなくもないが。

103 ：仕様書無しさん：04/05/23 04:45

Javaで
private void xxx() throws IOException {
try {
なんか処理;
} catch (Exception e) {
throw new IOException()
}
}

だれだこんなソース書けって教えた香具師はよ。
全例外処理がこうなってた。鬱・・

104 ：仕様書無しさん：04/05/23 13:10

どっかのソース見て意味もわからず真似し続けることってよくある。
新人とかいる場合には、例外処理方針とか事前にちゃんと打ち合わせとけ。

105 ：仕様書無しさん：04/05/23 13:36

>>102
厳密な独立採算でなくても、部ごとに予算ってものがあるから。

まあ、社外にも販売しているけど、実質社内のみというやつじゃないのか?

106 ：仕様書無しさん：04/05/23 13:37

やめたくなる、というわけでもないのだが、おかしなソースを発見。

int
function(object_t *obj)
{
　　obj->name = "hoge";
　　memcpy(obj->foo, bar, sizeof(hage));

　　/* その他obj を使った一連の操作が続く.... */

assert(obj);/* !? */
return 1;
}

そのassertは何？

107 ：仕様書無しさん：04/05/23 14:26

operator bool()にすごい仕掛けが仕組んであるに一票。

108 ：仕様書無しさん：04/05/23 14:31

object_t* に operator bool() は無理だろ。

109 ：仕様書無しさん：04/05/23 15:13

多分、テンプレで最初にこんな関数を一括作成すんじゃない？

int
function(object_t *obj)
{
assert(obj);
return 1;
}

その後、担当者がしこしこコードを追加していく。
でもたまたまコードを書く場所を間違えちゃってassertの前に書いちゃったと。

110 ：仕様書無しさん：04/05/23 15:15

その他obj を使った一連の操作の途中でobjに間違って0を代入するのを
防ぐためｗ

111 ：仕様書無しさん：04/05/23 15:25

単にコピペミスに１００００assert

112 ：仕様書無しさん：04/05/23 15:38

>>109
たぶんそのパターン。

しかし、今見返したら同じパターンの関数が３か所。
まぁ、何も言わずに直しておいてやろうッと。
実は>>110が正解だったらやだなぁ。

あぁ、俺の休日はいづこへ…。

113 ：仕様書無しさん：04/05/23 16:21

>>112　まぁ、何も言わずに直しておいてやろうッと。

言ってやれよｗ

114 ：仕様書無しさん：04/05/23 20:35

VB6使ってんだけど、変数がすべてpublicで宣言されてて頭ｸﾗｸﾗ・・・
ちなみに後にﾒﾝﾃする香具師が分かりづらいと言う理由で、ｸﾗｽとか構造体とかは
極力使用禁止・・・

---
W_S_契約日 = 20040606 '' ←ここと
W_S_契約期間 = 204 '' ←ここに値を積んで

Call 契約満了日取得() ''←この関数を呼べば

Debug.Print W_S_契約満了日 ''←ここに値がセットされている
---

このほうが判りやすいじゃんと反論されてしまいますたが・・・

115 ：仕様書無しさん：04/05/23 20:42

>>114
ＶＢは関数に引数を渡せないし、戻り値も返せない言語だったんですね！
ところで反論した香具師が得意な言語は何？

116 ：仕様書無しさん：04/05/23 20:50

>>115
COBOLﾃﾞｽﾖ・・・

まあ、場合によってはpublicで宣言した方がいいｹｰｽもあるだろうけど。
ﾌﾟﾛｼﾞｪｸﾄ自体が「COBOLしか知らない人でも読めるVBｿｰｽ」で書くことがﾃｰﾏに
なってるという、冗談のようなﾌﾟﾛｼﾞｪｸﾄだから・・・

117 ：仕様書無しさん：04/05/23 20:54

/* ==== ここまで読んだ ==== */

118 ：仕様書無しさん：04/05/23 21:34

/****** 読む価値無かった ******/

119 ：仕様書無しさん：04/05/23 22:14

/*　ここから先はコメントです

120 ：仕様書無しさん：04/05/23 22:29

コメント終了です */
やめたくなるほどじゃないけどかなり脱力したソース。（Java）

for(int i = 0; i < hogeList.size(); i++){
　HashMap hogeMap = (HashMap) hogeList.get(i);

　String nanika = (String) ((HashMap)hogeList.get(i)).get("nanika");
　String doreka = (String) ((HashMap)hogeList.get(i)).get("doreka");
　（以下延々と続く）
}

Map の変数の立場は・・・。

121 ：仕様書無しさん：04/05/23 22:34

↑　きっと後で使おうと思ってたんだよ・・

オレが見た脱力系コード

void hage()
{
//* リリース時はこのコードを生かす*/ hogehoge();
/* デバッグ時はこっち */ hoge();
}

ってなコードがあった。リリース時にコード修正させんな・・・
どっちが生きてるかマジ分かりくい。

122 ：仕様書無しさん：04/05/23 23:51

if (A == VAL){
hoge(A);
}else if (A == VAL){
huga(A);
}else{
if (A == VAL){
return A;
}
}

123 ：仕様書無しさん：04/05/24 01:23

bool a = isA();
if (a == true) {
return true;
} else {
return false;
}

124 ：仕様書無しさん：04/05/24 19:58

もちろんネタだよね？

125 ：仕様書無しさん：04/05/24 20:43

ネタだとしたら質が悪い
きっと最初は後始末みたいな処理が書いてあったんだろ

126 ：仕様書無しさん：04/05/24 20:51

だとしてもなんでリファクタリング（という程度でもないが）しないんだよ、と

127 ：仕様書無しさん：04/05/25 01:06

>125
ネタでは無いと思う。
以前他人がそう書いているのをツッコミ入れたら、リーダー以下メンバー全員に
「こっちの方が見やすい」と言われ、以降それが規約になった。orz

128 ：仕様書無しさん：04/05/25 01:36

数こそ力か……
まぁ生㌔ > 127

129 ：123：04/05/25 22:02

ネタじゃない。
>>127おんなじ感じだな…

ちゅうか、後始末が入ってたとかそういうんじゃなく、
みんなとっても自然に普通にこんなふうに書くんだよ…

130 ：仕様書無しさん：04/05/25 22:37

>>127
>以前他人がそう書いているのをツッコミ入れたら、リーダー以下メンバー全員に
>「こっちの方が見やすい」と言われ、以降それが規約になった。orz

>>129
>みんなとっても自然に普通にこんなふうに書くんだよ…

ぐは、マジですか・・・
俺のグループでこんなん書くのがいたら、
「もう一回 C の入門書読んでこい !!」
っつーとこだぞ。

131 ：仕様書無しさん：04/05/25 23:22

行数稼ぎ方法にしても、低質だなぁ。
一行で済むところを六行も書いて。

132 ：123：04/05/25 23:34

>>131
なんというか、目的や意図があってこうしてるんじゃないところがみそだ。

133 ：仕様書無しさん：04/05/25 23:56

isA()がなにか例外を吐く可能性のあるときは1行目は書いたほうがいいことも・・
　
　
いや、ないな。

134 ：仕様書無しさん：04/05/26 00:34

boolean返す関数が例外なんか投げちゃいけません。めっ。

135 ：仕様書無しさん：04/05/26 01:18

>134
いかなる場合もtrue吐き出すより良いと思うのですが。
病んでますか？私

136 ：127：04/05/26 02:02

も一つネタ投下。
フツー for を使って書くようなコード（単純にn回ループとか）を、何故か while 使って
書いてるヤシがいたのでその理由を聞いたら、
「for は（式を横に並べて書くから）見にくくて嫌」
だとさ。

まぁ ; で区切る辺り、昔流行ったスパゲティコードを彷彿とさせるのかもしれんが。

137 ：仕様書無しさん：04/05/26 02:10

そういう新人がいたよ。そいつは言語教育担当にそういう刷り込みをされていたからだったんだが。
「反復回数が計算可能ならforを使え」って何度言ったことか・・・

138 ：仕様書無しさん：04/05/26 08:27

whileのほうがforより小さい。だから「中に入ることが確実」な場合に承知で使ったならエラいが
新人じゃ単に刷り込みだろね。

139 ：仕様書無しさん：04/05/26 12:45

>>123
もしこれが一つの関数なら、
この関数の存在自体が不要だな。

# 素直に isA() を呼べば最もわかりやすく、かつ短く済む

140 ：仕様書無しさん：04/05/26 13:06

>>139

private:
foo m_hoge;

bool a = m_hoge.isA();

これがサンプルの時点ではしょられたと思いたい…

141 ：仕様書無しさん：04/05/26 13:17

つかさ、この例の最大の問題って、
if (a == true)
この条件判断文じゃねーのか ?

142 ：仕様書無しさん：04/05/26 14:22

C++かC99なら問題ないんでない？

143 ：仕様書無しさん：04/05/26 17:17

>>138
「小さい」ってなにが?

144 ：仕様書無しさん：04/05/26 17:18

>>123
会社じゃないが、ついさっき同類を発見したばかりだ。
『C++ Builder6 コンポーネント活用ガイド&実践プログラミング vol.1』の252ページ。

void __fastcall TForm1::Panel1DragOver(TObject *Sender, TObject * Source,
　　　　int X, int Y, TDragState State, bool &Accept)
{
　　TLabel* theLabel = dynamic_cast<TLabel *>(Source);
　　if (theLabel != NULL) {
　　　　Accept = true;
　　} else {
　　　　Accept = false;
　　}
}

145 ：仕様書無しさん：04/05/26 17:41

>>144
これはぎりぎりセーフじゃないの？

Accept = theLavel != NULL;
はちょっと抵抗あるぞ
これぐらいなら最適化も効きそうだし

指摘個所は無駄な引数の方か？

146 ：仕様書無しさん：04/05/26 18:18

Accept = ( theLabel != NULL ) ? true : false;
とか
Accept = theLabel ? true : false;
では？

147 ：仕様書無しさん：04/05/26 19:12

>>146
やめてくれ

>>136
Iteratorは遅いから使わないほうがいい、て人ならいますが。

148 ：仕様書無しさん：04/05/26 19:39

>>144
同類なのか？
漏れには別物にしか見えないが・・・

149 ：146：04/05/26 20:16

>>147
やめない(w
>Iteratorは遅いから使わないほうがいい、て人ならいますが。
OOPL使っている人ばかりではないぞ

150 ：仕様書無しさん：04/05/26 21:11

>>147
イテレータが遅いわけがない。って、C++じゃあないのか？
# 遅いイテレータもあるが、遅いとゆより、しかたのないこと。
もっと明確に述べてくれたまい。

151 ：仕様書無しさん：04/05/26 21:15

ちゅーか遅いイテレータなんて使い道無いやん。

152 ：仕様書無しさん：04/05/26 21:16

あ、違った。遅いイテレータを持ったコンテナの使い道が無いのか。

153 ：仕様書無しさん：04/05/26 21:16

コードの話してるのに・・・
デザパタ厨は来るな！

154 ：仕様書無しさん：04/05/26 23:30

>153
いや、C++ STLのIteratorの話だと思うんだけど……
これがカタカナでイテレータ、と書いてたらRubyかなと思うんだが。

155 ：仕様書無しさん：04/05/27 00:32

どうでもいいがnamazu.orgが凄いことに……
ねらー以外にあの文字列の意味が分かる香具師いるのか?
それともまさかクラッ(((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

156 ：仕様書無しさん：04/05/27 02:12

>>155
ん？臨時メンテ中でorzになってますた。
何が有ったん？

157 ：仕様書無しさん：04/05/27 05:50

>>155
ﾜﾗﾀorz

158 ：仕様書無しさん：04/05/27 06:21

>>155-156
「Namazuの転機。鬱。」
だそうだ。

159 ：仕様書無しさん：04/05/27 14:53

　141,144 と他の人の論点がずれてて面白い。

　漏れも　if( theLabel )　で良いと思うけど、変数の型が解り易い様に比較対照を
明示しろっていう人もいるかも知れんな。

160 ：仕様書無しさん：04/05/28 01:52

>155
ｽﾗﾄﾞにﾊｯｸされたと書いてあったぞ。
も○ら組もﾔﾗﾚﾀとか。

161 ：仕様書無しさん：04/05/28 02:06

>160
あり。そうだったんか……
でも「orz」はマジダッタノネ(ﾟ∀ﾟ)ｱﾋｬ

162 ：仕様書無しさん：04/05/28 09:25

最近、ソースコードの保守ばかりの毎日にうんざりしています。
特異なソースコードのため得られるものも少ないです。
今は、ＣＯＢＯＬチックなＪａｖａやっています。
こんな状況下で仕事に対する面白さを見出すにはどうしたら良いでしょうか？

新規開発ばかりはないと思いますが。

163 ：仕様書無しさん：04/05/28 09:33

>>162
大変失礼だが、なぜそういううんざいするような仕事に回されるのかを
真剣に考えたほうがいい。

164 ：仕様書無しさん：04/05/28 10:14

うんざい
〔「有財餓鬼(うざいがき)」の略「有財」の転〕人をののしっていう語。まぬけ。

なるほど。勉強になりました。

165 ：仕様書無しさん：04/05/28 11:30

「ＣＯＢＯＬチックなＪａｖａ」増えそうな悪寒。

ttp://slashdot.jp/articles/04/05/26/029221.shtml?topic=89

166 ：仕様書無しさん：04/05/28 12:08

164=162なら、何故汚れ仕事を押し付けられるのか明快だなｗ

167 ：仕様書無しさん：04/05/28 16:26

会長様の顔写真が240*320ピクセルのサイズで
常に最前面表示される社内アプリ。

画面サイズが1024*768なので激しく邪魔。

168 ：仕様書無しさん：04/05/28 16:33

>>167
フリーソフトで最前面になっているのを非最前面に変えてしまえ。

169 ：仕様書無しさん：04/05/28 17:38

>167
竹藤？

170 ：仕様書無しさん：04/05/29 11:14

http://www.shochian.com/exclfc.htm
間違いだらけのExcel関数ヘルプ

171 ：仕様書無しさん：04/05/29 13:13

m_mode = 0;
if (...) m_mode = 1;
...
if (m_mode != 0){...}
else{...}

こんなソースがあった(インデントは略してる)

m_mode = 0;
if (...) m_mode = 1;
if (...) m_mode = 2;
...
switch(m_mode){
case 0:{...} break;
case 1:{...} break;
case 2:{...} break;
}

項目が増えたのでこう書き直した
でも、何度やってもcase 2にとばない
1日格闘した結果わかったこと
bool m_mode;

さらに、CVSで調べたら半年前の俺のソースだった…

172 ：仕様書無しさん：04/05/29 13:34

>>171
そんなに１日もかけるなよ。

173 ：仕様書無しさん：04/05/29 16:13

>>171
つーか、直した後のソースも最悪だな。
そういうのはジャンプテーブル使えば格段にスッキリする。

174 ：仕様書無しさん：04/05/29 17:01

>>171　乙ｗ

>>172-173

あ”～っ、最近はどいつもこいつも・・・

175 ：仕様書無しさん：04/05/29 17:46

>>171
「case 2にとばない」と思った時点でトレースできれば１０分で終わっただろうに。

176 ：仕様書無しさん：04/05/29 17:55

>>173
ジャンプテーブルってのが良くわからないんだが、
良ければやり方教えてくれ
C++って、ラベルを配列でもてるのか？

関数配列するとローカル変数参照できないし、
引数渡しだと、引数10個ぐらいくっつける羽目になるんだが

177 ：仕様書無しさん：04/05/29 18:04

関数ポインタ覚えたてで使ってみたいんだろ。
３分岐しかないのにジャンプテーブルね...

178 ：仕様書無しさん：04/05/29 18:13

173の発言は、switch文の存在自体を否定してるも同然

なのはいいとして

boolに0やら1やら入れるのがバグの原因だろ・・・

179 ：仕様書無しさん：04/05/29 20:50

>>177
ジャンプテーブルなんて簡単なのに、面倒くさがるあんたの思考の方がよくわかんねぇ。
条件増える度にソースコード増やすの？テーブル増やすだけの方が簡単に決まってるよ。

180 ：仕様書無しさん：04/05/29 20:53

つーか、ジャンプテーブルにするか、switchにするかは
ケースバイケースだと思われ。
switchでの処理の中身分からないと、どっちがいいなんていえないでしょ。

181 ：仕様書無しさん：04/05/29 20:53

>173は↓だろ。
http://pc5.2ch.net/test/read.cgi/prog/1067874379/831

182 ：173：04/05/29 21:07

ジャンプテーブルぐらい入門書に載ってそうなモンだけどなー。

int func1(void)
{
　return 0;
}
int func2(void)
{
　return 0;
}
int func3(void)
{
　return 0;
}

staticint (*func[])(void)=
{
　{func1},
　{func2},
　{func3},

};

で、iが1の時にfunc1()、iが2の時にfunc2()、iが3の時にfunc3()を呼びたければ

　 func[i]();

とするだけ。switchより簡単だろ？

183 ：仕様書無しさん：04/05/29 21:14

>>182
だから、そこまでコストかけてやるものなのかは、switchの中見ないと
なんとも言えないって話だよ。
分岐が数パターンのうえ、中身が数行、仕様が決定して将来分岐が
追加されることが無いってのだったら、そんなの大げさじゃん。

184 ：仕様書無しさん：04/05/29 21:18

念のために言っておくが
>>182は>>176へのレスだから

185 ：仕様書無しさん：04/05/29 21:18

え、あそうなの。ごめん。

186 ：仕様書無しさん：04/05/29 21:21

>>182
誰もジャンプテーブルの解説してくれとは言っとらんわ。

つーか、
> staticint (*func[])(void)=
> {
> 　{func1},
> 　{func2},
> 　{func3},
>
> };
>
> で、iが1の時にfunc1()、iが2の時にfunc2()、iが3の時にfunc3()を呼びたければ
>
> 　 func[i]();
思いっきり間違ってまんがな。

俺の周りにも似たようなのが居るな。
いわゆるデザインパターン厨って奴で、無意味にStateパターンとかを使いたがる。
でも、こういう凡ミスによるバグが多くて、使えねえ。

187 ：186：04/05/29 21:23

>>184
おお、すまん。
> 誰もジャンプテーブルの解説してくれとは言っとらんわ。
この部分については間違ってた。

188 ：173：04/05/29 21:25

>>186

あんた、スレ全然読んでないのな。

>>176を５００００回は読みなおせ。

189 ：仕様書無しさん：04/05/29 21:26

>>182
誰もそのジャンプテーブルがわからんなどとは言ってない…
難しいから使わないとも言ってない…

190 ：173：04/05/29 21:29

>>186
あのー、インデントのミスってswitchじゃ起きない、と電波な事が言いたいわけ？
インデント確かにミスったが、それがswitchを使ったせいか、ジャンプテーブルを使ったせいか。
オレには、ジャンプテーブルを使ったせい、などとは口が腐っても言えない。

あんたの脳内でとてもオモシロ電波な論理があって、switchではインデントミスが
１００％起きないってのなら、納得しないでもないが……そんな論理無いだろ？

アレルギー早く治して、公平に物事を見る目を養え。

191 ：仕様書無しさん：04/05/29 21:30

For i = 1 To 3
　If i = 1 Then
　処理１
　ElseIf i = 2 Then
　処理２
　ElseIf i = 3 Then
　処理３
　End If
Next

だれか何がしたいのか教えてくれ…

192 ：173：04/05/29 21:30

>>189
オマエも>>176を読みなおせ。

193 ：仕様書無しさん：04/05/29 21:30

switch 文内の case の分布の仕方を見て実質ジャンプテーブルに
展開するくらいは、今日びのコンパイラは普通にやりますが。

194 ：仕様書無しさん：04/05/29 21:32

>>193
それこそ誰も言ってない……

195 ：仕様書無しさん：04/05/29 21:32

つか、switch 文って、もともとその実装の詳細をコンパイラに委ねて、
それをジャンプテーブルにした方が良さげな時には、コンパイラがちゃんと
ジャンプテーブルを作ってくれる、という事を期待して書くものじゃないのか？

196 ：仕様書無しさん：04/05/29 21:33

>>184
>>176の後半2行へはレスしないんか？

197 ：仕様書無しさん：04/05/29 21:33

>>176
ちなみにC++のクラスのラベルのジャンプテーブルに関する記述はここ。
http://hp.vector.co.jp/authors/VA009797/script/r02.html
かなり簡潔なコードが公開されとります。

198 ：仕様書無しさん：04/05/29 21:34

>>196
>>197見れ

199 ：仕様書無しさん：04/05/29 21:34

>>190
インデントミスではないと思われ

200 ：仕様書無しさん：04/05/29 21:35

>>192
オマエも>>176読み直して、後半2行の答えてやれ

201 ：仕様書無しさん：04/05/29 21:35

>>192
おまえが読み直せ！！

202 ：仕様書無しさん：04/05/29 21:36

>>199
今、試しにDigital Mars C/C++ Compilersでコンパイルしてみたが、
staticintのtypoと、インデントミス以外はちゃんと動いてるみたいだけど……
どこがミスってるの？

203 ：仕様書無しさん：04/05/29 21:37

>>200-201
>>197を見れ

204 ：仕様書無しさん：04/05/29 21:38

つか、関数テーブルにこだわるだけでswitchの使いどころを
しらない原理主義者は、相手にする必要なし。無視スレ。

205 ：仕様書無しさん：04/05/29 21:38

>>202
> で、iが1の時にfunc1()、iが2の時にfunc2()、iが3の時にfunc3()を呼びたければ
>
> 　 func[i]();

206 ：仕様書無しさん：04/05/29 21:39

>>195
普通、どう展開されるのかを気にするより、ソースコードの量及び可読性、メンテナンスのしやすさを論じるのでは

207 ：仕様書無しさん：04/05/29 21:40

switch 使った方が妥当だと思われるケース。

　switch( n ){
　　case HOGE: case MOGE:
　　　hoge( n );
　　　break;
　　case SAGE:
　　　sage( n );
　　　break;
　}

こーいうのをジャンプテーブルで書くと、イマイチ美しくない。

208 ：仕様書無しさん：04/05/29 21:40

>>203
>>182の書き込みに対していってるんだが…

209 ：仕様書無しさん：04/05/29 21:40

>>205
インデントミスをインデックスミスと読み替えてやろうよ……

210 ：207：04/05/29 21:42

訂正。
sage(n) -> sage( );

211 ：186：04/05/29 21:42

>>182
まだわからんのか?
> で、iが1の時にfunc1()、iが2の時にfunc2()、iが3の時にfunc3()を呼びたければ
> 　 func[i]();
iが0のときはどうなるんだ?

つーか、iが-1や999のときに～を実行したい、なんて要求がきたらどうするつもりだ?

俺的には、>>171のコードは
#define M_MODE_HOGE 0
#define M_MODE_FUGA 1
#define M_MODE_PIYO 2

...

switch(m_mode){
case M_MODE_HOGE:{...} break;
case M_MODE_FUGA:{...} break;
case M_MODE_PIYO:{...} break;
}
としておけば十分だと思う。

212 ：205：04/05/29 21:42

あほでした。逝ってきまつorz

213 ：仕様書無しさん：04/05/29 21:42

思いっきりスレ違いな論議してる時点で、両者逝って良しなワケだが

214 ：仕様書無しさん：04/05/29 21:44

>>191
俺も見たことある。

215 ：仕様書無しさん：04/05/29 21:44

>>206

>>195 の論拠
・case の後には定数しか書けない
・break キーワードを書かなければ、下に落ちてしまう
これらは明らかにジャンプテーブルに展開することを意識した仕様となっていると思うが・・・

ただ、条件の種類や数によって、それを展開すべきか否かが変わってくるので
どちらの状況にも効率よく対応できる switch が出来た、と。

216 ：仕様書無しさん：04/05/29 21:46

>>186
定数と関数のポインタを持ったstructを組んだりするのは、組み込み系では良くある事なんだが……
switch文がそれこそ10000行になったりしてメンテできなくなるんだよね、それ……

217 ：仕様書無しさん：04/05/29 21:48

多分>>173は組み込み系か、石の制御か、そこらの仕事をよくしてるんじゃないか、と。
switchより早いし、分岐が多くなるとswitchはメンテできなくなるしね。
最初から分岐の処理は関数化しておくのが定石な分野も多いし

218 ：仕様書無しさん：04/05/29 21:51

T_FUNC_TABLE funcTable[]={
/* KEY,PARA1,PARA2,func()*/
{ "ABC",C_PARA_1,C_PARA_2,func1},
:
:
}

というソースなら、交換機の世界ではデフォで使われてたりするな。

219 ：186：04/05/29 21:54

>>216
誰もジャンプテーブルを*絶対に*使うなとは言っとらんわ。
盲目的に「～は使うな、～を使え」なんてことを言うな、と指摘してるだけだ。
何事も適材適所。

で、>>171のソースだけ見て「switchは使うな、ジャンプテーブルを使え」なんて
言うのはナンセンスだと漏れは言ってるんだ。

220 ：仕様書無しさん：04/05/29 21:55

5桁の乱数を作る処理

For i = 1 To 5
　乱数ジェネレータをシステムタイマ値で初期化
　a = a + CInt(Rnd * 9) 　'　aは文字列変数
Next
r = Val(a)　'　文字列のaを数値に変換
同じ乱数が出来てたら最初から繰り返し

どうにかしてくれ…

221 ：仕様書無しさん：04/05/29 21:56

>>215
>ただ、条件の種類や数によって、それを展開すべきか否かが変わってくるので
>どちらの状況にも効率よく対応できる switch が出来た、と。

うーん、条件の数が変わるならジャンプテーブルの方が柔軟な気が……

キーが２つのジャンプテーブル

for( i=0 ; i<sizeof(funcTable)/sizeof(funcTable[0]) ; i++ ){
　if( funcTable[i].para1 == para1 && funcTable[i].para2 == para2 ){
　　funcTable[i].func();
　　return S_OK;
　}
}
return S_NG; //見つからなかったYO!

キーが１つの場合の楽なコーディング方法の為にswitchが生まれた、という事なら判るが、柔軟なのはジャンプテーブルだな。

222 ：仕様書無しさん：04/05/29 21:58

>>219
>誰もジャンプテーブルを*絶対に*使うなとは言っとらんわ。
>盲目的に「～は使うな、～を使え」なんてことを言うな、と指摘してるだけだ。
そう書いてあるように見えないです

-1とか999とかの反論なら、>>221で出来てるのでは。

223 ：仕様書無しさん：04/05/29 22:04

だれもできるか出来ないかの話はしてないと思われ…

いや、-1とかの話があったからしてないわけではないんだが
突っ込みの大本はそこではないというのは分かると思うが…

224 ：仕様書無しさん：04/05/29 22:04

>>220
それちゃんと動くのか？

225 ：仕様書無しさん：04/05/29 22:05

そのうち、条件分岐もジャンプテーブルっていいそ

226 ：仕様書無しさん：04/05/29 22:06

>>220
多分、恐ろしいほど正確な分布の乱数を取りたかったのかな。

見るに５桁の乱数をとりたいんだろうけど、

a = (int)(Rnd/100000);

とすると、intの最大値を2^32と仮定すると
4294967296
で
67296以上の数が出てくる確率が、他の数字よりも1/42949だけ少ない。

……ってRnd使ってる時点で、精度なんてアテにならん……

227 ：仕様書無しさん：04/05/29 22:08

>>221
違う。
例えば、キーが２個から３個に変わることは頻繁にある。
その時、
「今まで２個だったから if を使っていたけど、
３個だと（このプロセッサ上では）テーブルにすれば１命令分得するから、
実装方法をテーブルに変更しよう」
なんて馬鹿なことをやらない為だ。

228 ：186：04/05/29 22:09

>>222
> >誰もジャンプテーブルを*絶対に*使うなとは言っとらんわ。
> >盲目的に「～は使うな、～を使え」なんてことを言うな、と指摘してるだけだ。
> そう書いてあるように見えないです

そうか?
> いわゆるデザインパターン厨って奴で、無意味にStateパターンとかを使いたがる。
で漏れの意図は表現できていると思ったんだがなあ。

念のために解説しておくと、「Stateパターンを使う奴はデザインパターン厨だから
使えない」なんて言ってるわけじゃないぞ。
漏れも、*必要とあれば*ジャンプテーブルやStateパターンを使うこともあるし。

> -1とか999とかの反論なら、>>221で出来てるのでは。
なぜ>>221が反論になっているのかわからん。
解説してくれ。

229 ：仕様書無しさん：04/05/29 22:13

>>227
>>195とか>>215とかの流れからして、その理論は飛躍し過ぎでは。

ただ、元々switchで作っていて、キーが２つに増えるとなると、どう考えてもswitchよりジャンプテーブルのほうが対応は楽だろう。
switchという仕組みでは、どう頑張ってもキー１つしか使えないし(switchを入れ子にすれば出来なくないか。しかしそんなソース、メンテしたくねぇぞ！)

よってその論理おかしい。

230 ：仕様書無しさん：04/05/29 22:16

>>226
rand()の返す値はRAND_MAXで定義されてて
それは、最悪32767なので
結局一回じゃ5桁は無理かもしれん

で、面倒だから桁ごとに一回にしたんだろ
きわめて正当なプログラムっぽいぞ

231 ：仕様書無しさん：04/05/29 22:16

>>226
分布を考えるなら、そもそも簡便な実装の乱数関数は、
組にして使うべきではないというのは常識…

それ以前の部分に突っ込みどころ満載なわけだが…

232 ：仕様書無しさん：04/05/29 22:17

>>228
オレ222じゃないけど、普通に理解したけど……

typedef strucrt {
　int key;
　int (*func)(void);
} T_FUNC_TABLE;

T_FUNC_TABLE funcTable[] = {
{ -1, funcAAA },
:
{999, funcZZZ },
};

for( i=0 ; i<sizeof(funcTable)/sizeof(funcTable[0]) ; i++){
　if(funcTable[i].key == key){
　　funcTable[i].func()
　}
}

って所かな。

233 ：220：04/05/29 22:20

>>230
これ、VBのプログラムで、まあ、桁数が足りんからとかそういう理由ではないんだ。
というか、乱数の使い方をそもそも理解してないだよね…

234 ：仕様書無しさん：04/05/29 22:21

>>233
すまんプログラム良く見てなかった
ジャンプテーブルとごっちゃにｗ

235 ：232：04/05/29 22:21

書いてみて判ったけど、テーブル化ってのは「規模が大きなプログラム」では非常に有効な手なんだろうな。
慣れれば条件が柔軟に設定できる気がする。
判定とテーブルの組み合わせで、かなり柔軟な条件のジャンプテーブルが出来るな。

236 ：仕様書無しさん：04/05/29 22:22

>>229
すまん、>>221 の文読んで無意識に "キー" という言葉を使ってしまった。
もっと具体的に書く。

switch(a)
{
case 0: ... break;
case 1: ... break;
}

この場合、実装上は if にした方が早い事が多いが、

switch(a)
{
case 0: ... break;
case 1: ... break;
case 2: ... break;
case 3: ... break;
case 4: ... break;
}

この場合はテーブルにした方が早い事が多い。
このような変更に容易に対応できるのが switch 文。

237 ：186：04/05/29 22:25

>>232
おお、そうだな。
よく読まずにレスしてた。スマソ。

ただ、俺的には
> i<sizeof(funcTable)/sizeof(funcTable[0])
ってやるより、番兵を使うほうが好きかな。

238 ：仕様書無しさん：04/05/29 22:26

>>236
ああ、つまり速度の最適化をコンパイラに判断させる為にswitch文を使う、という事か。
実装志向ですなー。

で、結局>>206に戻るワケですね。

239 ：236：04/05/29 22:26

対応できる、というよりは
コンパイラが勝手に対応してくれる、
と書いたほうが分かりやすかったかな？

240 ：仕様書無しさん：04/05/29 22:27

それで、ジャンプテーブルより仮想関数がよい
という結論には何年後にたどり着く予定？

いい加減うぜえよ

241 ：仕様書無しさん：04/05/29 22:29

>>238
で、そこら辺の細かなメンテを switch を使えば
コンパイラが勝手にやってくれるので、
わざわざプログラマが
「ここは if を使うか、テーブルを使うか？」
なんて悩む必要が無くなる。

242 ：仕様書無しさん：04/05/29 22:30

caseの中身を{...}と書いているワケですが、この{...}が実は６０行ぐらい軽く逝っちゃうのは良くある事でして。
処理を内蔵するにはswitchのcaseって文法的に根本からして向いてないんだよね。
switchの悪い点は、まさしくソコで、ソコを無視してswitchを推すのもどうかなーと。

243 ：仕様書無しさん：04/05/29 22:32

>>241
>>206を読むに、その判断自体をしない、と言ってるのでは。

244 ：仕様書無しさん：04/05/29 22:33

>>220
全桁同じ数字ばっかだよ
9が出ね～よ
同値が出まくってめちゃパフォーマンスが悪いよ

245 ：仕様書無しさん：04/05/29 22:39

>>243
その場合、case が２つの時でもテーブルジャンプとなる。
勿論、各関数の引数の整合性も取らなくてはならない。
そして、case が１つ増えて、その関数が引数をもう一つ取らなくては
いけなくなったら、前の２つの関数のプロトタイプも変更となる。

246 ：仕様書無しさん：04/05/29 22:39

>>182 って、あくまで例え話だよね。本人も実際はやってみてない。
だって、変数スコープの関係で、caseのひとまとまりを関数呼び出しに
機械的にはくくり出せないもん。
実際やろうとする人（それがいいかは別として）はgotoで
実装するのかな。

247 ：仕様書無しさん：04/05/29 22:44

キーが複数になっても、それらのキーを内部的なスカラー値にすれば、
少なくともネストしたswitchなんて書かなくて済むが

248 ：仕様書無しさん：04/05/29 22:45

>>246
>>216
>>217
スレ読め

249 ：232：04/05/29 22:51

>>247
いや、スカラー値を持つのは、かなりメンテナンス性が悪い。
>>232のソースを書いて思ったのは、そういったメンテナンス性がテーブルだと柔軟に出来そうだという事。

typedef struct{
　int *pParameter;
　int parameter;
　int (func*)(void);
} FUNC_TABLE;

なんてしておくと、例えば
a=2の時はfunc1()
b=5の時はfunc2()
なんてのも出来るでしょ。
switchと比べて云々って話じゃなく、いいテクニックだなと思った。

250 ：186：04/05/29 23:10

>>242
> caseの中身を{...}と書いているワケですが、この{...}が実は６０行ぐらい軽く逝っちゃうのは良くある事でして。
本当に「良くある事」か?
少なくとも漏れのまわりでは、数行～十数行ぐらいのものが大半を占めてるがねぇ。

> 処理を内蔵するにはswitchのcaseって文法的に根本からして向いてないんだよね。
漏れが嫌いなのは、そうやって
・caseの中身に何十行も処理を書くのは見通しが悪い。
　↓
・そもそも、そういう記述ができるswitch～case文自体に文法的問題がある。
　↓
・ということで、switch文はやめてジャンプテーブルを使いましょう。
と話を飛躍させて、高々数行の処理のswitch文をもジャンプテーブルに
書き換えようとする香具師だけだ。

251 ：仕様書無しさん：04/05/29 23:40

だるい流れだな

252 ：171：04/05/29 23:44

なんか、やっぱり荒れてるというか…
てか、テーブルジャンプに関しては176の下2行に書いてあるとおりだ

全ての原因は、bool型なのにtrue, false以外を代入しているところ
なんでそんなことしているのは半年前の俺に聞いてくれ
.cppばっかり追ってたから、.hに原因があるとは思わなかったし…

あと、func[m_mode]() ってやるよりかは m_modeをvoid *() 型として宣言してやって
m_modeに直に関数ポインタを突っ込んでやったほうがすっきりしないか？

253 ：仕様書無しさん：04/05/29 23:53

このスレ観てると、うちの会社が平和に思えてくるよ。
ありがと。

254 ：仕様書無しさん：04/05/30 00:06

> いわゆるデザインパターン厨って奴で、無意味にStateパターンとかを使いたがる。
で漏れの意図は表現できていると思ったんだがなあ。

これは禿げしく同意だな。
ほとんどのケースでStateパターン使わない方がいいって結論になるよな。
デザパタの中では使用頻度の低いパターンだと思うぞ。

255 ：適材適所を忘れちゃイカン：04/05/30 00:06

>249
柔軟性が高いほど良いって思想はどうかと思うがナ。
無駄な柔軟性は危険を孕む。
例えば>232のソースはそのまんまだと、テーブル書き換えができてしまう。

あと>207,210も指摘してるが、ジャンプテーブルは引数の数が揃ってないと
美しさがイマイチ。
（不要な引数を用意したりすると、後で読んだとき「?」になったり…）

256 ：仕様書無しさん：04/05/30 00:09

>>255
柔軟性よりも単純さだな。
常にコードは単純に。

257 ：仕様書無しさん：04/05/30 00:13

Stateパターンの使いどころは、「系」が明確にモデル化できるところ。
状態とパラメータ群の関係が閉じている場合だ。

業務システムでは、adhocなパラメータ制御をやらざるをえない場面が多々ある。
よって、そんなに出番はない。

258 ：仕様書無しさん：04/05/30 00:22

えっと・・・

どうでも良いことでアフォみたいに言い争ってる香具師・・・・約４名
あきれてる通りすがり・・・約６名

こんなところか？
見てて悲しい論争だｗ

259 ：仕様書無しさん：04/05/30 01:28

こんなスレ読むの辞めようと思った……

260 ：仕様書無しさん：04/05/30 01:31

まあまて、彼らが仮想関数を再発明する過程をじっくり見守ろうではないか。

261 ：仕様書無しさん：04/05/30 01:37

てか、はじめからそういうスレだと思うが…

262 ：仕様書無しさん：04/05/30 04:07

スレタイを見ろ。＞テーブラーども

263 ：仕様書無しさん：04/05/30 08:43

switchだとかジャンプテーブルだとかについての
視野の狭い主観的な美意識を基にした他人から見たらつまらんこだわり
それ自体がスレタイみたいなソースを生みまくってる、という事には
奴等は多分一生気付かないんだろうな

たとえ例だろうとそこにコメントが一行も無い辺りに
奴等の腐れプログラムヲタっぷりが炸裂してやがらぁ

264 ：仕様書無しさん：04/05/30 09:36

↑コメントが無いので
上の話の内容がさっぱり理解出来ず
今、枕を涙で濡らしている香具師

265 ：仕様書無しさん：04/05/30 09:55

今度はコメントっすか…
次から次へとすげーのが沸いてくるな

266 ：仕様書無しさん：04/05/30 11:04

>>263
極めて視野の狭い主観的なお人ですね。

267 ：仕様書無しさん：04/05/30 11:54

コメント必要なのは精々>182,218,221,232 位だな。
他(>207,211,220,236)はコメント要るか?
この程度読めんとPGなんてやってられんと思うが。

…何か見事にテーブル至上派とswitch擁護派に分かれてしまったが他意はない。

268 ：仕様書無しさん：04/05/30 12:00

「コメントがないから読めない」ってのはそもそも誤り
「わかりやすく書かれていないからよめない」なら正しいが

269 ：仕様書無しさん：04/05/30 12:05

脊髄反射煽りｳｾﾞｪ
専門学校に(・∀・)ｶｴﾚ!!

270 ：仕様書無しさん：04/05/30 12:09

「俺はコメントなんて要らないし俺の書くコードも美しくて分かりやすいから必要ない　だから俺は付けない」
がスレタイを生産してんだよ。
被害者なら加害者になるなよ

271 ：268：04/05/30 12:20

>>270
「コメントが無いから読めない」という被害にあったことは無いなぁ
ついでに言うと「わかりやすく書かれていないからよめない」という被害にもあったことが無い。
書きなおすからな

272 ：仕様書無しさん：04/05/30 16:12

>>271
それでも、元の仕様がわからないから書き直せないってことはあるでしょ？

変な動きするけどバグなのか仕様なのかはっきりしなかったり。
ある機能がオーバースペックの可能性があるけど、削っていいか判断できず、
簡潔なコードに直せないとか。

いや「仕様をコメントとして添えろ」とまでは主張するつもりはないがな。
日曜なので、なんとなくマターリ気分でツッこんでみるわ。

273 ：仕様書無しさん：04/05/30 16:39

コメントには意図を書くべきだと思ってるんですが

274 ：268：04/05/30 17:11

>>272
「元の仕様がわからない」って状態は確かに存在する。ソースしか存在しないような状態ダナ
そういう場合は「元の仕様」と「目標とする仕様」の双方を書く。
その段階で双方の仕様書が、保守作業の定義となる。定義も不能な作業を行っても完了判定が出来ないしな
作業定義が終了したなら、「ソースに手を入れる」べきか「書きなおす」べきなの判断が可能になる。違っているか？
当然「元の仕様」が記述出来ないなら、その判断は即座に可能だ

>いや「仕様をコメントとして添えろ」とまでは主張するつもりはないがな。
組織によって呼び方は違うが、外部仕様/機能仕様/外形仕様と呼ばれる仕様書が存在しなければ
そのプログラムは保守対象にはならん。だからまず仕様書を書くわけだよ

日曜なのでマターリ気分で切り返してみたぞ（W

275 ：仕様書無しさん：04/05/30 17:51

理想論に生きている人ですね(´ー`)

276 ：仕様書無しさん：04/05/30 18:50

>>それでも、元の仕様がわからないから書き直せないってことはあるでしょ？
>>変な動きするけどバグなのか仕様なのかはっきりしなかったり。
>>ある機能がオーバースペックの可能性があるけど、削っていいか判断できず、
>>簡潔なコードに直せないとか。

とりあえず上司を巻き込み、問い詰めて仕様を逆算する判断の責任を転嫁する。
まずはそれからだねｗ

277 ：268：04/05/30 20:23

>>275
うん。まあソウかもシレン。でもこの程度の方法論も出てこない／通らない、
品質に対する意識のヒクーイ組織で仕事していたって楽しく無いからな
正面から反論してみ。

>>276
よさげ

278 ：仕様書無しさん：04/05/30 20:25

リスクのマネジメントだな。
熊とワルツを踊れ

279 ：仕様書無しさん：04/05/30 21:02

　　　　　,.．-──- ､　
　　　／. : : : : : : : : :: ＼
　　　 /.: : : : : : : : : : : : : : ヽ
　　 ,!::: : : : : :,-…-…-ミ: : :',
　　 {:: : : : :: : :i　'⌒'　'⌒'i: : :}　ワノレツって・・・
　　 {:: : : : : : | 　ｪｪ　ｪｪ | : :}　　　　　　∩＿＿＿∩ Shall we dance？
　　 { : : : : : :|　　　 ,.、　|: :;!　　　　／　　　　　　　ヽ
＿＿ヾ: : : :: :i 　r‐-ﾆ-┐| :ﾉ　　　　| ●　　　●　　　|
　　　　ゞ : :イ!　ヽ二ﾞノｲ‐′　　　　 |　( _●_)　　　ミ
　　　　　　　` ｰ一'´ヽ　＼　　,,-''"彡　　|∪|　＿＿/`''--､
　　）　　　　　|＠　　　　　 |ヽ／　　　　　ヽノ￣　　　　　　ヽ
　　|　　　　　 |　　　　　ﾉ / ⊂）　　　　　　　　　　　　ﾒ　　ヽ＿,,,---
　　|　　　　　.|＠　　　 |　|＿ノ　　,へ　　　　　　　　/　ヽ　　　ヽノ￣
　　|　　　　　|＿　　　/　/　 |　／　 |　　　　　　　　|　　ヽ＿,,-''"
_＿|＿　　　　＼＼,,-'"＼＿_／　　/　　

280 ：仕様書無しさん：04/05/31 00:08

>>68
最初の while ループは

do {
result = dosomethinb();
} while(result);

ってしない？あるいわ

while ((result = dosomething())) ;

とか？

281 ：仕様書無しさん：04/05/31 00:33

ジャンプテーブルを使うと綺麗な場合、下請け関数たちの呼び出しプロトコルが固定的で、それぞれの動作がchっこう姓を持っている場合かな？
システムコール一つで、各種ドライバにopen,read,write,closeできるというような
そういう束で扱いたい時には自然とジャンプテーブルにしてるな。

282 ：仕様書無しさん：04/05/31 02:54

代入している場所、分岐している場所、テーブルの3箇所になるんで
ジャンプテーブルは｢著しく可読性を下げる｣と思う
ここは、派生か関数ポインタの直接代入で切り抜けろよ、と思う

まぁ、俺自身はWindowsかLinuxがベースの仕事が多いから
携帯とかのプアーな環境ではそれもありなんだが

switchも最適化かかるから一概に悪くないと思う
そうや、unreachが使える言語ってC99だっけ？
switch+default unreachで必ずジャンプテーブルを組んでくれればそれでFAなんだがな

283 ：仕様書無しさん：04/05/31 03:17

>>282
>代入している場所、分岐している場所、テーブルの3箇所になるんで
>ジャンプテーブルは｢著しく可読性を下げる｣と思う

switch でもアホみたいにでかい switch はどうなんですか？
何事も程度問題なんだよ。お前の主観はどうでもいい。

284 ：仕様書無しさん：04/05/31 04:29

switchでもテーブルでもいいけどさ、ケースバイケースだろ
どっちもメリット、デメリットあるんだから
相手のデメリットを指摘してどーなの？なんて言っても仕方ないだろ

それとも、ここで片方に決めないとまずいのか？
自分がこっちのケースのほうが絶対に綺麗に行くって
信じたほうをかけばいいんでないかな

285 ：仕様書無しさん：04/05/31 04:49

ぶっちゃけどうでもいい

286 ：仕様書無しさん：04/05/31 06:21

>285
禿同
この程度で辞めたいと思うﾔｼが居るのか?
居るから議論になってるのかｗ

287 ：仕様書無しさん：04/05/31 11:08

まあ、先輩たちが例えばジャンプテーブルかswitch文かでこんな論争をいつまでも続けていたら、
そりゃあ辞めたくもなるよと教えてくれているのでは。

288 ：仕様書無しさん：04/05/31 19:26

仮に、ジャンプｦﾀかswitchｵﾀが社長で、おれが逆の立場だった場合、
「オレと同じ発想ができないお前は鼻クソ」、
「つべこべ言わずにオレの真似だけしてればいいんだ」、
「理屈っぽいんだよ、ムカツクんだよ」
などと言われた場合は辞めたくなるわな

オレの場合、言われました
辞めました

289 ：仕様書無しさん：04/05/31 19:56

生㌔

290 ：仕様書無しさん：04/05/31 22:08

switchとテーブルか！　白熱しておりますな。
すばらしい！　なんて参考になる議論なんだ！

・・・別スレ立ててそっちでやれ。

291 ：仕様書無しさん：04/06/01 00:08

プログラマって負けず嫌いが多そうだよね・・・自分を顧みても

292 ：仕様書無しさん：04/06/01 00:55

負けず嫌いというか、自信過剰なやつが多いな。
言うまでもなく漏れもそうなわけだが。

293 ：仕様書無しさん：04/06/01 01:09

>283
おまいテーブル廚だろ、とつまんない指摘はさておき、
べつに>282はswitchｻｲｺｰとは言ってないじゃん。
あくまで「テーブルは見づらい」「switchを避ける理由はない」と述べてるだけ。

それとテーブル派ｖｓ switch派とか寝言言ってるヤシ、>173からもう一度読み直せ。

294 ：仕様書無しさん：04/06/01 01:12

>>293
>>290

295 ：177：04/06/01 01:38

しばらくぶりに来たら、話題が固まってますね。。

煽ったのは漏れだろうか...

296 ：仕様書無しさん：04/06/01 01:54

いや177、君じゃない。俺の見るところ173だ

297 ：仕様書無しさん：04/06/01 02:08

ということは 173 の大漁節が聞こえるころでつね。

298 ：仕様書無しさん：04/06/01 02:26

173も釣られてる罠

299 ：仕様書無しさん：04/06/01 02:59

M$と肩を並べる某社の構築した某システム。
複数のシステム間をつなぐゲートウェイには、Windowsが使われていた。
その上で動いていたのは、共有フォルダ上にDBの内容を固定長テキストで書き出し、
あるいはその逆に共有フォルダに出力されたファイルを読み込みDBへ格納するだけの
単機能アプリが数十個。

…大体予想が着くとは思うが、仕様変更の度に大騒ぎになるわ、
1バイトのずれでエラーになったり最悪DB壊すわで、
某社のイメージとは大幅にかけ離れたブツであった。
人の命に関わるようなシステムで、こんな事やってて良いのかねぇ。

300 ：仕様書無しさん：04/06/01 08:06

３００！

ていうか住基ネットのシステムなんて（略

301 ：仕様書無しさん：04/06/01 23:20

>>299
まさか、Fが失敗したネットワークシステムってそれなのか？

302 ：仕様書無しさん：04/06/01 23:41

>>301
FはM$と肩を並べてないし、(その糞システムと)イメージが大幅にかけ離れてもない
Iとかじゃないの？

303 ：教えてクン：04/06/02 00:07

C99のunreachって何ですか？
かいつまんで教えてください。ポインタでもいいですよ。

304 ：仕様書無しさん：04/06/02 00:36

まさかデバッグ用のコードを消すと動かなくなるプログラムが
本当にあるとは思わなんだ

ちゃんと原因特定したけどさ
デバッグ用のコードが、volatileの役目を果たしていたらしい

丸１日これでつぶしちゃいました(´Д⊂ﾂｶｴﾅｲｼﾝｼﾞﾝﾃﾞｺﾞﾒﾝﾎﾟ

305 ：仕様書無しさん：04/06/02 01:20

>>304
１日なら使えるほうだよ。

前に職場にいた４３歳の人は、それ系で３週間悩んでて
進捗ゼロだったし。

306 ：仕様書無しさん：04/06/02 02:26

ごめんなさい。
今日の作業時間の半分はbuild.xmlの書き間違えと
Velocityの動かし方の確認に費やしてしまいますた。
……なんかもうJava(とくにJ2ME)いやぽ。

307 ：仕様書無しさん：04/06/02 07:51

>>304
俺の今やっている仕事のソースには、あちこちに

/* テスト用機能。本番では削除すること */

/* 仮実装。納品時は無効化するのを忘れないこと！！ */

とかいうコメントつきの処理が山ほどあるよ(ﾟ∀ﾟ)

308 ：307：04/06/02 07:51

勿論俺は引き継いだ人間な(´д｀)
そして無効化したら異常終了したりＤＢ壊れたりと最悪。

309 ：仕様書無しさん：04/06/02 08:51

>>307
ソースは消したんだけど、コメントを消すのを忘れただけなんだよ(´ー`)

ｲ㌔

310 ：仕様書無しさん：04/06/02 21:41

>>309
あーそれ有り得るな。
デバッグコードを消していいのかどうかは簡単に判断できるけど、
コメントは消していいのか判断つかない。

311 ：仕様書無しさん：04/06/02 22:03

消せ。
もしくはデバッグコード部分を消さず丸ごとコメントアウト、その中にコメントの内容も入れる。

312 ：仕様書無しさん：04/06/02 22:20

#if+#endifを使え。って、Javaクソなのか？

313 ：仕様書無しさん：04/06/02 23:57

Javaのソースで#ifdefとか書いてて、
javacに掛ける前にcl(でもccでもgccでも何でもいいけどさ)に掛けれ、
ってソースは辞めたくなる?
携帯向けのJavaの火消しに入れられたんだが、激しくそうしたい……
何が悲しくて16個のバイナリパッケージを作るのにいちいちソースを
コメントアウトしたりコメント外したりせんならんのじゃ。ったく。

# 流石にその辺の潮騒はbuild.xmlにタスクとして書いておくけど。

314 ：仕様書無しさん：04/06/03 03:02

>>313
それって。。。
要はコードを変更してるとゆうことなんでしょ？
テストはどうなってるんですか？ちゃんといちいちしてるの？

315 ：UNIX厨：04/06/03 13:50

>>313
いまどき cppなんか使わず m4だろ

316 ：仕様書無しさん：04/06/03 21:21

会社じゃなくて大学のJavaの授業なんだけど、
先生が作ったクラス名が
avltree6.java　data4.java　formatError.java　wordpair.class　wordpairintext.class

317 ：仕様書無しさん：04/06/04 01:36

>314
してるらしい。つーか前のプロジェクトのコードをスケルトン代わりに
もらったんだけど、そのコードがコメント付けたり外したりで
対処していた。
テスト項目見たら、その変更がかかる箇所がちゃんと変更されてるか
どうか、で9割占めてたよ＿|￣|○

>315
最初はVelocity使う仕掛けこしらえたんだけど、
antだけならまだしもサーバサイドJavaやるんでもないのに
Velocityまで入れてくれつったら将来引き継ぐ香具師が切れそうだなと思い。

318 ：仕様書無しさん：04/06/04 14:19

だれか >>316 について解説して。

319 ：仕様書無しさん：04/06/04 14:32

Java の命名規則を完全無視ってことだろう

320 ：仕様書無しさん：04/06/05 07:26

Javaはテーブルジャンプができないから糞。

321 ：仕様書無しさん：04/06/05 08:31

たいがいにしろよｗ

322 ：仕様書無しさん：04/06/05 16:48

>>320
いやがんばればきっとできるぞ。わら。

323 ：仕様書無しさん：04/06/06 10:31

Strategyパターンとか？

324 ：仕様書無しさん：04/06/06 15:46

PL/SQLのFUNCTIONを、Cみたいに使うの（出力パラメータと
戻り値-1とか返す）ってOKですか？

最近資格取るために勉強してたら、「FUNCTIONは値をひとつ
戻すために使います。出力パラメータを使う場合はPROCEDURE
を使います。」とかあって。
今のシステムのソースがぜんぜんそんなこと気にしてないんだけど、
別にいいのかなぁ・・・。
（FUNCTIONで戻り値を返そうとか統一されているわけではまったく無し。）

325 ：仕様書無しさん：04/06/06 16:54

PL/SQLの機能的にはFUNCTIONで返り値とPUTパラメーター双方返しても何も問題ない。

ただFUNCTIONとPROCEDUREを使い分ける基準が無いなら、分かりやすさという点じゃマイナスだな。

326 ：仕様書無しさん：04/06/07 02:06

>325
レスサンクス。
戻り値返すのとかは、あんまり気にしなくていいってことですね。

使い分ける基準とかは、全然ないです。
引き継いだとこがPROCEDURE使ってたから、機能追加もPROCDURE～とか、
たぶんそんなレベル・・・

ときどきごちゃまぜになって、FUNCTIONなのに出力パラメータにも戻り値の
変数があるのとかは、勘弁してほしい・・・(´Д⊂

327 ：仕様書無しさん：04/06/07 18:10

細かいことなんで辞めようと思うほどじゃないし、それ以前にとっくに辞める気なんだが、
CVSの履歴を見たら「リファクタリング」と称してシングルトンインスタンスを
取得している部分を全部クラス変数に直されていた。

public void xxx() {
Class1.getInstance().method1();
}
　　↓
static Class1 CLASS1 = Class1.getInstance();
public void xxx() {
CLASS1.method1();
}

これって
static PrintStream out = System.out;
public void xxx() {
out.println();
}
みたいで気持ち悪いと思うのは俺だけ？

328 ：仕様書無しさん：04/06/07 19:28

というか、一番問題なのはライフサイクルが変わるかも知れないことじゃ……。
遅延初期化を狙ってるならそのメリットが消えるし。
そこまでシビアな状況なのかどうかは知らんけど。

329 ：仕様書無しさん：04/06/07 21:57

>>328に一票。
つか、>>327が気持ち悪いって言ってるコードは全然気持ち悪くない。
それどころか、場合によってはよいコードだろ。

330 ：仕様書無しさん：04/06/07 22:29

>>327には早く辞めてもらったほうがいいな

331 ：327：04/06/07 22:44

ライフサイクルの問題はその通りだけど、一応発生しえないんで
考えから外してた。
遅延初期化については考えてなかったんで、けなす理由が一つ増えてサンクス。
下のコードは、少なくとも無駄にスコープを広くしてるんで
俺にはやっぱり気持ち悪い。
せめてローカル変数にしてくれればまだ納得したけど。
それよりも一番許せないのは、こんなところチマチマ弄くって
仕事した気になってる連中。
他に潰さなきゃいけない大穴が爆撃の跡みたいに空いてるってのに
コードの改悪して給料もらってるんじゃやってられねっての。

>>330
俺も早くそうしたいね。

332 ：仕様書無しさん：04/06/07 22:53

俺は以前、作成したクラスのフィールドが、
知らないうちに全部staticに変更されてた。
何かの拍子にstaticメソッドを作成してしまったらしく、
コンパイルエラーが出たから、出ないようにしたようだ。

まともに動くわけねーだろ…

333 ：仕様書無しさん：04/06/07 23:03

>>327
言動に視野の狭さを感じるのは俺だけか？

334 ：仕様書無しさん：04/06/07 23:08

最強なのは正にこの板の名無し状態のシステムですよ。
VBのシステムを無理やりASPに移行したんだけど、
主要なメソッドが１つのクラスの集中してて７万行とかあるんですよ。
それを何人かで直さなきゃいけないわけですよ。順番待ち。
で、仕様書は一切なし。それに順ずる資料も一切なし。

最　強　！

335 ：仕様書無しさん：04/06/07 23:40

そういうのを聞くたび、
プログラマから足を洗って本当に正解だったと思うよ。

336 ：仕様書無しさん：04/06/08 00:13

さすがにそこまでいくとネタすぎないですか？

337 ：仕様書無しさん：04/06/08 00:39

ネタくさいことが普通にあるのがこの世界

338 ：プログラマという仕事：04/06/08 00:57

事実はネタよりもネタ臭い

339 ：仕様書無しさん：04/06/08 01:02

酷いソースを掴まされたときどうしてますか？
リファクタリングしますか？

超巨大クラスのなかに超巨大メソッドが一つ。
メンバ変数が大量（７００以上）。

340 ：仕様書無しさん：04/06/08 01:05

>>339
UnitTest書けるのか？

341 ：仕様書無しさん：04/06/08 01:10

'Option strict ON

342 ：69式フリーPG ◆hND3Lufios ：04/06/08 01:13

>>332
マルチスレッド化するためにスレッドの制御関数をstaticで追加して
（thisポインタがあるとリンク出来ないので）、メンバ変数も全部staticにして、
この変数がいつのまにか変わるんですよといってた奴なら知ってるｗ。

thisポインタを引数で渡せばいいのに根

343 ：仕様書無しさん：04/06/08 01:20

strSQL = ""
strSQL = strSQL & "文字列"
strSQL = strSQL & "文字列"
strSQL = strSQL & "文字列"
strSQL = strSQL & "文字列"
strSQL = strSQL & "文字列"
strSQL = strSQL & "文字列"
:
:

344 ：仕様書無しさん：04/06/08 01:22

>>343
そこにif文やswitch文分岐だのforループだのが激しく混ざると上級
糞コードですよ。

345 ：82：04/06/08 01:24

>>343
う、ごめん。俺結構それやるわ・・・

346 ：345：04/06/08 01:25

しかも俺82じゃないしな。
すまん。

347 ：仕様書無しさん：04/06/08 01:27

int fd=/*ソケットディスクリプタ*/;

char ch;
while(終了条件){
　int ch = read(fd,&ch,sizeof(char));
　//省略
}

1byte毎かよ…

348 ：仕様書無しさん：04/06/08 01:41

グローバル変数でcnt定義

For cnt = 0 to 50
　なんか色々処理
　Method()
　なんか色々処理
Nect cnt

Sub Method()
　For cnt = 0 to 50
　　なんか色々処理
　Next
End Sub

「なんか色々処理」のなかでもcntの値をいじってて、
それで全体としては正しく動く。
もう、嫌がらせとしか思えんかったよ
念のため、もちろん実稼動してたまじめなプログラムだよ。

349 ：仕様書無しさん：04/06/08 01:51

For i = 1 To 100
　flag = 0
　For j = 1 To 100
　　If j = i Then flag = 1
　　If flag = 1 Then
　　　なんか色々処理
　　End If
　　If j = i Then flag = 0
　Next
Next

実際はもっともっと分けのわからん複雑なループのしかたしてたけど、
ニュアンスはこんな感じ。あ、こんなのが３重だったかな…
もう、何がしたいねん。

350 ：仕様書無しさん：04/06/08 01:53

>>344
ごめん、そういうとき、ﾎﾝﾄはどうすればいい?

351 ：仕様書無しさん：04/06/08 01:54

File file = //;
String fstr = file.getAbsolutePath();
//fstrをぐちゃぐちゃ加工する処理
File target = new File(fstr);

なんでもかんでも一度Stringにしたがる奴が多いのはなんでだ？
抽象化のメリットを1から勉強しなおせオマエラ。とおもった。

352 ：仕様書無しさん：04/06/08 01:59

先輩、プログラムを限界まで高速化しました！！

register int i;
for (i = 0; i < hoge; i++) {
Xlib（だっけ）のグラフィックス関連メソッド呼び出し。
}
まて、ちょっとまて。

353 ：仕様書無しさん：04/06/08 02:01

>>350

SQLGenerator gen = new SQLGenerator();
gen.setSelectCriteria(scollection);
gen.setWhereCriteria(wcollection);
//...
String sql = gen.generate();

正しいかはしらんけど、オイラなら例えばこんなクラスを要件に
応じて適当に作るだろうなあ。直接SQL文字列の組み立てをいろ
んなところでやることは避けたいな、と。

354 ：仕様書無しさん：04/06/08 02:04

VBでINIファイルの読み込み、APIなんざ使わずにテキストで読み込み。

If Left(buf, 8) = "HogeHoge" Then value = Mid(buf, 10)
If Left(buf, 6) = "Hogeyo" Then value = Mid(buf, 8)
延々と…

冗談だろ…

355 ：仕様書無しさん：04/06/08 04:56

>>351
日時型と文字列型を
激しく相互変換しまくってるコードに遭遇しました。

356 ：69式フリーPG ◆hND3Lufios ：04/06/08 05:21

テーブルに日付を文字列にして格納している奴は見たことあるな。
んで、集計するのにWHERE句で苦労したらしく、整数値型の列をAlterしてあった。
年、月、日と、みっつね。んで、それに全部インデックスかけてあるから、
年次処理でテーブルを掃除するのが遅いのなんのってｗ

357 ：仕様書無しさん：04/06/08 07:01

>>331
>それよりも一番許せないのは、こんなところチマチマ弄くって
>仕事した気になってる連中。
>他に潰さなきゃいけない大穴が爆撃の跡みたいに空いてるってのに
>コードの改悪して給料もらってるんじゃやってられねっての。

俺は、他に潰さなきゃいけない大穴が爆撃の跡みたいに空いてるってのに
そんなチマチマした修正を 2ch であげつらって、悦にいっている奴の方が
許せないが・・・

358 ：仕様書無しさん：04/06/08 07:41

>>357
ちょっとぐらい現実逃避させてくれよ～

359 ：仕様書無しさん：04/06/08 08:03

>>357
度を越して頭悪いと、揚げ足取りも寒いだけだね。

360 ：仕様書無しさん：04/06/08 09:20

>>343-344
俺それやるが。どうすればいいんだ？
４テーブルリンク、リンクキー合計５つ（２，２、１）
その他画面入力に応じた条件５つぐらいで頼む

>>353 VBの話だが、なにかいい案があればヨロシク

361 ：仕様書無しさん：04/06/08 09:50

テーブル、カラム、検索条件式をそれぞれクラスにすると扱いやすいよ。オブジェクト指向の手軽な例題になる。つーかね、動的なSQL構築を単純な文字列処理でやるのは激しくうざい。

362 ：仕様書無しさん：04/06/08 12:10

>>353
問い合わせ文を直接ごにょごにょするのではなく、
適切にオブジェクトに分割しましょうよ、ということですね?
了解です。

363 ：362：04/06/08 12:13

>>361 見ないで発言しちゃった。 orz
java や .NET (VB.NET, C#) ではよくやるんですけれど、
VB6 だとクラスが増えて、それはそれでうざいので、どうしたものかな、と。

364 ：仕様書無しさん：04/06/08 15:31

>>357
朝から寂しい奴だな。

365 ：仕様書無しさん：04/06/08 15:51

VBは一括だからなのか
クラスが増えるとコンパイル時間かかりすぎ

366 ：仕様書無しさん：04/06/08 17:10

さっき自分の書いたコードを眺めてたら、
switchが三つネストしていた。

ﾜﾗﾀ

367 ：仕様書無しさん：04/06/08 19:34

VBなら実行コードでどうなるかしらんけど
VBScriptだったらせめて

strSQL = ""
strSQL = "文字列" & _
　　　　　　"文字列" & _
　　　　　　"文字列" & _
　　　　　　"文字列" & _
　　　　　　　　　：

にした方が良さげ。

368 ：仕様書無しさん：04/06/08 21:04

>>353
サブクエリとかUNIONとかJOINとか使いたいときはどんなになる？
SQLべたに書くと予期せぬSQLエラーになったりするけど、
かといってSQLのメリット使えないのはもったいないと思うんだが。

369 ：仕様書無しさん：04/06/08 22:25

さっさとオブジェクト指向データベースが流行すればいいのに、
といってみるﾃｽﾄ。

ﾑﾘがあるか…

370 ：仕様書無しさん：04/06/08 22:26

>>367
たぶん、実行速度の観点から言っているのだろうけれど、
今は可読性を問題にしているのではないかと…

371 ：仕様書無しさん：04/06/08 23:08

>>368
俺も >>353 でサブクエリまで扱えるのか
疑問だった。そこまで含めて簡単・正確に
生成できるなら検討の余地あるけれど。

俺はVBでSQLベタ書き派でつ。
さすがに>>367の形式にはしますがね。

まあ、VBにはクラスなんてないから関係ないやね。(w

372 ：仕様書無しさん：04/06/08 23:08

あんまりこみ入ったことをやる必要はないんじゃない？

Criteria オブジェクトみたいなのは単純な表へのSELECT に特化させといて、
表のほうをUNIONやJOINを使ったビューにしておけばいいじゃん

373 ：353：04/06/08 23:29

>>372が前提かな。あるいは、単純なクエリの場合だけ、とか。

本格的にやろうとすると、コンパイラ書くようなもんだからなあ…
サブクエリくらいならコンポジットパターンで適当かませば、そん
なに面倒かけずに出来そう、かな？

374 ：仕様書無しさん：04/06/09 00:05

>371
VBで367の形式って面倒くさくない？
うちは変更するときは元の行をコメントアウトして履歴を残さなきゃいけないから、
ほとんどの人が343の形式でベタ書きしてる。

まぁ、規約が厳密に決まってないのをいいことに、367形式で直したとこだけ
上に抜き出してコメントアウトしたりもしてるけど・・・

テーブル5, 6個結合、検索条件20個とか当たり前で、もう悪夢のよう・・・

375 ：仕様書無しさん：04/06/09 00:21

>>374
あーそう、VBのアホ仕様では>>367の途中一行をコメントに出来ないんだよね
うちはSourceSafeで履歴管理させてて変更をコメントで残すような規約は特に無いからいいけど。

SQLクエリは業務ロジックの要素の中でも一際濃い部分だからなぁ
そこそこ神経使わないとパフォーマンスの低下にも直結するし。
生成アルゴリズムをまともにカプセル化出来るとは思えない…。

376 ：仕様書無しさん：04/06/09 00:50

業務系ではパフォーマンスよりも

メンテの判りやすさ、デグレの原因追求などが優先される

377 ：仕様書無しさん：04/06/09 00:57

"strSQL" って変数名はどこでも同じなんだね。
strQuery とかのほうが合ってる気もするが。

378 ：仕様書無しさん：04/06/09 14:24

>>377
全員、お前の職場の人間なんだよ

379 ：仕様書無しさん：04/06/09 14:55

何の迷いも無く「strSQL」とする漏れも377と同じ職場。間違いない。

380 ：377：04/06/09 15:24

マジか

381 ：377の会社の社長：04/06/09 16:06

おまいら仕事しろ。

382 ：377の隣の席の人：04/06/09 20:00

>>381
おまえモナー（´∀｀）

383 ：仕様書無しさん：04/06/09 20:20

うちは cSQL でつ。
c は character の c らしい。

384 ：仕様書無しさん：04/06/09 20:29

public boolean equals(Object obj) {
if ((obj instanceof StringChain) == false)
return false;

if (chain.equals(((StringChain) obj).getChain()))
return true;
else
return false;
}

ｷﾀ──────(ﾟ∀ﾟ)──────!!

385 ：仕様書無しさん：04/06/09 20:56

>>384
ごく普通のequalsメソッドの実装に見えるけど？
それとも、hashCodeメソッドが実装されてないとか？

386 ：仕様書無しさん：04/06/09 20:58

if(){

}

になってないのが気に食わないとか

387 ：仕様書無しさん：04/06/09 22:02

>>373
結局そこのインピーダンスミスマッチを解消しようとすると、
開発の負荷が上がるから単純にしておくのがいいと思うんだよね。
RDBMSって安くないし、機能豊富だし、変に技術持ったおっさん多いし。

って、スレ違いだ。すまん。

388 ：仕様書無しさん：04/06/09 22:43

>>384-386
return chain.equals(((StringChain) obj).getChain());
じゃないのが、嫌なんじゃない？

389 ：仕様書無しさん：04/06/09 23:06

public boolean equals(Object obj) {
return (obj instanceof StringChain) && chain.equals(((StringChain) obj).getChain());
}

390 ：仕様書無しさん：04/06/09 23:12

ありそうなレスが予想通りにあると嬉しいもんダナ

391 ：仕様書無しさん：04/06/09 23:18

ソースの行数で進捗を把握した気になってるアホな
上司向けに冗長に書いていると思ってみた

392 ：仕様書無しさん：04/06/10 11:27

ことさら叩くようなソースでもなかろうに

393 ：仕様書無しさん：04/06/10 13:18

実はchainフィールドがnullになる可能性があって
それでNullPointerExceptionが発生したとか？

つーか、Jakarta Commons LangのObjectUtils.equals(Object, Object)
か、それと同等のものを自作して使うのが普通だと思うが。

394 ：仕様書無しさん：04/06/10 13:48

月並みだが、ウチの会社は
if taeko < yoshiko then
go to kimie
end if
というソースが現役…
妙子より良子の方がいいと思うのになぜ君江の所に行くか、
と冷静に突っ込んでみたりしたが…空しい…もうだめぽ

395 ：仕様書無しさん：04/06/10 20:16

俺はそれをバイクの車種でやったよ。CB250とかSL350とか・・・

396 ：69式フリーPG ◆hND3Lufios ：04/06/10 22:22

if(Honda.nsr < Suzuki.Gag){

なんてコードがあったらバグと思うかもなぁ。。。

397 ：仕様書無しさん：04/06/10 23:09

同じプロジェクト内に、同じ意味を持つ変数が最低４つ、最高１２個あった
ソースを見た時は辞めたいとゆーか、思うより早く整理してしまった。

hoge1.c
strcpy( path, fullpath );

hoge2.c
strcpy( datapath, fullpath );

hoge3.c
strcpy( filepath, datapath );

hoge4.c
strcpy( filename, fullpath );

hoge5.c
strcpy( userfile, path );

398 ：仕様書無しさん：04/06/10 23:49

>>397
そういうのって一応テストするの？

399 ：仕様書無しさん：04/06/11 01:28

>>397
それらの変数名がその関数内の文脈において適切であるなら、何種類あっても問題ない。
たとえ実体が一つであってもだ。
名称の統一を行おうとするのは「変数名管理」といってCOBOL文化において良くみられるものだけど。

400 ：仕様書無しさん：04/06/11 10:39

それが全部グローバルなら、悲しくなるかもな。
ローカルなら、あんまり気にしない。

401 ：仕様書無しさん：04/06/11 11:10

>>399
COBOL文によく見られる変数名管理は、どちらかというと
「妙なプリフィックス+ID」という管理手法であって、
変数名を統一する目的ではないような…

402 ：仕様書無しさん：04/06/11 12:12

>>401
うん。その種のいわゆるインテリジェントコードと呼ばれる、一意化命名規則を使っているところは多い
ただ「意味が全然わからなくてあんまりだ」という理由で、意味のある名前を付与し管理しているところもある。
変数名をキーにしてデータベース化している。
データベースの参照はツールを使って誰でも出来るが、更新は管理者のみが更新可能。
サブシステム内のみならず全システム内で同一の変数名が使われる。

403 ：仕様書無しさん：04/06/11 12:54

先輩が書いたソースにあった、メッセージ文字列

　書式を変更するときの確認→ "Format Change ?"
　保存するときの確認→ "Save OK ?"
　読み込むときの確認→ "Load OK ?"
　削除するときの確認→ "Are You Delete ?"

海外向けなのにカタコトかよー。最後のなんかﾊｧ???だし。
しかも、もう出荷しちゃってるし orz
恥ずかしー

404 ：仕様書無しさん：04/06/11 13:10

>Are You Delete?
ﾜﾗﾀ

405 ：仕様書無しさん：04/06/11 13:38

Save OK?
Load OK?
なら
Delete OK?
でいいのにな・・・

406 ：Delete：04/06/11 14:15

呼んだ？

407 ：仕様書無しさん：04/06/11 18:07

deleteは形容詞だったのか！！！

408 ：仕様書無しさん：04/06/11 23:46

「あなたはDelete氏ですか？」と聞いているのかもしれん。

409 ：仕様書無しさん：04/06/11 23:50

>>408
Mr.テッキリ
http://www.din.or.jp/~f-aniki/sc/t_neta/ot3/ot_1541.htm

410 ：397：04/06/12 00:31

>>398-400
全部グローバル変数で、それぞれ512バイトずつ確保していたよ(；´д⊂）
仕様上ファイル名はフルパスで64文字になっているのに・・・

411 ：仕様書無しさん：04/06/12 01:07

Are you deleted?

412 ：仕様書無しさん：04/06/12 01:10

>>403
それ見て思い出したんで見に行ったら、続報がたくさん足されててまた笑った。
http://www9.plala.or.jp/pandanotasogare/dvd.html

413 ：仕様書無しさん：04/06/12 08:16

>>412
携帯電話の英語設定も大抵そんなのだよ
全部修正したろと思って英語表記が仕様上未決定の時に
キレイな英語にしておいたら、企画屋さんから
　「わかりづらい英語にしないで仕様通りにしてください」
とクレームがきた。

Delete Files All, OK?

のどこがわかりやすいのか・・・

Remove all files?

がフツーだろ。

414 ：仕様書無しさん：04/06/12 09:59

新人にVBの課題させたらグローバル変数使いまくり
こういうのがいい(？)コボラーになるんだろうなと思った。

415 ：仕様書無しさん：04/06/12 10:41

>>413
携帯の英語モードの需要は
かっこつけたつもりになりたいアホDQNに対してで
正しい文法は通じない…とか推測してみる

416 ：仕様書無しさん：04/06/12 11:26

つまり英語モードじゃなくてDQNモードだって事か

417 ：仕様書無しさん：04/06/12 11:42

>>413
直すなら事前に話しとけば良かったのにな

企画屋なんて自分らがやってることが正しいと信じて疑わない連中なんだから、
勝手に変えられていたら怒るよ

正しい、正しくないは（連中にとっては）また別の問題
理不尽だけど、俺にも経験があるから

418 ：仕様書無しさん：04/06/12 13:46

そうそう。企画ってのは別名「思いつき仕様提案チーム」だからな。
思いついた操作方法を仕様書としてあげ、操作設計書を漏れらが書いて提出したら、
それでもってようやく全体が見え、そこからまた思いつき修正依頼を出す。
開発に入り動くものが出てきたら、そこでようやく現実的に見ることができ、
そこから思いつき大幅仕様変更を息をするかのように提案する。

そんなことばっかやっているのに、売れると企画の人間がニュースページに
顔を出すんだよなあ。やってられねーよ

419 ：仕様書無しさん：04/06/12 16:37

そうそう、だからお前らも
いつまでもプログラマーなんかやってないで
ステップアップしなきゃダメよ

420 ：仕様書無しさん：04/06/12 17:34

ということで、明日から営業にステップアッぷします

421 ：仕様書無しさん：04/06/13 15:25

それはアップか？
いや、技術知識を活かしつつかつ営業の才能もあるならアップか。

422 ：仕様書無しさん：04/06/13 17:23

ドカタから抜け出せるという意味ではアップだろ

423 ：仕様書無しさん：04/06/13 17:35

土方 -> 詐欺師

424 ：仕様書無しさん：04/06/13 21:06

ひじかたさんは詐欺師なんかじゃねぇ！(；´д⊂）　

425 ：仕様書無しさん：04/06/13 22:15

鬼の副長だもんな。

426 ：仕様書無しさん：04/06/14 01:03

いや漫画家だ。

427 ：仕様書無しさん：04/06/14 10:14

艦長だよ

428 ：仕様書無しさん：04/06/14 11:59

　「トシちゃん25歳！」

429 ：仕様書無しさん：04/06/14 20:46

なるほど。
ソースコードに「トシちゃん25歳！」って書いてあったんだな。
そして、>>428はそれをみて会社を辞めようと思った訳だ。

430 ：仕様書無しさん：04/06/14 23:21

public class HogeHoge {

/**
* コンストラクタ
*/

}

431 ：430：04/06/14 23:22

ミスった。再度。今日見かけたコード

public class HogeHoge {

/**
* コンストラクタ
*/
void HogeHoge() {
}

}

432 ：仕様書無しさん：04/06/14 23:49

>431
……それでコンパイル通っちゃうんだもんなぁ。
コンストラクタで大したことしてなければ特に影響もないし……
とはいえ見ると鬱だ。

433 ：仕様書無しさん：04/06/15 00:02

>>431,>>432
何が問題か分かりません。
教えてください。

434 ：仕様書無しさん：04/06/15 00:07

voidかな？

435 ：仕様書無しさん：04/06/15 00:08

>433
431のコードにこう追加してみよう。
private int val;

で、HogeHoge()の中で
val = 10;
としてみる。
ついでにvalのgetterも書いておこう。

HogeHogeのインスタンスを生成してvalの値を取ると、あら不思議!!

436 ：仕様書無しさん：04/06/15 00:22

昔、C++に移植しる!! と言われて渡されたObjective-Cのソース

result = [ uge withHoge :
　　　　　　[[ hoge :[[
　　　　　　　[[[
　　　　　　　　[ huga withHoge:[ hage moge ]] mage]
　　　　　　　　　　　chige] choge :[ hyoge withPypge:[uge getPypge]
　　　　　　　　]]]] : [
　　　　　　　　　　　　　[
　　　　　　　　　　　　　　[[ ・・・・・・・

中括弧の数を数えるのが限界だった

437 ：仕様書無しさん：04/06/15 00:22

>>433
戻り値の型を書いたらそれはコンストラクタではなくメソッドだよ。ということ。
で、ご丁寧にJavaDocコメントで「コンストラクタ」と書いてあるのがさらに鬱

438 ：仕様書無しさん：04/06/15 00:28

(char*)hoge, &data[0];
(char*)moe, &file[0];

何だこりゃ、と思ったら担当者が何故か = と , を間違えたらしい。
コンパイルとおるなよ・・・(；´д⊂）

439 ：仕様書無しさん：04/06/15 00:34

>>436
括弧の数なんか数えるなよ。インデント見ればわかる。
そんなんじゃLispなんかやってられないぞ。

440 ：仕様書無しさん：04/06/15 00:42

>436
それ以前に "[]" は中括弧じゃないな。

441 ：仕様書無しさん：04/06/15 00:43

>>431
前それでバグってたソースがあった。
修正した形跡があるんだが、
「何故かコンストラクタが呼ばれないため手動で初期化」
と初期化用メソッドと、使う側にその呼び出しが追加されてた。

442 ：仕様書無しさん：04/06/15 00:47

>>438
コンパイルは当然のように出来るさ(w
ｃの言語仕様は「プログラマは間違えない」という前提で設計されているからな(w

443 ：仕様書無しさん：04/06/15 11:28

>>428-429
せめて「七味とうがらし」だったらなぁ…

444 ：仕様書無しさん：04/06/15 22:05

>>437
さんきゅ。

445 ：仕様書無しさん：04/06/16 22:36

>>442
警告は出てもいいような。
効果のない式がうんぬん、てやつ。

446 ：仕様書無しさん：04/06/17 09:41

#include "Windows.h"

447 ：仕様書無しさん：04/06/17 15:10

>>445
lint かけれ。
つーかそのレベルを出させると
(void)printf(...);
な行ばっかりになって鬱。

448 ：仕様書無しさん：04/06/17 17:20

>>447
lintクリーンなコードを書いていますが何か？

449 ：仕様書無しさん：04/06/17 22:13

>>448は偏執狂。間違いない。

450 ：仕様書無しさん：04/06/17 23:44

int foo(int *a){
a++;
return *a;
}

こんな感じのソースを書いてたら(途中大分省略)、先輩に
｢あー、なにやってるんだよ、馬鹿
引き数書き換えるんじゃねーよ、元の値までかわるじゃねーか｣

この会社辞めてもいいですか？

451 ：仕様書無しさん：04/06/17 23:54

辞めてもいいが、何で引数の元の値をそのまま返すのん？

452 ：仕様書無しさん：04/06/17 23:56

え？

453 ：仕様書無しさん：04/06/18 00:05

その先輩がまぁ分かってないのは確かだとしても
まぁ全体見ないと判断できないが>>450のソースはそれそのままでは俺もあんまり好きな雰囲気はしない…
ついうっかりバッファオーバーランとかしそう。

454 ：仕様書無しさん：04/06/18 00:10

>>450
今の職場にいる４３歳のダメぽ野郎よりマシだ
作業結果みたら、簡単な処理なのに関数が４０個もあるっちゅーから驚いて見てみたら、

int data_plus( int a )
{
int b;
b = a + 1;
return( b );
}
みたいな関数が山ほど。

455 ：451：04/06/18 00:58

>>452ボケてた…すまん。

456 ：仕様書無しさん：04/06/18 01:16

>>453
STLのイテレータだってほっとけばバッファオーバーランするぞ

457 ：仕様書無しさん：04/06/18 09:25

>>456
えええ、例外投げるんじゃなかったっけ？

458 ：仕様書無しさん：04/06/18 09:35

>>450
漏れがヘタレで良くわからないんだが、それは何をする関数なの？

459 ：仕様書無しさん：04/06/18 11:48

//メモリ領域をアロックする
LPBYTE buffer;
buffer = (LPBYTE)malloc(sizeof(BYTE) * dwDataSize);

　　…(略)…

//アロック済みメモリをガーベッジコレクションする
buffer = NULL;

…コレクションできていないようだが？(C++)
客に対して
「Windowsのバグでメモリが解放されないので、メモリが足りなくなったら再起動を」
とか言ってた気がするが、そういうレベルの問題では…('A`)

460 ：仕様書無しさん：04/06/18 12:12

>>459
＿|￣|●

そんなｺｰﾄﾞを書くから、Java厨とか言われちゃうんだよなぁ…

461 ：仕様書無しさん：04/06/18 12:54

ポインタの破壊がGCかよ
そーいう「何もわかってないヤツ」にコード書かせる
ことにこそスキル管理不在という最大の問題が存在すると思うが

462 ：仕様書無しさん：04/06/18 13:30

>>459
ツッコミどころが多くて迷うが、とりあえず

>「Windowsのバグでメモリが解放されないので、メモリが足りなくなったら再起動を」

こんな事を信じてくれる客先がいる事がうらやましい・・・

463 ：仕様書無しさん：04/06/18 13:33

>>459
ｳｷﾞｬ ━━('A`)━━ !!!!!

どっちかと言うと藻前が辞めるんでなくそれ書いた奴を違う業界に追い出してくれ…。

ちなみにうちの会社でもDBをCOBOL式にアクセスしてるクソwebアプリがあって、
プログラマがトランザクション知らなかったのか
複数人で使うと挿入する主キーが被って落ちる。
客への説明は「サーバへの過負荷」。
300人程度の社員が使う、おそらく同時利用はあっても３人程度のシステムで
どうやってXeonデュアルのサーバを過負荷にさせられんだか… ('A`)

>>461
>「何もわかってないヤツ」にコード書かせる
>ことにこそスキル管理不在という最大の問題が存在すると思うが
超同意。
最近文系で会社入ってから見よう見まねでプログラム書くようになったっていう程度の
サラリーマンエンジニアが増えて来てる気がする。
職人気質の無い奴等に売り物としてのシステムを作らせるのは詐欺。

464 ：仕様書無しさん：04/06/18 14:27

LPBYTEという名前のクラスがあって、
operator = にNULLを渡すと自動的に
free() するとか。

いや、なんでもない。

465 ：仕様書無しさん：04/06/18 14:46

>>464
そういう場合はnew使って欲しいなぁ～

そういう問題でもないか

466 ：仕様書無しさん：04/06/18 15:54

>>463
Java厨＝文系だと思っていないか
文学部卒でC++屋の俺にとってこれ以上の屈辱はない

467 ：仕様書無しさん：04/06/18 16:21

馬鹿な奴が"デフォルトの値"として選んだ文系とそれ以外の文系は、
本当は分けて考えるべきなんだけどね。
後者を「論理が苦手」とする理由は無いし。

でも分ける手段が無いからなぁ。

468 ：仕様書無しさん：04/06/18 21:46

>>467
文系に2通りあるなら、そもそも文系を出した時点で差別だ。
ためしに>>463の「文系」を「黒人」でも「女」でも「えた」にでも、
置き換えてみればわかりやすいだろう。

469 ：仕様書無しさん：04/06/18 22:08

×文系は馬鹿
○馬鹿は文系

470 ：仕様書無しさん：04/06/18 22:38

糞コード読解力養成本って出版したら売れるかな
もちろん付属CD-ROMの中身は大量のサンプルコード

471 ：仕様書無しさん：04/06/18 23:10

>>470
藤原なんとかが本出してなかったか？

472 ：仕様書無しさん：04/06/18 23:21

>470-471
Cプログラミング診断室、ですな。
tp://www.pro.or.jp/~fuji/mybooks/cdiag/index.html

473 ：仕様書無しさん：04/06/18 23:36

糞コードのオンパレードです。
「何をしたらいけないかを知りたい」とか「自虐的な精神修養をしたい」
という人にのみ推薦

474 ：仕様書無しさん：04/06/18 23:50

いまさらCで綺麗なソースがかけてもね。
Java版とかC++版なら欲しいが。

475 ：仕様書無しさん：04/06/19 00:11

みなさんにOSを供給してくれている米国の某巨大ソフトウェア会社は
手違いで綺麗なCのソースコードのサンプルを提供してくださいました。

476 ：仕様書無しさん：04/06/19 09:05

>>474
綺麗なソースの書き方と言語は関係ないだろ
言語やプラットフォームやツールが変わるたびに、一から丸暗記しなおすタイプか？

477 ：仕様書無しさん：04/06/19 10:20

さらにいえば、JavaもC++もCの系列山車

478 ：仕様書無しさん：04/06/19 11:03

>>476
関係あるんじゃない？特にＣは・・・・。
酷いポインタの使い方とか、無意味なマクロ連打とか。

479 ：仕様書無しさん：04/06/19 11:11

今新たなプロジェクトに入って他人のコード修正してるが
グローバル変数使いまくりで、しかもある関数呼ぶときに
引数であるグローバル変数渡してるくせして、
その関数の中でさらに別のグローバル変数使ってたり書き換えたり･･･
同じ意味の変数が複数あったり、同じ意味で同じ値の定数が複数あったり･･･
もうイヤだ！

480 ：仕様書無しさん：04/06/19 12:01

>>479
俺の隣の席のヤツか！？orz..

481 ：480：04/06/19 12:12

>>479
もしお前が俺の隣の席のヤツなら、月曜日小さな声で「ぬるぽ」と言ってくれ。
「がっ」という声が返ってきたら、そのプログラム作ったのは俺だ。
ほんとスマン。

482 ：仕様書無しさん：04/06/19 12:20

スマンで済む問題か？

483 ：479：04/06/19 12:30

>>481
たぶんおまいじゃないな
だって今休日出勤中で隣も居る
月曜日じゃなくて今言おうか

484 ：仕様書無しさん：04/06/19 13:48

>>483
さりげなく、「あ～、このままだとぬるぽになっちゃうな～」
とか言うのが吉

485 ：仕様書無しさん：04/06/19 18:00

先輩から引き継いだＣのコード、何かあるとすぐフラグ立てになっていて
処理がフラグ判定の嵐、グローバル変数が鬼のようにある
５～６行を超える繰り返し系の処理は全て関数。（引数も戻り値もなし）
その結果

int main( void )
{
flag_clean();
data_chg();
if( data > 8 ) datamanuflag = ON;
data_swap();
if( dataswapflag == ON ) dataswap_ok_flag = ON;
data_copy();
if( datacopyflag == ON ) datacopy_ok_flag = ON;
if( datacopy_ok_flag == OFF && data_break_flag == OFF ) data_check();
if( datachkflag == ON ) data_set();
}
こんなんばっかし。

486 ：仕様書無しさん：04/06/19 18:20

>>485
>５～６行を超える繰り返し系の処理は全て関数。（引数も戻り値もなし）

C++では正しいかもしれない。
for_eachに関数オブジェクトを渡して処理するのが推奨されてる。

487 ：仕様書無しさん：04/06/20 01:11

>>458
たぶんこんな感じ。

int foo(int *a){
a++;
return *a;
}

void hoge(){
int len, ret;
int hairetu[] = {1,2,3,4,5};
len = sizeof(hairetu)/sizeof(int);
for(int k=0;k<len;k++){
ret = foo(&hairetu[k]);
printf("count='%d'\n", ret);
}
}

結果
count=2
count=3
count=4
count=5
ドッカーン

488 ：仕様書無しさん：04/06/20 01:12

パート１から>>ALL

ちっちぇえ悩みだな～

489 ：仕様書無しさん：04/06/20 03:23

　　　/*
　　　|
　　　|
　　　|
　 ∧|∧
　（ / ⌒ヽ　　　　　|￣￣￣￣￣￣￣
　　| | 　　|　　　　　|
　　∪ / ﾉ　　.　　　|
　　ﾉﾉﾉ　　　　　 */
　main　　　　　　　(
　　　　　　　　　　　)
　　　　　　　　　　　{
　　　　　　　　　　　}

正しいCのコード

490 ：仕様書無しさん：04/06/20 13:35

>>489
a.c:1: error: stray '\241' in program
...
a.c:15: error: stray '\311' in program
a.c:15: error: 構文解析エラー at end of input

491 ：仕様書無しさん：04/06/20 13:42

全角スペースでなく半角スペースに直さないといけないな。
スペースは で表現汁

492 ：仕様書無しさん：04/06/20 17:41

>>489　はその程度のコードさけ書けないぬるぽＰＧとして、今すぐコメントを実現しる。

493 ：仕様書無しさん：04/06/20 17:49

さけ？

494 ：バキュ ◆b.4YMMQI62 ：04/06/20 18:21

えっスピリタスだってどこどこええっどこ？？

495 ：仕様書無しさん：04/06/22 13:57

JavaでopCompみたいなクラス名をつける香具師って頭おかしいんじゃなかろうか

496 ：仕様書無しさん：04/06/22 17:00

>>495
それだけ書いても意味がわからんよ。

497 ：仕様書無しさん：04/06/22 17:35

いやクラスなんだから、動詞が名称になっているってこと自体が変だ
と言いたいのでは

498 ：仕様書無しさん：04/06/22 19:10

動作を表すクラスだったらいいんじゃね？

499 ：仕様書無しさん：04/06/22 19:22

>>498
具体的な例を書いてみてくれないか？
OOPなんだからクラスはオブジェクトだよな。
おれはOOは半可通だって自覚してるからエロい人に指摘してもらいたいんだ。

500 ：仕様書無しさん：04/06/22 22:25

１．クラス名に略名をつけるな（長くていいからわかりやすくしろ）
２．クラス名の最初の文字は大文字にしろ
ということだろう。
この規則守らないとｷﾓい（少なくともJavaではね）。

501 ：仕様書無しさん：04/06/22 22:55

>>500
いつも思うが、２番は言語仕様にすればよかったのに。

502 ：仕様書無しさん：04/06/22 23:19

>>499
498ではないが、自分の場合、C++だと通常のクラス名は名詞で統一して
ファンクタだけ、動詞って感じにしている。(この例ではPrintクラス)

しかし、Javaでクラス名が動詞になる例は、今まで見たことないな・・・・・・。

// 例) 配列の値を出力する、オブジェクト指向の欠片も見当たらないサンプル。
#include <iostream>
#include <algorithm>

class Print {
public:
    void operator()(int value) const {
        std::cout << value << std::endl;
    }
};
int main()
{
    int data[] = {0, 1, 2, 3};
    std::for_each(data, data + sizeof(data)/sizeof(data[0]), Print());
    return 0;
}

503 ：仕様書無しさん：04/06/23 08:37

え、言語に依存するの？

504 ：仕様書無しさん：04/06/23 12:56

C++だと
getDate()みたいなメソッド名よりGetDate()ってメソッド名が普通だよね。
Javaだと逆だけど。

505 ：仕様書無しさん：04/06/23 13:49

pf_date_GETDATE_20040623()

506 ：仕様書無しさん：04/06/23 20:15

職業プログラマはほんとにこんな関数名つけるんですか

507 ：仕様書無しさん：04/06/23 21:03

職業PGにありがちで、思わず首を傾げてしまうのは
#define VALUE_ZERO (0)
#define VALUE_ONE (1)
#define VALUE_TWO (2)
:
だね。

#define SYSTEM_ERROR (-1)
なんてのも見たことあるし。んで、
if(open(...) == SYSTEM_ERROR) エラー処理;
if(pthread_create(...) == SYSTEM_ERROR) エラー処理;
みたいに使うのな。前者はともかく、後者は間違ってるし。

508 ：仕様書無しさん：04/06/23 21:07

職業プログラマにありがちであるのは確かだが、
職業プログラマであるからではない、単なるアホであるからだ

509 ：仕様書無しさん：04/06/23 21:26

いきなり
return -1;
とかやられるよりマシだべ。

510 ：仕様書無しさん：04/06/23 22:16

たまーに>>509みたいなの見かけるけど
さすがに>>507みたいのは見たこと無い・・・・

511 ：仕様書無しさん：04/06/23 22:23

>>509
いきなりreturn -1;でいいじゃん。

#define SYSTEM_ERROR (-1)
return SYSTEM_ERROR;
なんて目がちかちかするよ。

512 ：仕様書無しさん：04/06/23 23:06

>>507
>#define VALUE_ZERO (0)
>#define VALUE_ONE (1)
>#define VALUE_TWO (2)

ソレと似たようなのを現実に見たときはすこし気が遠くなった

513 ：仕様書無しさん：04/06/23 23:15

>>507
＞#define VALUE_ZERO (0)
＞#define VALUE_ONE (1)
＞#define VALUE_TWO (2)

これの意図、何となく分かったぞ。
多分、本当は下に書いた感じの意味があるんだよ。
#define XXSYSTEM_COMPLETE (0)
#define XXSYSTEM_CONNECTION_ERROR (1)
#define XXSYSTEM_OPEN＿ERROR (2)
でも、作ってる時は名前思いつかなかったから、
とりあえずZERO,ONE,TWOにした。
こうしとけばあとからgrepかけて一括置換できる。

514 ：69式フリーPG ◆hND3Lufios ：04/06/23 23:26

pthread_createは０以外だからね。
WinのAPIでも実は０と０以外なんだが、殆どTRUE(1)を返すから
==TRUEとしているコードを時々見るな。

515 ：仕様書無しさん：04/06/24 00:18

>>65 さんへ

要するに、

処理A
|
処理B
|
処理C
|
処理D

の様な処理で、途中でNGになった時は後の処理をさせないような制御を
どう実現するかだと思うんだけど。
Cの場合、goto か do{ break }while(0) しか方法がないと思う。
(ループしないので、while(1){ break } より do{ break }while(0) ね）

で、自分は、do{ break }while(0) の方が良いと思う。
理由は、break した時は、do{ }while(0) の次に処理が進むのがぱっと見で分かる。
do{ }while(0) 内はインデントするだろうし、直感で分かるんですよね。

gotoだとそうはいかない、処理A～処理Dはインデントされないだろうし、
gotoのラベルが全部同じラベルかどうか、gotoの飛び先がどの辺に書かれているかを
目で追わないといけないし。

>>68 さんの場合は、その制御を関数を使って実現していますが、
それだけの為に関数を作るのもどうかと思います。

人によっては大した差じゃないと思うかもしれませんが、自分は糞ソースを沢山
保守してきて、凄く苦しめられてきたので、パット見で、視覚的に処理の流れが
分かるっていうのは凄く重要だと思っています。

516 ：仕様書無しさん：04/06/24 00:22

setjmp/longjmpで例外送出もどき、ってやってる人いる？

517 ：仕様書無しさん：04/06/24 00:24

ret=処理A
if(ret==OK) ret=処理B
if(ret==OK) ret=処理C
if(ret==OK) ret=処理D

ではいかんのか？

518 ：仕様書無しさん：04/06/24 00:27

>>517
>それだけの為に関数を作るのもどうかと思います。

519 ：仕様書無しさん：04/06/24 00:31

return (処理A&&処理B&&処理C&&処理D) ? 1:0;
とか書いてまうけど。

520 ：仕様書無しさん：04/06/24 00:33

>>518
関数切るのが重大事な馬鹿開発には付き合えんな。

521 ：仕様書無しさん：04/06/24 00:36

とりあえず>>515とは一緒に仕事したくないし、
>>515の書いたソースには関わりたくない

522 ：仕様書無しさん：04/06/24 00:37

それ自己満足の世界だな

523 ：仕様書無しさん：04/06/24 00:40

>>513
隊長！DATE_1 = 0, DATE_2 = 1, ... DATE_30 = 29, というのを発見しました！
何故そうしたのかを聞いたらDBから読み出す日付データが0基準なのでずれるからだそうです。
マジで氏ねよと思いますた。

524 ：仕様書無しさん：04/06/24 00:40

>>515
Stateパターンで実装かなあ…Cなら関数ポインタ使えば簡単さ。

525 ：仕様書無しさん：04/06/24 00:41

>>521
同意

526 ：515：04/06/24 00:42

>>517
ありですね^^;
ただし、各処理がある程度の規模なら。2,3行で終わる処理だと．．．

>>519
途中でNGになった時は後の処理をさせない．．．

527 ：仕様書無しさん：04/06/24 00:43

>>526
false && printf("hello\n"

528 ：515：04/06/24 00:44

>>521
>>525
自分だったらどうするか理由も述べて欲しい

529 ：527：04/06/24 00:44

途中で送信されちゃった。
トリッキーだけどNGになったら後の処理は実行されないよ。

530 ：仕様書無しさん：04/06/24 00:46

>>526
>途中でNGになった時は後の処理をさせない．．．
普通の言語なら、FALSE挟まったら以降は処理されないでしょ。

531 ：仕様書無しさん：04/06/24 00:50

まあ、脳梗塞馬鹿が管理やっていると、関数一個追加するのにいちいち
お伺い立てて許可ﾓﾗｳ羽目になったりするからな。

532 ：仕様書無しさん：04/06/24 00:52

小さい関数1個作るのにテスト仕様書3枚書かないといけなかったりな。
ﾊﾊﾊﾊ

533 ：仕様書無しさん：04/06/24 00:57

>>515
do{}while()のくせにループしないのは異常。
ぱっと見でだまされる。あり得ない。

gotoの方がよい。まともなソースならgotoの使い方なんか限られてる。

糞ソースを前提にするなら、そもそも俺はそういうレベルの糞ソースは書かないし、
俺が今後どう書こうが、現存する糞ソースに影響を及ぼさないから語るだけ無駄。

534 ：仕様書無しさん：04/06/24 00:57

#inlucde<stdio.h>void main(){printf（"なぜかｺｿﾊﾟｲﾙできない"）；}

535 ：69式フリーPG ◆hND3Lufios ：04/06/24 01:03

>>533
こういうのを見たことがある。

　　for(i = 0; i < MAXIMUM_HOGE; i++){
　　　　if(i == 0){
　　　　　　：
　　　　　　：
　　　　　 break;　　　　　　
　　　　}
　　　　：
　　　　：
　　}

最初ピンとこなかったんだけど、最初はHOGEの個数だけ処理する
必要があったのを、仕様変更で１つしか処理する必要が無くなり、
こういうことをしたみたいだった。

536 ：仕様書無しさん：04/06/24 01:03

みなさん、そこでlongjmpの出番ですよ。

537 ：仕様書無しさん：04/06/24 01:09

…引数３０個の関数を見た時…orz

538 ：仕様書無しさん：04/06/24 01:11

400以上前のレスへの遅レス返すような池沼あいてになに
マジになってますか？

539 ：仕様書無しさん：04/06/24 01:13

フラグのtrue/false評価を行うif文でネストが7重、1000行超えの
関数を見たとき。

はっはっは、ソースが幾何学模様のようだ！

540 ：69式フリーPG ◆hND3Lufios ：04/06/24 01:14

インデントが画面を往復しているコードも見たことあるなぁ。（80桁）

541 ：仕様書無しさん：04/06/24 01:16

藤原さんのCプログラミング診断室を昔笑いながら読んだ覚えがあるんだけど、

こんどのメンテ対象のソース、アレに載ってたヤツだ…orz

542 ：仕様書無しさん：04/06/24 01:19

>>539
モアレ起きてるっしょ。

543 ：仕様書無しさん：04/06/24 01:52

今度金融系のシステムやるんだけど
random_price()って関数作ってみるよ。
動作に問題なくてもこの関数名に何人が気づきそして俺を止めるのか・・。

544 ：515：04/06/24 02:06

>>515
自分は、
>do{}while()のくせにループしないのは異常。
>ぱっと見でだまされる。あり得ない。
そうですか？、自分はこの、do{ break }while(0) のテクニックを
保守していて知ったのですが、最初はおやっ？と思ったけど、すぐ
理解でましたよ。しかも結構使われているので定石だと思っていました。
なので、これを否定している人がいたので意外でした。

gotoを使っている人のソースは糞が多かったし、gotoを使うのが恥ずかしい
ってのもあるので、自分はこれからも、do{ break }while(0) を使いますね。

>俺が今後どう書こうが、現存する糞ソースに影響を及ぼさないから語るだけ無駄。
これはちょっと意味が分かりません。

545 ：515：04/06/24 02:08

ミスった　
>>533
です。

546 ：仕様書無しさん：04/06/24 02:16

>>515

>>526で
>>>519
>途中でNGになった時は後の処理をさせない．．．
なんて言ってる時点でお前は馬鹿だと露呈したんだから
お前が>>544で何と言おうが全く説得力がない。

547 ：仕様書無しさん：04/06/24 07:12

システム共通
　#define TRUE 1
#define FALSE 0
ある画面
　#define GM_DATALIST_TRUE TRUE
#define GM_DATA_LIST_FALSE FALSE
ある画面
　#define DERRCHK_OK FALSE
#define DERRCHK_ERR TRUE
ある画面
　#define CHK_0 TRUE
#define CHK_1 FALSE
#define CHK_2 FALSE
ある画面
　#define TRUE2 TRUE
　#define FALSE2 FALSE

やめろ、やめてくれぇーーーツ！！！！！！

548 ：仕様書無しさん：04/06/24 08:09

すげー昔FALSE/TRUEを使うのが面倒くさくて
0/1で比較してた時期があった。

549 ：仕様書無しさん：04/06/24 08:11

そういや
enum {
loop_counter_1 = 1,
loop_counter_2,
loop_counter_3,
loop_counter_4,
loop_counter_5,
.
.
.
loop_counter_200
};
というソースを見たことあったっけな。

550 ：549：04/06/24 08:15

で、ソース作ったやつになんでこんなのやったか聞くと
　「そうしないとループが何回回るかわかりにくいじゃないか」

for( i = 0; i < loop_counter_152+1; i++ ) {

じゃあ、なんでここ+1しているんだ？loop_counter_153でいいじゃないか

と聞いたら、
　「いやあ、なんかそのソースバグってて150以降、１回少なく回るんだ。おかしいんだよ、なぜか」

loop_counter_146
loop_counter_147,,
loop_counter_148,
loop_counter_149,
loop_counter_151,
loop_counter_152,
loop_counter_153,
.
.
.
,

551 ：仕様書無しさん：04/06/24 08:34

笑い死にさせるきですか(笑)

552 ：仕様書無しさん：04/06/24 09:12

バカやろう、吹いたじゃねえかｗ

553 ：仕様書無しさん：04/06/24 09:12

>>537
Javaのメソッドで引数130個を見たことある

554 ：仕様書無しさん：04/06/24 09:38

>>544
>gotoを使っている人のソースは糞が多かったし、gotoを使うのが恥ずかしい

技術者なんだからもう少しマシな理由をつけてくれ。

555 ：仕様書無しさん：04/06/24 09:55

gotoに関してはそれについて述べてる奴が置かれてる環境によって
随分意見が分かれてるような気がする。
要するに使い方次第で毒にも薬にもなるってことなんでしょうな。
当たり前すぎてｺﾞﾒﾝ。
ｱｯ！使い方次第で毒になっちゃうようなものは使わないにこした
ことはないか・・・

556 ：507：04/06/24 10:46

>>513
話の流れが変わった後で申し訳ないのだが、
かのソースは
for(i = VALUE_ZERO; i < ARRAY_MAX; i = i + VALUE_ONE){ ... }
とか、
memset(buf, VALUE_FF, sizeof(buf));
なんだよ。

書いた本人に聞いてみると、
「コーディング規約にマジックナンバー使うなってあったから。」
と、おおよそ予定通りの回答。
0にZEROなんて定義名付けたって「マジック」のままで何も解決して無いじゃんと
諭してみるけど、効果なし。

ついでにループカウンタ回すのはインクリメント演算子使った方が
わかり易くないか？と問うたところ、
「前置と後置で作用の違いを考えるのがめんどくさいから。」
とのたまう。まあ、こっちは許容範囲かなぁと思うけど。

557 ：仕様書無しさん：04/06/24 10:51

職業プログラマってそんなんでもやってけるんですか

558 ：仕様書無しさん：04/06/24 11:00

>>557
やっていけるよ。

559 ：仕様書無しさん：04/06/24 11:10

>>557
残念ながら。
職業人としての判断は、
「このようなコードが存在するのは、コード記述者のスキルの問題もさることながら、
スキル管理および品質管理の不在という組織体制の不備に起因する」だ。
だから「この会社辞めよう(ry」というスレタイが正しいわけだよ。わかったかな（ｗ

560 ：仕様書無しさん：04/06/24 12:27

「フラグ変数の使いまわしによるバグが多発していたため、
変数名の先頭に業務名を示すフラグをつけることで
使用フラグの衝突を防止します」

int LGN_IFlg0001;
int LGN_IFlg0002;
int GSG_IFlg0001;
char GSG_CFlg0002;
...

惜しいな、「各業務画面はマルチスレッドで複数動作する」
という仕様がなければうまくいったかも知れない(藁

561 ：仕様書無しさん：04/06/24 12:31

>>556
>0にZEROなんて定義名付けたって「マジック」のままで何も解決して無いじゃん

これには同意するが

>「前置と後置で作用の違いを考えるのがめんどくさいから。」
>とのたまう。まあ、こっちは許容範囲かなぁと思うけど。

こっちは同意できない。
このケースの場合、どう考えても作用の違いが影響しないし。

562 ：仕様書無しさん：04/06/24 12:45

＞こっちは許容範囲かなぁと思うけど

こんな>>556を世間は許容できません

563 ：仕様書無しさん：04/06/24 13:34

俺はgoto使って糞になっているソースを見てみたい…
いや、作れといわれれば簡単に作れるけどさ
現実にそんな奴がいるとは思えな…

いや、事実は消毒よりキアリー

564 ：仕様書無しさん：04/06/24 13:37

>>563
構造化構文が存在しない昔の言語だと全然珍しくないのだが

565 ：仕様書無しさん：04/06/24 14:09

なんでもかんでも
グローバル変数

566 ：仕様書無しさん：04/06/24 14:13

N-BASICなら普通ですけど？

567 ：仕様書無しさん：04/06/24 14:25

いまN88BASICのシステムのメンテやれって言われたら
そりゃ辞めようと思うわな（ｗ

568 ：仕様書無しさん：04/06/24 14:25

>>566

いや、Cです

569 ：568：04/06/24 14:27

追記
tmp_hogehoge
って変数がわんさかありました

570 ：仕様書無しさん：04/06/24 18:07

>>515(528)
525です

遅レス申し訳ない。
自分はたいてい>519 氏と同じように、&&で連結して書いてる。
処理のボリュームによっては関数化もする。

自分が>521氏に同意したのは、まぁ単純に
>Cの場合、goto か do{ break }while(0) しか方法がないと思う。
と･･･『しか方法がないと思う』といきなり断定しちゃう姿勢が気
に入らなかったからだ。
経歴長いくせに糞ソース書き散らかす奴ってのは、自分のコーデ
ィングスタイルに根拠のない自信をもち、より一般的なわかりや
すいコーディングスタイルというものを探求する気持ちを失って
しまった奴だ。あなたにはそういう奴の匂いを感じた。
（ぱっと見ってか直感でね）
とりあえずそういう奴とは一緒に仕事したくないし、そういう奴
の書いたソースには関わりたくない。まぁそんな理由だ。

他にもいろいろ書こうと思ったけど、
>526
> >>519
> 途中でNGになった時は後の処理をさせない．．．
とか書いてあるのをみた時点であほらしくなった。まず、言語仕
様をよく勉強してください。社内の糞ソースだけを頼りに勉強す
るのはやめたほうがいいですよ。

571 ：仕様書無しさん：04/06/24 19:47

>>544
最初はおやっと思ったんなら、ぱっと見で騙されたって事だろ。
gotoだって>>515のような使い方ならすぐに理解できるはずだ。
べつにdo{}whie(0)がよい記述法だから理解できたわけではない。
単にロジックが単純だから理解できたんだよ。

そもそもdo{}while(0)と、そこら中に飛びまくるgotoを比較することが間違い。
後者の方がロジックが複雑なんだから理解しがたいのは当たり前。

だいたいdo{}while(0)が定石だと思っているのもおかしい。
入門書でそんな書き方を見た事あるか？

572 ：仕様書無しさん：04/06/24 20:16

たしかに571みたいな未だ入門書のレベルに居る奴には定石ではないかもな。

なーんて言ってみたりして☆

573 ：仕様書無しさん：04/06/24 20:30

とりあえず、こっち行っとき。
goto文を恐れなく使う兵達のスレ
http://pc5.2ch.net/test/read.cgi/tech/1021364372/l50

574 ：仕様書無しさん：04/06/24 20:38

おいおい、do{}while(0) ずいぶんとバカにしてるけど。
PHPのマニュアルにも載ってるぞ、しかも
「優れたCプログラマは、コードブロック中での実行中止が可能な
do..whileループの別の使用法について熟知しているかもしれません」
だってよ！
http://jp.php.net/manual/ja/control-structures.do.while.php

まあ、俺もgotoは嫌いだな。gotoを使ったソースを新人が保守してみろ、
なんだぁgoto使ってもいいんじゃんって、安易にgoto使う奴が増えそうで。

return (処理A&&処理B&&処理C&&処理D) ? 1:0;
は可読性わるいよ。

575 ：仕様書無しさん：04/06/24 21:11

? 1:0;って必要なのか？

576 ：gotoラブラブ：04/06/24 21:44

int hoge()
{
...

if (あんな) {
goto ERR_ANNA;
}
...
if (こんな) {
goto ERR_KONNA;
}
...
return nomal_stat;

ERR_ANNA:
後処理;
return err_anna;
ERR_KONNA:
後処理;
return err_konna;
}

こんなのは良くやるけどなぁ

577 ：仕様書無しさん：04/06/24 21:48

>>576
int hoge()
{
...

if (あんな) {
後処理;
return err_anna;
}
...
if (こんな) {
後処理;
return err_konna;
}
...
return nomal_stat;
}
ではイケナイ理由は？

578 ：gotoラブラブ：04/06/24 21:55

>>577
ｽｸﾛﾙﾏﾝﾄﾞｲ…というのは半分ウソで、上から読んでいったときにエラー処理の
コードを読んで、メイン処理の思考を中断するのがうざいから

579 ：仕様書無しさん：04/06/24 22:04

>>578
goto文みた時点で思考がぶてぃきれる漏れは甘い？

580 ：仕様書無しさん：04/06/24 22:04

>>575
論理演算の結果が真のとき値が1になるのなら不要だな

581 ：gotoラブラブ：04/06/24 22:11

>>579
ある意味、そのためのgoto

上から読んで行って

>if (あんな) {
ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

>goto ERR_ANNA;
>}
('A`)

こういう気分にするため。

582 ：仕様書無しさん：04/06/25 00:19

Select ... From ...
Where DATEPART(year, DATE_E ) Between :intYearF And :intYearT
And DATEPART(month, DATE_E ) Between :intMonthF And :intMonthT
And DATEPART(day, DATE_E ) Between :intDayF And :intMonthT

こんなプログラムが現役です。Σ(ﾟρﾟ；)

わざわざ、日付を年、月、日に分解してまで何の範囲で抽出したいのでしょう？
入力する日付の範囲は特に制約ありません。月がまたいだら、ボロボロな結果になります。

多分、作った人は、
Where DATE_E Between :datDateF And :datDateT
にすると、datDateTの時刻部分が0:00:00以外だと、選択から外れるから
わざわざDATEPARTにしたんだと思う。
でも完全に使い方間違ってるよ。

583 ：582：04/06/25 00:21

4行目の :intMonthT は単純に :intDayT の間違いね。

584 ：仕様書無しさん：04/06/25 01:45

ここだけの話ですが
先月、株式会社○○システムソリューションに納品した
経営戦略システムですが・・・

単体テストはまったくやってません。
というかコンパイル時の警告も全部取り除いていません。
おぼえがきとかのコメントが残ったままです。
間に合わないんでいきなりシステムテストやりました。

ごめんね。

585 ：仕様書無しさん：04/06/25 02:07

安心しる。
納品*後*に客先で単体テストなんかザラだ。
ていうか納品後に要件変更とはこれいかに。

586 ：仕様書無しさん：04/06/25 02:17

おまえら凄いな

587 ：仕様書無しさん：04/06/25 03:08

ねえここまでソフトウェア業界がぐだぐだなのって、
日本だけなの？　どこでも似たようなもんなの？

588 ：仕様書無しさん：04/06/25 03:36

設計は新卒SEが、実装は派遣PGが、という腐ったシステムはたぶん日本くらいだろう。

589 ：69式フリーPG ◆hND3Lufios ：04/06/25 03:39

>>582
ﾜﾛﾀ
>>356みたいなのはみたことあるけどね。

590 ：仕様書無しさん：04/06/25 09:53

>>587
設計はおろか、要件定義まで丸投げしているのは日本ぐらいという話は聞いた事がある。
アメリカあたりだとエンドの情報システム部がきちんと設計までするそうな。
そのためにある程度の企業になると、設計の出来るSEを漁ってた時期があったとか。

591 ：仕様書無しさん：04/06/25 12:10

>>574
というか、GNUなソースを見るとマクロ定義の中には大量にあった。
そっち系では一般的なのか。

ところで、do{ ... }while(0);駄目って言ってるのは、ループの構文を
ループに使わないのがいかんのだよね。
前に途中でreturnで脱出するのも嫌ってる意見があったが。

592 ：仕様書無しさん：04/06/25 12:58

C に

・複文に名前を付けられる
・break で脱出するブロックを指定できるようにする

という機能があればいいんだよね。

593 ：仕様書無しさん：04/06/25 14:17

>>592
goto程度にひどいことになりそうな希ガス

594 ：仕様書無しさん：04/06/25 14:26

>>593
Adaにある構文だからいいんじゃね？
break(2); よりよっぽどマシ

595 ：仕様書無しさん：04/06/25 14:37

>>553

ま、まぢっすかｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
引数だけでインデントが必要なのか…

596 ：仕様書無しさん：04/06/25 14:41

>>595
Javaって構造体が無いから（ｗ
クラスがあるけどね

597 ：仕様書無しさん：04/06/25 15:00

関数アドレスのテーブルでいいじゃん。

598 ：仕様書無しさん：04/06/25 15:27

>>594
可読性が。入れ子の中が外にいきなり飛び出したり、手前のbreakより入れ子のbreakのが
より外に飛び出すのとかって・・・。

だいたい３重以上の多重ループを使ってるやつはそれだけで問題だ。

599 ：仕様書無しさん：04/06/25 15:31

>>598
なぜ３重以上だと問題なんだ？そんなものはケースバイケースだろうが。

600 ：仕様書無しさん：04/06/25 15:48

まぁ Stackちっくに、
ちゃんと順番に抜ける方がわかりやすいよな。

601 ：仕様書無しさん：04/06/25 16:04

可読性が、という話になったらbreak自体が相当性質が悪い
まず、どこに飛ぶかわからない
インデントが最初に低くなった場所と思ってたら
ifによるインデントは無視するから、結構はなれてたりする

結局、breakがどこに飛ぶかをみるには、
ソースの前に戻ってfor, while等を探す
そしてそれに対応する括弧を探すと2ステップ必要になる
さらに、breakを見逃しててループ追加するとバグの温床になる

breakが優れているのは可読性じゃなく筆記性
ラベルつけなくていいからねぇ

602 ：仕様書無しさん：04/06/25 16:07

結局、そのためのコメントを書いたり。

603 ：仕様書無しさん：04/06/25 16:09

動けばいい・・・最近つくづくそう思うようになってきた。

604 ：仕様書無しさん：04/06/25 16:15

>>603
末期症状

605 ：仕様書無しさん：04/06/25 16:23

頼むから動いてくれ・・・毎日お祈りしてます。

606 ：仕様書無しさん：04/06/25 16:41

>>599
誰にも見せないプログラムというケースならどう書いても動けばいいが。
他人がみなきゃならんから問題なのだよ。

607 ：仕様書無しさん：04/06/25 17:05

breakの可読性とか、３重ループごときが問題とか、
なんでバカにあわせて、コードを書かなきゃならんのだ？

608 ：仕様書無しさん：04/06/25 17:11

>>601
break の使い方を理解していないのか？それとも釣りか？

609 ：仕様書無しさん：04/06/25 17:12

職業としてプログラムを書くのなら、読める人間の比率を最大にするように書くべし

610 ：仕様書無しさん：04/06/25 17:41

>>607
バカにあわせないとトラブルが起きるから。
コーディング規約がなんで生まれたかも理解できないような環境にいるとわからんだろうが。

611 ：仕様書無しさん：04/06/25 17:47

>>609
プログラムを知らない奴には読めません、どう書いたって。

612 ：仕様書無しさん：04/06/25 17:50

今まさに目の前に

　　while (TRUE) {
　　　　switch (～) {
　　　　　　case 1:
　　　　　　　　for (～) {
　　　　　　　　　　if (～) {
　　　　　　　　　　　　break;
　　　　　　　　　　}
　　　　　　　　}
　　　　　　　　if (～) {
　　　　　　　　　　continue;
　　　　　　　　}
　　　　　　　　break;
　　　　　　case 2:
　　　　　　　：
　　　　　　　：　(for と continue と break のつづれ織りが10回ほど)
　　　　　　　：
　　　　}
　　}

こんなのがあるんだが
　1. break が switch/while/for のどれに対応するのか判り辛く
　2. そのくせ continue は switch を飛び越して while に戻る
ここまで汚いコードが書けるなんて、C もまだまだ深いな…

613 ：仕様書無しさん：04/06/25 17:52

>>612
その程度のコード、普通に読めよ……

614 ：仕様書無しさん：04/06/25 18:17

くそ汚い部屋に住み続けてると普通に汚い程度じゃ何も感じなくなるってことか

615 ：仕様書無しさん：04/06/25 18:23

>>612
2番目の項目は分からないこともないが、

>　1. break が switch/while/for のどれに対応するのか判り辛く

そんなの分からないのお前だけだ。

616 ：仕様書無しさん：04/06/25 18:31

ここは、コードの読解力のないバカどもが、
傷を舐め合うスレですか？

617 ：仕様書無しさん：04/06/25 18:46

へへん。>>612程度のソースなんて簡単ジャン。
こんな程度を「汚い」って言う奴は馬鹿にしてやろう。
・・・という心の声が聞こえる気がしたぞ

「複雑さを理解出来る度合い」には個人差があることを知れ
そしてPGが相手にするべき困難さの筆頭に「複雑さ」があることも

618 ：仕様書無しさん：04/06/25 20:04

>>611
だから一切の努力を放棄するわけですか?
言い訳が下手糞すぎますね :-P

619 ：仕様書無しさん：04/06/25 20:21

>>612を見てこれを思い出した。

ttp://www7.plala.or.jp/takamura/program/poor04.html

620 ：仕様書無しさん：04/06/25 20:27

タブ2とかタブ4の奴が書きそうなコード

621 ：仕様書無しさん：04/06/25 21:43

>>591
複数の文をマクロに入れるときの定石。ここで話されている途中breakとは関係ない。

#define a do { x; y; z; } while(0)

if (flag)
a;

みたいに書いても問題がない。

622 ：仕様書無しさん：04/06/25 22:43

3重のループに関しては漏れも同意する。
そういうのは関数(もしくはメソッド)に切り分けるべき。
3次元の座標を扱ってループさせるみたいな処理は別だけど。

関数指向ってのは別に共通の処理を一箇所にまとめるだけじゃない。

623 ：仕様書無しさん：04/06/25 23:26

...
i++;
array[i-1][0] = 0;
array[i-1][1] = 0;
...

なぜそこでi++する？

624 ：仕様書無しさん：04/06/25 23:37

本物のプログラマは第一作目のハーマイオニーが一番好きだ

625 ：仕様書無しさん：04/06/26 00:24

プログラマーなら
できるだけきれいなコードのみ書くよう努力して
できるだけ汚いコードも読めるよう努力するべきだろ？

俺には無理だが

626 ：仕様書無しさん：04/06/26 00:28

>>625
物には限度というものがある

627 ：仕様書無しさん：04/06/26 00:29

まあ、汚さが次元を超越しているコードというのも
確かに存在する。

628 ：仕様書無しさん：04/06/26 00:44

穴埋めの課題として出されたプログラム、
for(){
  for(){
    if(){
      if(){
        if(){
        }else{
          if(){
            if();
            if(){;}
            if(){;}
          }
......この後、最初のfor()が終わるまでにif,elseがまだ続く

助けて('A`)
課題として適してないだろ・・・

629 ：仕様書無しさん：04/06/26 00:48

>628
きっと「このようなプログラムは書いてはいけません」が正解なんだよ…orz

630 ：仕様書無しさん：04/06/26 01:12

>>628
課題として適してない職場であることを祈ろう

631 ：仕様書無しさん：04/06/26 14:06

>>343

632 ：仕様書無しさん：04/06/26 18:47

>>343
>>367

633 ：仕様書無しさん：04/06/26 18:56

= >>710

634 ：仕様書無しさん：04/06/26 19:29

>>631-632 なにがやりたいのやら。
とりあえず1行修正のきかない>>367は全撤去

635 ：仕様書無しさん：04/06/26 19:35

>穴埋めの課題として出されたプログラム

実はリファクタリングの例題なのさ
元の動作を壊さずに、理解しやすい形になるまで分解すればよい

636 ：仕様書無しさん：04/06/26 21:18

>>634
>>375で既出

637 ：仕様書無しさん：04/06/26 22:04

世の中、リファクタリングの例題だらけだよ･･･。

638 ：仕様書無しさん：04/06/26 22:24

>>628は、forがシンプルな2段で、中身は条件分岐だけじゃん。
これ以上、リファクタリングで何か良くなるとは思えないが。
別関数にわけても、見た目はシンプルになるが、動作は追いにくく
なるだけじゃないの。
やろうとしていることが複雑なら、コードはその複雑さより簡単に
なるわけないし、そういうコードを追えないようでは使い物にならない。

639 ：仕様書無しさん：04/06/26 22:35

＞別関数にわけても、見た目はシンプルになるが、動作は追いにくく
＞なるだけじゃないの

あふぉでつか

640 ：仕様書無しさん：04/06/26 22:37

>>638
>やろうとしていることが複雑なら、コードはその複雑さより簡単になるわけない
へぇ

641 ：仕様書無しさん：04/06/26 22:44

Aが１でBが４，６，１２，２２
Aが１でBが５でCが２，３，１９かDが９
Aが１でBが６か３０でDが７より大きい
場合は１を、・・・なら２を・・なら３

て仕様が１０００項目も並ぶのがバッチ系

だが、VBで５０００行はねえだろ前の前の担当よ

642 ：仕様書無しさん：04/06/27 00:20

>>638
>>別関数にわけても、見た目はシンプルになるが、動作は追いにくく
>>なるだけじゃないの。
>>やろうとしていることが複雑なら、コードはその複雑さより簡単に
>>なるわけないし、そういうコードを追えないようでは使い物にならない。

処理手順を整理し、段階区切って意味を考え、インタフェースを決めて関数化すれば
動作を追う場合に突き止めたい事に関係ない部分までなめなくても済む。

ひょっとしてCOBOLerの方？
全てグローバル変数渡しのサブルーチンだったら確かに言うとおりだねｗ

643 ：69式フリーPG ◆hND3Lufios ：04/06/27 00:28

関数化したほうがコールスタックで流れを追いやすいかもね。

644 ：仕様書無しさん：04/06/27 00:32

>>638
「動作を追う」？違う。
論理構造とデータ構造を把握せずに「動作を追う」のは
木を見て森をみないのと同様だ

645 ：仕様書無しさん：04/06/27 00:46

相変わらず関数化もままならないｺﾎﾞちゃんがいるｽﾚ

646 ：仕様書無しさん：04/06/27 00:51

>>601
Javaのbreakはラベルをつけられるんだよね。
方向性としては、これは便利だと思う。
一方でローカルのStatic変数を無くしたのは
もったいないと思うが。

647 ：仕様書無しさん：04/06/27 00:57

>>647
goto とどう違うんでつか？

648 ：仕様書無しさん：04/06/27 01:00

gotoのように無闇に飛び先を設定できない
(具体的には後ろにしか抜けない)から
gotoのようなスパゲティコードになる可能性が低い。

649 ：仕様書無しさん：04/06/27 01:04

>gotoのようなスパゲティコードになる可能性が低い

なんとかの一つ憶え
スパゲティコード==goto

650 ：仕様書無しさん：04/06/27 01:07

可能性が低いのは事実ですが何か？
お前こそ脊髄反射レスしてんじゃねーよ。

651 ：仕様書無しさん：04/06/27 01:12

俺はgccの独自拡張の関数内関数を入れてくれたほうが嬉しいかなぁ…
breakの変わりに関数作ってreturn使えば割と解決する場合が多いんだよね
かといって、クラスとして新たに関数追加するのも面倒…

あと、前に戻るgotoはここ5年ほど使う場面に出くわしたことがない
大概、do～while構文で間に合うことが多い

てか、gotoのデメリットとしてよく言われるスパゲティコードだが、
breakでスパゲティ作られている方が圧倒的に多いと思う

652 ：仕様書無しさん：04/06/27 01:12

おまえら子どもみたいな煽りあいして楽しいですか

653 ：仕様書無しさん：04/06/27 01:17

>>651
>てか、gotoのデメリットとしてよく言われるスパゲティコードだが、
>breakでスパゲティ作られている方が圧倒的に多いと思う

それは「gotoを使うな！」といい続けた結果gotoの量が少なくなっただけ。
「breakやcontinueも使うな！」といい続ければbreakの量も減ってスパゲティも減るだろう。

654 ：仕様書無しさん：04/06/27 01:17

少年の心を忘れない大人が集うスレはここですか。

655 ：仕様書無しさん：04/06/27 01:18

楽しいなぁ

656 ：仕様書無しさん：04/06/27 01:37

「スパゲティを作るな！」

657 ：仕様書無しさん：04/06/27 01:46

普通の人が書くソース
for(int i=0;i<10;i++){
　if(a[i]==0) break;
a[i] = i;
}

>>653が書いたソース
for(int i=0;i<10;i++){
　if(a[i]==0){i=10;}
else{a[i] = i;}
}

658 ：仕様書無しさん：04/06/27 01:47

「日本人なら米を食え!」

659 ：仕様書無しさん：04/06/27 01:51

>657

for(int i=0;i<10;i++){
　if(a[i]==0){
　　ループの次にやりたい処理
　　 :
}
　else{a[i] = i;}
}
ループの次にやりたい処理
:

660 ：仕様書無しさん：04/06/27 01:51

>>657
ループ中にループ抜ける条件が変わるなら
do　while使えばいい

661 ：仕様書無しさん：04/06/27 01:52

「釣ったら食え！」

662 ：仕様書無しさん：04/06/27 01:55

>>657
知障？>>653の意味すら汲み取れないなんてマジで心配なんだけど。

gotoの害はさんざん言われてるから変なgotoは比較的少ない。
breakやcontinueの害はあまり言われてないから変なbreakやcontinueはまだまだあるところにはある。

無闇に使うなと全く使うなの区別もつかないなんて。

663 ：仕様書無しさん：04/06/27 01:58

>662 心配性な方でつね素敵(はぁと)

664 ：仕様書無しさん：04/06/27 02:02

　　　　∩＿＿＿∩
　　　　| ノ　　　　　ヽ-'''''';、　いろいろ餌がでてくるけどさ、
　 ,,.....-|　　●　　　● |　　）　正直クマもおなかいっぱいなのよ…。
”” ;　　|　　　　( _●_)　ミ　　　　　§
　 ;;　　彡､　　　|∪|　　､｀＼＿_===・
　;　　/　＿＿　ヽノ　/´　――┴;;
　;　　(＿＿＿）　　　 |　　―――'"
　￣￣￣￣￣）　,,..-'''⌒;,　　　/
　￣￣￣￣／　　　 ,,..-.';;-'　｜
　　　　　　　（　　,,...-''";;.,　";,..-'"
　　　　　　　|"””　　 _,.-|;　 ;|
　　　　　　　|_,,...--''" 　"'-''"
―――――'"

665 ：仕様書無しさん：04/06/27 02:02

>>662
マジで言ってるんだったら、他人に迷惑かける前に
（もうかけまくってるんだろうが）プログラマという職業を
辞めてくれ。

チームに馬鹿がいると、邪魔なの。

666 ：ﾀﾞﾐｱｿ：04/06/27 02:04

667 ：仕様書無しさん：04/06/27 02:08

goto=スパゲティなんて言ってる奴は
80年代からタイムスリップしてきたとしか思えないんだが

これだから最近の本を読んでないとしよりは嫌だよなぁ～
現役のコボちゃんかしら？

668 ：仕様書無しさん：04/06/27 02:11

また「gotoの害」かよ。そして「breakやcontinueの害」まで出てきたか。
そんなもん無い。そういう害があるように見えるだけだ。
元凶は「関数がでかすぎるという害」だろ。

669 ：仕様書無しさん：04/06/27 02:18

>668
>元凶は「関数がでかすぎるという害」

元凶は「設計できてない」だな

670 ：668：04/06/27 02:30

>>669 そう。
関数がでかすぎるという害 : 観察結果
設計できてない : 観察結果から導き出される、問題の表明

といったところ

671 ：仕様書無しさん：04/06/27 02:40

>>667
は、はちじゅうねんだい？お前も10年ほど遅れとるぞ。

672 ：仕様書無しさん：04/06/27 02:42

>>667
ぷぷぷっ８０年台なんてＣすらできないっつーのｗｗ

673 ：仕様書無しさん：04/06/27 02:52

>>672
そんなエサで俺様が(ry

674 ：仕様書無しさん：04/06/27 02:57

>672
C言語:1972年頃にDennis M. Ritchieが開発した
です。

goto=スパゲティって話も80年代の話と違うが(w

675 ：仕様書無しさん：04/06/27 03:08

>>674
会社で、C言語が1972年頃できたって話題なったから
「俺といっしょじゃん俺1972年生まれだよ」って言ったら
UNIXヲタの童貞くんに露骨に嫌な顔されたよ。そんでそいつに
そんなことはたいしたこと無いって必死に否定されたよ・・・
アホらしい事思い出した・・・

676 ：仕様書無しさん：04/06/27 03:22

>>647
>goto とどう違うんでつか？
>>647のようなことが起きません。

677 ：仕様書無しさん：04/06/27 03:35

>>674
ぐぐってみたら、あの"Go To Statement Considered Harmful"って
1968年なのね…。

678 ：仕様書無しさん：04/06/27 03:41

タイトルコメントにKANEBOと書かれていた。
不審に思い、仕様書を見たら「鐘紡」とかかれていた。
先輩に聞いたところ、あのカネボウで間違いないらしい。

しかもΣ(・A ・ ) ｿｰｽｷﾀﾅｲ!!

679 ：仕様書無しさん：04/06/27 05:33

>>676
それがラベル付きだと…って話かと。

680 ：仕様書無しさん：04/06/27 08:18

で、おまいらいつまで「スパゲティソース」なんて
オッサン言葉使っているんでつか？

今の若者は、そんなこと言いませんよ。

今の若者は、
↓

681 ：仕様書無しさん：04/06/27 08:29

パスタソース

682 ：仕様書無しさん：04/06/27 08:30

ボンゴレ

683 ：仕様書無しさん：04/06/27 08:45

スバグェッティ

684 ：仕様書無しさん：04/06/27 09:02

TK-80が1976年だよなぁ
I/O創刊が78年だっけ？

10年前からGoToの弊害だけは指摘されてたの？

685 ：仕様書無しさん：04/06/27 09:15

BASIC自体はその10年前からあったと思う。
goto が実装されていたかどうかは知らないけど

686 ：仕様書無しさん：04/06/27 10:06

>>684
そうらしい。1968年にEdsger W. Dijkstraが "Go To Statement Considered Harmful"
http://www.acm.org/classics/oct95/ を発表して一大論争になったのだ、と
長老が言っておった。

687 ：仕様書無しさん：04/06/27 10:58

n88basicはgotoやgosubだけで、関数という概念が無かった気がする。
だからgotoはあらゆる部分に飛べるから、使いまくると確かにスパゲッティコードになってた。

Cとか関数内しかgoto先にならないような言語では、スパゲッティが出来ても
所詮その関数内だけなんだよね。

だから、Cでgoto使うのは対した問題ではないと思ってる。
main関数に全ての処理を書く、とかされたら泣いちゃうけど。

688 ：仕様書無しさん：04/06/27 11:37

>>687
n88basicにも deffn がありますよ。1行の数式をユーザー関数化するものなので、あんまり使い物にならないですけど。

Cでのgotoが関数内限定といっても、
構造化プログラミングの要素である「分岐」・「反復」の範疇に入るgotoは許せるけど、
ifやforなどのブロック内に飛び込むといったのは許せないなぁ。
for ループの中に飛び込む switch なんて論外…。

個人的には、脱出のための goto だけは通してる。元々、break、return といった構文があるわけで、その延長上って感じで。

FILE *fp = NULL;
int *ptr = NULL;
if ((fp = fopen(ほげほげ)) == NULL) goto err;
if ((ptr = malloc(ほげ)) == NULL) goto err;

(通常処理)

:err
free(ptr);
if (fp) fclose(fp);
return

みたいな感じ。

こういうのをまじめに if で囲っていくと、どんどん深くなってよけい見にくいと思う。

689 ：仕様書無しさん：04/06/27 11:50

gosub使えば関数とほとんど一緒じゃん

690 ：仕様書無しさん：04/06/27 12:05

N88 のレベルになると GOSUB *FOO とかラベル使えるしね。
でもグローバル変数の呪いから逃れられない

691 ：仕様書無しさん：04/06/27 14:10

グローバル変数しかない、とか
変数とかに好き勝手な名前が使えない、とか
昔の言語ではいわゆるプログラム設計が重要だった

だからといって今時の言語で同じように設計するな!ﾔﾒﾃｸﾚ!
なんだよ変数 XXXX0099 って...

692 ：仕様書無しさん：04/06/27 15:15

メソッドの戻り値を文字列で返すプログラムを渡された。
全部のメソッドがそうなっている。

char *getTitleName()
{
　　if (this->titleName)
　　　　return this->titleName;

　　return "未設定";
}

693 ：69式フリーPG ◆hND3Lufios ：04/06/27 15:20

80年代初頭もスパゲッティプログラムという言葉はあったし、
それはBASICやアセンブラで無茶苦茶なgoto(jump)しまくるコードの
ことを言ってたような気がする。
あの頃はgoto, gosub(jmp/call)をわかりやすく組むのがマナーとされていて、
禁止というわけじゃなかったな。つか、禁止されたら何も出来んｗ
PCの世界でgoto禁止と言い出したのは、LatticeCやTurboPascalが普及してきた
80年代後半じゃないかな。

694 ：仕様書無しさん：04/06/27 15:24

>>693
爺氏ね

695 ：仕様書無しさん：04/06/27 15:50

>>692
ケータイ開発だと、グローバル変数（staticではない）を
返す関数が山のようにあるのが常識ですが、何か？

つーか、static変数ならともかくグローバル変数なのに
値の取り出し、参照が全部関数化されているこのケータイって・・・

696 ：仕様書無しさん：04/06/27 16:20

>>692
MFCだとCStringの返り値で関数を書くことが結構多いけど、それって問題かな？

697 ：仕様書無しさん：04/06/27 16:36

MFCだとCStringの返り値で関数を書く、とは一体どゆこと？

698 ：test：04/06/27 16:51

test

699 ：仕様書無しさん：04/06/27 16:51

MFCだとCStringの返り地で関数を書く、ということじゃないかと思われる。

700 ：仕様書無しさん：04/06/27 16:54

MFCだとCStringの返り地、ってどういう意味？
返り値じゃないのか？
関数を返り値ってどういう意味？？？

701 ：仕様書無しさん：04/06/27 17:02

CStringの返り値で関数を書く？

返り値がCStringの関数を書くってこと？

日本語おかしくない？おかしいのは俺？

702 ：仕様書無しさん：04/06/27 17:12

MFCだとCStringの返りに、血で感数を書くことが結構で、
多い日も安心という意味であろう、おそらくたぶんきっと必ず。

と思う。

703 ：仕様書無しさん：04/06/27 17:24

それよりもwin開発でしか通用しない、CStringとやらを説明してクレ
推測は容易だが、推測前提でレスできんし

704 ：仕様書無しさん：04/06/27 18:08

てか、スパゲティの根本ってBASICの実行速度が遅いってのもあったね
そのお陰で、速くて難解なプログラムが尊重されていた時代でもあったし

705 ：後藤：04/06/27 19:05

なんだか貶されてるな…

706 ：仕様書無しさん：04/06/27 19:07

「CStringの返り値」って言語があるんじゃない？

707 ：仕様書無しさん：04/06/27 19:27

CStringの返り血で書く、とかだったら呪いの呪術っぽくてよいね

708 ：仕様書無しさん：04/06/27 20:00

呪いの呪術って何だよいったい。
CStringの返り血が血文字で呪いのサバトかよ。意味わかんねぇよ。

709 ：仕様書無しさん：04/06/27 20:14

「呪いの呪術」って「腹が腹痛」みたいな感じだな

710 ：仕様書無しさん：04/06/27 20:31

まじないの呪術とか。

711 ：仕様書無しさん：04/06/27 21:29

スパゲッティソースって言い方はやめゆお

キミの部屋の電気コード風味ソース

でいいじゃないか

712 ：仕様書無しさん：04/06/27 21:29

ここ、哲学スレかなんか？

713 ：仕様書無しさん：04/06/27 21:31

void hoge(void)
{
}

な関数使ってる場合、全てグローバル変数・構造体で処理が書いてあって・・・
('A`)
グローバル変数がどう動いてるか分かる術はありまつか('A`)?

714 ：仕様書無しさん：04/06/27 21:35

無いぞ（ｗ
デバッガによっては特定の変数が変更されたときブレークするものもあるけど

715 ：仕様書無しさん：04/06/27 22:01

>713
グローバル変数を直接読み書きせず、げったーせったー経由汁！

716 ：仕様書無しさん：04/06/27 22:56

>>715
それができる奴はそんなことせん。

717 ：仕様書無しさん：04/06/27 23:06

血で血を洗うソースコード

718 ：仕様書無しさん：04/06/28 00:22

CString ≒ std::string

719 ：仕様書無しさん：04/06/28 00:39

>>717
昔のプロジェクトを思い出したorz

720 ：仕様書無しさん：04/06/28 02:03

>716

>全てグローバル変数・構造体で処理が書いてあって・・・
>グローバル変数がどう動いてるか分かる術はありまつか
って質問だろ？

721 ：仕様書無しさん：04/06/28 02:11

goto 文を使わなくても、
最後に他の関数を呼び出す関数を大量に作成することで
goto文に負けないくらいの可読性を実現できることを最近知り、
目から鱗でした。ある意味、感動しました。

722 ：仕様書無しさん：04/06/28 03:49

>>720
だから外側から何とかできないと意味ないだろってこと。

723 ：69式フリーPG ◆hND3Lufios ：04/06/28 03:51

そのグローバル変数をトレース出力するマクロを、全コードに一行おきに挿入。

724 ：仕様書無しさん：04/06/28 11:45

>717
血で皿を洗うソースコード
に見えた徹夜明け

725 ：仕様書無しさん：04/06/28 12:31

もう、グローバル変数が使える言語は時代遅れだと思うがどうよ

726 ：仕様書無しさん：04/06/28 12:34

globalというクラスのpublic staticな変数に移行するだけと思われ

727 ：仕様書無しさん：04/06/28 12:37

因みに、ネパール語でウンコの事を、｢ゴーバル｣という。

728 ：仕様書無しさん：04/06/28 12:38

>>726
図星だ。

729 ：仕様書無しさん：04/06/28 18:04

＞７２６
変数だけ集めた「グローバル変数クラス」なるものを作って、
ほかのクラスで変数を使うときには必ずそこのを利用するってこと？

730 ：仕様書無しさん：04/06/28 18:20

class GlobalVal {
public:
　static　int　nFlag0001;　
　static　int　nFlag0002;
};

731 ：仕様書無しさん：04/06/28 19:09

こんなのやだよーw
でも作る奴はいるんだろうな。
こうやってバカは綿々と受け継がれていくんだな……

732 ：仕様書無しさん：04/06/28 19:40

全メンバがstaticなクラス1つだけで構成されたプログラムとか作りそうな勢いだな。

733 ：69式フリーPG ◆hND3Lufios ：04/06/28 19:54

全てのメンバがpublic staticのDataDivisionクラスとかProcedureDivisionクラスとか
あったりして。

734 ：仕様書無しさん：04/06/28 21:13

亀レスだがすごいことを発見。

>>459
そのソース見たことある＿|￣|........

735 ：仕様書無しさん：04/06/28 21:38

>730
バッドノウハウ...

736 ：仕様書無しさん：04/06/28 22:27

>>730
なんだか、コボちゃんが好きそうな気配が…

737 ：仕様書無しさん：04/06/28 22:32

>>692
戻り値がchar*自体は問題なし。C言語の標準関にだってある。
ただ、titleNameはおそらくprivateだと思うが、戻り値にconst付けないと意味無し。

>>696
全く問題なし。CString::Left の戻り値だってCStringだから。

738 ：仕様書無しさん：04/06/28 22:34

>>737
そういう問題じゃ・・・・

739 ：仕様書無しさん：04/06/28 22:38

COBOLerってそんなにクズなの？
ていうかCOBOLってどんな言語？

740 ：仕様書無しさん：04/06/28 22:40

>>739
DIVISION

741 ：仕様書無しさん：04/06/28 22:44

っていうか、COBOLerと同じ給料は納得いかねえ！
オープン系手当つけろや。

742 ：仕様書無しさん：04/06/28 22:54

新人に COBOL 教える俺。
言葉を発する度に新人の未来をもぎ取っていくような罪悪感を覚える俺。

743 ：仕様書無しさん：04/06/28 22:56

ﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞ
ﾊﾞｲｵｰﾊｻﾞｰﾄﾞﾊﾞｲｵｰﾊｻﾞｰﾄﾞ
ﾊﾞｯﾊﾞｯﾊﾞﾊﾞﾊﾞｯﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞ
ﾊﾞｲｵｰﾊｻﾞｰﾄﾞﾊﾞｲｵｰﾊｻﾞｰﾄﾞ
ﾊﾞｯﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞｯﾊﾞﾊﾞﾊﾞｯﾊﾞﾊﾞﾊﾞ
ﾊﾞｲｵｰﾊｻﾞｰﾄﾞﾊﾞｲｵｰﾊｻﾞｰﾄﾞ

744 ：仕様書無しさん：04/06/28 23:02

>>742
心配するな　
反面教師としてお前は満点だ
「ああはなりたくない」という強い意欲をみんな感じてるだろう

745 ：仕様書無しさん：04/06/28 23:31

if (cond1) {
　foo();
}
else {
　if (cond2) {
　　bar();
　}
　else {
　　if (cond3) {
　　　baz();
　　}
　}
}

else if って知ってるか？

746 ：69式フリーPG ◆hND3Lufios ：04/06/28 23:38

else ifは駄目ってコーディング規約があるところはある。
理由はよく覚えてないけど、インデントがずれる(?)とか言う話。

747 ：仕様書無しさん：04/06/29 00:16

頭おかしいね

748 ：仕様書無しさん：04/06/29 00:19

>>745
もしかしてそのコードはelse ifを使ってないと思ってたりして。
もしくは、else ifって構文があると思ってたりして。

749 ：仕様書無しさん：04/06/29 00:20

でもあえてelse if にしたくないときってない？
条件判断の意味というか系列が違うというか。

if (a > b) { // a と b の比較
　・・・
}
else if (a == b) { // a と b の比較
　・・・
}
else { // a と b の比較
　if (c % 2 == 0) { // c の判定
　　・・・
　}
　else { // c の判定
　　・・・
　}
}

みたいな。アマチュア考えですか？

750 ：仕様書無しさん：04/06/29 00:23

>>749
注釈ウザイ

751 ：仕様書無しさん：04/06/29 00:24

>>749 いや、普通だろ。

752 ：751：04/06/29 00:25

おっと、if,elseの使い方だけな。
そのコメントは異常。

753 ：仕様書無しさん：04/06/29 00:39

俺ならこうコメントする。

if (a > b) {
　・・・
}
else if (a == b) {
　・・・
}
else {
　// a < b
　if (c % 2 == 0) {
　　・・・
　}
　else {
　　・・・
　}
}

754 ：仕様書無しさん：04/06/29 01:20

・else if ｳｾﾞｰ

if (a > b) {
　・・・
}
if (a == b) {
　・・・
}
if(a < b){
　if (c % 2 == 0) {
　　・・・
　}else {
　　・・・
　}
}

755 ：仕様書無しさん：04/06/29 01:51

>>754
else自体をなくそうってのも一理あるんだよな。
実行する条件を見極めるのが非常に容易になるから。
でも実用言語でelse無しだったら、叩かれるだろうね。

756 ：仕様書無しさん：04/06/29 03:28

if (cond1) {
　foo();
}
if(!cond1 && cond2) {
　　bar();
}
if(!cond1 && !cond2 && cond3) {
　　baz();
}

757 ：仕様書無しさん：04/06/29 03:37

>>754
aとかbの値を書き換える可能性は？
現在はなくても、ひょっとして書き換えることがあるかもしれない。
そういうときの保守性のためにもelseは使った方がいいと思う。

758 ：仕様書無しさん：04/06/29 03:59

>そういうときの保守性のためにも

そういうときが来た時に対応するだけでよいだろ
(aとかbを書き換えるなら目くそ鼻くそ)

759 ：仕様書無しさん：04/06/29 11:27

>>757-758
まあ上記の>>753や>>754の「・・・」の部分でaとbの変更の有無の判断が即座に可能かどうかに依存することだな。
現時点で「即座に判断できる」という状態であっても、将来的にはどうなるか判らんし。

if ( a > b )　foo( ・・・ );
if ( a == b ) bar( ・・・ );
if ( a < b )　baz( c, ・・・ );
とか
if ( a > b )　foo( ・・・ );
else if ( a == b ) bar( ・・・ );
else baz( c, ・・・ );
にすれば「即座に判断できる」という状況は確保出来るぞ(w
どうよ

760 ：仕様書無しさん：04/06/29 11:45

Select Case Sgn(a - b)
Case -1
　なんとか
Case 0
　かんとか
Case 1
　うんとか
End Select

761 ：仕様書無しさん：04/06/29 12:51

Cには「else if」と言う構文はない。

　if() 文1 else 文2

の「文2」に if 文を書いているに過ぎない。

762 ：仕様書無しさん：04/06/29 14:45

だから、それが嫌だといってるんじゃん

763 ：仕様書無しさん：04/06/29 14:52

それはあなたがそう言っているに過ぎない。

764 ：仕様書無しさん：04/06/29 20:12

>>732
ソレに近いモノの仕様書を見たことはある
それぞれに100前後のメソッドが定義された「業務コントローラ」と呼ばれるクラス群だった

自分が実装担当にならなかったことを神に感謝した

765 ：仕様書無しさん：04/06/30 00:28

>>759
ここのソースばかり見ていると、aもbもグローバル変数で・・・
ということが想像できるんだが。

766 ：仕様書無しさん：04/07/01 11:32

グローバル変数好きな奴って多いんだな。

767 ：仕様書無しさん：04/07/01 11:48

>>766
グローバル変数の仕様を社長に強要されました
「変数を一箇所で宣言しておけばソースが読みやすいだろう」だって

ちなみに社長はｺﾎﾞﾗｰ兼ﾏｶｰ

768 ：仕様書無しさん：04/07/01 18:47

>>766
再帰を使うときは確かに便利だぞ。

769 ：仕様書無しさん：04/07/01 19:21

('A`)ｺﾎﾞﾗｰｷﾀｰ

770 ：仕様書無しさん：04/07/01 19:31

確かに再帰で書くときは便利だが、解読性が極度に低下する。
ツケが回ってくるぞ。引数を省略する誘惑に負けるな。

771 ：仕様書無しさん：04/07/01 22:20

マカーだがグローバル変数はむしろ嫌いだ

772 ：仕様書無しさん：04/07/01 23:32

σ(^_^ もマカーだが、グローバル変数が嫌いなわけだが。

773 ：仕様書無しさん：04/07/02 00:05

マカーはグローバル変数よりも糞だから気にするな。

774 ：仕様書無しさん：04/07/02 01:05

糞でも1000台あつめりゃなんとかなる
ttp://www.wired.com/news/images/0,2334,60821-9177,00.html

775 ：仕様書無しさん：04/07/02 01:11

工作員乙。

776 ：仕様書無しさん：04/07/02 03:01

>>730
参照が無くなってクラスがアンロードされて、
次に使うときは初期化されていた
なんてことは無いのかしら

777 ：仕様書無しさん：04/07/02 06:06

>>776
staticってわかる？

778 ：仕様書無しさん：04/07/02 06:14

はは・・・。

779 ：仕様書無しさん：04/07/02 08:01

776はこの会社辞めたいと思った上司の一言

780 ：仕様書無しさん：04/07/02 12:33

C++の処理系は知らないんだが、Javaだとクラス自体がGCの対象になることがある。
その場合staticな変数の領域も削除されてしまう。

C++にも、そんな処理系ある？

781 ：仕様書無しさん：04/07/02 12:54

C++にはGC自体ないんだが…

782 ：780：04/07/02 13:12

そういやそのとおりでした…

783 ：仕様書無しさん：04/07/02 13:52

>>746
阿呆な話だ、と思ったが
　if {
　　：
　}
と常に括弧を書けってゆー規約だったら、else 以降も勿論
　else {
　　：
　}
になる筈で、まあ筋は通ってるかも試練。

>>755
　if (! cond)
　　　goto cond_else;
　　　：
　// cond 時の処理
　　　：
　goto cond_next;
cond_else:
　　　：
　// !cond 時の処理
　　　：

cond_next:

アセンブラっぽい C。

784 ：仕様書無しさん：04/07/02 14:40

グローバル変数で質問。
ghInstanceとかghWndとか作るのは普通でもよくあること？
それともそれぞれ引数に付けたり、関数のほうで取得したりする？

785 ：仕様書無しさん：04/07/02 14:50

異常だけどよくあること。

786 ：仕様書無しさん：04/07/02 15:06

㌧
よく使うモジュールにまでghInstanceとかexternしてたから感覚が麻痺しそうになってたよ。

787 ：仕様書無しさん：04/07/02 15:13

>>783
switch(cond){
case true:
　...
　break;
default:
　...
　break;
}

788 ：仕様書無しさん：04/07/02 15:49

>>784
何事でもそうだが、融通の利かない奴、あるいは物ってのは、
実際には何の役にも立たない。
一方、融通の利きすぎるってのも、これまた何の役にも立たない。

そこらへんの塩梅ってのが、人生の醍醐味じゃあないですかね？

789 ：仕様書無しさん：04/07/02 15:53

>>784
プロセス起動から終了まで存在してて
しかも値が変わらないようなのは
グローバルでも全然OKじゃないかと思うが。

790 ：69式フリーPG ◆hND3Lufios ：04/07/02 16:18

>>789
プロセスのヒープハンドルをグローバルに置くことは良くやるね。

791 ：仕様書無しさん：04/07/02 19:20

>>789
値が変わらない事を保証する仕掛けをうっておくべきだと思う。

792 ：仕様書無しさん：04/07/02 23:41

public class Global {
　public static final int HOGE = 256;
　public static final int HAGE = 22360679;
　・・・
}

793 ：仕様書無しさん：04/07/02 23:47

一度ハゲちまったら死ぬまでハゲ……

794 ：仕様書無しさん：04/07/03 00:27

>>784
俺は起動時の初期処理で設定されてそれ以後の処理で変更されない
変数はグローバル変数にする派。

そんな俺から言わせてもらうと、その変数名はいただけない。

795 ：仕様書無しさん：04/07/03 00:50

>>770
再帰でグローバルって使うと便利な物なの？

796 ：仕様書無しさん：04/07/03 00:58

スタック使えない場合はグローバルで実装汁

797 ：仕様書無しさん：04/07/03 00:59

>>795
カウンタにでもするんじゃないの？

798 ：仕様書無しさん：04/07/03 01:29

でもあえてグローバルにする必要はあんまりないんじゃないの？

799 ：仕様書無しさん：04/07/03 01:35

そのようなソースを量産することにより、
俺はここまで派遣期間を伸ばしてきたんだ。
あながち悪いもんじゃないさ。

800 ：仕様書無しさん：04/07/03 01:35

だ・か・ら、グローバル使わないとできない場合だって

801 ：仕様書無しさん：04/07/03 01:38

複数関数にわたるような再帰でグローバル使うと便利な場合なんて
あんまりない事ないか？

802 ：仕様書無しさん：04/07/03 01:39

>>800
誰もそんなこといってない気がするけど言ってるの？

803 ：776：04/07/03 04:47

C++ だったねスマソ
Java だとシングルトンが回収されちゃったりするんで

804 ：仕様書無しさん：04/07/03 08:49

>>803
良く知らないんだけど、
＞Java だとシングルトンが回収されちゃったりするんで
ってどういうこと？勝手にクラスがアンロード？されちゃうわけ？

805 ：776：04/07/03 12:49

>>804
ちょっと調べてみたら、1.2以降(?)は
ブートストラップローダでロードされたクラスは
アンロードされないのね
首吊ってきま

806 ：仕様書無しさん：04/07/04 19:06

ところで、終わった話を蒸し返すようでなんなんだが、
このスレ的には

switch(1){
　　default:
　　　　：
　　　　処理１;
　　　　：
　　　　if(なんちゃら)break;
　　　　：
　　　　処理２;
　　　　：
　　　　if(なんちゃら)break;
　　　　：
　　　　処理３;
　　　　：
　　　　if(なんちゃら)break;
　　　　：
　　　　：
　　　　：
}

なコードってどんなもんだろうか？

807 ：仕様書無しさん：04/07/04 19:23

>>806
どうも糞も・・

808 ：仕様書無しさん：04/07/04 19:23

>>806
敢えて

do {} while(0)

を使う事を避ける意味は何？

809 ：仕様書無しさん：04/07/04 20:12

>808
意味は書いたやつに聞いてくれ。
結構よくあるコードなのか、正真正銘の糞なのか知りたかっただけだ。

810 ：仕様書無しさん：04/07/04 20:49

>>807
ブロックの先頭で異彩を放ってるだけdo{}while(0)よりましか。

811 ：仕様書無しさん：04/07/04 23:29

>>809
どちらも糞コードだ。
んなことは人に聞かずに、自分で気が付け

812 ：仕様書無しさん：04/07/05 00:17

>>807
continueでも抜けれるので、do{} while(0)のがまし

813 ：仕様書無しさん：04/07/05 00:31

switch(n){
　case 1:
　　;
　　if(...)break;
　　;
　　if(...)break;
　　;
　　break;
　case 2:
　　;
　　if(...)break;
　　;
　　break;
　default:
　　;
　　if(...)break;
　　;
　　break;
}

ってのなら見たことあるな
どのみち見にくいことには変わりないが

814 ：仕様書無しさん：04/07/05 02:03

>>812
continueで抜けられると何かうれしいのか。

815 ：仕様書無しさん：04/07/05 02:43

>>814
新人いじめに最適

816 ：仕様書無しさん：04/07/05 03:02

>>813
そういうパターンでジャンプテーブル使わないのはﾅﾝﾃﾞでしょうか？
関数に切り出してあったほうが読みやすいと思うんだけど…

817 ：仕様書無しさん：04/07/05 03:12

>>816
ケースバイケースだって何度も言ってるじゃん。

818 ：仕様書無しさん：04/07/05 03:24

>>817
>>816じゃないが、どういうケースのとき、
>>813の書き方がベターだと言えるのか知りたい。

819 ：仕様書無しさん：04/07/05 03:41

単にジャンプテーブルを否定しただけじゃないの？
ジャンプテーブルはいろんな意味で使いにくいしなー

820 ：仕様書無しさん：04/07/05 09:17

一行で済む処理、しかも他では使われない処理を
関数に切り出すような愚行はやめてくれよな

ケースバイケースって言って、自分で想像できない奴は糞だ

821 ：仕様書無しさん：04/07/05 13:36

プ

822 ：仕様書無しさん：04/07/05 13:41

リ

823 ：仕様書無しさん：04/07/05 13:42

マ

824 ：仕様書無しさん：04/07/05 14:18

[ハド]

825 ：仕様書無しさん：04/07/05 17:47

・・・ム？

826 ：仕様書無しさん：04/07/05 19:03

プリマドム？

……白鳥の湖をおどる黒い三連星？

827 ：仕様書無しさん：04/07/05 23:01

>>820
関数に切り出すことの真の意味を分かってないね。
関数名の付け方が重要なんだ。

828 ：仕様書無しさん：04/07/05 23:30

#define Hoge
#define hoge

/* ... いろんな関数があって */

int
func(Hoge hoge)
{
　　return 1;
}

829 ：仕様書無しさん：04/07/06 01:32

>816,817
(1)C++ではないC言語で、コールスタックの消費を抑えたい時。
(2)関数のシグネチャを統一出来ない時。(この場合は統一しないで切り分け、switchで呼べば良いが）

個人的には>813程度なら1画面に収まるし、インデントも浅いから切り分けなんて必要ないと思うが。

830 ：829：04/07/06 01:47

試しに>813をジャンプテーブルで実装してみた。改行制限に引っかかるのでやや見にくく書いたがそれは勘弁。
void one( void )
{
　　;
　　if(...)return;
　　;
　　if(...)return;
　　;
}
void two( void )
{
　　;
　　if(...)return;
　　;
}
void other( void )
{
　　;
　　if(...)return;
　　;
}
void sample( int n )
{
　　void (*func_tbl[])(void) = { one, two };

　　if( sizeof(func_tbl)/func_tbl[0] > n )?
　　　　func_tbl[n]();
　 else
　　　　other();
}

831 ：829：04/07/06 01:49

連続カキコですまんが訂正…。

誤： if( sizeof(func_tbl)/func_tbl[0] > n )?
正： if( n < sizeof(func_tbl)/sizeof(func_tbl[0]) )

832 ：仕様書無しさん：04/07/06 03:27

sizeofで比較文を書くとwarning が出るんだよなぁ～
#define SIZE(a) を作っておけばいいんだが…
このサイズを求めるdefineが統一されてなくて4人が4人とも好きな名前で出来てた

みんなで書き加える共通ソースがそれはもう凄いことに…

833 ：仕様書無しさん：04/07/06 21:13

sizeofで警告が出るか？その警告の意味は分かって回避してるんだろうな？

834 ：仕様書無しさん：04/07/07 00:58

>>832
どんな警告のこと言ってんの？

835 ：仕様書無しさん：04/07/07 01:01

>>831 のソースだと警告出るに変換ﾖﾛ

836 ：仕様書無しさん：04/07/07 01:05

>>834
signedとunsignedの比較かな？
でも、そうだとすると、
> #define SIZE(a) を作っておけばいいんだが…
ここの意味がわからない。

837 ：仕様書無しさん：04/07/07 01:13

Cを離れて久しいが、sizeof が返すのは size_t じゃなかったっけ？

838 ：829：04/07/07 01:19

警告の件については、下手な小細工使った上にVCなんぞで検証した私の不備です。すんません。
それよか>813と>830-831 を比較した上での、ジャンプテーブルを使わずswitchで書く事の
是非をお聞きしたい。

839 ：仕様書無しさん：04/07/07 01:41

>>838
ふうん。関数ポインタの配列をジャンプテーブルって呼ぶんだ。知らなかったYo。
どっちでもイイという回答では満足しなそうだな。
この例に限って言えば当然、関数ポインタの配列を使う方が良いさ。
関数参照のオーバーヘッドが無視できるような実行環境ならね。
理由は「シンプルだから」だよ。
#この種の話題の総論は回答しない。あくまで「この例」に限った話だよ

840 ：仕様書無しさん：04/07/07 09:16

シンプル･･･？
実際のプログラム上では、引数もあるだろうし条件も変わってきて、
各関数内の処理がよほど長くない限りシンプルになるとは思えん

841 ：仕様書無しさん：04/07/07 09:24

>>838
switch文の中で関数を呼び出す

っていう選択肢はないのか？

842 ：仕様書無しさん：04/07/07 11:16

まあ、使いたい年頃なんだよ。
いろいろと理由を考えてさ。
もうすぐ、気が付くと思うよ。

843 ：仕様書無しさん：04/07/07 15:58

ま、よくある話だが、今日引き継いだソースにあったコメント。

if(条件)
{
　　a=0;　　　　//aを１にする。
　　…
}
else
{
　　a=1;　　　　//aを2にする。
　　…
}

844 ：仕様書無しさん：04/07/07 17:37

(　ﾟдﾟ) ……?
　
(つд⊂)ｺﾞｼｺﾞｼ
　
(；ﾟдﾟ)
　
(つд⊂)ｺﾞｼｺﾞｼ
　　_, ._
（；ﾟ Дﾟ） …？!

845 ：仕様書無しさん：04/07/07 19:30

aは配列の添え字か何かではないだろうか。

846 ：仕様書無しさん：04/07/07 20:45

ここは定期的にジャンプテーブル厨が沸くインターネットですね。

847 ：仕様書無しさん：04/07/07 21:00

つーか
ｓｗｉｔｃｈ信奉廚もいいかげんウザイ
別のスレで議論してくれ

848 ：仕様書無しさん：04/07/07 22:07

どっちもウザイ

849 ：仕様書無しさん：04/07/08 01:26

>>845
BASICから移植したんだろうな

850 ：仕様書無しさん：04/07/08 01:33

ま、よくある話だが、今日引き継いだソースにあったコメント。

if(条件)
{
　// "条件"が成立した場合
　　…
}
else
{
　// "条件"が成立しなかった場合
　　…
}

851 ：仕様書無しさん：04/07/08 01:36

// delFlgではないが
String[] delFlg = new String[list.size()];

じゃあなんなんだよ、、、、

852 ：仕様書無しさん：04/07/08 01:49

>841，842
アナタたち、仕様書とかよく読まずに、いきなりコーディングするタイプでっしゃろ。

853 ：843：04/07/08 11:02

>845
いや、"a"はどういう画面を表示するか決める結構重要なフラグだったりします。
このソース書いたのは素人で、どうしようもなくなったということで引き継いだんですが、
他にも
g.setColor(Graphics.getColorOfName(Graphics.RED));　　//文字列色　黒の指定
とか、
g.drawImage(image11,0,160);　　//イメージの描画タイトルブルー
（このimage11ってのは灰色のグラデーションパターンで、タイトルとは関係ないとこで使う）
とか、
ワザととしか思えない罠があちこちに仕掛けられてあります。

854 ：仕様書無しさん：04/07/08 21:26

(void)printf(...)
(void)strcpy(...)
って書いてるの見たのだが、これって何を意図してるんだろう。
激しくみにくくて鬱。

>>843
ﾜﾗﾀ

855 ：仕様書無しさん：04/07/08 21:37

>>854
それは「lintにエラーを出させないための処置」。
printfやｓｔｒｃｐｙは返り値を持つ。(void)をつけないと
「返り値が無視されている」というエラーがでる。
とある有名なunixカーネルは全てその様な
「lintクリーンなコード」で記述されているのだそうな

856 ：仕様書無しさん：04/07/08 23:02

お前ら、仕様的にありえないパターンのデータが来たときの
処理ってどうしますか？

例外に飛んで異常終了するようにすれば、
「なんかこの処理が落ちるんで、明日出て緊急で調査して！
（誰だこの糞データ作ったのは！）」とか言われ、
データが悪くてもそれなりに動くようにすると、
「商用環境に不正データが登録されたため、日曜みんなで修正！」
とか言われるしまつ・・・

どっちの方がマシなんですか

857 ：仕様書無しさん：04/07/08 23:36

>>856
しらねーよ

858 ：仕様書無しさん：04/07/08 23:58

それは、「ウンコとカレーの命題」ってやつだ

859 ：仕様書無しさん：04/07/09 00:07

>>856
つ[辞表]

860 ：仕様書無しさん：04/07/09 00:28

>>856
そんなデータは捨てる。捨てたことをログに残しておいて、客の(ﾟДﾟ)ｺﾞﾙｧ!!に備える。
「こんな糞データが来たので捨てましたよ、仕様変えるの？」ってな感じで。

861 ：仕様書無しさん：04/07/09 00:50

>>860
確かにその手が一番効くよな…
前にホスト系糞プロパーと大喧嘩した時に役に立ったよ
（結局政治力の差で屈したが…(涙)）

862 ：仕様書無しさん：04/07/09 01:06

>>858
カレーも喰っちまえばいずれうんこになる、ってことだよね

863 ：856：04/07/09 01:26

>860
うちはユーザが画面（他会社作）から操作するアプリなんで、
捨てられないしログもはけなくて、画面にエラーメッセージ
出すしかできないんだよ・・・
しかも、サーバで異常終了したときのエラーメッセージは
「サーバ処理でエラーが発生しました。」←これは仕様で決まってる。
確実に問い合わせが・・・＿|￣|○

>859
ボーナスもらったら決行します。

864 ：仕様書無しさん：04/07/09 01:49

>863

ログが吐けない,という状況がちょっとわからないんだけど。
そのアプリがローカルなファイルを勝手に作ってはいけないということなら
Winならイベントログ、Unix系ならsyslogに吐いて見るというはどう?

ところでどちらの方法を取っても客のゴルァ電から逃れられないというのを
前提にするなら、より被害の少ない「例外で異常終了」の方がまだましと
消去法で考えるしかないのでは?
DBにありえない糞データが登録されてしまったのを修正するコストの方が
圧倒的に高くつくと思うんだが。

865 ：仕様書無しさん：04/07/09 02:08

856がボーナスもらうまで耐えれば糞データが登録されても構わないかもな

866 ：仕様書無しさん：04/07/09 11:56

>>856
辞表出すのは勝手だが、うちは低スキルお断りだからうちにくるなよ

867 ：仕様書無しさん：04/07/09 13:39

>863
　ユーザが他社のアプリで手入力→他社アプリから863のアプリへデータが送信される
っていう構造なの？

　だったらまずは他社アプリを吊るし上げるべきなんでは……？

　つか、アプリ間でデータの入力許容範囲が異なってるんだよな、それ？

868 ：仕様書無しさん：04/07/09 14:08

>>863
サーバ側でデータのチェックとかできないのか
不正なデータはサーバ側ではじいてログに吐けばいいと思うのだが、ダメなのか

869 ：仕様書無しさん：04/07/09 17:32

自動車関係の子会社の会社説明会に行ったときに何か言ってたな。
自動車の部品の仕様書が上のほうからとめどなく流れてくるが、
連絡なしに仕様が変更されるおかげさまで入力インタフェースやらその他もろもろ書き換えるのが面倒だとかなんだとか。

正直、その程度で根を上げてくれると困る。
ま、元々なかったシステム部門を社内の理系社員だけ寄せ集めて作ったらそうなるのも仕方ないか。

870 ：仕様書無しさん：04/07/09 17:40

>>869
連絡なしに仕様変更する時点で大問題だと思うが。

871 ：仕様書無しさん：04/07/09 18:00

連絡もせずに仕様変更する事は大問題だが、
連絡したはずなんだけど、なぜか伝わってなかった
ってのは許されてしまうんだよな、
っていうか、ちゃんと伝えろ。

872 ：仕様書無しさん：04/07/09 18:21

×××データ仕様

そのときの気分で以下の仕様の内いずれか一つが選ばれる。
また、人事異動に際しデータ仕様が変更されるので対応可能にすること。

873 ：仕様書無しさん：04/07/09 18:59

つまらん

874 ：仕様書無しさん：04/07/09 20:33

>>869
学生さんらしい反応ですね。

875 ：仕様書無しさん：04/07/09 21:44

ま、ここでの反応はそんなものか

876 ：仕様書無しさん：04/07/09 22:05

ソースじゃないんだが、もらった名刺に[email protected] と書いてあった。
これを見て雇用契約は締結せず退社。

877 ：仕様書無しさん：04/07/09 22:49

hogehoge.co.jp っていいな。そのメアド欲しい。

878 ：仕様書無しさん：04/07/09 23:22

>>869
ひょっとして◆◆◆自動車?

879 ：仕様書無しさん：04/07/09 23:40

>>878
伏字のよーで、伏字でないなw

880 ：856：04/07/09 23:55

>864
そうですローカルに吐けないんです。
そういう時はそこら辺に吐けばいいのか・・・参考にします。
やっぱ例外で異常終了のほうがまだマシでいいか～

>867
一応メインは
　画面でいろいろ選択＆入力→サーバーで加工して登録
→作ったデータを別の画面で組み合わせる→サーバー
→・・・
って感じ。なお、サーバーも最初はいろんな会社が作ってたらしい。
うちは下請け（下請けな事は他所には秘密）だから力関係
最下位で、あんまり他社と戦えないのです・・・

>868
できるけどこのパターンの時はあり、このパターンは無しとかだから、
とてもチェックしきれない・・・。
稼動4年目なのでDBの中身が既におかしいことも多数。
昨年他のシステムのDBも吸収して、テーブル数は300超（汗

881 ：仕様書無しさん：04/07/09 23:56

マツダ自動車
いすゞ自動車
トヨタ自動車
ホンダ自動車
スズキ自動車

882 ：仕様書無しさん：04/07/09 23:56

>>880
＞できるけどこのパターンの時はあり、このパターンは無しとかだから
そ　れ　を　チェックするのが　役　目　だ　ろ

883 ：仕様書無しさん：04/07/10 00:01

>>881
イッコ忘れてる
◆◆◆

884 ：仕様書無しさん：04/07/10 00:04

>>883
みつ菱？

885 ：仕様書無しさん：04/07/10 00:06

>>880
要するに、システムが腐ってるということですね

886 ：仕様書無しさん：04/07/10 01:27

DBに糞データフラグを作る。これで消すのも楽。

887 ：856：04/07/10 02:10

>882
いいえ、「異常データはあるのがおかしい」ので、それをチェックする
予算は下りてないので、役目ではないのです。

そもそも、まず状態遷移ごとの正しいデータパターンを提示してください。
現在のところ、間違ってるか判断する方法が、難解な仕様書と
にらめっこする（たいてい書いてない）か、慣れた人が見る以外に
ないのです。
っていうか、仕様で決まってるチェック項目だけで、毎開発ごとに
デスマーチ・・・

888 ：仕様書無しさん：04/07/10 02:17

エラーメッセージの文言まで決めてるようなクソ内部規約など便所に流しちまえ

889 ：仕様書無しさん：04/07/10 05:37

>>863がコーダならご愁傷様。
だがちゃんと働いているなら、現状としかるべき仕様にした場合との比較をして、仕様変更を提示するべきだな。
予算を確保しなくちゃならん。

前者と後者でコストは雲泥の差になるはず。
スーツは予算や経費には敏感な人間が多いから、かならず数字で示せ

890 ：仕様書無しさん：04/07/10 06:12

>>889
>だがちゃんと働いているなら、現状としかるべき仕様にした場合との比較をして、仕様変更を提示するべきだな。

し　か　る　べ　き　仕　様　

便利な言葉だ・・・・・

891 ：仕様書無しさん：04/07/10 10:48

>>890
叱るべき仕様ならよく見るぞ。

892 ：仕様書無しさん：04/07/10 11:56

とりあえずサーバーエラーになったときは
次からは弾くようにしてるんでしょ？
ならいつかは安定するじゃん。そういうの好き

893 ：仕様書無しさん：04/07/10 12:11

>>891
（･∀･)つ＿　ｻﾞﾌﾞﾄﾝﾄﾞｿﾞｰ

894 ：仕様書無しさん：04/07/10 18:09

>887
　つまり、自分達のプログラムは、「はなから正しいデータしか来ない前提」なんだよね。
　もしおかしなデータが来たら、それはエラーとして潰すしかない。スルーすることはでき
ない、ってことでしょ。
　だとしたら、問題はこっちへデータを渡してくる部分にあるわけだから、そのことはきち
んと伝えなきゃ駄目じゃん。下請けだのなんだのってのは関係ないよ。どうしても他社に言
えないなら直接の元請けにまず伝えて、そっから連携他社にｺﾞﾙｧしてもらえ。

　で……もし元請けがやらんようだったら、そんときは抜けること考えた方がいい（会社と
して）。絶対無駄なマンパワー食ってる。

895 ：仕様書無しさん：04/07/10 18:49

>>894
俺は>>887じゃないが、下請け（俺んとこは曾々々孫請け）だから
お上には逆らえんのよ。。。

896 ：名無しさん＠そうだ選挙に行こう：04/07/11 10:47

>>895
よくある話だから上のほうの人たちとは仲良くなっておかないとね

897 ：仕様書無しさん：04/07/12 23:03

>887
>現在のところ、間違ってるか判断する方法が、難解な仕様書と
>にらめっこする（たいてい書いてない）か、慣れた人が見る以外に
>ないのです。

なら、ノーチェックでええやん。後で問題になっても｢うちのせいじゃない｣

898 ：仕様書無しさん：04/07/12 23:54

>>897
ここまでの話の流れから察するに>856の置かれてる状況は「ご愁傷様」で
「うちのせいじゃない」が通用しないんだろうけどね・・・。

899 ：仕様書無しさん：04/07/13 00:13

>なら、ノーチェックでええやん。

学生じゃないんだからさ。

900 ：894：04/07/13 01:06

>895
　その場合、とりあえず直接の取引先（曽々々孫なら、曽々孫）には言うでしょ。
　そこから順繰りに上げてってもらうしかあるまいて。

　途中で潰されるのが多いのは確かだけどな。

901 ：仕様書無しさん：04/07/13 01:52

>899

>例外に飛んで異常終了する
:
>データが悪くてもそれなりに動く
:
異常終了させない & それなりに動かないよーにする

>なら、ノーチェックでええやん。

902 ：仕様書無しさん：04/07/13 12:25

>>901
夏休みの宿題じゃないんだからさ

903 ：仕様書無しさん：04/07/13 18:13

いや、子供じゃないからこそ責任の所在は明らかにして
しかるべき対処を促すべきだと思うがね。

…現実問題としてそれが可能かどうかはおいておくとして。

904 ：仕様書無しさん：04/07/13 19:17

要するに、文句いわれたときに、言い返せるだけの準備はしておけと。

905 ：仕様書無しさん：04/07/14 19:52

過去ログ全部読んだわけではないので重複してたらごめんなさい。
でもこんな「オッペケペー」はいないと思います。
main(){
.
whila(1)
.
for(xx;xx;xx)//xxは適当に考えてね！
　　　　while(xx){
for(xx;xx;xx){
//この先for, whileのループが15段
}
}
}
}
（既存のすべてをブラックボックスにしてEngineを積んで
イベントでたたいて事なきを得ましたが、、、）

906 ：while(1)：04/07/14 20:06

文字化けと、スペースが省略されるみたいで「お見苦しい」カキコをしました。
その２：
#define EMERGENCY 0xFE;
#define EMERGENCY_MASK 0xFE

if((Event && 0xFE)==0xFE){
}

数百箇所の条件分岐がすべて直値で、、、、

907 ：仕様書無しさん：04/07/14 20:18

>>906
なにそれ？
何をどうしたいの？

908 ：仕様書無しさん：04/07/14 20:29

>>906
つっこむところは沢山あるが、コードよりも

>数百箇所の条件分岐がすべて直値で、、、、

これが一番謎。
つっこみどころはここじゃないだろうと小一ｊ

909 ：仕様書無しさん：04/07/14 22:23

>>906
論理積だと条件が成立し得ないわけだが…

910 ：仕様書無しさん：04/07/15 00:24

論理積はビット演算の間違いでしょ。
それくらいは許してやろうよ。

ちなみに

911 ：仕様書無しさん：04/07/15 00:26

& だろーが && だろーが呼び名は「論理積」で合ってると思います！

912 ：582：04/07/15 01:56

あﾞぅ～
イライラして眠れません。

うちの部門の環境は、
設計書なし、テスト仕様書なし、プロセスフローなしです。
それでもＩＳＯとやらとってますよ。（詐欺みたいなもん）

それから、バグ持ちのプログラムを平気でコピーして利用するので
ウィルスのようにバグが増えてます。
その度にＳＱＬエラーなどなど。

ＳＱＬエラーが出るとユーザーに「ここの入力忘れたのがいけなかったんですね」
なんて謝られる始末。
プログラムが悪いんだよぅ。

あと、先輩社員に「あれの仕様変更まだ出来てないの？」　（ちょっと小バカにした言い方）

もうアホかと。仕様変更のテストしているうち、まったく関係ないところの
バグが見つかるんだよ。

913 ：仕様書無しさん：04/07/15 02:46

>912

TDD汁!

914 ：582：04/07/15 03:01

TDD = テスト駆動開発？

ググったら出てきたけど、初めて聞いたなぁ。

915 ：while(1)：04/07/15 03:43

経験豊かなエンジニアの皆様に大変失礼いたしました！
if((Event & 0xFE)==0xFE)
と書けばOKでしょうか？問題はHeader-Fileの定義がコードに全く使われていない
のを実機無しのリバースしたもんだから、、、
あるまじめな方は担当部分の直値（上の例では0xFEが該当いたします）をすべて
定義に従って書き換えて動作検証に3ヶ月かけましたが、#defineで三重に名前の変わる
定数、0xAA-> KUSOTTARE -> UNKO_TABERA -> UNCHIを45のソースで各々違う同数の
#include XXXX.H, YYYY.INCに注意しながら書き換えて自律神経の薬を飲んでいる
方を尻目に見ながらそんな時間も与えられず、、、、
まあ皆様のような専門家ならばCD-ROM眼いっぱいの直値コードや17段のループの
ネストにも敢然と立ち向かうでしょうから、このスレにはもう出てきませんので、、、

オブジェクト指向ツールは氾濫してても、「茹で立てのソーメンのザル入り」型ソフトしか存在しない
「技術立国」が知らぬうちに周辺国のCN, NK, SK, TW, VN, に制覇さてしまったのは見ていられません
が、また明るい明日もあるでしょう、、きっと、、、多分、、、、願わくば、、、、、
だって専門家の方々は「新しいC++の文法」に詳しく、見た目に「他人に分からぬコード」を書くのが
「最新流行」のようですから、、、

916 ：仕様書無しさん：04/07/15 04:00

何が言いたいのかよくわらない。

917 ：仕様書無しさん：04/07/15 04:01

よくわらない
よくわらない
よくわらない

918 ：仕様書無しさん：04/07/15 08:37

>>917
それを即レスかよ

919 ：仕様書無しさん：04/07/15 09:35

>>915
こういうのを見ると、いっつも思うんだけど...

「母国語もマトモに使えない香具師に、第二言語は無理」

920 ：仕様書無しさん：04/07/15 09:48

>>915
>if((Event & 0xFE)==0xFE)
>と書けばOKでしょうか？

普通に
if(Event & 0xFE)
だけでいいんじゃないか？

>#defineで三重に名前の変わる定数

状況がわからないからコメントしにくいけど、#defineで同じ値を別変数として
名前を変えて切ったりするのはそんなに特異なことじゃないよ。
ビット演算に使用する値なんかはよくそういうことをやる。
ただ引き継いだ人間のスキルが低すぎると迷宮入りするけどね。
つうかオブジェクト指向ツールの批判する前にgrepやsedぐらい使えよ。

921 ：仕様書無しさん：04/07/15 09:54

>>920
1)if((Event & 0xFE)==0xFE)
2)if(Event & 0xFE)

1と2だと動作が違ってしまうが。

922 ：920：04/07/15 10:03

>>921
ごめん。
たしかに動作かわっちゃうね。

>>906に#define EMERGENCY_MASK 0xFE って行があったから、
条件を満たしている状態毎にif文きってるのかと勘違いしてたよ。

923 ：仕様書無しさん：04/07/15 10:10

/******************************************
この会社・・・ってわけじゃないけど
倒産した会社のソースメンテナンス頼まれたが、
コメントがニュー速っぽいＡＡでいっぱいだった。
ﾐﾐ彡彡ﾞﾞﾞﾞﾞ""""""""ヾ彡彡彡
ミミ彡ﾞ　　　　　　　　　ﾐﾐ彡彡
ﾐミ彡ﾞ　＿　　　　＿　ﾐﾐミ彡
ﾐミ彡 '´￣ヽ　　'´￣｀ ,|ミﾐ彡　
ﾐﾐ彡　-=・‐'　〈‐=・=- .|ﾐミ彡　
　彡|　　／　|　　　　 |ﾐ彡　　　／　　
　彡|　　　´-し｀)　　／|ﾐ|ﾐ　　　｜
　ゞ|　　　　､,!　　　　 |ソ　　　<そりゃつぶれるだろ
　　　ヽ　'´￣￣￣`ﾉ /　　　　　｜
　　　 ,.|＼､　　　' ／|､　　　　　
￣￣| ｀＼.`──'´／ |￣￣＼　
　　　＼　~＼,,／~　 /　　　　　＼

*****************************************/

924 ：920：04/07/15 10:11

条件を満たしているじゃなくて、条件の一部をだな・・・
徹夜明けで頭が朦朧としてて文章になってないな。
駄目駄目じゃん漏れ･･･とりあえず逝ってきます

925 ：仕様書無しさん：04/07/15 19:31

>>911
お前の設計書は怖くて外注に出せない。一生ＰＧ汁。

926 ：仕様書無しさん：04/07/15 19:48

ヘ_ヘ
ミ・・ミ　ということにしたいのですね？
( ° )～

927 ：仕様書無しさん：04/07/15 20:55

この会社辞めようと思ったのはソースコードせいじゃなくて、
本当の理由は、自分が日本語不自由で周りとうまくコミュニケーション取れなくて
会社に居づらいからなんじゃないのかな？

928 ：仕様書無しさん：04/07/15 21:09

>>927
自分のことデスカァ？

929 ：仕様書無しさん：04/07/15 23:32

>>928
はい、そうです。

930 ：仕様書無しさん：04/07/15 23:58

>>929
oh,me too!!

931 ：仕様書無しさん：04/07/16 01:43

>914
>初めて

早く始めろ!

932 ：仕様書無しさん：04/07/16 08:10

DDT汁!

933 ：仕様書無しさん：04/07/16 08:43

>>932
…CP/M?

934 ：仕様書無しさん：04/07/16 12:03

懐かしいったらありゃしない＜DDT

935 ：仕様書無しさん：04/07/16 12:19

占領軍が消毒に使ってたやつだっけ？　＞＞DDT

936 ：仕様書無しさん：04/07/16 13:50

プロレス技じゃなかったけ？>>DDT

937 ：仕様書無しさん：04/07/16 16:33

>>936
Google先生によると、技ではなく、プロレス団体そのもののようですね。

938 ：仕様書無しさん：04/07/16 17:06

>>937
技もあるよん。

デンジャラスドライバーテンリュウの略でDDT
http://www.wrestling-high.com/tenryu/h999/h054.htm

939 ：仕様書無しさん：04/07/16 17:55

>>938
＞デンジャラスドライバーテンリュウの略でDDT
それは天竜が言ってるだけ。
もしくは、天竜の使うDDTのみを「ﾃﾞﾝｼﾞｬﾗｽﾄﾞﾗｲﾊﾞｰﾃﾝﾘｭｳ」という。

940 ：仕様書無しさん：04/07/16 18:12

おいらはシンボル使いたかったのでZSIDでした

941 ：仕様書無しさん：04/07/16 19:26

磁気テープのことか？

942 ：コンピューター衛星：04/07/17 00:31

こちらはSIDです…
UFOの…進入を…キャッチしました。
速度は…ソル１．

943 ：仕様書無しさん：04/07/17 02:11

>>942
ﾌｯ、ﾌﾙｰ

944 ：仕様書無しさん：04/07/19 20:14

ぬるぽ

945 ：仕様書無しさん：04/07/19 20:24

ｶﾞｯ

946 ：仕様書無しさん：04/07/19 20:54

939は橋本ファン

947 ：仕様書無しさん：04/07/20 23:59

コメントと、関数名と、実際に書かれている処理すべてが合っていないorz

948 ：仕様書無しさん：04/07/21 00:19

>947
がんがれ。正しいのは唯一、実際に書かれている処理だけ……のはずだ。

949 ：仕様書無しさん：04/07/21 01:16

/*
* 与えられた２つの Integer の差の絶対値を返す。
*/

public Integer multiple(Integer a, Integer b) {
　　return a.add(b);
}

950 ：仕様書無しさん：04/07/21 11:32

>>949
ひひ、ご愁傷様です。

951 ：947：04/07/21 22:51

>>948
「コメントと処理が合っていないときは、多分両方とも間違っているだろう」
って言うのが通説でして.......

952 ：仕様書無しさん：04/07/21 22:55

それどころかメソッド名まで

953 ：仕様書無しさん：04/07/21 23:17

"２つの Integer"ってとこがあってるだけマシじゃないか。。。

954 ：仕様書無しさん：04/07/21 23:55

で、ある日キレた椰子が>949のようなメソッドを粛正してくれようと
大ナタを振るうと
http://pc5.2ch.net/test/read.cgi/prog/1085306859/259
のような惨事を引き起こすこともあり。世の中、右も左もまっくら森じゃございやせんか。

955 ：仕様書無しさん：04/07/24 18:57

ぬる

956 ：仕様書無しさん：04/07/24 19:40

ぽガッ

957 ：仕様書無しさん：04/07/25 21:30

ＤＢに生パスワードのカラムが！

ソースというよりＤＢ設計です。
世間一般に公開しているシステムなんですが
ＤＢに生パスワードのカラムがあります。
しかも実データのテーブルのバックアップが
/tmp やら / に aaa.csv などの名前であっちこっちに残っています。
下っ端の俺でも、誰でも、見れてしまいます。

えーっと会員数２０万人なんですが。。。
ヤバイなこれ。と思いつつも他の大小の問題がたーくさんあって改善できないままでいる。
こういうのってどこでも一緒なのかな？

958 ：仕様書無しさん：04/07/25 22:29

>>957
ありえない
少なくともうちではだけど

959 ：仕様書無しさん：04/07/25 22:31

バックアップが散乱してるのは好ましくないが
DBに生パスを入れるのは場合によるだろ

webメールを実装しようとしたらPOP3の生パスは
どこかに置いておかなきゃならんわけだし

960 ：仕様書無しさん：04/07/25 23:47

いや、そこは生じゃなくて暗号化しておけよ
DBから取り出す時に複合化して送信されたパスワードとチェックすればいいだろ

961 ：仕様書無しさん：04/07/26 01:33

DBに入れるレベルなんてポリシーによりけり。
ま、望ましくはないけどね。

962 ：仕様書無しさん：04/07/26 03:08

DBは普通誰でも見られる状態にはないはずだから
それを誰でも見られるよーってところに問題があるんだと思うよ

バックアップcsvは問題外だけど

963 ：仕様書無しさん：04/07/27 14:00

>>960
普通、復号化はしないだろ。

964 ：仕様書無しさん：04/07/27 16:12

安全性から言えば暗号状態で保存しておいて、入力されたパスワー
ドを同じ関数で暗号化した結果と比べるくらいは普通だわな。当然
暗号化には逆演算ができないかきわめて困難なものを。

パスワードを何らかの方法で教えてくれるWebサービスってのは
どっかに生パスワードが保存されてるわけで、かなり不安になる。

965 ：仕様書無しさん：04/07/27 16:51

>>964
でも、秘密の質問+答え形式のパスワード称号なら
その答えをキーにして暗号化してしまえばいいんじゃないか？
チェックサムみたいなものをつけてれば、一応、でたらめな答えは防げると

966 ：仕様書無しさん：04/07/27 22:11

>>964
＞パスワードを何らかの方法で教えてくれるWebサービスってのは
＞どっかに生パスワードが保存されてるわけで、かなり不安になる。
なぜそういう結論になるのか教えてくれ。

>>965
普通はパスワード忘れたときのリマインダの話だと思うが（質問と答え）…

967 ：仕様書無しさん：04/07/27 23:36

>>964
通信路での安全性を考えたら、その方法は使えない場合が多い。

たとえば、APOPのチャレンジレスポンスとか。
これは生パスワードに復元できていないと認証できない。

968 ：仕様書無しさん：04/07/28 00:02

別にチャレンジ＆レスポンスでも、
生パスワードを復元できないとならない理由は無いと思うが…

969 ：仕様書無しさん：04/07/28 05:43

クライアントサイドで２重に暗号化(ハッシュ化)してくれるなら、復元できなくてもかまわないが
APOPだとクライアントは不特定だからそうもいかないだろ

970 ：仕様書無しさん：04/07/28 08:29

…そうなるか？
ただのハッシュならそういう仕様にしとけば問題ないと思うが？