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

1 ：仕様書無しさん：2007/08/14(火) 23:48:45

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

ちなみにここは質問スレじゃないので
技術的な質問がしたいならム板 http://pc11.2ch.net/tech/ に逝って。

前スレ
この会社辞めようと思ったソースコード＃17
http://pc11.2ch.net/test/read.cgi/prog/1183700531/

2 ：仕様書無しさん：2007/08/14(火) 23:50:36

>>1
乙

3 ：仕様書無しさん：2007/08/14(火) 23:57:48

for(;;) System.out.println(">>1乙");

4 ：仕様書無しさん：2007/08/14(火) 23:59:21

>>1乙ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ

5 ：仕様書無しさん：2007/08/15(水) 00:28:49

while(!1) printf(">>1\n乙");

6 ：仕様書無しさん：2007/08/15(水) 00:37:39

あらすじ

西暦2922億年、人類は滅亡していた。
天皇陛下は長生きしてください。消費税の増税には反対です。
つーかもうスレ終わりじゃないか

7 ：仕様書無しさん：2007/08/15(水) 00:57:03

>6
終わらせてどーすんだよっ!!

(1..1000).each {|n| puts ">1乙"}

8 ：仕様書無しさん：2007/08/15(水) 00:57:12

2000億年後なんかどうでもいいが、天皇なんて近い将来死ぬって分かってるんだから
元号の処理くらいちゃんとやっておけよ

9 ：仕様書無しさん：2007/08/15(水) 00:59:37

>(1..1000).each {|n| puts ">1乙"}
↑これ糞コードっぽくね？

10 ：仕様書無しさん：2007/08/15(水) 01:01:09

一瞬何語かわからなかった俺にはどうでもいい

11 ：仕様書無しさん：2007/08/15(水) 01:06:42

まぁ
1000.times { puts "乙" }
でいいな。

12 ：仕様書無しさん：2007/08/15(水) 01:39:17

puts "乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙乙"

13 ：仕様書無しさん：2007/08/15(水) 02:24:05

while True:
　　　　print "乙"

14 ：仕様書無しさん：2007/08/15(水) 03:22:52

そういやだいぶ昔に星新一が
2001年になったら「日扇（にせん）」と改元すればいい
なんていってたなぁ

15 ：仕様書無しさん：2007/08/15(水) 03:50:31

今は年号も数十年は続くけど、江戸時代以前なんてコロコロ変わりまくりだったんだぜ
その頃の日本人にとっては時間の概念はそこまで重要ではなかったんだろうけどな

16 ：仕様書無しさん：2007/08/15(水) 04:02:19

大規模な天災があるたびに改元とかな。

17 ：仕様書無しさん：2007/08/15(水) 05:15:45

For i=0 To 2
　Print ">>1乙"
　i=i-1
Next i

18 ：仕様書無しさん：2007/08/15(水) 11:45:35

税率、元号以外の時限爆弾って何があるかな？

19 ：仕様書無しさん：2007/08/15(水) 12:10:03

道州制とか？
まだ当分先だろうけど

20 ：仕様書無しさん：2007/08/15(水) 13:06:29

ISBN13桁化でちょっと大変だった

21 ：仕様書無しさん：2007/08/15(水) 13:46:45

改修費用が発生する（＝仕事が発生）から税制改正は賛成。
増税は反対。
消費税は円周率派。

22 ：仕様書無しさん：2007/08/15(水) 14:06:42

そういや「ケータイ、PHS、11桁～♪」なんてCMが流れた頃もあったな

23 ：仕様書無しさん：2007/08/15(水) 14:07:09

>>17
>i=i-1
おわらねぇぇぇ

24 ：仕様書無しさん：2007/08/15(水) 14:16:37

>18
サマータイム

25 ：仕様書無しさん：2007/08/15(水) 14:31:31

俺は関わったことないけど、市町村の合併（の特例）（→市町村コードの新設・廃止）は
まだ継続中らしいね。

26 ：仕様書無しさん：2007/08/15(水) 15:41:12

買掛金の支払管理で
銀行合併の大ブームにぶちあたって
支店情報も含めての統合機能が
土壇場で追加になって死ぬかと思った。

27 ：仕様書無しさん：2007/08/15(水) 20:07:16

>>15-16
改元が数年に１回とかが当たり前だったら、
最初からそれを織り込んで作るでしょう。

28 ：仕様書無しさん：2007/08/15(水) 20:13:13

昭和天皇が長生きだったからな
ついつい、天皇はいつまでも生き続けてるんじゃないかって錯覚に陥るのさ

29 ：仕様書無しさん：2007/08/15(水) 20:50:19

>>18
人工キー、自然キーって言葉おれも最近知ったけど、人工キーは全部爆弾になりえると思ったほうがいいね。

30 ：仕様書無しさん：2007/08/15(水) 21:09:01

それは人工キーの作り方があまりにヘタクソなんじゃないか?

31 ：仕様書無しさん：2007/08/15(水) 21:28:36

>>30
まちがえた。人工キーと自然キーが逆だった。

32 ：仕様書無しさん：2007/08/15(水) 22:44:33

前スレ989
＞いまだに内部は昭和で動いてるシステムもありそうだなあ
もし年2桁で今昭和64+18=82年・・・
あと18年か。
むしろ元号変わるタイミングでリプレースできりゃいいけどな。

33 ：仕様書無しさん：2007/08/15(水) 22:47:15

東大前にある喫茶店を思い出した
レジがやたら古くて 380円のものを注文すると3.80と印字したレシートになる
380円を3円80銭と入力して今でも使ってるんだよな
趣があっていいぞ

34 ：仕様書無しさん：2007/08/15(水) 22:47:38

>>32
18年後には、内部は昭和で動いていることすら忘れ去られていそうな罠…

てか、それまでに1回くらいはリプレースのチャンスあるでしょ。多分…

35 ：仕様書無しさん：2007/08/15(水) 23:35:45

紀元もあと30年くらいか。

36 ：仕様書無しさん：2007/08/15(水) 23:42:18

カフェ本?

37 ：仕様書無しさん：2007/08/15(水) 23:47:49

>>18
銀行口座

38 ：仕様書無しさん：2007/08/15(水) 23:50:51

元号って単に、表示時等に動的に充てるだけであって
元号込みのデータを内部で使ったりはしない・・・・よな　さすがに無いと信じたいw

39 ：仕様書無しさん：2007/08/15(水) 23:58:33

コボラが
01 GENGOU
05 MEIJI PIC X(3) VALUE "ﾒｲｼﾞ"
05 TAISYOU PIC X(5) VALUE "ﾀｲｼｮｳ"
05 SYOUWA PIC X(4) VALUE "ｼｮｳﾜ"
05 HEISEI PIC X(4) VALUE"ﾍｲｾｲ"

みたいなことしてるかも…

40 ：仕様書無しさん：2007/08/16(木) 00:01:00

>>38
ある。それを知っているからこそ、話題になるんじゃまいか？

41 ：仕様書無しさん：2007/08/16(木) 00:01:37

そいやJavaもやっと年号ロケールをランタイムのレベルで対応したんだっけ？
遅いよな。

42 ：仕様書無しさん：2007/08/16(木) 00:03:05

去年の6でJapaneseImperialCalendarが実装されたな。
いままでIBMのICUしかなかった。

43 ：仕様書無しさん：2007/08/16(木) 01:37:20

　ルオーだろ。

44 ：仕様書無しさん：2007/08/16(木) 06:57:14

>32
昭和127年や昭和255年までなら大丈夫じゃないかなｗ

45 ：仕様書無しさん：2007/08/16(木) 08:27:14

COMP-3で持ってるかも・・・

46 ：仕様書無しさん：2007/08/16(木) 12:25:16

カフェ本は喫茶店じゃねえだろ

47 ：仕様書無しさん：2007/08/16(木) 22:34:18

public xl as Object

48 ：仕様書無しさん：2007/08/16(木) 23:41:51

HogeHoge=HogeArr(i)(j)(0)
FugaFuga=HogeArr(i)(j)(1)

49 ：仕様書無しさん：2007/08/17(金) 03:34:09

>>33
それ、ドルとセントじゃないの？

50 ：仕様書無しさん：2007/08/17(金) 10:26:44

それは進駐軍が放出したレジなのかと。

51 ：仕様書無しさん：2007/08/17(金) 12:52:56

>49,>50
なにバカ言ってるんだ
日本の方が進んでたんだぞ

http://www.ncr.co.jp/library/library/register/reg02.html

52 ：仕様書無しさん：2007/08/17(金) 19:42:36

>>39
こら、キャラ数合わせないと帳票ずれるでしょ

53 ：仕様書無しさん：2007/08/17(金) 19:44:09

すまん出力領域へMOVEするから関係ないのな。
つーか >>39コンパイルエラー

54 ：仕様書無しさん：2007/08/17(金) 20:33:42

>>53
>>39ピリオドがない？

55 ：仕様書無しさん：2007/08/17(金) 20:45:19

行の最後は必ずピリオドで終わるなんて信じていると
F通COBOLでは痛い目見るぞ。

コンパイルエラーすら出ないで通るし...orz

56 ：仕様書無しさん：2007/08/17(金) 20:58:13

>>55
変数の定義でも？

57 ：仕様書無しさん：2007/08/19(日) 18:09:36

随分コボラが多かったんだなこのスレ。

58 ：仕様書無しさん：2007/08/19(日) 18:26:31

コボラは老害。死ぬかさっさと去るべき。

59 ：仕様書無しさん：2007/08/19(日) 18:27:44

滅びても
第二・第三のコボラが・・・・

60 ：仕様書無しさん：2007/08/19(日) 18:57:57

コボラは滅びぬ。何度でも甦るさ。

61 ：仕様書無しさん：2007/08/19(日) 19:17:40

ロ○テ　コボラのマーチ

62 ：仕様書無しさん：2007/08/19(日) 19:28:49

>>61
不味そうだ

63 ：仕様書無しさん：2007/08/19(日) 19:53:58

>>61
あんまり大量生産しないでください…。

64 ：仕様書無しさん：2007/08/19(日) 19:55:17

立ち位置的にはオロナミンCぐらいじゃないの？
なんでまだ残ってるんだコンナモンみたいな

65 ：仕様書無しさん：2007/08/19(日) 19:56:03

有毒だな。食べた会社は死んでしまう

66 ：仕様書無しさん：2007/08/19(日) 20:00:09

残ってると言うより、企業によっては増え続けてますよ。

67 ：仕様書無しさん：2007/08/19(日) 20:07:08

癌細胞みたいだな。w

68 ：仕様書無しさん：2007/08/19(日) 21:23:47

なんかコボラの描いたソースは無条件にこのスレテーマに該当しそうな勢いだな。

69 ：仕様書無しさん：2007/08/19(日) 21:35:48

コボラ出血熱

70 ：仕様書無しさん：2007/08/19(日) 22:12:09

スペースコボラ

71 ：仕様書無しさん：2007/08/19(日) 22:12:21

エボラに失礼

72 ：仕様書無しさん：2007/08/19(日) 22:34:01

刃こぼら

73 ：仕様書無しさん：2007/08/19(日) 22:57:52

「コボちゃん」の名前の由来って・・・

74 ：仕様書無しさん：2007/08/19(日) 23:00:34

コボルで動いてるからでしょ？

75 ：仕様書無しさん：2007/08/19(日) 23:13:11

田畑小穂だっけ?

76 ：仕様書無しさん：2007/08/20(月) 00:34:09

COBOLが動くのか凄いな

77 ：仕様書無しさん：2007/08/20(月) 01:08:39

去年までUNIXでCOBOLつかってましたよ。
その時点でやめたくなりました。

78 ：仕様書無しさん：2007/08/20(月) 01:51:38

あんな糞言語があんな高価な理由が解らん<COBOL

79 ：仕様書無しさん：2007/08/20(月) 02:23:20

>61
マーチはマーチでもデスが付くマーチなんだろうな…

80 ：仕様書無しさん：2007/08/20(月) 02:35:18

糞言語というよりは「古代言語」と言うべきかな？

81 ：仕様書無しさん：2007/08/20(月) 05:58:11

フォートランもそう呼ばれることはあるけど、コボルよりは読みやすいね

82 ：仕様書無しさん：2007/08/20(月) 05:58:56

で、その古代言語で書かれた古文書の解読に今日も俺はいそしむわけだ…

83 ：仕様書無しさん：2007/08/20(月) 12:07:02

富士通日立はCOBOL好きだからなぁ

84 ：仕様書無しさん：2007/08/21(火) 00:12:09

COBOLの新しい規格って現場じゃ使われてるのかな?

85 ：仕様書無しさん：2007/08/21(火) 01:50:50

知らんﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ

86 ：仕様書無しさん：2007/08/21(火) 01:58:49

ああ、ここもついに犯され始めたかﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ

87 ：仕様書無しさん：2007/08/21(火) 02:00:22

コボラ捨てたいﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ

88 ：仕様書無しさん：2007/08/21(火) 09:01:16

寿司食いたいﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ

89 ：仕様書無しさん：2007/08/21(火) 09:08:26

いあ。いあ。ふんぐるい　むぐるうなふ　こぼる　ふたぐん

90 ：仕様書無しさん：2007/08/21(火) 10:05:16

本当の悪夢はｺﾎﾞ会社が唐突にJAVA開発始めたとき

ﾏﾁﾞｼﾇﾙ

91 ：仕様書無しさん：2007/08/21(火) 13:20:31

Javaで（辞めたいほどの）糞コードって書けるの？

92 ：仕様書無しさん：2007/08/21(火) 13:22:37

伝統の数千行main()とか、catch(Exception e){} とか
興味深いコードは沢山あるぞ

93 ：仕様書無しさん：2007/08/21(火) 14:55:16

本物のコボラはどんな言語の上でもCOBOLプログラムを書ける。

94 ：仕様書無しさん：2007/08/21(火) 14:58:09

どんな言語もCOBOL風にやっちまうんだよな

変数も定数も全部大文字とか
数値をいちいち文字列に変換してから処理とか

95 ：仕様書無しさん：2007/08/21(火) 15:29:20

>>88
ガリでも食ってろﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ

96 ：仕様書無しさん：2007/08/21(火) 16:11:58

VBみたいな自動文字整形されちゃうのは無理だろとか思ってたら
コメントに大文字英数でCOBOL訳が書いてあった。

97 ：仕様書無しさん：2007/08/21(火) 17:02:18

すげぇ執念((((；ﾟДﾟ))))

98 ：仕様書無しさん：2007/08/21(火) 17:03:33

∩(・∀・)∩いあ！こぼる！こぼる！！

99 ：仕様書無しさん：2007/08/21(火) 17:12:29

COBOL対訳付きのソースなんて・・・

100 ：仕様書無しさん：2007/08/21(火) 17:37:02

訳が許されるのはアセンブラまでだよね～

101 ：仕様書無しさん：2007/08/21(火) 18:55:45

コボラの執念は異常

102 ：仕様書無しさん：2007/08/21(火) 21:11:59

怨念だろ...

103 ：仕様書無しさん：2007/08/21(火) 21:30:03

上司「新しい案件の話なんだが、某社にてコボルで作成された古いシステムがある」
俺「（あー、リプレースか・・・）」
上司「で、そいつが寿命と言う事もあり、リプレースの時期にある。」
俺「（流行でJavaでWEBとか言うんだろうな、糞）」
上司「そこで、新しくコボルでリプレースする事になった」

・・・・は？

俺「いや、自分も周りもコボル使える人なんていないんですが・・・」
上司「大丈夫。俺でも読める」

辞めるかな、この会社。
って辞めたくなった上司の一言のネタだな、こりゃ

104 ：仕様書無しさん：2007/08/21(火) 21:37:29

>>103
COBOLでWEBだな。

105 ：仕様書無しさん：2007/08/21(火) 21:42:58

COBOL ON RAILS

106 ：仕様書無しさん：2007/08/21(火) 22:09:21

>>103
…ウチは PL/I→COBOL だよ

107 ：仕様書無しさん：2007/08/21(火) 22:26:03

ACAX

108 ：仕様書無しさん：2007/08/21(火) 23:11:18

皆大文字使うんだな、流石だ。

109 ：仕様書無しさん：2007/08/21(火) 23:28:33

>106
逆行しとるがなｗ

110 ：仕様書無しさん：2007/08/22(水) 00:13:37

C言語において、、、
ヘッダファイルにグローバル変数が"定義"してある。(externはなく、staticでもない)
そのヘッダは #ifndef XXX_H の様な記述は無く、多重includeの対策は無い。
標準ライブラリで定義済の変数を、何故か自分で定義している。
バグがあり、症状も現れている。(テストしてないだろてめぇぇぇ)
潜在バグも既に発見されている。(ローカル配列のポインタを返すなど)
必要も無いのに、全レコードを読み込んで保持する。(reallocを繰り返す)
そのreallocは ptr = realloc(ptr, size);
文字列リテラルの連結 "AAAA" "BBBB" をいちいち、strcatなどで連結する。
一つめのifで確定した条件をネストしたifでもう一度聞いている。
関数一つが数百行。
ifやfor/whileのネストは８段階くらい。
コメントアウトされた部分が、実際に生きているコードより長い。
原則１プログラム１ソースファイル。
など。

111 ：仕様書無しさん：2007/08/22(水) 00:18:02

>>92
＞catch(Exception e){}
ん、これ何か問題が？

112 ：仕様書無しさん：2007/08/22(水) 00:18:55

＞ヘッダファイルにグローバル変数が"定義"してある。(externはなく、staticでもない)
gccなんだろうかねぇ・・・。

113 ：仕様書無しさん：2007/08/22(水) 00:21:13

>>111
例外の握りつぶしは犯罪
１００歩ゆずってもログに吐け、なにが起きたか解らないだろ・・・

114 ：仕様書無しさん：2007/08/22(水) 00:23:07

「全盛期の糞コード」スレみたいな

･あまりにコンパイルエラーが出るからエラーでもバイナリ生成
･ソースファイルを保存しただけでOSがフリーズした

115 ：仕様書無しさん：2007/08/22(水) 00:23:47

>>113
再スローすれば握り潰しにはならないぞ。
エクセプションは例外の種類別に処理するのが望ましいというだけで・・・。
オマエの発言は厨臭いな。

116 ：仕様書無しさん：2007/08/22(水) 00:24:59

>>115
> catch(Exception e){}
このコードのどこが再スローしてるんだよｗ

117 ：仕様書無しさん：2007/08/22(水) 00:25:34

情報漏えい対策とかで、爆弾みたいなツールを導入された
なにかやる度に動き始めて、PCの起動に約１０分
ソースは全て暗号化されているから、都度解凍しなくてはならない
パスワードも凝っていてフザケンナ

で、ソースも暗号なんですよｗ

118 ：仕様書無しさん：2007/08/22(水) 00:26:17

>>115
＞catch(Exception e){}
ブロックの中身を省略してレスしたわけじゃなくて、
ホントに何の処理もしないcatchが入ってるってことじゃないか？

119 ：仕様書無しさん：2007/08/22(水) 00:26:30

>>115
> catch(Exception e){} ←
跡形もなく握りつぶしてますがなｗ

120 ：仕様書無しさん：2007/08/22(水) 00:27:58

> catch(Exception e){}
の時点で糞だろ
再スローしたとしても、throws Exception と記述するハメになる

121 ：仕様書無しさん：2007/08/22(水) 00:28:08

シェルスクリプトにて、
複数あるシェルスクリプトの共通的な環境変数も、いちいち其々に書く。
テンポラリファイルを消さない。(消すJOBを別定義してある)
変数を必要もないのに環境変数化にする。
必要もないのにawkなどを使いたがる。
引数かリダイレクトで済むのに、なぜか cat file | grep ..など
シェルスクリプトを「シェル」と(ry

122 ：仕様書無しさん：2007/08/22(水) 00:29:50

>>116
あぁ。すまんな。
このスレでは過去から何度も(Exception e)について議題に上がってたんだよ。
もう、ずっと前の過去スレから。

そんなトコにツッコミ入れるとは思いもよらなかったよ。

123 ：仕様書無しさん：2007/08/22(水) 00:41:32

>>122
思い込みでソース書きそう。
しかも自分の思い込みが常に正しいと思ってるな。
一緒に仕事したくないタイプ。

と思い込みにより断定してみた。

124 ：仕様書無しさん：2007/08/22(水) 00:43:45

禿同

125 ：仕様書無しさん：2007/08/22(水) 00:43:51

>>123
自己紹介乙。

126 ：仕様書無しさん：2007/08/22(水) 00:49:47

>>109
それがさ、情報処理試験の選択肢から
PL/I が既に消えてるからって理由らしいんだよ…

確かに COBOL はまだある…あるけどさ…？

127 ：仕様書無しさん：2007/08/22(水) 01:04:52

>>122
なにこの上から目線ｗｗｗ

128 ：仕様書無しさん：2007/08/22(水) 01:07:16

>>127
オマエのようなバカで厨にはちょうどいいんだよ。

129 ：仕様書無しさん：2007/08/22(水) 01:12:00

catch(Throwable e){}

130 ：仕様書無しさん：2007/08/22(水) 01:19:51

そこまでやればもう拍手をやりたいなｗ

131 ：仕様書無しさん：2007/08/22(水) 09:35:59

>>113
会社に握り潰しどころか、正常値返して何事もなかったかのように振る舞うソース書くツワモノが……

でも、返す値が出鱈目だから、結局駄目なんだけど

132 ：仕様書無しさん：2007/08/22(水) 10:16:09

>>131
それは正常値を捏造してんじゃなくて、
エラーの時はエラーコードを返すって
懐かしい習慣を今の世に伝えようと
しているんではないかと。

で、コメントにエラーコードとエラー内容の
対応が書いてあったりしてなあ。

133 ：仕様書無しさん：2007/08/22(水) 10:16:43

>>131
返り値捏造はスゴイと思うです。

134 ：仕様書無しさん：2007/08/22(水) 10:37:54

>>132
いや、理解しがたいかもしれないがマヂ
例外起きるとDBの値を適当に持ってきてやがった

orz

135 ：仕様書無しさん：2007/08/22(水) 11:20:30

>>110
> そのreallocは ptr = realloc(ptr, size);
何か問題が? realloc ってそういうもんだよね。
reallocならmemcpyもしてくれるし。
memcpyが要らない場合でも、memcpy は普通無視できる程度の時間しかかからないし。

> 文字列リテラルの連結 "AAAA" "BBBB" をいちいち、strcatなどで連結する。
場合によってはそういうのもアリじゃないか?
目くじら立てるほどとは思えん。
もちろん、バッファ境界を気にしてなくてバッファオーバーフローが起きるなら別だが。

俺C++使いだが、stream に連続して << 操作したり、
std::basic_string<T> に連続して += したりするぞ?
その方が意味が明確になる場合もあるからな。

136 ：仕様書無しさん：2007/08/22(水) 11:25:00

>>135
realloc() が失敗したら漏れる。

137 ：仕様書無しさん：2007/08/22(水) 11:26:49

>>135
文字列リテラルは並べて書くだけで連結できる。

138 ：仕様書無しさん：2007/08/22(水) 11:45:23

>>134
それ、プログラマーとしてってより
人間として失格だよ！

139 ：仕様書無しさん：2007/08/22(水) 13:17:21

>>136
reallocが失敗するような状況で、それが何の問題が？

140 ：仕様書無しさん：2007/08/22(水) 13:41:37

ptr1 = realloc( ptr, size );
if( ptr1 ) {
ptr = ptr1;
}
else {
// ptr に有る情報は何かに使う
}
とか？
もっとも malloc() がコケた以上先の処理がまともに動くとも思えんけど
しかし１レコード読むごとに realloc() してたら殺したくなるな

141 ：仕様書無しさん：2007/08/22(水) 13:54:58

>>110のようなソースの修正やってて文句言いながらやってたら
リーダーに「人のソースにいちいち腹が立つような人は要らない。他にも人間はいる」
とかいわれて別チームに振りなおされた漏れ
まさかそのソース、お前が書いたのか？

142 ：仕様書無しさん：2007/08/22(水) 14:02:10

出来ることって、せいぜい free して、
アプリケーションを終了するくらいだな

キャッシュとかのためにメモリバカ食い設計になっているプログラムなら、
キャッシュを解放して再挑戦する価値はあるかもしれないが、
それでもフラグメンテーションがすごそうだからやっぱり何も出来ないかもしれないな

143 ：仕様書無しさん：2007/08/22(水) 14:40:56

/* ここから先は見ちゃイヤン */

ってコメントがついた、そりゃーもうすんばらしい若気の至り満載な関数がorz

144 ：仕様書無しさん：2007/08/22(水) 14:50:57

>>142
>free して、
>アプリケーションを終了
やめとけ。

(以下、例のループ)

145 ：仕様書無しさん：2007/08/22(水) 15:40:09

さぁ、fjに行こうかｗ

146 ：仕様書無しさん：2007/08/22(水) 20:08:21

>>120

int a = 10; // default value
try {
a = Integer.parseInt(aStr);
} catch (NumberFormatException e) {}

はやるなぁ。

147 ：110：2007/08/22(水) 20:19:19

realloc と文字列連結の話は、>>136,>>137の通りです。
mallocで最初に150MB程度確保、その後reallocで25MBずつ拡張、最終的に350-400MB程度まで確保です。
reallocで失敗したらすぐ終了してるんですが、reallocとかmallocで確保した領域は、
freeしなくても、プログラムの終了時に自動解放される(または場合が多い)、
との事ですが実際のところどうなんでしょうね？

>>141
あなたを苦労させているのは、私じゃありませんよ。
私も(心の中で)グチりながらやってます。

148 ：仕様書無しさん：2007/08/22(水) 20:30:31

>>146
場合によるけど起こりえないならRuntimeExceptionでラップして投げとく方がいいし、入力側でチェックしたり先に変換しておくほうがベターだろ

149 ：仕様書無しさん：2007/08/22(水) 20:50:04

>>148
その入力時チェックと、NG時の値の設定を同時にやりたいんだろう。
と言うか俺もやるよこれ。楽で。
もちろん、すごい回数やるような時には使わないが。

150 ：仕様書無しさん：2007/08/22(水) 20:58:38

全角通っちゃうけど

151 ：仕様書無しさん：2007/08/22(水) 21:02:04

職場じゃないし議論しても意味はないけど

例えば「２０」と間違えて全角で入れてしまった場合、ユーザーには何の警告も出さずにデフォルトの１０に設定されてしまうが、それでいいの？

152 ：仕様書無しさん：2007/08/22(水) 21:13:10

いい。
指示されてない以上それでまったく問題ない。

気を利かせて作ってあげてもまったく感謝しないのだから、そこは追加料金貰う。
それが業界標準。

153 ：仕様書無しさん：2007/08/22(水) 21:25:47

そりゃ、そんな会社は辞めたくなるな

154 ：仕様書無しさん：2007/08/22(水) 21:28:25

知識も技術もない奴が書いたならば仕方ないとも思うが、解っていて書くのマとしてどうよ？

155 ：仕様書無しさん：2007/08/22(水) 21:29:25

>>147

fj.lang.c malloc free でぐぐる。

156 ：仕様書無しさん：2007/08/22(水) 21:42:16

>>149
にしてもちょっと判りにくい。
catchの中で10を入れてもらった方が
やりたい事が素直に伝わる。

157 ：仕様書無しさん：2007/08/22(水) 23:10:24

ユーザーは間違いを指摘されると苛つくもんだ。
黙ってデフォルト値のほうがマシなケースも多い。
金とか命がかかってるなら別だけどね。

158 ：仕様書無しさん：2007/08/22(水) 23:12:09

でもデフォルト値に変更されたことを報知する仕組みはあったほうがいいよな

159 ：仕様書無しさん：2007/08/22(水) 23:24:12

間違いを指摘されて苛立つと文句くるくらいなら入力させなきゃいいんじゃねｗ

160 ：仕様書無しさん：2007/08/22(水) 23:29:01

一般的なユーザ
↓

ヤダャダー!
〃〃∩　_,,_
　⊂⌒( `Д´)
　　`ヽ_つ⊂ノ

間違いを指摘されるのは
　　　_,,_
〃〃(`Д´∩
　　⊂　　 (
　　　ヽ∩　つ

でも黙って
デフォルト値を入れられるのもいや
〃〃∩　_,,_
　⊂⌒(つД´)
　　`ヽ_ノ⊂ノ

可愛い彼女も欲しい …
　　　∩
　⊂⌒(　_,,_)
　　`ヽ_つ⊂ノ

... ...
zzz…
　　　∩
　⊂⌒(　_,,_)
　　`ヽ_つ⊂ノ

161 ：仕様書無しさん：2007/08/22(水) 23:35:19

＞でも黙って
＞デフォルト値を入れられるのもいや
＞〃〃∩　_,,_
＞　⊂⌒(つД´)
＞　　`ヽ_ノ⊂ノ

大丈夫だよ、君は気づかないｗ

＞可愛い彼女も欲しい
禿同

162 ：147：2007/08/23(木) 00:29:06

>>155 ありがとう。
ttp://www.mk.ecei.tohoku.ac.jp/~masahide/knowhow/C_FAQ_2
の 7.24にありました。やはり、当てにしない方が無難ですね。

163 ：仕様書無しさん：2007/08/23(木) 00:58:40

>>162
釣り?　またループしたいの?
あなたの使おうとしているOSや処理系のマニュアルを読みなさい。
Cの規格をいくら読んでも無駄。

164 ：仕様書無しさん：2007/08/23(木) 14:06:12

「fj行こう」＝「富士の樹海行こう」だと思った

165 ：仕様書無しさん：2007/08/23(木) 14:27:05

え？違うの？

166 ：仕様書無しさん：2007/08/24(金) 11:53:53

そんな貴方に

uwarite

167 ：仕様書無しさん：2007/08/24(金) 20:56:34

うわらば

168 ：仕様書無しさん：2007/08/24(金) 21:09:06

>>164
「富士通に行こう」かと思った。
意味は>>164と変わらんが。

169 ：仕様書無しさん：2007/08/24(金) 23:29:50

少しは関数名を考えろと思った

int fuck()
{
//何かのチェック処理
}

170 ：仕様書無しさん：2007/08/24(金) 23:35:57

func
fund
fune
funf
fung
funh
連番にするなと言っておいたら、こんなん書かれた事ある。
書いた奴はぶん殴ったのは１０年以上前の思い出

171 ：仕様書無しさん：2007/08/24(金) 23:45:57

「funeです。来週のサザエさんは、funf, fung, funh の三本です。」

172 ：仕様書無しさん：2007/08/24(金) 23:49:44

俺だったら褒めてやるけどなｗｗｗ

173 ：仕様書無しさん：2007/08/25(土) 00:26:41

どんだけ天邪鬼ｗ

174 ：仕様書無しさん：2007/08/25(土) 00:39:01

for (int i = 0; i < nSize; i ++)
{
//設定値読み込み
Dokjinoyomikomikansuu();　　//正式名称は忘れた

//処理・・・
}

ってのを見たことがある。同じ設定を何度も何度も、ループで読んでる。
しかも、そのループ自体が別の関数からループで呼ばれている……

設定情報って一度だけ読めばよかったんじゃないのか？

175 ：仕様書無しさん：2007/08/25(土) 00:39:40

ちなみに、設定値読み込みはファイルから読み込んでいる。

176 ：仕様書無しさん：2007/08/25(土) 00:48:44

>>174-175
システム次第なんでなんとも言えんなぁ。

177 ：仕様書無しさん：2007/08/25(土) 01:47:25

別スレッドで設定が更新される可能性があるんでしょ。ないんだろうけど。

178 ：仕様書無しさん：2007/08/25(土) 09:34:47

>>171
来週もまた、見てくださいねー！

fungっfunf

179 ：仕様書無しさん：2007/08/26(日) 01:27:45

会社の業務システムの年号が昭和。
印刷すると伝票が昭和で出てきて、みんな修正テープで手修正。

直すように俺が投入されたが・・・スパゲッティだし・・・

180 ：仕様書無しさん：2007/08/26(日) 01:32:52

２０年近く放置かよｗｗｗｗ

181 ：仕様書無しさん：2007/08/26(日) 01:33:13

出力直前に63引いて平成にするだけってことでなんとか・・・・

182 ：仕様書無しさん：2007/08/26(日) 01:36:02

それ「だけ」のことすら簡単にいかないのが
スパゲティのスパゲティたる所以かも。

183 ：仕様書無しさん：2007/08/26(日) 01:39:26

>>179
それって最近の話？もう平成19年なんですが...
古いシステムでソースも見にくいものに限って、仕様書／設計書もない。
ってパターンかな、、、

184 ：仕様書無しさん：2007/08/26(日) 01:39:42

だろうな。
印刷した紙の隅っこに昭和と平成の変換式を出力汁

185 ：仕様書無しさん：2007/08/26(日) 01:43:39

いやもう、印刷だけの処理なら、新しく書き直しちゃった方が早いかもね。

186 ：仕様書無しさん：2007/08/26(日) 01:50:08

>185
印刷だけで1実行モジュール? 何を呑気な
まず間違いなく入力参照更新印刷、全部1つに詰め込まれてるだろうさ。
昭和時代のスパゲッティにMVC分離なんて念仏にもならんよorz

187 ：仕様書無しさん：2007/08/26(日) 01:59:06

だろうなー
大丈夫だろうと６３引いてみたらば、予期せぬ所で計算が狂うとか確実に出そうだ

188 ：仕様書無しさん：2007/08/26(日) 03:47:18

年をループカウンターに使ったりとかあったりしてなw

189 ：仕様書無しさん：2007/08/26(日) 04:11:40

夢は膨らむなｗ

190 ：仕様書無しさん：2007/08/26(日) 05:03:34

悪夢だな…

191 ：仕様書無しさん：2007/08/26(日) 07:07:56

どうせなら西暦に直せよ。
4桁にするのは無理っぽいかも知れんがな…。
年号だとまた変わるぞ。

192 ：仕様書無しさん：2007/08/26(日) 07:15:37

そんなに長く使われると思わなかったんだろうな
Javaの2億9千万年問題も夢物語だが意外と起こるかもしれんなあ
http://ja.wikipedia.org/wiki/Java%E6%89%B9%E8%A9%95

193 ：仕様書無しさん：2007/08/26(日) 09:52:35

>>187
その - 63 を書くべき場所が、1ヶ所ならいいけど

194 ：仕様書無しさん：2007/08/26(日) 10:02:36

どうしてみんな元号が好きなのかよくわからん。
規定かなんかあったっけ？

195 ：仕様書無しさん：2007/08/26(日) 10:42:40

官公庁の風習

196 ：仕様書無しさん：2007/08/26(日) 12:59:43

JCLの印刷機に対応したDD文をファイルに変更。
そのファイルを読み込み、昭和=>平成変換プログラムに通す！

197 ：仕様書無しさん：2007/08/26(日) 14:17:25

>>194
使わないと街宣車がやって来る。

198 ：仕様書無しさん：2007/08/26(日) 15:04:15

キリスト教国でもないのに
キリスト暦を使うわけにもいかんだろ

199 ：仕様書無しさん：2007/08/26(日) 15:08:29

ここはユリウス通日で通すしかないな。

200 ：仕様書無しさん：2007/08/26(日) 15:40:55

神武紀元があろう

201 ：仕様書無しさん：2007/08/26(日) 16:42:21

防衛庁納入では必須だよ

202 ：仕様書無しさん：2007/08/26(日) 16:43:49

ttp://ja.wikipedia.org/wiki/%E7%9A%87%E7%B4%80

安田生命保険（今の明治安田生命保険）は1970年代に個人情報管理のシステムを構築することになった。
その際システムの担当者は、20数年後に生じるであろう2000年問題を予測していた。
そこで、年号の下2桁にグレゴリオ暦や元号ではなく神武暦（グレゴリオ暦－40年）を使用した。
そのことにより、安田生命保険は2000年問題を40年先送りした。

203 ：仕様書無しさん：2007/08/26(日) 16:54:22

unixタイムでいいよ

204 ：仕様書無しさん：2007/08/26(日) 17:13:06

わかってたらもっとマシな回避方法を取れとｗ
変換が増えて面倒そうだし

205 ：仕様書無しさん：2007/08/26(日) 17:13:30

>>202
予測しておきながらそんな解決方法を取るってのはアホだな。

206 ：仕様書無しさん：2007/08/26(日) 17:14:38

>>204,>>205
思ったとおりの反応。そして俺も同意。

207 ：仕様書無しさん：2007/08/26(日) 18:56:22

分かってて何もしないのよりもよっぽどマシだと思うがこれは酷いｗｗ

208 ：仕様書無しさん：2007/08/26(日) 19:21:46

一瞬「2038年問題よりも先まで耐えられる分マシじゃん」と思ったが、
time_tもそろそろ64ビット以上で定義するのが当たり前になってきてるんかな。

209 ：仕様書無しさん：2007/08/26(日) 19:33:00

>>204
>>205
>>206

さすがにストレージがここまで値段が下がるとは予測できなかったと思われ。

210 ：仕様書無しさん：2007/08/26(日) 21:48:03

いくらなんでもこのシステムやコードはリプレースされてるのでは？
1970年代だし…

211 ：仕様書無しさん：2007/08/26(日) 22:09:20

そういって動き続けているコードがどれだけあることやら

212 ：仕様書無しさん：2007/08/26(日) 22:34:41

#include "stdafx.h"
class f{public:void oO(char*c){printf(c);return;}};
int main(){
　　f(O_O);
　　(O_O).oO("定時まであと1時間半、どうやって潰そう・・・。")
;for(;;);return 0;
}

仕事しろ仕事。

213 ：仕様書無しさん：2007/08/26(日) 22:37:13

>>211
ボイジャー2号は1977年打ち上げ

それ以前に起動完了して未だに動いてるのは知らね。

214 ：仕様書無しさん：2007/08/27(月) 10:19:19

ボイジャーとかはレアケースだろとかいわれそうだけど
普通の業務システムで30年以上動いてる相手に
仕事したよ。

足りない機能をJavaで作ったんだけど、なんかMQとかで
つないでるらしい。

リプレースすりゃいいじゃんって話にはなかなかならないって。

215 ：仕様書無しさん：2007/08/27(月) 18:15:25

「動いてるものは下手にいじくるな」つーのが鉄則だし

216 ：仕様書無しさん：2007/08/27(月) 19:25:36

そして手遅れになる

217 ：仕様書無しさん：2007/08/27(月) 23:01:58

派遣だが、思いっきり派遣先に内緒でソースコード全部書き換えたよ。
あまりにも糞過ぎるコードなんだもん……期限は特に切られてなかったし、
少々時間かかっても、ソースコードが書き換わって、試験成績書と設計書（もちろん、なかった）
が添付されてればOKだよな？　別に全部書き換えるなとは言われてなかったし。
たかだか、2,3万行のプログラムだったし……

218 ：仕様書無しさん：2007/08/27(月) 23:15:11

>>217
世間一般ではたぶんNGだな

219 ：仕様書無しさん：2007/08/27(月) 23:30:40

相談もなしってのはなぁ

220 ：仕様書無しさん：2007/08/27(月) 23:34:52

信頼され具合とか仕事の任され具合とか会社の文化とか
他にも色々と絡んで来るだろうけど
一般論だとNGだろうなぁ。

221 ：仕様書無しさん：2007/08/27(月) 23:42:14

どこかに話通さないと大変そうだなぁ

222 ：仕様書無しさん：2007/08/27(月) 23:45:30

内緒ってのはマズいよなぁ。

223 ：仕様書無しさん：2007/08/27(月) 23:48:26

話通そうとしても絶対NG返ってくるだろうしなぁ

224 ：仕様書無しさん：2007/08/27(月) 23:52:01

あ、言っておくが指示そのものが曖昧だったんだぞ。
おまけに、結果論だが改修よりも工数がかからなかった。

さらに、バグも減りまくった。
ついでに言うと、改修要求のうち一つがかなり深い部分までプログラムを書き換えないといけないところだったために、
全改修でなくても、どのみち、同じぐらいの改修は必要になっていたよ。

まぁ、でも相談は必要だったろうな……

225 ：仕様書無しさん：2007/08/27(月) 23:53:52

まあ、相談せずにやっておいて、承認でたら置き換えて終了ってのはよくやる。
指示が曖昧で何も決まらず時間だけが過ぎているから、とりあえず改修してしまっておくのは仕方ないわ

226 ：仕様書無しさん：2007/08/28(火) 03:48:58

まぁ味方になってくれそうな上司に前のものと新しい設計書渡して｢こんなんどうですか？｣
とか聞いて、説得して、｢実わ出来てるんですが｣とか

227 ：仕様書無しさん：2007/08/28(火) 07:37:08

>>224
> さらに、バグも減りまくった。
減りまくってもゼロじゃない限り、何か起きたときに責任問題になる。

「以前のソースを改修すればこのバグは無かったんじゃないのか？」とかとか...

相談しておかないと結局は痛い目を見る事になる。
揚げ足取る奴はどこにでも居るからな。

228 ：仕様書無しさん：2007/08/28(火) 09:37:39

> さらに、バグも減りまくった。

この言い回しで程度が知れるな。

229 ：仕様書無しさん：2007/08/28(火) 10:40:13

ソースコード云々より、まず給料が出ないので、、、

230 ：226：2007/08/28(火) 12:50:00

これさ当人以外に、｢問題なし｣と思っているやつはいるのか？

231 ：仕様書無しさん：2007/08/28(火) 13:08:30

「問題なし」は知らんが「やむなし」はいそう

232 ：仕様書無しさん：2007/08/28(火) 13:10:40

勝手に修正し後日別料金請求して
「おまいは悪徳リフォーム屋か」
と褒めて欲しかっただけじゃないかなと思ってる

233 ：仕様書無しさん：2007/08/28(火) 13:44:02

>｢実わ出来てるんですが｣

馬鹿？

234 ：仕様書無しさん：2007/08/28(火) 18:56:15

既存プログラムの修正：如何に少ない修正で所望の変更を行うかに全力を注ぐ
新規プログラム(既存に類似機能あり)：如何に少ない追加で所望の機能を得られるかに全力を注ぐ
新規プログラム(既存に類似機能なし)：如何に似せたソースコードで所望の機能を得られるかに全力を注ぐ

新規プロジェクト：好きなだけ新しい手法・コーディング・クラス設計その他をぶっこんで、決まったルールに従い好きなようにコーディングする

以上俺ルール

235 ：仕様書無しさん：2007/08/28(火) 19:01:23

やむなしはあるな、どうやっても直せなそうなコードってあるだろ、あべし製とか

236 ：仕様書無しさん：2007/08/28(火) 21:31:19

>既存プログラムの修正：如何に少ない修正で所望の変更を行うかに全力を注ぐ
>新規プログラム(既存に類似機能あり)：如何に少ない追加で所望の機能を得られるかに全力を注ぐ

典型的な失敗プロジェクト

237 ：仕様書無しさん：2007/08/29(水) 00:38:51

>234
漏れなら設計、実装(修正)、試験、（客や上司・メンバーへの）説明、
のトータルコストで考える。

238 ：仕様書無しさん：2007/08/29(水) 00:45:12

あべし(ノ∀`)

239 ：仕様書無しさん：2007/08/29(水) 05:54:25

>>234
>既存プログラムの修正：如何に少ない修正で所望の変更を行うかに全力を注ぐ

悲しいかな、漏れもそれを考えてやってるだ。
コードの修正箇所増＝ドキュメント増＆確認工数増とかって理由でな。

理想をいうと、所望の変更ってのが当初から与えられていたとしたときに書くコードを、
修正のときにも書くべきだと思ってるんだが。

理想と現実のギャップが大きすぎるなあ。

240 ：仕様書無しさん：2007/08/29(水) 13:27:23

>>234
めっちゃリアルやな。
ソースレビューやってソース管理して技術者を萎縮させてるNECや日立がやりそうなこと

241 ：仕様書無しさん：2007/08/29(水) 13:32:36

>>235
「直せる人、手を挙げて～」ってやって誰も手を挙げなかったから、リーダーが折れて
作り直しになったことがあるな…。既に玉砕者が2人くらい出てたし。

読むだけで狂いそうになるくらい、糞なコードだった。

242 ：仕様書無しさん：2007/08/29(水) 15:13:21

> ソースレビューやってソース管理して

これが技術者を萎縮させるのか・・・？

243 ：仕様書無しさん：2007/08/29(水) 15:28:41

ソースレビュー＆管理は必要だと思うんだが、
ソース読まない（読めない）人にレビューさせると、うるさくてかなわんと思うことはあるかな。

244 ：仕様書無しさん：2007/08/29(水) 17:49:23

異常なソース管理するとうんざりだなｗ

245 ：仕様書無しさん：2007/08/29(水) 19:01:27

異常な「ソース管理」？
「異常なソース」管理？

246 ：仕様書無しさん：2007/08/29(水) 19:59:57

修正箇所は「修正begin/end」のコメントで囲む。
元のソースはコメントとして残す。
diffも残す。

なんて管理があったな。
svn使っているのにヽ(`Д´)ノ

247 ：仕様書無しさん：2007/08/29(水) 21:28:35

マイクロソフトにもメンテあきらめたコードがなかったっけ？
Java関係のIEモジュールかなんかで。
第一人者の大学教授に開発してもらったけど、他のプログラマがメンテできないコードなので、
サポート終了することにしたって話。

248 ：仕様書無しさん：2007/08/29(水) 22:20:19

それがどうした？

249 ：仕様書無しさん：2007/08/29(水) 22:32:33

過去ソースの復旧作業で納期前の１週間を潰した俺が通りますね

250 ：仕様書無しさん：2007/08/29(水) 23:21:44

Hoge val;
val = new Hoge();
if(hogeDict.TryGetValue("a", out val))
{
　　val = HogeDict["a"];
　　...
}

251 ：仕様書無しさん：2007/08/30(木) 21:45:59

だってvalが好きなんだもん！ほっといてくれよ！

252 ：仕様書無しさん：2007/08/30(木) 23:21:36

>>250
何言語か分からんけど、察するに、
アウトパラメータなのに、直前にインスタンスをわざわざ作ってる。
ってあたりが嫌なのだと見た。
そして成功したら多分、valには既に HogeDict["a"]が入っているので、
if内 val = HogeDict["a"]が不要。

憶測ですがあってる？

253 ：仕様書無しさん：2007/08/30(木) 23:32:09

bufなアナタはC/C++派。
tmpなアナタはVB派。
foo/barなアナタはPerl派。
ローマ字なアナタはCOBOL派。

254 ：仕様書無しさん：2007/08/31(金) 10:51:54

>>253
ローマ字以外当てはまる私は何派でしょう？

255 ：仕様書無しさん：2007/08/31(金) 12:01:46

ごった煮派

256 ：仕様書無しさん：2007/08/31(金) 13:07:48

カオス派

257 ：仕様書無しさん：2007/08/31(金) 13:21:29

ファンタジーと呼ばれるものをするよ派

258 ：仕様書無しさん：2007/08/31(金) 13:48:10

ビューティを紡ぎ奏でるよ派

259 ：仕様書無しさん：2007/08/31(金) 20:36:27

>>257-258
狼へ帰れｗ

260 ：仕様書無しさん：2007/08/31(金) 23:41:31

懐かしいなｗ

で、結局するの？

261 ：仕様書無しさん：2007/08/31(金) 23:54:04

$url="doc_root";
$url="doc_root"."img/game";
$url="doc_root"."img/game"."/m";
$url="index.php";
header(Location　:　$url);

262 ：仕様書無しさん：2007/09/01(土) 00:13:34

まて下から2行目は書き損じじゃないんだな? 本当にこの通りなんだな?

263 ：仕様書無しさん：2007/09/01(土) 02:51:55

>>246

「だって印刷したときに履歴が追えないじゃないか。」
（cvsやsvn＝ソース共有ツールという認識っぽい）

中には、納品物が揃って初めてコミットなんてプロジェクトも…
そうしないとCVSのリビジョン番号が揃わないからだってさ。

264 ：仕様書無しさん：2007/09/01(土) 03:20:27

>>263
うちはもっと緩いから良いのかも知れないけど、
時々CVSとかにコメント無しでコミットする人を見ると
粉炉したくなる．．．

と言うか、氏ね　と思わないこともない。

実行もしないし、思わないんだけどね！

265 ：仕様書無しさん：2007/09/01(土) 03:47:51

>>263
なるほどリビジョンをタグがわりに使うわけか。
新しい。

266 ：仕様書無しさん：2007/09/01(土) 04:08:48

あーでも次のリリースは
どうせリビジョンそろわないじゃん。

267 ：仕様書無しさん：2007/09/01(土) 10:49:24

どっかにスペースでも入れて、本質的に変わらんモンをcommitしなおしたりすんじゃねーの？

268 ：仕様書無しさん：2007/09/01(土) 11:36:05

インデント調整とか本質は変わらんでも、意味がある修正もあるがな

269 ：仕様書無しさん：2007/09/01(土) 12:29:01

リビジョンが1つ上がることに、空行のスペースが1個ずつ増えるんだよ

270 ：仕様書無しさん：2007/09/01(土) 13:44:05

>>269
どっかのメールソフトみたいだな。
「　　　　　　　　　　　Re:Re:Re:Re:Re:Re:」

271 ：仕様書無しさん：2007/09/01(土) 20:04:09

「印刷したとき」のために
プログラムとして必要なく、可読性を下げるコードを残すのか┐(´･∀･`；)┌

272 ：仕様書無しさん：2007/09/04(火) 02:41:20

関数のヘッダーコメントに
「関数内で呼び出してる関数（標準関数とかは除く）の名前と機能を書け」
って指示がプログラム完成後に出た。
俺以外の人が書いたソースは1関数500行以上とかなんで
それぐらいたいしたことないね、みたいな感じなんだけど
ある程度真面目に関数分割した俺はすごくガッカリ
俺だけ量多すぎて手伝ってもらうことになったんだけど
「なんでこんな手間のかかる書き方するんだよ。
センスないんじゃないの？」
って言われた。手伝ってもらってる手前、反論もできなかった
まさか自分が書いたソースコードがきっかけで会社辞めようと思うことなるとは

273 ：仕様書無しさん：2007/09/04(火) 02:58:15

かわいそす

274 ：仕様書無しさん：2007/09/04(火) 03:00:10

>>272
>1関数500行
これ後で読む人もかわうそす

275 ：仕様書無しさん：2007/09/04(火) 05:50:13

>>272
その指示の意図が全く解らん
上司も1関数500行タイプで嫌がらせされたとしか...

276 ：仕様書無しさん：2007/09/04(火) 07:59:50

>>275
1関数500行だから、何やっているのかわからなくて
レビューできなかったんじゃないか？

277 ：仕様書無しさん：2007/09/04(火) 09:39:35

長文読んでいただきありがとうございます

指示の大元は客
1関数500行を苦にするのは俺ぐらいで他の人は全員平気
なんで

>>274
かわいそうなのは俺ぐらい
新人もこういう書き方がプロなんだと思って育つ

>>275
意図は多分なし
少なくとも俺個人攻撃はなさそう

>>276
レビューなんかしない職場
仮にレビューなんかやったら
「お前のソースはあちこちに処理が飛ぶから読みにくい」
って俺が吊るし上げ食らうだろうけど

278 ：仕様書無しさん：2007/09/04(火) 09:49:48

職場を変えるか変わるかどっちかにしなきゃ。

まぁとりあえず頑張れ。

279 ：仕様書無しさん：2007/09/04(火) 09:54:37

頑張っては駄目だ

280 ：仕様書無しさん：2007/09/04(火) 10:00:11

だいたい完成後にコメントとはいえソースの変更を易々と受け入れるようなところは話にならない

281 ：仕様書無しさん：2007/09/04(火) 10:17:12

その話にならない会社が多いから話になる訳で･･･

282 ：仕様書無しさん：2007/09/04(火) 12:55:04

コメントの条件が
「そのコメントを見て同等の関数をかけること」
なら、>>272 が圧倒的有利なんだけど、
そういう理想論は残念ながら(業務の世界では)現実には即していないからな……。

500行の関数とかだと、関数名から動作の推定は厳しいだろうし
コメントも内容を全然表していないだろうしな…。

283 ：仕様書無しさん：2007/09/04(火) 13:23:35

#define IF if(
#define THEN ){
#define ELSE } else {
#define ELIF } else if (
#define FI ;}
#define BEGIN {
#define END }
#define SWITCH switch(
#define IN ){
#define ENDSW }
#define FOR for(
#define WHILE while(
#define DO ){
#define OD ;}
#define REP do_lbr
#define PER }while(
#define DONE );
#define LOOP for(;;){
#define POOL }

284 ：仕様書無しさん：2007/09/04(火) 13:27:47

ﾜﾗﾀ

285 ：仕様書無しさん：2007/09/04(火) 14:16:59

むりくり違う言語にしようとしてるのかｗｗｗ

286 ：仕様書無しさん：2007/09/04(火) 16:46:02

Steve Bourne キタコレ

287 ：仕様書無しさん：2007/09/04(火) 17:10:52

>>283
ベル研究所の人ですか?

288 ：283：2007/09/04(火) 17:32:23

ちっ、ばれちまったか。

289 ：仕様書無しさん：2007/09/04(火) 17:45:03

これか～。
http://www.kaimei.org/note/book_out/expert_c.html

Algolなんだね。みんな物知りだな。

290 ：仕様書無しさん：2007/09/04(火) 17:49:23

ん？もしかして、このプリプロセッサ使って
sh書いたの？うわー。

291 ：仕様書無しさん：2007/09/04(火) 20:28:15

>>283
こんな感じでC言語モドキのソースが大量生産されている職場とか普通にあるから困るw

292 ：仕様書無しさん：2007/09/04(火) 23:50:57

懐かしいな、このホンどこいっちゃったかな。

293 ：仕様書無しさん：2007/09/05(水) 00:04:42

#define MOD(M, N) (M-(int)(M/N)*N)
#define RAND(N) MOD(rand(), N)

#if 0
#define randn RAND
#else // MODが直るまでこっちを使え
int randn(int n)
{
　　int x;
　　do { x = RAND(n); } while (x >= n);
　　return x;
}
#endif

294 ：仕様書無しさん：2007/09/05(水) 01:15:00

>>293
直るまでといっても、randnの中でMODが使われてる気配。

295 ：仕様書無しさん：2007/09/05(水) 03:40:21

#defineの引数がかっこで囲まれてないから
優先順位が低い演算子がきたら項が分断されて、あぼん。

296 ：仕様書無しさん：2007/09/05(水) 12:31:57

MODなんて自作する必要あるん？
％じゃだめなんだろうか

297 ：仕様書無しさん：2007/09/05(水) 12:44:26

だめなんですよ。

298 ：仕様書無しさん：2007/09/05(水) 12:47:03

シェフのこだわりである。

299 ：仕様書無しさん：2007/09/05(水) 12:47:07

なぜに？

300 ：仕様書無しさん：2007/09/05(水) 14:54:02

レポーターはそう尋ねた。

301 ：仕様書無しさん：2007/09/05(水) 16:18:42

なぜに？ってベル研究所の人にも
いってやりたいよなw

302 ：仕様書無しさん：2007/09/05(水) 21:50:48

>>296
小数以下が欲しいんじゃない？

303 ：仕様書無しさん：2007/09/05(水) 21:59:58

modで少数以下？

304 ：仕様書無しさん：2007/09/05(水) 22:26:33

MODで小数って新しい概念だなぁ

305 ：仕様書無しさん：2007/09/05(水) 22:37:13

少数の何が新しいのかわからん俺に詳しく。
3.5 mod 2 = 1.5 とか普通だろ？

306 ：仕様書無しさん：2007/09/05(水) 22:52:39

>>305
VB6だと0が返ってくるんだぜ

307 ：仕様書無しさん：2007/09/05(水) 23:08:57

>305

それを小数以下というのか･･･

何だかなぁ(｡-_-｡)

308 ：仕様書無しさん：2007/09/05(水) 23:14:51

java で試したら、 3.5 % 2 == 1.5　だったよ。

309 ：仕様書無しさん：2007/09/05(水) 23:59:46

とはいえ、近似値である小数の剰余って使いにくそう

310 ：仕様書無しさん：2007/09/06(木) 00:32:45

mod本来の意味から外れててなんだか気持ち悪いです

311 ：仕様書無しさん：2007/09/06(木) 00:57:26

>>307
説明よろ

312 ：仕様書無しさん：2007/09/06(木) 05:49:43

小数点以下ならfmodでいいんじゃ？

313 ：仕様書無しさん：2007/09/06(木) 07:58:19

>>311
素直に「間違えました」って言えよｗ

314 ：仕様書無しさん：2007/09/06(木) 12:31:20

会社を辞めたいとは思わなかったが…

ある案件の障害対応で、カバレッジを通そうとした時、用意されたテストケースで
どうしても通らないところがあって、実際には業務的に通らないと判明した時、泣きたくなった。

更に、もう１個の修正対象ソースはそのソースのコピペな上に、今度はテストケースがコピペ。
おまけに、今度は通らなかったロジックを通す必要がある。
不審に思って以前にテストした担当者に聞いてみたら、
丸々のコピペだからかたっぽはテストしていないと判明orz

ええ、泣きながらテストケース作り直して全部通しましたとも。

あん時、顔は笑っていたけど、目に殺意が入っていたかも・・・

315 ：仕様書無しさん：2007/09/06(木) 15:47:36

>>313

316 ：仕様書無しさん：2007/09/06(木) 19:53:05

>>314
丸ごとコピペって。
鉄拳制裁したれ。

317 ：仕様書無しさん：2007/09/06(木) 20:25:19

>>316
そんなんで鉄拳制裁していた手がいくつあっても足りないな、うちの会社の場合。orz

318 ：仕様書無しさん：2007/09/06(木) 20:35:46

クロスカウンター方式を提案します。
一定期間ごとに実施すれば各期間で必要な手は最大でも一つでとても経済的です。
導入されてはいかがですか？

319 ：仕様書無しさん：2007/09/06(木) 22:03:32

テストケース

～～であることを確認する　　　○　　←レッツコピペ！！
～～
～～
～～
～～

320 ：仕様書無しさん：2007/09/06(木) 22:53:39

○×は面倒だからどうしてもコピペになっちゃうな
まだOKNGのほうがいい

321 ：仕様書無しさん：2007/09/06(木) 23:33:28

システム全体がフランケンシュタインを髣髴とさせるコピペばかりのソース
もちろんドキュメント一式も上記怪物の生まれ変わりのよう

現在も増改築の真っ最中

322 ：仕様書無しさん：2007/09/07(金) 00:27:31

で、ある日突然崩壊する。

323 ：仕様書無しさん：2007/09/07(金) 01:01:11

if (a == 0) hoge(); みたいなコードがあったら、

条件:a == 0 → 結果:hoge()をコールする

のように、コードそのまんまのテストケースを書くように指示されていたので、
言われたままに書いていたけど、バグの数も基準があって、バグが0だとまずいといわれた。
こんなテスト仕様書で、どうやってバグをだすんだよ。

324 ：仕様書無しさん：2007/09/07(金) 01:13:51

俺が昔やった方法を教えてやろう。
つテスト仕様書にバグを含める

バグの発生率が２～５％程度にならないと、充分に試験ができていない、と見なす某大手

325 ：仕様書無しさん：2007/09/07(金) 01:19:45

>>324
>>323は、テスト仕様書も、コードと突き合わせながらレビューをして、それでOKをもらう必要があるので、
そのワザは使えません。
仕切ってる人が、単体テストの意味を取り違えてるとしか思えない…

326 ：仕様書無しさん：2007/09/07(金) 01:55:36

そういう事なら、その仕切ってる人がバグだな

327 ：仕様書無しさん：2007/09/07(金) 01:58:40

>>325
出来上がった成果物を信用していないというか、
ソースコード自体を信じてないみたいなテスト仕様書だな

328 ：仕様書無しさん：2007/09/07(金) 02:11:23

ソースコードをじゃなくてコンパイラとか言語そのものを信じてないんだと思うよ。
>>323じゃないけど
hoge = "test";
で「hoge変数に test という文字列が格納されていること」
みたいな試験項目を見たことあるから分かる

329 ：仕様書無しさん：2007/09/07(金) 05:44:10

ちょっとつきあった某社：「コンパイラを信じてなにかあったらどうするんだ？」って、
未だにASMオンリー。　しかもそれがルネサスとかじゃなく、LSIC80でさえも。
親分がJRじゃなければとっくにつぶれてるぞ。

330 ：仕様書無しさん：2007/09/07(金) 07:10:26

そこまで言うなら、
「アセンブラを信じてどうするんだ？ハンドアセンブルだろ....」

って言い返せよ。

331 ：仕様書無しさん：2007/09/07(金) 07:52:49

多分最適化でおかしくなっちゃうコードでも書いてるんだろ

332 ：仕様書無しさん：2007/09/07(金) 07:53:07

「機械を信じてどうするんだ！手で計算しろ！」

333 ：仕様書無しさん：2007/09/07(金) 08:15:09

ICなんか信用ならん
タイガーを使え！

334 ：仕様書無しさん：2007/09/07(金) 08:56:36

他人なんか信用するな！
頼れるのは己の力のみ！

335 ：仕様書無しさん：2007/09/07(金) 11:16:24

そこ、開発成果のリリースまでどれくらいかかってるんだろ？>>329

RADを要求される案件が多いので、VBやC#にどっぷりの漏れ。
ASMでどれほどのRADができるのか知りたい。

336 ：仕様書無しさん：2007/09/07(金) 11:27:54

どんな開発環境で作ってもプログラムは最終的に機械語になるわけで、
既存の開発環境でできる事は機械語と1対1対応できるアセンブラにできない事はない

337 ：仕様書無しさん：2007/09/07(金) 11:32:23

マ板でコスト無視な発言はイタイですよ

338 ：仕様書無しさん：2007/09/07(金) 20:57:07

どの板でもネタにマジレスは痛いんだぜ

339 ：仕様書無しさん：2007/09/07(金) 21:03:23

>>335
そんな馬鹿丸出しのことを言っているのは上の方だけで、現場では普通に
Cで開発、上には -S したアセンブリソースしか見せない、みたいな予感。

340 ：仕様書無しさん：2007/09/07(金) 21:24:07

>>327
そもそもそのソースが本当に仕様を満たしてるかどうかがわからんのに
なんでソースを中心にテストを作るのか

341 ：仕様書無しさん：2007/09/07(金) 21:52:59

きっと辞めたくなる会社の上司だな

342 ：仕様書無しさん：2007/09/08(土) 01:57:07

>323
どーしよーもない場合は
「テストケースを想定して、そこで見つかるようにわざとバグらせておく」
もうちょっと前向きな意図で、「ベバッグ」と称してそういうことをすることがある、らしい。201の鉄則本にあった。

この場合は……hoge();の前に;でも入れておくかな。

343 ：仕様書無しさん：2007/09/08(土) 02:46:38

それはコンパイル通らんような気が

344 ：仕様書無しさん：2007/09/08(土) 02:57:35

テストを別の人がする時には、テストする人をテストするバグを混ぜることもあるよね
境界条件の以下と未満を置きかえるような、まともにテストすれば必ず見つけられる簡単なバグ

ただ、バグを入れたことを忘れる俺のバグが問題なんだよな

345 ：仕様書無しさん：2007/09/08(土) 02:59:37

>>343

346 ：仕様書無しさん：2007/09/08(土) 03:10:31

>>344
故意バグ一覧.xls
作ろうぜ

347 ：仕様書無しさん：2007/09/08(土) 03:22:41

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　この故意バグ一覧.xlsとはなにかね？
＼
　￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣
　（　・ハ・）　∧ ∧ ＜　あ・・・いや・・・・
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿
￣￣￣￣￣（つ＿つ＿＿
￣￣￣日∇￣＼|>>346　|＼
　　　　　　￣　　　=======　　＼

348 ：仕様書無しさん：2007/09/08(土) 03:55:38

仕様の正に要の部分がバグってる（別の案件のテスト中に見つけた）のに、
1年以上も、バグのまま動いてるプログラムがある。
テスト実績はすべてOKで残っている。
実質、業務では使っていない項目ということで、放置したままだ。。

349 ：仕様書無しさん：2007/09/08(土) 04:03:25

でもバグ一覧は作っておいたほうがいいな
報告済みかそうでないか分かるだけでも安心感が増す

350 ：仕様書無しさん：2007/09/08(土) 07:17:40

>>349
作るな！

バグ・トラッキング・システムを使え！

351 ：仕様書無しさん：2007/09/08(土) 09:21:30

おれ、バグ見つけるのも再現させるのも、そしてそれを直すのも得意なんだけど、
何故かみんなから嫌われてる...orz

352 ：仕様書無しさん：2007/09/08(土) 10:01:40

人には「自分とは異質なもの（自分に出来ないことをやっちゃう奴・
自分には理解できない話をする奴・自分の知らないことを知ってる奴）
を嫌ったり排除したりする」傾向があるからな...しかも馬鹿な野郎ほどその傾向が強い。

353 ：仕様書無しさん：2007/09/08(土) 10:07:29

その傾向に陥ってないか自問自答するのは容易じゃないよね．

354 ：仕様書無しさん：2007/09/08(土) 10:11:13

351じゃないけど、
バグ出しを続けた結果、そのシステムは作らなかったことになったことがあるな。
一つ直させると二つ壊れてくるというゴールドラッシュだったな。

355 ：仕様書無しさん：2007/09/08(土) 10:13:50

１つで２つならば少ないんじゃない？
少しでもいじるとシステムが動かなくなるのがデフォってのもあるわけで・・・

356 ：仕様書無しさん：2007/09/08(土) 12:10:28

>>350
開発部署で用意されてるBTSに入れてるんだけどさ、見てくれないし全部スルーされちゃうんだよね

357 ：仕様書無しさん：2007/09/08(土) 13:44:29

>>356
それはきっと

バグ
たっぷりで
際限が無い

からだよ

358 ：仕様書無しさん：2007/09/09(日) 00:46:34

>>350
でも結局報告するときは結局BTSからバグ一覧を作成することになる場合が多い希ガス。
csvとかで。

359 ：仕様書無しさん：2007/09/09(日) 01:12:28

>>358
なるよな。。
なんか紙で出てこないと不安らしい。
我慢できる限界がエクセルの一覧表。
しょうがないから、BTSのxmlからcsv吐き出すスクリプト組んだよ。。
余計な仕事させやがって。

360 ：仕様書無しさん：2007/09/09(日) 21:24:20

/*
if　いふ
else　えるす
while　わほいる？
do　どー
fopen　ふぉーぷん
fread　ふれっど
fwrite　ふうらいと
fclose　ふくろーず
*/

なにこのカンペ……

361 ：仕様書無しさん：2007/09/09(日) 21:34:42

>>360
答えが間違ってるカンペって・・・

362 ：仕様書無しさん：2007/09/09(日) 21:44:18

「わほいる？」に萌えた
語感がかわいい

わほいる

363 ：仕様書無しさん：2007/09/09(日) 21:52:48

微笑ましいが・・・・他所でやって欲しいな

364 ：仕様書無しさん：2007/09/09(日) 21:57:06

/* */
ってVC2005だと
行選択時の//の一括付加・削除のときに巻き込まれて /* → *　になったりするから使いづらい
ゲイツ死ね

365 ：仕様書無しさん：2007/09/09(日) 22:11:42

/*横綱.c/*

#include <朝青龍.h>

366 ：仕様書無しさん：2007/09/09(日) 23:04:45

>>360
do どー
fclose ふくろーず　(梟？)
がチョット好き

>>365
/* 横綱.c/* これコメントとして間違ってない？
下の行もコメントアウトしてるのか。

367 ：仕様書無しさん：2007/09/09(日) 23:10:27

どう見ても間違ってますw

368 ：仕様書無しさん：2007/09/09(日) 23:11:25

>>360
ふくろーずってバンドの名前みたいだなw

369 ：仕様書無しさん：2007/09/09(日) 23:15:17

きっと甲本ヒロト。

370 ：仕様書無しさん：2007/09/10(月) 08:52:15

ギリギリガガンガン

371 ：仕様書無しさん：2007/09/10(月) 20:03:31

ソースというよりmakefileなんだけど、
依存関係が間違ってるとか、は当然のごとくあり。
今日見たのは、
CFLAGS=
としてオプションも消しているのを見た。
コメント化してデフォルトを有効にすると、警告がでるわでるわ。
コンパイラを誤魔化すためにやってるんじゃないかと思った。
もともとバグのあるソースだし、表面的にでも動くように、見なかったことにしました。
(ほんとはバグも表面化してるけどw)

372 ：仕様書無しさん：2007/09/10(月) 20:45:49

今更だけど、なんで日本のソフトウェア業界ってこんなに壊滅的なの？

373 ：仕様書無しさん：2007/09/10(月) 20:52:39

どこの国も変わらんと思うぞ。
派手さでいえば米国の方が上だし。

374 ：仕様書無しさん：2007/09/10(月) 21:49:17

C言語で作ってあったプログラムで、makefileでヘッダの依存関係が無かったので
depend追加したら毎回全てのソースがコンパイルされるようになった。
なんでかな～、と思って調べてみたら、依存関係のトップにあるヘッダが
make時に毎回自動生成されてやがる。

こんなmake環境にした開発者、氏ね。

375 ：仕様書無しさん：2007/09/11(火) 00:24:58

>>373
米国の場合は、それを埋め合わせるセンスがあるんじゃないかと思ってる。
着眼点や、機能のまとめかたやUIの作りなどのセンス。
これがスマートだと、バグが判明しても、使い続けざるを得ないという気になってしまう。

376 ：仕様書無しさん：2007/09/11(火) 01:02:33

使い物にならない奴が志望してくるのがいかん。
大学で切り落とせ。
アホに単位をやるな。

377 ：仕様書無しさん：2007/09/11(火) 01:11:47

未経験者をいきなり実戦投入するとひどいのが出来上がる。
俺自身「今ならもっと上手く書けるのに」「あの時これを知ってれば」って思い出すことがある。
そんな自分と比べても、酷すぎるのが今の職場...orz

378 ：仕様書無しさん：2007/09/11(火) 01:36:06

>376
そこでFizzBuzzですよ

379 ：仕様書無しさん：2007/09/11(火) 01:36:10

新人が使えないのは仕方ないが
使えないベテランが沢山いる、不思議なこの業界

380 ：仕様書無しさん：2007/09/11(火) 02:01:54

>379
「ベテラン」というのが履歴書に書かれた経験年数に基づく呼称でないのなら
確かに不思議だが

381 ：仕様書無しさん：2007/09/11(火) 02:20:30

使えない奴は派遣するってことで

382 ：仕様書無しさん：2007/09/11(火) 03:57:18

>>374
正直makefileって規模でかいとよく分からなくなるのがデフォというか
新たな仕様にしてほしいぐらいだ

383 ：仕様書無しさん：2007/09/11(火) 07:23:02

>>382
ant使え、

384 ：仕様書無しさん：2007/09/11(火) 08:14:37

今のパソコンなら速いから、全コンパイルのbatでもすぐ終わるでしょ。
俺はmakeとbatと両方用意して、「makeを知らない保守者はbatでいいよ」と書き添えてる。

385 ：仕様書無しさん：2007/09/11(火) 08:15:57

扱うファイルが、100個ぐらいとか、依存関係がシンプルなものだけなら、makefile もまだ手軽で良いけどね。
それ以上で makefile 使ってるプロジェクトに関わると眩暈がするな。
世の中、もうちょっとマシなものが、いくらでもあるのによりによって makefile かよって。

386 ：仕様書無しさん：2007/09/11(火) 10:57:02

>>384
んなもん、規模や開発環境によるだろ
うちのプロジェクトはフルコンかけると2時間くらいかかるぞ
重要なヘッダが更新されると、すぐにフル逝っちまう orz

387 ：仕様書無しさん：2007/09/11(火) 12:20:57

ヘッダの切り分けがおかしいんだろ

388 ：仕様書無しさん：2007/09/11(火) 14:25:27

フルコン2時間って携帯？
規模に対して環境が貧相な現場って他に浮かばないんだけど

昔、入った携帯の現場で warning が10000超えたのは笑ろた

389 ：仕様書無しさん：2007/09/11(火) 18:31:45

少ねえ少ねえ

390 ：仕様書無しさん：2007/09/11(火) 21:10:04

コンパイルのバグか何かで、6万後半あたりでwarningの数が一旦0になったこともあったな。

391 ：仕様書無しさん：2007/09/11(火) 21:13:54

臨海値65535か　16bit unsigned

392 ：仕様書無しさん：2007/09/11(火) 21:19:13

コンパイラをバグらせるとは・・・

コンパイラ「想定の範囲外です・・・」

393 ：仕様書無しさん：2007/09/11(火) 21:19:35

臨海値

394 ：仕様書無しさん：2007/09/11(火) 21:20:05

むしろfloatで

395 ：仕様書無しさん：2007/09/11(火) 21:38:24

今はlong long があるじゃまいか！

396 ：仕様書無しさん：2007/09/11(火) 21:48:18

遊戯、もうやめて！
コンパイラの示す warning は既に臨海値よ！！

397 ：仕様書無しさん：2007/09/11(火) 21:59:07

const TYPE const*const&;

398 ：仕様書無しさん：2007/09/11(火) 22:33:15

/* index.html */

#html

head()

{
style;style.css
}

body()
{
test.
}

#html

399 ：仕様書無しさん：2007/09/11(火) 22:44:26

これは新しい言語

400 ：仕様書無しさん：2007/09/12(水) 03:34:02

#define head nanntoka
#define style kanntoka
#define css kanntoka
#define body foo
#define test bar
#include "index.html"

401 ：仕様書無しさん：2007/09/12(水) 09:09:54

#include "mychtml.h"

int main() {
html(
head(title("Test Page")),
body("Hello, world !!!<BR>\n")
);
}

402 ：仕様書無しさん：2007/09/12(水) 22:56:12

Const Arr = "a,b,c,d"

function aaa()
　for i = lbound(split(arr,",")) to ubound(split(arr,","))
　　if split(arr,",")(i) = "a" then
　　　aaa = split(arr,",")
　　end if
　next
end function

こんなん

403 ：仕様書無しさん：2007/09/12(水) 23:09:30

>>402
splitやり過ぎってヤツですか。

404 ：仕様書無しさん：2007/09/12(水) 23:15:26

ソースコードがスパゲッティ！でもそんなの関係ねぇ！

405 ：仕様書無しさん：2007/09/12(水) 23:33:39

>>402
んんん！？なんだか見覚えがあるw

406 ：仕様書無しさん：2007/09/12(水) 23:50:26

>>402
これは素晴らしい無駄関数ですね

407 ：仕様書無しさん：2007/09/13(木) 00:26:45

これはあれだ、きっとsplit呼び出しの結果が全て同じだと判断して、
自動的に一回の呼び出しに纏めてくれる、素晴らしいコンパイラが存在するんだよ！

408 ：仕様書無しさん：2007/09/13(木) 00:29:07

それでも最適化なら・・・最適化ならきっとなんとかしてくれる・・・！！

409 ：仕様書無しさん：2007/09/13(木) 00:31:24

探すと本当にあるから困る

410 ：仕様書無しさん：2007/09/13(木) 00:33:19

最適化? こんぱいる?
くっふふふ
VBScriptというものは
ひとたび構文木にさえ解析されてしまえば
二度とは
二度とは

411 ：仕様書無しさん：2007/09/13(木) 00:56:55

スパゲティと申したか

412 ：仕様書無しさん：2007/09/19(水) 19:03:16

#ifndef Hoge
typedef struct tag_Hoge {
(略)
} Hoge;
#endif

え～っと。

413 ：仕様書無しさん：2007/09/19(水) 19:52:58

・・・きっとCは初めてなんだよ。
先週入門書を読み終わったばかりなんだ。
きっと、きっと・・・

414 ：仕様書無しさん：2007/09/20(木) 00:24:54

ifndefが嫌いだ
なんでifnodefじゃねぇんだ　ややこしいよ
#if !definedのほうがマシだ。どうせ多重防止とかだったらpragma onceで事足りるからいいけど

415 ：仕様書無しさん：2007/09/20(木) 16:09:26

>>412
そのソースの意図がさっぱりわからない。
#define と typedef を混同したのだろうか…

416 ：仕様書無しさん：2007/09/20(木) 18:13:33

>>414
リリース版を表すNDEBUGの方が…

標準に従うと、デバッグ版のみ有効にするのに
#ifndef NDEBUG
...
#endif
と否定が２回来て嫌な感じだ
結局可読性とかで _DEBUG が使うんだけどな

って脱線しすぎか。

417 ：仕様書無しさん：2007/09/20(木) 18:42:13

NDEBUGは<assert.h>が見るんだっけか。

418 ：仕様書無しさん：2007/09/20(木) 18:55:12

>>415

FAQ級の落とし穴らしい。
http://www.kouno.jp/home/c_faq/c10.html#15

419 ：仕様書無しさん：2007/09/20(木) 19:52:18

そういうレベルが普通なのか？

420 ：仕様書無しさん：2007/09/20(木) 23:51:55

>>415,418
？？。何をやろうとしてるのかすらさっぱりわからんのだが・・。

421 ：仕様書無しさん：2007/09/21(金) 00:14:14

>>420
たぶん>>415の言うとおり#defineとtypedefを混同してるんだと思う。

・・・typedefを何回も呼ぶつもりなのか???
後から呼んだ方が有効になるなら、実害はなさそうだけど・・・

と思って試してみたら、さすがに名前が衝突してるってエラーが出た。

422 ：仕様書無しさん：2007/09/21(金) 00:19:15

「Hoge」がまだ定義されてなければtag_Hoge型の構造体としてHogeを定義、ってことだろう
何をしたいと思ったかは分かっても何に使うはさっぱりわからんw

423 ：仕様書無しさん：2007/09/21(金) 00:40:31

Hogeが定義済みだったときにどんな動作をするんだろうな

424 ：仕様書無しさん：2007/09/21(金) 03:36:09

なるほど、こういうレベルが普通なんだな……

425 ：仕様書無しさん：2007/09/21(金) 13:07:19

public String getErrorMessage() {
// TODO 自動生成されたメソッド・スタブ
return null;
}

426 ：仕様書無しさん：2007/09/21(金) 13:13:55

Cで継承とかしようってことかな。

#include "FooExt.h"

#ifndef FOO
#define FOO
typedef strcut foo{
　method1,
　method2,
}Foo;
#endif

で、FooExt.hとかで
typedef strcut foo{
　method1,
　method2,
　method3,
}Foo;
#define FOO
とか。。
考え過ぎか？。

427 ：仕様書無しさん：2007/09/21(金) 21:15:10

>>425
？？？
・・・catchしたいのかなぁ・・・

428 ：仕様書無しさん：2007/09/21(金) 22:00:54

>>425 が何を言いたいのかさっぱりわからない
これってIDE(eclipse,netbeans,etc)で自動生成されたメソッドでしょ？
納品されたソースにこんなのがあったら嫌だけど、開発中なら腐る程あるよ

429 ：仕様書無しさん：2007/09/21(金) 22:20:59

private String errorMessage;
から自動生成されたのは分かるが戻り値がぬるぽ

430 ：仕様書無しさん：2007/09/21(金) 23:33:24

もう辞めた会社のソースだけど、何年も運用を続けてきたシステムの仕様変更があるからと、
俺も参加することになったときに、一月に現行処理のバグを200くらい報告したことがある。
仕様変更自体よりバグとりの時間の方が長い位だった。
そのためだけに一月くらい時間をもらえたのが幸運だったけど。

あと今の現場。JSPのソースが全部スクリプトレット。全部 out.println　とかで書いてありやがる。
ほとんどCGI気分だっ。

431 ：仕様書無しさん：2007/09/21(金) 23:34:52

>>428
保守するコードを開いてみたらTODOだらけってのはよくある話。

432 ：仕様書無しさん：2007/09/21(金) 23:56:00

藤堂さんのおおいしょくばなんだね…

433 ：仕様書無しさん：2007/09/23(日) 01:39:37

手順書はsudoさんだらけだしな

434 ：仕様書無しさん：2007/09/23(日) 02:07:31

作業始めたら安藤さんのお世話になりっぱなしだ

435 ：仕様書無しさん：2007/09/23(日) 02:28:45

うちには後藤さんが多いから困る

436 ：仕様書無しさん：2007/09/23(日) 02:34:01

んなこたー知らねーよ

437 ：仕様書無しさん：2007/09/23(日) 02:48:43

三木だったり後藤だったりする

438 ：仕様書無しさん：2007/09/23(日) 02:53:17

// クローズ処理
if(rs != null){
rs.close();
rs = null;
}

（；＾ω＾）・・・

439 ：仕様書無しさん：2007/09/23(日) 02:59:31

>>438
あるいは正しいような気すらしてくる

440 ：仕様書無しさん：2007/09/23(日) 03:04:50

旧VBっぽいアレだな

441 ：仕様書無しさん：2007/09/23(日) 09:12:56

もうやめたけど前の会社

面接でC++が出来るかどうか聞かれて、出来ますと答えて入社。
引き継いだコードの cout を printf で書き直したらただの C になった。

442 ：仕様書無しさん：2007/09/23(日) 12:02:26

>>438
これはwindowsのリソース関係の処理？
windowsはよく知らないけど、きっと delete this; してるんだよ。そう願いたい。

443 ：仕様書無しさん：2007/09/23(日) 12:26:43

>>438
javaではよく見るな。
優先的にGCの対象にするためにわざと参照を外しているらしい

444 ：仕様書無しさん：2007/09/23(日) 12:42:49

>>443
インスタンス変数に持つとかアホな状況でなければ、変らないけどなー

445 ：仕様書無しさん：2007/09/23(日) 12:54:05

そうなんだけど、今のプロジェクトでは
必要でなくなった変数にはnullを入れるというコーディング規約
さらにハンガリアン記法も強制
定数名が60文字以上ある状態なのに80文字で折り返し強制
ほか多数
バカ（というか時代遅れ？）が上に立つとろくな事にならんという見本

446 ：仕様書無しさん：2007/09/23(日) 13:08:40

長くても分かりやすい名前をつけろというけどさ、
その上でコードは80文字で折り返せって言うのも訳が分からん話だな。

447 ：仕様書無しさん：2007/09/23(日) 13:22:07

>>445
なるほど、改善提案もできないコミュニケーション能力の欠如した引っ込み思案の自分を
棚上げしてこんなところで文句を垂れる君はバカではないんだw

448 ：仕様書無しさん：2007/09/23(日) 13:33:44

60文字の定数のどこが分かりやすいんだ？

449 ：仕様書無しさん：2007/09/23(日) 14:01:15

>>447
くされ基盤チーム乙ｗ

450 ：仕様書無しさん：2007/09/23(日) 14:06:28

>>447
お前はまずスレタイ読んだ方がいいな。

451 ：仕様書無しさん：2007/09/23(日) 14:32:22

CHogeClass::CHogeClass()
{
delete m_pPtr;

...
}

いきなりdelete。
リリースモードだと奇跡的に動くがデバッグモードだと動かない。
そこで、コードを修正するのではなく全員リリースモードだけで開発し始めた。
当然数ヵ月後僕はその会社にいなかった。

452 ：仕様書無しさん：2007/09/23(日) 14:40:01

>>451 直せよw

453 ：438：2007/09/23(日) 14:56:56

>>439 >>442 >>443　>>445

438です。
コメント部分が冗長すぎただけで、処理事態は問題はないです。

rs に　null を入れるのは　メモリ使用量の多いオブジェクトを、
早めにガーベージコレクションの対象にするためで
間違ってはいないと思います。

ただそれだけでした＞＜

454 ：仕様書無しさん：2007/09/23(日) 15:04:54

>>451-452
ﾜﾛﾀ

455 ：仕様書無しさん：2007/09/23(日) 15:06:41

>>453
コメントも別に冗長じゃないけど。
他の処理との兼ね合いで書いているだけでしょう？
//ここでクローズ処理してます。ガベコレ対策でnullいれとります。
//なにか問題でも？
とか書いてあったら冗長だけどな。

456 ：仕様書無しさん：2007/09/23(日) 15:10:16

無意味なコメントはよくあるよな。

// ストリームを開く。
public OutputStream openStream() {
...;
}

アホか。

457 ：仕様書無しさん：2007/09/23(日) 15:16:15

>>456
コメントを抽出するソフトとかあるんだけど、それは知らない？

458 ：仕様書無しさん：2007/09/23(日) 15:18:24

よーし、修正しちゃうぞ。

//! ストリームを開く。
public OutputStream openStream() {
...;
}

459 ：仕様書無しさん：2007/09/23(日) 15:34:48

>>455 >>457

SUNが提唱している、
「Java Code Conventions」
ttp://www.tcct.zaq.ne.jp/ayato/programming/java/codeconv_jp/CodeConventions.doc4.html#385
＞コードの中に既に含まれている情報やコードから自明であるような情報を重複させることは避ける

に記載されているように、冗長なコメントは書くべきではないと私は考えます。

コメント自体は書けば書くほど可読性を下げます。
コメント無しで理解できるコードを目指すのがベストだと思っています。
（と、いってもまったくコメント無しでのコードを書くのも不可能でしょうけど）

ちなみにドキュメンテーションはまた別ですが。

460 ：仕様書無しさん：2007/09/23(日) 15:36:08

>>457
抽出して削除＆書き直しするの？

僕のばあいは、もともとソフト会社じゃないから、Delphi、shのスクリプト、C、C++、C#、JavaScript、MATLAB
、WindowsScriptとか、あとNastran等々みんな適当なコードが残ってる。
「お前出来るだろ」ってほとんどコメント無しでの糞コードでくるから、リファクタリングとかだけでも
「無理っす。無理っす。無理っす。」を連発してる。

てか、いろいろ言葉が通じない。みんな言葉が通じるだけましだよ。

461 ：仕様書無しさん：2007/09/23(日) 15:51:28

>>459
それは奢りだと思うよ。
誰でもコード読めるわけじゃないしね。
「このブロックでは、○○の処理をしています」って書いてある事で
とりあえず数十行が簡単に読み飛ばせるなら、その方が効率がいいのは自明。
あなたの理想は以心伝心っと同じで、まあある種ありえない理想だと思うよ。
それ言ったらドキュメントも折衝も要らないからね。
全ては「ソースみろ」で済む。
実際はそうあいかないよ。

462 ：仕様書無しさん：2007/09/23(日) 15:53:25

>>460
抽出してドキュメントを作る参考にするんだよ。
それで処理のサマリーが分かれば、読むときに楽でしょ？

仮に明日全く知らない言語の修正依頼が来たらどう？
適切なコメントがあったら、楽だと思わない？
言語の勉強をゼロから初めて、それからソース読むよりはさ。

463 ：仕様書無しさん：2007/09/23(日) 16:08:29

日本人で>>459を実践したい人には
　「なでしこ」
ちょーお奨めです。

464 ：仕様書無しさん：2007/09/23(日) 16:09:36

>>437
「三木」って何？

465 ：仕様書無しさん：2007/09/23(日) 16:16:52

>>462
書いてること正しいと思うけど、
”言語を全く知らない人”を想定してコメントを書くって作業は（個人的に）勘弁して欲しい。

466 ：仕様書無しさん：2007/09/23(日) 16:22:27

>>465
だから、それがセンスとバランスなんだって。
//ファイルオープン
//読み込み
//整形
//出力
とかブロックごとにあったら、知らなくても概要は理解できるし、
知っている人にも（余程無能でなければ）邪魔にもならないでしょ。
全く知らない人に完璧に理解させるのは無理でも、手助けにはなる。

VBAとかExcelマクロも数えると、過去にやった言語は20くらいになるし、
極端に多いとも思わない。
ちょっとしたマクロの手直しのために、一からその言語の勉強やるのは厳しいしね。

コメント要らないなら、そもそも、除去なんて簡単にできるしね。
無いコメントを生成はできないけど。

467 ：459：2007/09/23(日) 16:22:30

>>461

私も、コメント無しで完全に理解できるコードは不可能だと思っています。

ただし、
「処理フローが明らかであるのにコメントを付けては、
品質が下がるだけでメリットがない」
ということを言いたかっただけです。

＞コメントは，コードの概観と，
＞コード自体からは読み取ることのできない付加的な情報を与えるものであるべきである．

この考えが伝わるつもりでレスしましたが、
文章が至らず誤解させてしまったようです。申し訳なかった。

468 ：仕様書無しさん：2007/09/23(日) 16:24:56

>>467
書いた側と読む側が非常に優秀ならコメントなしでも読めるよ。
そんで俺の言ってる必要なコードは、あなたの言っている「コードの概観」の話だしね。
「コメントがあるほど可読性さがる」ってのが間違いだって言うなら別にいんだけど。

469 ：仕様書無しさん：2007/09/23(日) 16:26:32

>>466
センスとバランスとかＳＥとは思えないアバウトな表現。

ＪＡＶＡ言語を知っているというのは、コードを読む上では必須でしょ。

言語を理解した上で
「スパゲティコードだからコメントつけないとわからん」
というならわかるけど。

君の理論だと、コメントの統一性が保たれない。

プロジェクトが始まる前に
このメソッドを使うときは　コメントを付ける、つけないとか
全てのクラスに対して説明しなければいけない。

470 ：仕様書無しさん：2007/09/23(日) 16:31:33

こんなコードはコメントが必須（実話）

// foo に bar を代入し、計算結果をDBに格納する
public getPoo() {
// ながーいコード
}

471 ：仕様書無しさん：2007/09/23(日) 16:31:47

まぁ、見た限りだと

「ＪＡＶＡ初心者のためにコメントをつけて仕事を早く回す」か
「品質のために冗長なコメントはつけない」　の意見がわかれてるだけでしょ。

前者も後者も言い分はわかるけどね。

そもそも2人の目的からして違ってるから結論でないでしょ。

472 ：仕様書無しさん：2007/09/23(日) 16:32:42

おっと訂正。

// foo に bar を代入し、計算結果をDBに格納する
public void getPoo() {
// ながーいコード
}

473 ：仕様書無しさん：2007/09/23(日) 16:36:29

中小企業なら前者の考え（コーディングを早く終わらせてコスト削減）
大企業なら後者の考え　（早く終わらせるよりも品質確保）

でいいじゃん。

474 ：仕様書無しさん：2007/09/23(日) 16:41:36

>>472

// foo に bar を代入し、計算結果をDBに格納する
public void getPoo() {
}

どこが　get　してるんだよｗｗ

475 ：仕様書無しさん：2007/09/23(日) 16:52:11

>>471
いや、その場合品質って何？って話だと思うけど。
よっぽど冗長じゃなきゃ読み飛ばせばすむコメントで品質さがるかな？
そこまでストイックに減らすのって正直自己満足の世界だと思うんだけど。

//このブロックで、先頭の不要行を削除

で10行さらっと読み飛ばせるコメントをつけないメリットの方が
大きいとは思えないな。

476 ：仕様書無しさん：2007/09/23(日) 16:54:34

別につけたくないならつけないでいいけどさ。
もっとも害なのは変なこだわりとか自己満足をおしつけて
「俺はこれが正しいと思う。だから全員これをやれ。
これ以外はクオリティが下がるのでダメだ」って奴だと思う。
真面目な話。
そしてそういう奴は大抵「いや、あんたそれ以前にマシなコード書いてよ」
って奴なんだよな。
自己満足と自己肯定ばっかりで、「いや、もしかしたらこっちの方がいいのかも」
とは少しも考えない。
俺は人に押しつけまではしないけどね。

477 ：仕様書無しさん：2007/09/23(日) 16:58:07

>>475

＞よっぽど冗長じゃなきゃ読み飛ばせばすむコメントで品質さがるかな？

下がるわ。コメント範囲の大小は関係ない。

478 ：仕様書無しさん：2007/09/23(日) 16:58:19

>>475に同意。
三行ごとにコメントがついてるとかの極端な話じゃなければ、ついてて良いと思う。
何事もないよりある方がマシ。

479 ：仕様書無しさん：2007/09/23(日) 16:58:59

>>476
だから、自己満足じゃなくて、Sunの規約に準じてるだけでしょ？
そこを無視するとかプログラム的にはありえんわ

480 ：仕様書無しさん：2007/09/23(日) 17:00:31

ま、sunの言う通りにやればいいんじゃないの？
とにかくsunが言うんだから間違いないよねぇｗ

481 ：仕様書無しさん：2007/09/23(日) 17:02:38

なでしこ使うんだ。
なでしこなら冗長なコメントなんか付けなくなる。

482 ：仕様書無しさん：2007/09/23(日) 17:02:47

ちなみにCOBOLでコード書く場合もsunの規約に従う必要あんのかな？
Java限定の話だったっけ？

483 ：仕様書無しさん：2007/09/23(日) 17:03:37

自分の理論で「これはこうあるべき」って書くから駄目なんでしょ。
自己流コーディングはよくないよ。

Sunの規約として用意されてるなら使うべきだし、
そのプロジェクトの規約として別な方法が記載されていたらそっちを優先すべき。

484 ：仕様書無しさん：2007/09/23(日) 17:04:43

>>483
プロジェクトの規約も使用言語も一切無視して、とにかく「コメントは少ない方がいい。
sunがいうんだから間違いない！！」ってキチガイさんに言ってやってくださいｗ

485 ：仕様書無しさん：2007/09/23(日) 17:05:51

>>482

COBOLはその言語に適した規約があるでしょ。
言語によって保守や拡張性に対する考え方も違うしね。

486 ：仕様書無しさん：2007/09/23(日) 17:07:07

>>485
だよね。
それを無視して「コメントは少ない方がいい！」ってほえてるのって馬鹿過ぎだよね。
いつからJavaの話になったんだか。

487 ：仕様書無しさん：2007/09/23(日) 17:07:19

>>479

488 ：仕様書無しさん：2007/09/23(日) 17:08:08

>>484
だからさ・・・

「プロジェクトの規約として別な方法が記載されていたらそっちを優先すべき」

って言ってるでしょ。
そりゃクライアントがそういう風に指定したらそっちを使うのが当たり前っしょ。

わざわざ指定されてるのに別な書き方してたら訴えられるそ。

おまえはどんなプロジェクトだろうと自己流コードをかいてりゃいいさ

489 ：仕様書無しさん：2007/09/23(日) 17:08:38

>>482
sunのガイドラインがどうこう言う前に、コボルは旧コードをコメントアウトして残すのを辞めれ。

490 ：仕様書無しさん：2007/09/23(日) 17:08:44

MSのハンガリアンマンセーに従ってた奴乙

491 ：仕様書無しさん：2007/09/23(日) 17:09:44

>>488
＞だからさ・・・
＞「プロジェクトの規約として別な方法が記載されていたらそっちを優先すべき」

うん。
だから言っている内容を変更したわけだよね？
それって後付けだよね？
だとしたら、最初に言った「コメントは少ない方がいい」って間違えたんだよね？

492 ：仕様書無しさん：2007/09/23(日) 17:10:15

>>486

いや、>>485は君と対立してた俺なんだけど・・・

Javaの話してたんじゃないの？

そういうことならすまんかったわ。
あくまで俺のはJava限定の話ね。

493 ：仕様書無しさん：2007/09/23(日) 17:11:12

自分がコメントあったほうが読みやすいから、そうしてる
規約でダメなら渡すときにコメント全削除してやるからいいよ

494 ：仕様書無しさん：2007/09/23(日) 17:11:20

>>469

495 ：仕様書無しさん：2007/09/23(日) 17:11:50

>>492
そうか。
Java限定なんて前提は初めてだけど、君が前提を間違えていたと言う事ね。
なら仕方ない。
もっともJava限定でも当初の「コメントは少ない方が良い」って間違えているけどね。
プロジェクト規約の方が優先度高いんだから。
ま、今は理解したらしいけど、少なくとも最初は間違えて書いたのは事実だよ。
気をつけてねｗ

496 ：仕様書無しさん：2007/09/23(日) 17:12:43

>>493
天才児あらわるｗ

>>494
その前からJava前提で書いているよ。
そんな話どこにもなかったのにね。

497 ：仕様書無しさん：2007/09/23(日) 17:14:35

>>495
プロジェクトの規約に従うのは前提条件でしょ？

後付けで、
「プロジェクトとしてまったく異なる規約が存在しているとしたら？」
と言われても困るわ

そりゃ、どんな間違った書き方でも仕様でも、客が指定してきたら従うよ。
その点については君と同意。

ただし、特に指定されてないならSun準拠にしとけば間違いないでしょ。

ちなみに俺もいちいちほかの人の書いたものを指摘はしないけどね。
お金くれるなら別だけど。

498 ：仕様書無しさん：2007/09/23(日) 17:16:33

>>497
煩いバカだな。

499 ：発端：2007/09/23(日) 17:27:12

>>438 >>453 >>459 です。
私の書いたことが原因でスレが荒れてしまい申し訳ないです。
みなさんそれぞれの意見が聞けたことで大変勉強になりました。

このスレは好きなスレの一つなので、
上記の件については終わりということでお願いしますm(__)m

500 ：仕様書無しさん：2007/09/23(日) 17:30:40

流れていたときにリアルタイムで読んでなかったのでタイミングを逃したけど。

>>461
>誰でもコード読めるわけじゃないしね。
>「このブロックでは、○○の処理をしています」って書いてある事で
>とりあえず数十行が簡単に読み飛ばせるなら、その方が効率がいいのは自明。

○○を名前にしたメソッドに切り出す。

というのが定石で、Sunのなんたらってのも、そういうコーディングが前提かと。

まあ、我々はネイティブではないので
メソッド名でわかるコードを書くというのは現実的には敷居が高いが、
Javadoc をちゃんと書けばそれほど無茶な話でもないと思われ。

501 ：仕様書無しさん：2007/09/23(日) 17:31:25

悪いコメントの例　言語はC

int wrk_COUNTER1; /* カウンタ1 */
具体的な文言はともかくこのレベルのコメントが実在した。
どんな言語だろうとコレはさすがに....ていうか変数名からしてヤバい。
しかもコレグローバル変数なんだぜ！

ほかにも /*ファイルを開く */ /* 変数をインクリメント */
納品するソースを練習台にするなよorz

502 ：仕様書無しさん：2007/09/23(日) 17:45:08

ステートメントレベルコメントの問題は

・コードとコメントを同期させて管理していくのが手間
・コメントを付ける基準の統一が難しく、個々のコーダー任せになる

かな。
前者は関数レベルでも同じじゃないかと思うかもしれないけど、
関数レベルというのは設計段階で fix されているべきもので (少なくとも理屈では)
そこが頻繁に更新されるというのは、コメント以前に別の問題がある。

503 ：仕様書無しさん：2007/09/23(日) 18:48:23

コードの方をわけ分からなくすれば解決だぜ!

// ストリームを開く。
public T0000 F0000() {
...;
}

504 ：仕様書無しさん：2007/09/23(日) 19:25:43

>>503
天才

505 ：仕様書無しさん：2007/09/23(日) 19:28:41

>>503
本気であるので困る
// 検索結果を取得する
public D001_0012 F001_0012(I001_001 arg0) {
}
当然、Excelの管理台帳（笑）で管理される

506 ：仕様書無しさん：2007/09/23(日) 19:30:52

これはひどい・・・

507 ：仕様書無しさん：2007/09/23(日) 19:37:47

ちなみにサーバーサイドJavaだったんだが、表示するJSPも G001_002U.jspとかだぜ。
あわせてG001_002U.jsがそれぞれセットになっているからカオスすぐる

で、Gなんだが良く解らないから聞いてみたんだ。
「画面のGだろ、そんなことも解らないのか？」と怒られた(´・ω・`)

508 ：507：2007/09/23(日) 19:43:19

思い出せばもっと色々あったぞ。
・変数は全て文字列（当然DBも）
・親会社のバグだらけの怪しいフレームワーク強制
で、オチだったんだが、中国へのオフショア（笑）で夜逃げされた。

509 ：仕様書無しさん：2007/09/23(日) 19:44:07

なんというコボル脳…。

510 ：仕様書無しさん：2007/09/23(日) 19:44:49

画面のGとか凄すぎるﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ

511 ：仕様書無しさん：2007/09/23(日) 19:51:09

printf("HelloWorld!!ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ\n");

512 ：507：2007/09/23(日) 19:51:11

もっと晒すぜ、ﾋｬﾎｰ
データ構造定義（笑）はこんな感じ
データ構造定義ID D001_0012
項目ID 長さ（中略）備考
D001_0012_001 18 （中略）商品ID（9桁）

513 ：仕様書無しさん：2007/09/23(日) 19:53:02

まぁアレだろ。Fだろ。

514 ：仕様書無しさん：2007/09/23(日) 19:55:53

Gって言ったらゴキブ

ぅゎぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁ

515 ：仕様書無しさん：2007/09/23(日) 19:56:44

>>513
残念。 N系

516 ：仕様書無しさん：2007/09/23(日) 19:57:23

誤： printf("HelloWorld!!ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ\n");
正： printf("HelloWorld!!\n");ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ

517 ：仕様書無しさん：2007/09/23(日) 19:58:23

寿司食いたいﾌﾌﾌﾌﾌﾌﾌ

518 ：仕様書無しさん：2007/09/23(日) 20:04:09

printf(buf);

buf内に%sが入って死亡・・・・・・

519 ：仕様書無しさん：2007/09/23(日) 20:13:51

祭りに乗り遅れた・・・

520 ：仕様書無しさん：2007/09/23(日) 20:18:52

// ずっと俺のターン
while (1)
printf'("ﾌ");

521 ：仕様書無しさん：2007/09/23(日) 20:34:35

ガリでも食ってろﾌﾌﾌﾌﾌﾌﾌ

522 ：仕様書無しさん：2007/09/24(月) 02:20:45

G001_001？？？ってのは、
画面ＩＤをそのまま名前にしてるんなら保守はしやすいのかもしれん。
もちろん画面ＩＤがきっちり管理できてるのが前提だけど。

523 ：仕様書無しさん：2007/09/24(月) 02:33:26

>>522
おまえは設計するなよ！約束だぞ！

524 ：仕様書無しさん：2007/09/24(月) 02:40:18

ID項目それぞれに対する説明の文書なりpdfがあるんじゃないの
それなら分かる

525 ：仕様書無しさん：2007/09/24(月) 06:57:17

>>524
わかりやすい命名になってればその文書自体不要になるか、
大幅に簡略化できる。

なまじ素直な性格だと、
「業界の先輩たちが長いことやってることだから、なにかよいことがあるんだろう」
って思っちゃうんだよなあ…
昔々、ディレクトリというものが無く、
データ領域につける名前に大文字と数字6文字とか8文字とかしか
使えなかった時代の習慣を引きずってるだけなんだが。

526 ：仕様書無しさん：2007/09/24(月) 07:19:10

コボルのコメントってどう書くんだっけ。さすがに３８年も書いてないと忘れた。

527 ：仕様書無しさん：2007/09/24(月) 07:42:33

528 ：仕様書無しさん：2007/09/24(月) 09:31:28

きたねえ穴だな

529 ：仕様書無しさん：2007/09/24(月) 11:29:14

>>522
氏ね

せめて、ItemList_02.jsp とかある程度はまとめた上での連番にするべきだろ

530 ：仕様書無しさん：2007/09/24(月) 11:31:49

>526
行番号の直後の桁にアスタリスク

531 ：仕様書無しさん：2007/09/24(月) 11:57:25

>>530
きたねえ穴だな

532 ：仕様書無しさん：2007/09/24(月) 12:07:51

>>530
きたねえ穴だな // じつは入れたいと思っている気持ちの裏返しの発言

533 ：仕様書無しさん：2007/09/24(月) 12:48:06

// キーボードの状態を取得する
bool getKeyboardStatus()
{
　//キーボードの状態がおかしい
if (status_ == RESPONSE_ERROR) {
　　// 投げる
　　throwKeyboard();
　}
　return status_;
}

みたいな名前と処理が一致しない関数が
山ほどあって気が抜けない (´Д｀;)

534 ：仕様書無しさん：2007/09/24(月) 12:49:29

>>533の返り値は気にしないで・・・。

535 ：仕様書無しさん：2007/09/24(月) 13:17:56

while (1)
{
　int nRet;
　nRet = 仕事();
　if (nRet == ERROR)
　{
　　int nMood = Get今の気持ち();
　　if (nMood == BUTIKIRE)
　　{
　　　throwMouse();
　　　throwKeyboard();
　　　beatNeighbor();
　　　quitJob();
　　　break();
　　}
　}
}

536 ：仕様書無しさん：2007/09/24(月) 13:47:47

while(辞めない) {
while (1)
{
　int nRet;
　nRet = 仕事();
　if (nRet == ERROR)
　{
　　int nMood = Get今の気持ち();
　　if (nMood == BUTIKIRE)
　　{
　　　throwMouse();
　　　throwKeyboard();
　　　beatNeighbor();
　　　quitJob();
　　　break();
　　}
　}
}
}

537 ：仕様書無しさん：2007/09/24(月) 14:02:06

>>536
　　　　　　　　　　　　　　＼　　　∩─ｰ､
　　　　　　　　　　　　　　　＼／　●　､_ ｀ヽ
　　　　　　　　　　　　　　　　/ ＼(　●　 ● |つ
　　　　　　　　　　　　　　　　|　　 X_入__ノ　ミ　俺は釣られないクマ･･･
　　　　　　　　　　　　　　　　､　(＿／　　　ノ
　　　　　　　　　　　　　　　　　＼＿＿＿ノﾞ
　　　　　　　　　　　　　　　　／丶'　⌒ヽ:::
　　　　　　　　　　　　　　　/ ヽ　　　 /　/:::
　　　　　　　　　　　　　　　/　/へヘ/　/:::
　　　　　　　　　　　　　　 /　＼ヾミ　 /|:::
　　　　　　　　　　　　　　（__／| ＼___ノ/:::

538 ：526：2007/09/24(月) 17:28:31

>>530 ありがとです。

539 ：仕様書無しさん：2007/09/24(月) 17:30:27

プログラミングが上達するコツ
http://pc11.2ch.net/test/read.cgi/tech/1190555031/

540 ：仕様書無しさん：2007/09/24(月) 19:11:26

int mind;
mind = kokoro()

while (1)
{
　mind -= 1;
　if (mind < 0)
　{
　　takeMedicine();
　　goHospital();
　　if (mind < 0)
　　{
　　　quitJob;
　　　break();
　　}
　}
}

541 ：仕様書無しさん：2007/09/24(月) 20:42:13

>>540
これバグってるだろｗｗ
仕事してないのになんで mind-=1 なんだよ。
仕事しろ仕事ｗ

542 ：仕様書無しさん：2007/09/24(月) 20:50:48

>>540
Jobインターフェースが実装されてません。
java.neet.helloworkパッケージからインポートして実装してください

543 ：仕様書無しさん：2007/09/24(月) 21:02:35

NoSuchMethod : kokoro()

544 ：仕様書無しさん：2007/09/24(月) 21:14:18

今システムテストしてるソース群みてびっくりしたよ、
ぜんぜんエラーハンドリングしてないの
最近の奴らは戻り値とか関係なしか?

545 ：仕様書無しさん：2007/09/24(月) 21:21:29

俺は自分がデバッグする時楽するために
必ず戻り値のチェック入れてる

546 ：仕様書無しさん：2007/09/24(月) 21:21:51

レスをスルー
例外もスルー

547 ：仕様書無しさん：2007/09/24(月) 21:54:30

「この子画面処理中に異常が発生したらどうすべきか」全く書いてないから実装してあげませんw

548 ：仕様書無しさん：2007/09/24(月) 22:34:12

レスをスロー
例外もスロー

549 ：仕様書無しさん：2007/09/24(月) 23:26:52

まぁ、なんでもかんでもCatchすりゃいいって考えるのは厨だね。
本来どっかでバグがあってこけることでそのバグを見つけるかもしれないってのに
Catchして適当な処理したら、何年たっても見つからない可能性がある。

550 ：仕様書無しさん：2007/09/24(月) 23:27:57

catch 厨

551 ：仕様書無しさん：2007/09/25(火) 00:14:56

>>549
戻り値を監視しながら処理を進めるのが普通だと思ってたが
転職先ではエラー処理は書かないのが基本だった…

郷に入れ歯

552 ：仕様書無しさん：2007/09/25(火) 00:21:51

C系だとアサーションは入れるけど
結局リリース時には素通りだったりするよね

553 ：仕様書無しさん：2007/09/25(火) 00:22:00

>>551
お前が正しい。

554 ：仕様書無しさん：2007/09/25(火) 01:44:59

>>552
だったりと言うかリリースならアサーションはスルーされて当然じゃ？

555 ：仕様書無しさん：2007/09/25(火) 01:46:41

>>554
開発・テスト時に異常にならなければそれでOKじゃね？とエラー処理入れないままなパターン。

556 ：仕様書無しさん：2007/09/25(火) 02:02:11

たまに実行時エラーにアサーション入れたりする奴がいるから困る。
つか、リリースモードでリリースする、
っていう確約が何も無いのにアサーション入れたりする奴がいるけど、
全くもって正気かどうか疑いたくなる。

557 ：仕様書無しさん：2007/09/25(火) 02:37:16

>>556
リリース版で最終テストしてリリースするっていうのは、
ものすごく基本的な話なんじゃないのか?

世の中には、
『デバック版でしか動かないからそのままリリース』
という輩も居るらしいが…

558 ：仕様書無しさん：2007/09/25(火) 04:05:27

msvcrtd.dll（デバッグ版Cランタイム）は再配布禁止…らしいな。

559 ：仕様書無しさん：2007/09/25(火) 11:05:02

FILE1 とか RET2 とか…ソレは何のファイルなのか、どんな戻り値なのか。
辞めようとまでは思わないけどさ。

560 ：仕様書無しさん：2007/09/25(火) 14:13:53

ABAPで例外を拾おうとあくせくした日々が懐かしい。
そもそもまともに例外を拾う気の無いツールでそんなことするのは無駄だった。

561 ：仕様書無しさん：2007/09/25(火) 17:23:02

スレ無いから聞いてみるけど、"QAC"ってどうなの？
そこそこ使えるようだが俺的には　hoge==TRUE　を問題として検出しないツールはあまり信用できない。
(ほかにも=と==の間違い疑惑を指摘しなかったりとか）

で、うちの会社アホみたいにこのツールの出力結果を信奉している。
相当投資したみたいだから盲信したくなるのはわからないこともないがね。

562 ：仕様書無しさん：2007/09/25(火) 17:36:06

TRUE==hogeを俺は認めないぞ
可読性が著しく低下する。
そんなソースは書いたことがないぞ。

563 ：仕様書無しさん：2007/09/25(火) 18:11:03

TRUE==hogeってことは…TRUE値と、他の真の値を区別したい場合だよな、きっと？

564 ：仕様書無しさん：2007/09/25(火) 18:28:11

もしも真実がホゲだったなら...どうする!?

565 ：仕様書無しさん：2007/09/25(火) 19:03:55

QACを参考に修正したことなど一度も無いな。
開発内テストが終わった後にかけるので意味が無い。

というかこれユーザインタフェースが終わってる。
使いづらいったらありゃしない。

566 ：仕様書無しさん：2007/09/25(火) 21:14:29

・副作用がある
・定数として評価できる

567 ：仕様書無しさん：2007/09/25(火) 21:45:14

「hoge==TRUE」よか「=と==の間違い疑惑」のほうが重要じゃね？
後者に引っかからなくていいから前者に引っかかって欲しいの？
変数同士になっても有効なのは後者じゃ？

ま、どっちでもええか

568 ：仕様書無しさん：2007/09/25(火) 22:23:30

>>561
たぶん検出のための設定があると思うぞ。

569 ：仕様書無しさん：2007/09/25(火) 22:40:20

bool check(hoge){
　　bool TRUE;
　　if (hoge >= 0 && hoge <= 100){
　　　　TRUE = true;
　　} else {
　　　　TRUE = false;
　　}
　　return TRUE;
}

570 ：仕様書無しさん：2007/09/25(火) 22:41:03

うわすっげえむずむずするコード

571 ：仕様書無しさん：2007/09/25(火) 22:46:42

>>569
きもちわりぃｗ

定数左派の人って範囲チェックのときはどうかくの？
( 0 < hoge && 100 > hoge )ってなるのかな？
==の時だけ定数左？

572 ：仕様書無しさん：2007/09/25(火) 22:56:49

>>571のいる会社は大変だな

573 ：仕様書無しさん：2007/09/25(火) 22:59:25

for文書くときもやっぱ
for(int i=0;10>i;i++)
みたいに書くんだろうか？

574 ：仕様書無しさん：2007/09/25(火) 23:13:54

>>573
そういう人もいるよ。

575 ：仕様書無しさん：2007/09/25(火) 23:13:57

gccで動かしててC99仕様で書いてる。
QACにかけるとエラーだらけ。。

576 ：仕様書無しさん：2007/09/25(火) 23:19:08

C99はできる子。

577 ：仕様書無しさん：2007/09/25(火) 23:28:36

>>572
周りに定数左派がいないもんで、ちょいと疑問に思っただけなんだ。

578 ：仕様書無しさん：2007/09/26(水) 01:08:52

気分で左右を入れ替える俺は駄目人間だぜ

579 ：仕様書無しさん：2007/09/26(水) 01:20:07

統一感が無いのはいかんな

580 ：仕様書無しさん：2007/09/26(水) 05:33:49

i++ でも ++i でもいいときに
++i を使う人ってどれくらいいるかな

581 ：仕様書無しさん：2007/09/26(水) 07:40:44

そもそも++i 自体使わなければならない場面はゼロに近いし・・・
わんらいなー気取りで可読性を低くしているのに気付かないだけ

582 ：仕様書無しさん：2007/09/26(水) 08:31:40

「間」なんかは数学では ( 0<x<100 ) とか書くでしょ。だからｃでも ( 0<x && x<100 ) って書く。

583 ：仕様書無しさん：2007/09/26(水) 08:35:28

iteratorを進めるときは使うなぁ、++i。

584 ：仕様書無しさん：2007/09/26(水) 09:32:02

普通の組み込み型等なら後置、イテレータだったりオーバーロードされテルものだったら前置

585 ：仕様書無しさん：2007/09/26(水) 10:13:58

これはイテレータとか、区別するのも性能劣化も嫌だから、
どちらでも良いときは常に前置。

586 ：仕様書無しさん：2007/09/26(水) 10:19:44

同じく無駄な性能劣化は嫌だし、区別するのも面倒だから前置
最近の賢いコンパイラなら後置でも最適化で一時オブジェクトつくらずにやってくれるかもしれんが

587 ：仕様書無しさん：2007/09/26(水) 10:21:11

>そもそも++i 自体使わなければならない場面はゼロに近いし・・・
for (int i = 0; i < N; ++i) なんて頻出じゃないのか？

C#やJavaのforeach(相当)構文や、C++のgenericを使いまくるんなら別だが。
それでも数値インデックスが必要な場合は結構あると思うけど。

588 ：仕様書無しさん：2007/09/26(水) 10:30:55

性能劣化のは ++i より i++ が遅いってやつ？

589 ：仕様書無しさん：2007/09/26(水) 10:45:49

i++ はもとの i を返すために operator++ 内で一時オブジェクトを作るからな

int 程度だったら無視しても構わない劣化に過ぎないだろうが、
オブジェクト(よく使うのは iterator)のコピーなんてさせたらどれだけ劣化するか。

それが最適な構文なら、富豪的プログラムの観点からは問題無いんだが
i++ と ++i ってソースの可読性上は大した違いは無いから、
必要以上に自ら望んで劣化させる必要も無かろうと。

個人的には後置++ はあまり必要ないんだよな。
int j = i++;
とか書かれると一瞬思考が止まる。
漏れのアホな頭ではどうにも評価順が自然に解釈できないらしい。

590 ：仕様書無しさん：2007/09/26(水) 11:39:18

どうしても後置がいいっていうのは
array[ index++ ] = x;
みたいなときだな

591 ：仕様書無しさん：2007/09/26(水) 15:46:27

>>589
なるほど。
普段からjava使ってるから operator オーバライドの影響は頭から飛んでたわ。
++i 派から i++ に矯正された身でやんす。

592 ：仕様書無しさん：2007/09/26(水) 16:17:47

do {
} while( (++n)<(sizeof hoge) )　なんてよく書くから、けっこう使うな。

593 ：仕様書無しさん：2007/09/26(水) 16:22:29

for文でやれ

594 ：仕様書無しさん：2007/09/26(水) 17:10:37

forだと初期化のあとケツの判定に飛ぶのがｲﾔﾝ。初期化のあとに１回判定が入る展開もあったり。
do whileだと静的にも動的にもキレイ。

595 ：仕様書無しさん：2007/09/26(水) 23:39:18

なぜか俺の教育係だった人はfor文を嫌っていた。
俺が下についていたとき、ほとんどのループ処理をwhileで書いてた。

コメントを見ると”とりあえず”って言葉が多くて大丈夫かいな？って思ってた。

596 ：仕様書無しさん：2007/09/26(水) 23:45:22

そういわれるとforって異質かなという気がしてくる。
( ; ; )セミコロンが気に入らんとか？ｗ

597 ：仕様書無しさん：2007/09/26(水) 23:51:42

>>595
「とりあえず」は俺もよく使う。
検索とかに使うキーワードというか、いわばタグ的に。

統合開発環境のブックマーク機能を使えという話もあるが
作業ファイルをクリーンすると飛んでしまうこともあるから、と言い張って
俺様専用的に使わせてもらってる。

598 ：仕様書無しさん：2007/09/26(水) 23:54:47

「せっかくだから」とか使おうかしら

599 ：仕様書無しさん：2007/09/27(木) 00:11:19

某IDEに毒されたか、VBでも「' TODO:」ってやっちまう最近の俺

600 ：595：2007/09/27(木) 00:33:01

>>596
いやーなんでだろうね。いまだにわかんない。
今は管理役（≠管理職）になってるからコード書かなくなったから、
一緒に仕事することもほとんどないし。

そうそう、if文とかwhile文の後ろが処理1つで済むとき(nNum++とか)は
スコープは絶対につけないというこだわりも持ってた。

こんなことを新人の頃のコードレビューで何度指摘されたことか。。。

601 ：仕様書無しさん：2007/09/27(木) 00:34:02

なるべくforよりforeachを使うぜ！
perlはお呼びでない？そんな……

602 ：595：2007/09/27(木) 00:43:30

>>597
"とりあえず"ってコメントは､今となっては俺も使っちゃうんだけど､
今一緒に仕事してる人から
「問題見つけたときに直す気なのかなって思うと指摘しづらいし､
勝手に直していいのかもわからないからやめて」
っていわれたよ。

うちは検索キーワードはプロジェクト始まるときに､
各機能ごとに決められてそれ以外使えなくなるよ。

603 ：仕様書無しさん：2007/09/27(木) 01:22:17

"とりあえず"
"取り急ぎ"
"おそらくこれでOK"
"暫定"

604 ：仕様書無しさん：2007/09/27(木) 01:33:51

"やらなきゃいけない"

おまえがやれ

605 ：仕様書無しさん：2007/09/27(木) 02:39:57

"なぜか動くのでこのまま"

606 ：仕様書無しさん：2007/09/27(木) 02:43:33

"ここでぬるぽ発生の可能性あり"

607 ：仕様書無しさん：2007/09/27(木) 04:16:17

"後で書き直す"

…いつ？

608 ：仕様書無しさん：2007/09/27(木) 05:38:39

"怒涛のごとく改変"

609 ：仕様書無しさん：2007/09/27(木) 07:40:25

>>603
w
言われてみれば確かに使う
ずーっといつまでも「とりあえず」のままだなｗ

610 ：仕様書無しさん：2007/09/27(木) 08:24:59

"適当に埋めてみた"

書いた奴を土に埋めたくなる……

611 ：仕様書無しさん：2007/09/27(木) 09:18:24

コメントスレになっとるｗ
そういや、笑ったコメント晒すスレ落ちちゃったね

612 ：仕様書無しさん：2007/09/27(木) 10:39:22

建てようとしたら規制かかってたorz

613 ：仕様書無しさん：2007/09/27(木) 12:28:48

"俺はもうだめだ・・・あとは・・・頼む・・・ぞ・・・・"

614 ：仕様書無しさん：2007/09/27(木) 13:07:36

コメントスレ需要有るんなら立てよっか

615 ：仕様書無しさん：2007/09/27(木) 13:10:00

立てた
コメント関係はこっちでよろ

ttp://pc11.2ch.net/test/read.cgi/prog/1190866177/

616 ：仕様書無しさん：2007/09/27(木) 23:19:45

c++でさ。メンバ変数ってどれぐらい公開する？

１）　全て非公開private or protected
２）　状況によりけり
３）　全て公開　public

俺は今まで、３は有り得ないと思ってたんだけど、
どのソースも３ばっかなんだ。誰か何とかしてくれ……

617 ：仕様書無しさん：2007/09/27(木) 23:21:24

(1)のつもりで作る
流動的に(2)へ移行することもある

618 ：仕様書無しさん：2007/09/27(木) 23:22:55

C++じゃgetメソッドいっぱい作っても使いにくいだけだし

619 ：仕様書無しさん：2007/09/27(木) 23:30:41

俺のいる職場のjavaでかかれたコードは
public static だらけだよ。

public final static String sShopNo = "ShopNo"; とか言うのがズラーっと並んでて、
文字列連結の + でつないでSQL文をつくってる。

620 ：仕様書無しさん：2007/09/27(木) 23:32:50

(1)だろ
(2)だって可能な限り避ける
(3)は確かに辞めたくなる...

621 ：仕様書無しさん：2007/09/27(木) 23:35:14

全部公開ってstructじゃん

622 ：616：2007/09/27(木) 23:42:58

やっぱそうか……色々といいたいことはあるコードばっかなんだが、やっぱりそうなんだな。
あと、もう一つ気になるところがある。

この会社では、同じ処理を書くときに、一から書き直す風習があるんだわ。
これもどうかなぁ……って思ってしまうよ。

623 ：仕様書無しさん：2007/09/27(木) 23:45:38

コピペじゃなくて新しく書くってこと？

624 ：仕様書無しさん：2007/09/27(木) 23:58:18

>>623
イエス。全く処理内容が同じなのに、新しく書き起こしている。
理由がさっぱり分からん。

625 ：仕様書無しさん：2007/09/28(金) 00:02:08

ステップ数(笑)稼ぎ

626 ：仕様書無しさん：2007/09/28(金) 00:10:24

>624
版管理とは別な意味でソースコード管理が下手なのかも。
「自社のコード」を蓄積しないで、「顧客に納めるコード」ばかり書いていて
結果、別PJで書いたコードは流用できないから毎回フルスクラッチとか……

627 ：仕様書無しさん：2007/09/28(金) 00:23:02

>>624
元のコードに問題が見つかったとか。
少しでも改善出来る部分があったとか。
新人の練習台にしてるとか。
そうでもしないと余る人員がいるとか。

628 ：仕様書無しさん：2007/09/28(金) 00:23:09

>>626
正解かも……
あれだ。顧客に納めるで思ったんだが、ソース納品な案件があれば少しは変わるような気がしてきた。
まぁ、あんなコードは外部に見せられないけど……

629 ：仕様書無しさん：2007/09/28(金) 00:25:05

>>627
そういうんじゃないんだよ。
例えば、ログ出力処理があったとするだろ。

そしたら、ある場合はグローバル関数にかかれてたり、ある場合はクラス化されてたり、
ある場合はダイアログクラスのメンバ関数に埋め込まれていたり。DLLになってたり……

いや、全部同じ処理なんだぜ。全く……何回読んでもこぴぺで良いじゃんって思えるコードなんだぜ……

630 ：仕様書無しさん：2007/09/28(金) 00:26:39

おっと、途中で投げてしまった。

そんなだから、人員が余る・新人の練習以外は全て違うんだよ。
ちなみに、中途採用ばかりで新人もいない会社だから、その理由で新人の練習という理由もない。
いつも人員不足で悩んでるところだから、人員が余るもない。

631 ：仕様書無しさん：2007/09/28(金) 00:27:58

>>629
いや、そこはコピペじゃなくてＤＬＬでいいじゃんとかクラスでいいじゃんじゃないのか？

632 ：仕様書無しさん：2007/09/28(金) 00:31:53

>>631
そうなんだけどね。要はつまり、とにもかくにも再利用しないとこだと言いたかった。

633 ：仕様書無しさん：2007/09/28(金) 00:37:49

カプセル化って大原則だと思ってたが
案外、世の中には浸透してないのか？
カプセル化されてないソースを読むなんて神業だろ。

634 ：仕様書無しさん：2007/09/28(金) 00:45:24

>638
日本は神の国で八百万の神が、ってのはあながち嘘でもないってことか
あれを読む程度で神と言えるのなら……

635 ：仕様書無しさん：2007/09/28(金) 00:47:10

八百万ステップなら神

636 ：仕様書無しさん：2007/09/28(金) 00:50:19

ロギング処理がダイアログのメンバ関数。
プログラミングできない連中麦価なんじゃないか？　単純に

637 ：仕様書無しさん：2007/09/28(金) 01:31:18

ダイアログごとにロガーがあるのか？

638 ：仕様書無しさん：2007/09/28(金) 01:33:21

ぬるぽ

639 ：仕様書無しさん：2007/09/28(金) 01:34:43

>>634はこの３文字からあれだけの情報量を読み取ったのか

640 ：仕様書無しさん：2007/09/28(金) 01:41:22

妄想が激しすぎるな

641 ：仕様書無しさん：2007/09/28(金) 02:01:37

上司　『こんなところでレス返してる暇があったら、もっとステップを稼げッ』

642 ：仕様書無しさん：2007/09/28(金) 02:50:46

ステップ♪ステップ♪ランランラン♪

643 ：仕様書無しさん：2007/09/28(金) 02:54:57

また1名旅立たれたようです

644 ：仕様書無しさん：2007/09/28(金) 21:49:46

「来週あたり各自宅のPCの検査いくんで」

これはない

645 ：仕様書無しさん：2007/09/28(金) 23:48:48

void reduce(int*number, int*denom){int a,b,tmp; a=abs(*numer);
b=abs(*denom); /*a>=bとなるように入れ替える*/ if(a<b){tmp=a; a=b;
b=tmp;} /*互除法で最大公約数を求める*/ do{tmp=a%b; a=b; b=tmp;}
while(b!=0); /*約分する*/ if(a>1){*numer/=a; *denom/=a;}}

実際は途中改行なしで1行1関数
最初見たときプロトタイプ宣言が並んでるのかと思ったら
関数定義だからびっくりしたわ

646 ：仕様書無しさん：2007/09/29(土) 00:06:49

そして、それらは全てコメントアウトされていた。ってオチとか

647 ：仕様書無しさん：2007/09/29(土) 00:33:46

>>644
winny関連？家庭訪問みたいでやだなｗ

648 ：仕様書無しさん：2007/09/29(土) 00:37:12

>>644
それは上司の自宅へも行くのか？

649 ：仕様書無しさん：2007/09/29(土) 02:17:23

hoge.asdf(fuga);
x
piyo.method();

果たして彼は x と書いてある行にあった文字列を切り取り出来たのであろうか・・・・。

650 ：仕様書無しさん：2007/09/29(土) 02:39:46

辞めようとは思わないソースだけどｗ
ってかコンパイル通らなくね？defineされてるとか？

651 ：仕様書無しさん：2007/09/29(土) 02:43:04

>>645 改行がアレだけど、中身は以外と、まともっぽい。

652 ：仕様書無しさん：2007/09/29(土) 03:12:53

>>557
亀レスだが、
Xbox360のバグまみれソフトだった、カ○ドセプトサー○がそうだったらしい。
なにしろ、Releaseビルドだと、起動すらしなかったとか。
冗談だろ・・・って言ったら、冗談じゃねぇ・・・と言われたときはさすがにあきれたねぇ。
ちなみに聞いた奴はあのバグまみれ騒動以来会社辞めたらしい。(そりゃそーだ)

653 ：仕様書無しさん：2007/09/29(土) 08:51:25

>>633
うちの職場でもそうなんだけど
世の中はカプセル化を否定する方向に向かっているよ

http://www.arclamp.jp/blog/archives/000541.html

654 ：仕様書無しさん：2007/09/29(土) 09:53:22

カプセル化不要な方向に進んでいるのはあるけど、データの分離は別の話だと思うが？
しかし、プログラマのレベルが低すぎるからこそカプセル化が必要なんだと思われ。

655 ：仕様書無しさん：2007/09/29(土) 10:57:57

>>653
世の中もなにもその記事だけじゃん。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

656 ：仕様書無しさん：2007/09/29(土) 13:06:17

>>653
…つまらん。

657 ：仕様書無しさん：2007/09/29(土) 21:46:25

VBだが文字列の切り出しに何でもかんでもMid使ってる
Mid(str, 1, 1)……ってLeft知らんのかこいつは……

658 ：仕様書無しさん：2007/09/29(土) 21:51:13

てか、VBの場合ついLeft$, Mid$, Right$, String$って書いてしまうのは漏れだけか？

659 ：仕様書無しさん：2007/09/29(土) 22:08:31

ロートル

660 ：仕様書無しさん：2007/09/29(土) 22:44:57

>658

｢1｣が変数なら間違いとは思わんが、直値なら･･･

まぁいいか、VBならｗ

661 ：仕様書無しさん：2007/09/29(土) 22:51:57

$つけないとVariant型が返ってくるぜ

662 ：仕様書無しさん：2007/09/29(土) 23:02:41

>658
ﾉｼ
……でも元ソースが全体に$なしがはびこってたり
そもそも、「そんなに文字列と数値をごたまぜで扱いたいならPerlで書けよ」
って言いたくなるよーなのだと諦めて$なしで書くorz

String型で計算の時だけCCurかましてずーーーーっと数値保持してるのを見たときなんてもうね(つ´д｀;)

663 ：仕様書無しさん：2007/09/29(土) 23:02:59

今調べたんだけど Mid てステートメントもあるんだね。

664 ：仕様書無しさん：2007/09/29(土) 23:08:37

>>657
Leftって文字列を扱うクラス以外にもあったから
VB6みたいにLeft()って書いてもエラーになる

名前空間とクラス名を指定しないとダメだから
そいつは使えないと判断したんじゃね

665 ：仕様書無しさん：2007/09/29(土) 23:38:15

えーっと VB.NET？

666 ：仕様書無しさん：2007/09/30(日) 01:34:01

microsoft.visualbasicはいらんぜよ

667 ：仕様書無しさん：2007/09/30(日) 01:36:03

VS2005は無料版があるけど、インストールがﾏﾝﾄﾞｸｾｰから試してねぇな
仕事で使ったことも無いな

668 ：仕様書無しさん：2007/09/30(日) 02:00:25

VC6のときのPlatformSDKがほしい

669 ：仕様書無しさん：2007/09/30(日) 02:08:42

VSEE2008インスコしたけど・・・どうなの？

670 ：仕様書無しさん：2007/09/30(日) 02:45:19

>668
CD取り寄せできるお
Feb 2003がVS6対応最後のPlatformSDK
めりけんからの送料掛かるけどなorz

671 ：仕様書無しさん：2007/09/30(日) 09:23:37

>>662
VB6の本質はVariantだった。
それが理解できずに普通の型チェックを期待して四苦八苦した時期がありました・・・

672 ：仕様書無しさん：2007/09/30(日) 10:32:47

単発ならLeft$使うけど
周囲にMid$があるなら敢えてMid$統一しておく
VB6の案件は厨や新人にお鉢が回るかもしれんから

673 ：仕様書無しさん：2007/09/30(日) 10:42:44

>>657
そのレベルだとどっちでもいいと思うが・・・
どっちかってとあとは本人の好みの問題。

674 ：仕様書無しさん：2007/09/30(日) 13:18:33

Midが周囲で使われてるからって、leftをmidに直しても、何もいいことないだろ?

675 ：仕様書無しさん：2007/09/30(日) 13:54:25

可読性があがる

VBで開発する以上、低スキルな保守要員が宛てがわれる可能性は考えとくべきじゃね？

昨日HelloWorldした新人でも違いが解りやすいじゃん

676 ：仕様書無しさん：2007/09/30(日) 14:10:24

Mid(str, 1, 1) なんて書いてあると、何か意味があるのかと悩んでしまうな。
意味がわかるような関数を使おう。

似たような事例で、PEARに登録されているPHPのライブラリのひとつだが、
こんなん書いてあって意味がわからなかった。

substr_replace('string', 'replace', 0, 0);

関数の意味は名前のとおり、第三引数はstart、第四引数はlength
実際のコードは第一引数は文字列の配列だった。

677 ：仕様書無しさん：2007/09/30(日) 14:20:44

何か意味があるのかと悩む理由が解らんな
自作関数ならともかく。

678 ：仕様書無しさん：2007/09/30(日) 14:21:35

それはお前が何も考えて無いからだなｗ低脳コーダー乙

679 ：仕様書無しさん：2007/09/30(日) 14:30:49

新人でも文字列操作関数ぐらい全部わかるだろｗ

680 ：仕様書無しさん：2007/09/30(日) 14:32:07

動けばどっちでもいいと思うけど。
くだらん

681 ：仕様書無しさん：2007/09/30(日) 14:52:47

>>644
ありえねぇーｗｗｗｗ
んなこと言うような企業は間違いなくDQN

682 ：仕様書無しさん：2007/09/30(日) 15:04:22

>>644
言われても嫌だが、ソースコードに書いてあっても嫌だな...

683 ：仕様書無しさん：2007/09/30(日) 15:30:55

>>680
仕事なら、動くだけじゃだめだろ。

684 ：仕様書無しさん：2007/09/30(日) 16:05:16

>>683
仕事なのに「動けばいい」「スパゲティだからってゼロから作り直すのは駄目」とか
それなのに「機能追加しろ」とか言われ、選手交代になった派遣社員が通りますよ…

685 ：仕様書無しさん：2007/09/30(日) 16:54:10

>>675
いや、可読性下がるんじゃね?

686 ：仕様書無しさん：2007/09/30(日) 16:57:46

leftとmidを混在させないで、midに統一したら読みやすくなるって説は、
leftとmidの機能を思い出しながら読むのが大変って意味か?

687 ：仕様書無しさん：2007/09/30(日) 17:19:45

固定長テキストファイルを読み出すときに、
Left$(str, 10)
Mid$(str, 11, 10)
～
Mid$(str, 101, 10)
とかずらずら書いて、一番上のLeft$をMid$にしたら、
引数の数もそろって綺麗なんじゃね？　って10秒くらい考えたけど、
ばかばかしいのでそのままテストをした覚えはある。

688 ：仕様書無しさん：2007/09/30(日) 17:25:28

あー位置が揃うとか、そういう意味か。

689 ：仕様書無しさん：2007/09/30(日) 17:30:08

この場合だったら
for i = 1 to 10
hoge(i) = mid$(str, i*10+1, 10)
next
とか書けばすっきりじゃね？

690 ：仕様書無しさん：2007/09/30(日) 17:53:27

若人の俺は、VBのファニー文字みたいな奴がよくわからん。
体型立てて勉強しようにも、そういった資料が少なくない？

691 ：仕様書無しさん：2007/09/30(日) 17:56:27

ファニー文字って、$とか%とか?
ヘルプに載ってるんじゃないの?

692 ：687：2007/09/30(日) 18:47:14

>>688
そういう意味で悩んだけど、可読性があがるとは今でも思わないな俺は。

>>689
昔のコードなんで覚えてないからてきとーに書いたんだけど、
文字長ばらばらで、forでまとめるわけには行かなかったと思った。
そうであって欲しい。　そうでなければ悲しすぎる。

693 ：仕様書無しさん：2007/09/30(日) 18:57:52

もし使ってる言語に、midやらsubstring相当の機能しかなかったら、leftやらrightやらって
ルーチンを自作して使う。
機能が限定されてるルーチンのほうが意図が伝わるから。

694 ：仕様書無しさん：2007/09/30(日) 19:19:42

顧客　「開発方法はLyeeとありますが？」
カテナ「はい。Lyeeです。」
顧客　「Lyeeとは何のことですか？」
カテナ「理論です。」
顧客　「え、理論？」
カテナ「はい。理論です。開発期間が従来の5分の1～10分の1です。」
顧客　「・・・で、そのLyeeは当社での開発で何のメリットがあるとお考えですか？」
カテナ「はい。設計もテストも不要です。」
顧客　「いや、そもそも設計やテストは貴社の担当です。それに設計書が無いのは不安ですね。」
カテナ「でも、業務知識がなくても開発可能ですよ。」
顧客　「いや、可能とかそういう問題じゃなくてですね・・・」
カテナ「ドキュメント量が100分の1ですよ。」
顧客　「ふざけないでください。それに100分の1って何ですか。だいたい…」
カテナ「1%です。保守資料無しとも考えられます。深層心理においては…」
顧客　「聞いてません。帰って下さい。」
カテナ「あれあれ？怒らせていいんですか？使いますよ。Lyee。」
顧客　「いいですよ。使って下さい。Lyeeとやらを。それで満足したら帰って下さい。」
カテナ「運がよかったな。今、撤退を決めたみたいだ。」
顧客　「帰れよ。」

695 ：仕様書無しさん：2007/09/30(日) 20:14:58

>>694
Lyeeでググってみたけど、ＵＭＬからソースコード生成するのと似たようなもん？
完全生成できたとしてもシステムテストとかはするよな、普通。

696 ：仕様書無しさん：2007/09/30(日) 21:58:53

思い出した！
VBで「こうやんないとうまく動かない」みたいな(正確には覚えてないけど)関数名があった。
コメントならまだしも、勘数名でこれとは...

697 ：仕様書無しさん：2007/09/30(日) 23:08:32

>>694
普通はこうなる。

顧客　「開発方法はLyeeとありますが？」
カテナ「はい。Lyeeです。」
顧客　「Lyeeとは何のことですか？」
カテナ「理論です。」
顧客　「え、理論？」
カテナ「はい。理論です。開発期間が従来の5分の1～10分の1です。」
顧客　「つまりその分開発費用も安くなると言うことですか。すばらしい。よし採用。けってーい。」

まあ、Lyeeなんてしらんがなｗ

698 ：仕様書無しさん：2007/10/01(月) 01:06:28

Lyeeって情報システム板でやたらスレが荒れてた記憶があるな。

699 ：仕様書無しさん：2007/10/01(月) 02:31:13

だってあれは・・・良く見てみれば。プリコンパイラにしか過ぎない。

700 ：仕様書無しさん：2007/10/01(月) 03:52:55

てｓｔ

701 ：仕様書無しさん：2007/10/01(月) 12:41:33

>>670
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm

702 ：仕様書無しさん：2007/10/01(月) 21:10:18

>>670
>>701
スレ違いになってしまったけどサンクス
これでCPANの古めのモジュールがmakeできるかもしれん

703 ：仕様書無しさん：2007/10/02(火) 22:02:30

>>696
そういえばあの関数なぜかうまく動かないからその関数は自分で作ったよ。
傍から見たらライブラリにあるのになんで？って思われるだろうな。

704 ：仕様書無しさん：2007/10/05(金) 01:03:37

Cで関数定義の頭に概要の説明が書いてあるソースがあった。

/* -- 概要
共通ログ出力関数

呼び出し方法: void logfunc(int errcd, char *funcname);
引数:なし
戻り値:0:正常 -1:異常
*/
void outlog(int errcd, char *funcname)
{
...以下定義

もう一つ
/*
呼び出し方法: int func(void)
戻り値:0:正常 -1:異常
*/
void func(){/* 定義 */}
..で実際の呼び出し箇所にいくと
func("XXXX");

1つ2つならまだいいけど、万事がこんな感じ。コメントウソ書きすぎ。
わざとやってるんじゃないかと疑いたくなってくる。

705 ：仕様書無しさん：2007/10/05(金) 02:41:57

「苦肉の策」とか「後で修正しておくこと」とかもう諦めてるんだけど、
「苦肉の策！(笑)」とか「後で修正する必要アリ(´д｀)」とかになってるとマジ辛い。
昨日も昼ごろ似たようなコメント見つけて午後ずっと気分悪かった。

706 ：仕様書無しさん：2007/10/05(金) 09:18:07

気持ちに余裕がないのね

707 ：仕様書無しさん：2007/10/05(金) 09:34:42

ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=41464&forum=7&start=16
どれを削除したらいいか判断できないような混沌としたプロジェクト
Ｃ＃ってこんなのが普通なのか？

708 ：仕様書無しさん：2007/10/05(金) 10:51:30

>>707
コーディング規約や開発者のコード管理能力の問題だろ。
C#に限らず、どんな言語を使ったって、混沌とさせる奴はいる。

それを解決できるツールがたまたま（同じ必要性を感じた）先人によって作られているか、
そんなツールを見つけられるかどうかで、問題を糊塗できるかどうかの違いだけだ。

709 ：仕様書無しさん：2007/10/05(金) 13:04:25

>>708
C#だからひどくなったんでしょ

710 ：仕様書無しさん：2007/10/05(金) 13:10:19

>>708
スレタイ嫁

711 ：仕様書無しさん：2007/10/05(金) 13:39:25

>>708
何が原因でそんな混沌としたプロジェクトになったかなんて興味なくて、
そいうプロジェクトにいたら会社辞めたくなるだろうなってことだよ。

Ｃ＃は知らないけど、Ｃ＃だからこそ何を削除したらいいか検索するのが不可能って流れになってるじゃん。
少なくともＣ＋＋やＶＢだったら不要メソッドのリストアップは簡単に出来ただろうにね。
（Ｊａｖａも知らないけど、Ｊａｖａもそうなのか？）

Ｃ＃コワーｗ

712 ：仕様書無しさん：2007/10/05(金) 14:15:41

コードの7割くらいがコメントアウトされた過去のコードのプロジェクトに入れられた…
#if 0～#endifで除外されたブロックも多数あって発狂しそう orz

713 ：仕様書無しさん：2007/10/05(金) 14:36:27

スレ違いっぽい話題を引きずることになるかも知れないけど
C++やVBだと不要メソッドのリストアップにどういう方法があるの？

714 ：仕様書無しさん：2007/10/05(金) 14:59:20

うちはVB厨だが、これを使ってる
ttp://www011.upp.so-net.ne.jp/flatsoft/soft/fs_about_vbcheck.html

715 ：仕様書無しさん：2007/10/05(金) 16:09:54

＞Ｃ＃だからこそ何を削除したらいいか検索するのが不可能って流れになってるじゃん。
どこにそんな流れがあるんだ

716 ：仕様書無しさん：2007/10/05(金) 16:13:01

>>713
ググレカス

717 ：仕様書無しさん：2007/10/05(金) 16:14:38

つーか、リフレクションを駆使するようなチームだったら、コードをクリーンに保つくらいすると思うんだが。

718 ：仕様書無しさん：2007/10/05(金) 16:51:09

>>715
C#嫌いが嵩じて幻覚でも見てるんじゃ

719 ：仕様書無しさん：2007/10/05(金) 17:00:20

>>713
VBでこれ使ってる。
ttp://www.aivosto.com/vb.html

Cならsplint、C++は昔なんか使ってたような気がするけど忘れた。

720 ：仕様書無しさん：2007/10/05(金) 22:33:55

不要社員のリストアップに

721 ：仕様書無しさん：2007/10/05(金) 23:41:32

>>708
この前、fxcopとかってツールをためしに使ったら、使われてないメソッドとかは指摘されてたような。うろおぼえ。

722 ：仕様書無しさん：2007/10/05(金) 23:41:46

>>711
C++はおろか、Javaや最近のVBですらリフレクションが実装されていることを知らないこと、
それ以前に問題の本質を見つけられない濁った目、そして文中に漂う全角アルファベット、

おまえ、もしかしてコボラだなww

723 ：仕様書無しさん：2007/10/05(金) 23:47:35

こぼらがいっぴき
こぼらがにひき…

この辺で…俺のはじめてのプロジェクトは火を噴いてあたりを転げまわりだした。

724 ：仕様書無しさん：2007/10/06(土) 00:02:02

ぇ、C++ってリフレクションあったっの? C++/CLIじゃなくて?

725 ：仕様書無しさん：2007/10/06(土) 00:02:49

>>707
関係ないが、そこで、上から目線で教えてやってるジッタってやつは、よそのスレで、ツッコミ入れられまくってたヤツだな。
このエントリで。
http://blogs.wankuma.com/jitta/archive/2007/07/26/87218.aspx

726 ：仕様書無しさん：2007/10/06(土) 00:22:24

本当に関係ねえ

727 ：仕様書無しさん：2007/10/06(土) 08:20:06

>>725
先輩だか上司だかに、添削と言って、こんなソースにされたら、やめたくなるよ。

728 ：仕様書無しさん：2007/10/06(土) 14:14:55

dim strTemp(10) as string
const intTemp as integer = 10

for i as integer = 1 to intTemp
strTemp(i) = ""
'処理
next

729 ：仕様書無しさん：2007/10/06(土) 14:17:15

どの辺が気に入らないんだろう

730 ：仕様書無しさん：2007/10/06(土) 14:30:39

VBなところ

731 ：仕様書無しさん：2007/10/06(土) 14:35:35

for i as integer = 0 to intTemp

732 ：仕様書無しさん：2007/10/06(土) 14:53:15

for i as integer = LBound(strTemp) to UBound(strTemp)

733 ：仕様書無しさん：2007/10/06(土) 15:03:54

ＶＢの文字列って初期化されてることが保障されてなかったっけ？

734 ：仕様書無しさん：2007/10/06(土) 15:06:03

for i as integer = 0 to intTemp-1

735 ：仕様書無しさん：2007/10/06(土) 15:12:03

綺麗なコーディングしてるだろ

バグってるんだぜ、これで…

736 ：仕様書無しさん：2007/10/06(土) 15:30:29

>>733
保障されてる

737 ：仕様書無しさん：2007/10/06(土) 19:51:32

VBって確か、
配列宣言時に指定する数が、
要素数じゃなくて添字の最大値なんだよな

738 ：仕様書無しさん：2007/10/06(土) 20:15:39

dim a(3) なら a(0) ～ a(3) だっけ？
昔のベーシックで a(0) を無しにしてメモリを節約するとかいう
セコいオプションがあったような記憶がある。

739 ：仕様書無しさん：2007/10/06(土) 20:21:04

VBでは、option base で配列の添字を 1～にするか0～にするか変更できる。

740 ：仕様書無しさん：2007/10/06(土) 20:59:49

もうすぐ64ビットが当たり前になる時代にそんなオプション意味あるんか？

741 ：仕様書無しさん：2007/10/06(土) 21:32:07

メモリの1バイトは血の一滴だ！

742 ：仕様書無しさん：2007/10/06(土) 21:39:56

おしい
血より精液のほうが説得力あったのに

743 ：仕様書無しさん：2007/10/06(土) 21:40:28

初期化が保証されてても初期化、ということにはあまり文句は言わない
でも過保護言語のVBだし事情が違うのかな

744 ：仕様書無しさん：2007/10/06(土) 21:43:52

初期化で思い出したけど
MFCとかでポインタ先が破棄済みかどうかに( pTest )ってやってるの困る
解放後の0割り当てなんてコード全体で徹底するのか？
いずれにせよMFC内部で delete this とかやるのあったらダメ

745 ：仕様書無しさん：2007/10/06(土) 22:06:11

メモリ管理もろくに出来ない無能な人間のための言語というアピールはひしひしと感じる
便利だから使うんじゃない，それしか使えないんだ，てな

746 ：仕様書無しさん：2007/10/06(土) 22:26:48

管理以前にそもそもメモリの概念が分かっていません。

747 ：仕様書無しさん：2007/10/06(土) 22:34:13

メモリの節約、スレッドの節約、etc...

748 ：仕様書無しさん：2007/10/07(日) 00:07:44

給料の節約、残業代の節約、etc...

749 ：仕様書無しさん：2007/10/07(日) 00:10:42

>>744
> 内部で delete this とかやるのあったらダメ

そうか?

750 ：仕様書無しさん：2007/10/07(日) 03:47:54

>>725
相当に疑わしい人間だな。

751 ：仕様書無しさん：2007/10/07(日) 07:16:38

> 解放後の0割り当てなんてコード全体で徹底するのか？
逆に delete して NULL 入れてないやつはぶっ殺したくなる

752 ：仕様書無しさん：2007/10/07(日) 08:29:44

自所持ﾎﾟｲﾝﾀをNULLにしたところで
その参照先を他のやつもﾎﾟｲﾝﾀで参照してたら・・・・そっちが自動でNULLになってくれるわけじゃないから
NULL当てはめて安心するなんて無意味っちゃ無意味

753 ：仕様書無しさん：2007/10/07(日) 09:22:50

意味不明。
自ポインタで必要なくなった参照先は、他のやつでも必要なくなるって決め付けてるのか？
そんなもん、プログラムのロジックによりけりだと思うが。他では保持する必要があるかもしれないし。
NULL当てはめて安心したいのは、処理が他の参照先に移ってるのに自ポインタが保持してるせいで
誤ってアクセスするというようなことを起こさないための防衛策もあるだろ。

「この会社辞めようと思った」の９０％くらいは真実だと思うが、１０％くらいは「辞めようと思った」奴の
レベルが低すぎるんじゃないかと思うことがある。

754 ：仕様書無しさん：2007/10/07(日) 09:53:34

言ってることが全然分からんな。
よほど内部・詳細設計が腐っていると見える。

755 ：仕様書無しさん：2007/10/07(日) 10:57:20

>>751
そんなことするのヘタクソだけだろ。

756 ：仕様書無しさん：2007/10/07(日) 10:59:49

Javaで、1000行以上のメソッド（この時点でどうかとおもうが）を抜ける時に
一々オブジェクトにnullを入れて片付けているのを見たとき。
そんなどうでもいい気を使う前に、そのくそ長いメソッドを見直せと。

757 ：仕様書無しさん：2007/10/07(日) 11:07:22

Javaは変数スコープ明確にしてGCに任せるだけだから楽だな

758 ：仕様書無しさん：2007/10/07(日) 12:32:51

gcなんて訳の分からんもんによくお任せできるな
お前は通りすがりのオヤジに家の留守番を頼めるのか？

759 ：仕様書無しさん：2007/10/07(日) 12:40:28

いや、javaは別にgc依存でいいんじゃないか？
そういう言語なんだし。

760 ：仕様書無しさん：2007/10/07(日) 12:50:25

>>753
deleteした場合の話だろ？

761 ：仕様書無しさん：2007/10/07(日) 13:00:12

同じアドレスを共有しているポインタがあるのに delete するって
それだけで重大な設計ミスだな

所有権移行なら、delete せずに権限渡して
自分のポインタは NULL 設定とかする(auto_ptr がこうなってるな)し、
複製ならオブジェクトのコピーするだろ、普通
複数箇所で共有するなら、いいからスマートポインタ使っとけって話だし

762 ：仕様書無しさん：2007/10/07(日) 13:06:13

>>757
スマートポインタも使わないのか？
参照カウンタだって立派なGCだが。

763 ：仕様書無しさん：2007/10/07(日) 13:13:28

>>758
それを言い始めたらコンパイラも実行環境も何もかも信用できなくなるよ

764 ：仕様書無しさん：2007/10/07(日) 13:42:04

ぬるぽ

765 ：仕様書無しさん：2007/10/07(日) 13:48:08

お前らはデンマークの2流都市出身の禿や
カナダの糞田舎で育ったキモいオッサンの作った言語なんて信用できるのか？

766 ：仕様書無しさん：2007/10/07(日) 14:02:00

malloc/freeのペアを使っていた時代は、freeの後にNULLは設定していたなー
論理的な異常処理とかでやむを得ず処理を終了する場合は、
ポインタ参照用変数がNULLじゃなけりゃ取りあえずfreeしまくってexitしていた。

まぁ、三つ子の魂百までじゃないけど、たまにそうコーディングして苦笑する事が最近はある。

767 ：仕様書無しさん：2007/10/07(日) 14:07:25

最初に疑うべきはいつの時代でも自分のコーディングだけどな！

768 ：仕様書無しさん：2007/10/07(日) 14:34:45

ポインタをNULLクリアしなきゃならないコードの書き方を疑え。

769 ：仕様書無しさん：2007/10/07(日) 15:01:04

>>763
どんなコンパイラも実行環境も最初は通りすがりのおっさん程度の信頼性しかないものだ。
それが大勢に使われて、もまれて、信頼できる警察官になるんだよ。

770 ：仕様書無しさん：2007/10/07(日) 16:00:39

いまどき C++ で自分で delete 書いてる時点で何かおかしいと疑ったほうがいい。
std::auto_ptr, boost::scoped_ptr, boost::shared_ptr で全部済ませとけ。

771 ：仕様書無しさん：2007/10/07(日) 16:12:58

boost の利用は標準に取り込まれてから考える

772 ：仕様書無しさん：2007/10/07(日) 16:52:43

std::auto_ptr を delete 書くのを省くためだけに使うんだったら帯に短し襷に長しだな

773 ：仕様書無しさん：2007/10/07(日) 17:17:30

>>772
へ？その目的で使ったら十分だと思うよ。
本人の意思とは関係なく例外安全性が付いてきたりするけど、別に余計なもんじゃないし。

774 ：仕様書無しさん：2007/10/07(日) 17:32:33

まぁでもエラー処理とか例外安全とか一切考慮してないような自作スマートポインタクラスを使うのもなぁ～

775 ：仕様書無しさん：2007/10/07(日) 17:33:38

普段ウォシュレットを使い慣れている奴はたまに駅の便所で拭かずにパンツを上げるらしい。
もしくは美味く拭けずに手にウンコ付けまくりんぐとか。

一番多いのが、ちゃんと拭いて流したつもりでも毛に残ったウンコでパンツが黄色いとかだな。

776 ：仕様書無しさん：2007/10/07(日) 17:57:15

エクセルが信用できないので計算機で出した値を手入力してます
ＧＣが信用できないので（ry

777 ：仕様書無しさん：2007/10/07(日) 18:12:18

GCはいつインスタンスが破棄されるか分からんのでデストラクタ使い辛いのがなぁ・・・

778 ：仕様書無しさん：2007/10/07(日) 18:33:56

ところでここはいつから"この会社辞めようと思った自分の一言"スレになったのですか?

779 ：仕様書無しさん：2007/10/07(日) 18:41:25

>>778
知るか。どうでもいい事書くな！ヴぉけ

780 ：仕様書無しさん：2007/10/07(日) 18:41:26

javaやC#も、スコープ抜けたら、デストラクタ(相当)がコールされる仕組みを作ってくれたらいいのに。
メモリ以外のリソースの開放がかえってめんどくさくなったな。

781 ：仕様書無しさん：2007/10/07(日) 18:41:49

1メソッドだらだら1000行とか書くやつは害虫としか思えん。
自分が辞めるよりそいつを駆除したほうがいいだろ普通。

782 ：仕様書無しさん：2007/10/07(日) 18:51:41

>>780
javaならファイナライザがあるよ

783 ：782：2007/10/07(日) 18:52:39

と思ったけど動くタイミングが微妙だな

784 ：仕様書無しさん：2007/10/07(日) 19:52:52

C++/CLIを使えばいいじゃない

785 ：仕様書無しさん：2007/10/07(日) 20:00:32

>>775
普通はウンコ吹いてからウォシュレット使うでしょ

786 ：仕様書無しさん：2007/10/07(日) 20:01:12

>>780
C#のusingでスコープ囲む奴じゃダメ？

787 ：仕様書無しさん：2007/10/07(日) 20:04:38

>>785
最初にウォシュレットで残留物を洗い流してから、
紙に色が付かなくなるまでふきふきしてる。

788 ：仕様書無しさん：2007/10/07(日) 20:13:15

>>786
usingでもいいけど、開放したいのが複数あったらネストが深くなるからね。

using (IDbConnection conn = new ・・・) {
  conn.Open();
  using (IDbCommand cmd = conn.CreateCommand()) {
    cmd.CommandText = "・・・";
    uding (IDbDataRedader reader = cmd.Execute・・・） {
      while (reader.Next()) {
        ・・・
      }
    }
  }
}

C++/CLI や D みたいにやれたらいいのに。

789 ：仕様書無しさん：2007/10/07(日) 20:15:33

>>787
それだと横に飛び散る様な気がするから俺は、>>785派

790 ：仕様書無しさん：2007/10/07(日) 20:33:57

>>788
順序は無視して、単純に開放したいのが複数あるときは
using( ... )
using( ... )
{}
って出来たと思う。的外してたらすまんす。

791 ：仕様書無しさん：2007/10/07(日) 20:58:01

exit(-1);

792 ：仕様書無しさん：2007/10/07(日) 22:11:26

>>777
デストラクタは破棄される自分自身が保持してるものをアボンヌする「のみ」・・・のはずだから
まぁタイミングなんて別にいいじゃん・・・・。いや実際処理入れられるけど、出来るけれど

793 ：仕様書無しさん：2007/10/08(月) 00:04:26

自分の持っているもののみを開放するのみとは言え、

class CFile {
public:
　　CFile() : m_fileptr(NULL) { }
　　~CFile() { Close(); } // まさに開放するのみ
　　bool OpenForRead(const std::string &path);
　　bool OpenForReadWrite(const std::string &path);
　　void Close();
private:
　　FILE *m_fileptr;
};

CFile *file = new CFile();
file.OpenForReadWrite("/tmp/hoge");

// ここで GC の対象になったとして

CFile *file = new CFile();
file.OpenForRead("/tmp/hoge");

OpenForReadWrite, OpenForRead は
Reader-Writer Lock で flock かかるとして、
OpenForRead が成功するか失敗するかわからん、
というのが悩みどころなのでは。

いや、この場合は明示的に Close してやればいいんだけど。
# C/C++ しかわからんので C++ + GC という謎の物体でスマン

794 ：仕様書無しさん：2007/10/08(月) 00:16:00

実処理の発動はともかく破棄権を与えるタイミングは把握できるはずだから問題ない・・・と思うんだけど

795 ：仕様書無しさん：2007/10/08(月) 03:43:17

># C/C++ しかわからんので C++ + GC という謎の物体でスマン
途中まで読んで、最近はgc付きのC++なんてのがあるのかと思ったぞ

796 ：仕様書無しさん：2007/10/08(月) 03:54:21

// cnt が 0 より大きかったら処理する
if (cnt > 0) {
}

797 ：仕様書無しさん：2007/10/08(月) 04:00:34

if (cunt < dick) {
　　　// や～ん、こわれちゃう！
}

798 ：仕様書無しさん：2007/10/08(月) 05:34:57

デバックの結果、不等号の向きが逆、ってのはよくある話で

799 ：仕様書無しさん：2007/10/08(月) 07:00:58

// 余計な物がありますよ
if( a < 20 );
{
return hogehoge.detteiu( pero-n, a );
}

800 ：仕様書無しさん：2007/10/08(月) 09:40:32

>>796
見りゃわかるから、そんなコメントいらね！ってこと？
もしくは、 0 < cnt のほうが見やすいだろ！ってことか？

801 ：仕様書無しさん：2007/10/08(月) 11:29:35

>>800
そんなこともわからんのも
まずいと思う。

802 ：仕様書無しさん：2007/10/08(月) 12:07:32

>>gc付きのC++
C++/CLI　でもこれはやるのかな?

803 ：仕様書無しさん：2007/10/08(月) 12:16:56

>>801
や、すまん。俺も悩んだ。

804 ：仕様書無しさん：2007/10/08(月) 12:21:43

if (cnt > 0) {
}

何の問題もないだろ、
おれもこう書くが？

805 ：仕様書無しさん：2007/10/08(月) 12:26:31

ネタはコメントの方だろ

806 ：仕様書無しさん：2007/10/08(月) 12:29:42

俺の部署のコーディングルールだと直値は禁止なので０じゃなくて
if(cnt > (int)NUMBER_ZERO){
}
とかにしないといけない。

807 ：仕様書無しさん：2007/10/08(月) 12:31:03

> NUMBER_ZERO

808 ：仕様書無しさん：2007/10/08(月) 12:31:41

> if(cnt > (int)NUMBER_ZERO){
> }
> とかにしないといけない。
まったく意味無しのウザイルールだな。
仕様が変わって 1 より大きくなったら、
if(cnt > (int)NUMBER_ONE){
}
ってすべて書き直すんだな。

あほだ

809 ：仕様書無しさん：2007/10/08(月) 12:33:12

古典的な誤りだな

810 ：仕様書無しさん：2007/10/08(月) 12:37:36

別にいいんだけど、NUMBER_ONEとかってセンスないっていうか、
ちょっとウケるな。
そもそもそこを閾値として、THRESHOLDなんたらとかにしておけば、仕様が変わった場合、
その定数の定義を変えるだけでいいが、NUMBER_ZEROだったら、
結局全部探して直さなきゃならないから、全く意味ないと思うが。

811 ：仕様書無しさん：2007/10/08(月) 13:22:51

> 仕様が変わって 1 より大きくなったら、

いやーこうじゃないか？

#if 0
#define NUMBER_ZERO 0
#endif
/* 2007/10/08 nanasi808 */
#define NUMBER_ZERO 1

812 ：仕様書無しさん：2007/10/08(月) 13:34:14

#if 0
#define NUMBER_ZERO 0
#endif
/* 2008/10/08 洋司 */
#define NUMBER_ZERO 1

813 ：仕様書無しさん：2007/10/08(月) 13:35:56

>>811
定数名と内容が一致してないだろ。
ダメダメなコードの典型だと思うぞ。

814 ：仕様書無しさん：2007/10/08(月) 13:38:30

#if 0
#define NUMBER_ZERO 0
/* 2008/10/08 洋司 */
#define NUMBER_ZERO 1
/* 2009/10/08 洋司 */
#define NUMBER_ZERO 2
/* 2010/10/08 洋司 */
#define NUMBER_ZERO 3
#endif

/* 2011/10/08 洋司 */
#define NUMBER_ZERO 4

815 ：仕様書無しさん：2007/10/08(月) 13:39:10

#defineでてきたか・・・、そんなことで#define使うなよ
その部分のソースのみを見て名前から動きが理解できないじゃないか・・・

816 ：仕様書無しさん：2007/10/08(月) 13:40:25

洋司うるさいｗ

817 ：仕様書無しさん：2007/10/08(月) 13:44:01

洋司はもうちょっと検討段階で頑張れよｗ

818 ：仕様書無しさん：2007/10/08(月) 13:46:51

#if 0
#define NUMBER_ZERO 0
/* 2008/10/08 洋司 35歳*/
#define NUMBER_ZERO 1
/* 2009/10/08 洋司 36歳*/
#define NUMBER_ZERO 2
/* 2010/10/08 洋司 37歳、リストラされる*/
#define NUMBER_ZERO 3
#endif

/* 2011/10/08 陳姪用 */
#define NUMBER_ZERO 4

819 ：仕様書無しさん：2007/10/08(月) 13:48:28

そういうところは仕様は絶対かわなんないんだよ。
もしNUMBER_ZERO で定義してるんだったらNUMBER_ONEってのもどっかにあるだろうし。
よほど変なコーディングでない限り、その部分が24になったり10456になったりとか
することはないよ。変わる仕様だったら別な名前でちゃんと定義してるだろ。
自分も>>808と似たようなところだが、
どんな数字も全部そう書くようにする規約があるからわかるんだが
１回しか登場しなくてどうやったって誰が書いてもどんなに仕様が変わっても
そこだけは必ず０から始まるようなものって結構あるんだよ。
たとえばゼロ割を回避するためだったり。

820 ：仕様書無しさん：2007/10/08(月) 13:49:01

引き継ぎcomplete!!

821 ：仕様書無しさん：2007/10/08(月) 13:49:36

>>819
うまいことまとまった。サンクス

822 ：仕様書無しさん：2007/10/08(月) 13:50:52

>>819
元の書き込みはそうだろうが、俺らが文句言っているのは>>808に対してなので、
その辺、勘違いしないでよね！！

823 ：仕様書無しさん：2007/10/08(月) 13:52:10

>>822
>>808 も >>819 も同じ事いってるだろ、ヴぉけ
お前は洋司レベルだな

824 ：仕様書無しさん：2007/10/08(月) 13:53:59

>>819
NUMBER_ZEROってのが一般的に利用するcommon的なソースであって絶対に変化のない物なら理解できる

だが、そのシステムに特化したソース内では利用すべきじゃないと思う
それならば別の名前を付けることもできるだろうし、ゼロってのは数字であって名称ではないし

825 ：仕様書無しさん：2007/10/08(月) 13:54:40

>>823
褒め言葉として受け取っておこう！！

826 ：仕様書無しさん：2007/10/08(月) 13:55:21

おれは洋司とは仕事したくないぞ

827 ：仕様書無しさん：2007/10/08(月) 13:56:00

>>824
そうだね。
そのゼロがなんなのか分かる名前なら意味あるけど、
ただNUMBER_ZEROじゃ、打つのが面倒なだけで、0って直書きするのと変わらない。

828 ：仕様書無しさん：2007/10/08(月) 14:20:27

しかし、これがNUMBER_ZEROでなく(int)NULLだとさらに混沌の度が増す……

829 ：仕様書無しさん：2007/10/08(月) 14:30:39

「FIVEは5か?」は昔からある教訓で、
>>819の考えは適切ではない。

830 ：仕様書無しさん：2007/10/08(月) 14:43:47

定数ゼロを使う場合なんて大半は
マクロ定義改変でゼロ以外に変更してコードの理屈が通るとは考えられないしなぁ
必要かどうか、なら要らないわな

831 ：811：2007/10/08(月) 14:44:24

完全にネタのつもりで書いたのに。マジレスしてるやつは議論の余地があるとでも思ってるのか？恐ろしい。

832 ：仕様書無しさん：2007/10/08(月) 14:45:08

NUMBER_ZERO
この名前に誰も突っ込まないのがなあ。
SECTION_ZEROとかROW_ZEROとかのグループ的な意味を持つ場合ならいいけど
そうじゃないイミフな定数は定義した意味が半減するし

833 ：仕様書無しさん：2007/10/08(月) 14:52:19

>>832
みんな突っ込んでるだろ。
ZEROと書いといて、仕様変更で「0」以外の値になることは考えないのか？という話で。
代案もセンス悪い。
漏れだったら、COUNTER_START_NUM か何か、ZEROを含まず機能を類推できる名前にする。

834 ：仕様書無しさん：2007/10/08(月) 14:55:06

現実に周囲を見回すと、物に名前を付けるって意味について二通りの意識を持つコーダーがいる気がするな

今後の拡張等を踏まえて、利便性を追求するのためにとりあえず名前を付ける人
ソースを分かりやすくするために適切な名前を付けようとする人

で、前者は大抵ワガママなソースになりがちで嫌われると思う

835 ：仕様書無しさん：2007/10/08(月) 14:58:59

＞誰も突っ込まないのがなあ

突っ込んでんじゃん
文盲か？

836 ：仕様書無しさん：2007/10/08(月) 15:02:18

>SECTION_ZEROとかROW_ZEROとかのグループ的な意味を持つ場合ならいいけど

いいのかよｗ

837 ：仕様書無しさん：2007/10/08(月) 15:07:02

釣れるのは雑魚ばかりか

838 ：仕様書無しさん：2007/10/08(月) 15:19:47

関数は５０行ぐらい、多くても１００行までにしてくれ、と言っても
理解できない奴が多すぎて困る。
１０００行とか天才かよと。

839 ：仕様書無しさん：2007/10/08(月) 15:25:22

関数分割って結構難しいと思う。
ノッて書き出すと１関数でずっと続けちゃうし、分割した方がいいと思っても、
バグ発生や見通しが悪くなるのが怖くてなかなか踏み切れない。
できるかできないかがプログラマのセンスの差なんだろう。

840 ：仕様書無しさん：2007/10/08(月) 15:44:21

そういう問題じゃねぇだろ

841 ：仕様書無しさん：2007/10/08(月) 15:44:42

> バグ発生や見通しが悪くなるのが怖くてなかなか踏み切れない。

釣りか？

842 ：仕様書無しさん：2007/10/08(月) 15:48:08

関数分割で見通しが悪くなる、ってどんだけ

843 ：仕様書無しさん：2007/10/08(月) 15:53:07

839だけど、俺くらい技術の低いプログラマだと、そういうレベルで
悩んでしまうってことです。
バグ発生は、同じ変数を他所でいじってるんじゃないかと取り越し苦労して、
見通しが悪くなるのは、機能を適切に分割できなくて、引数が複雑に
なったり、戻り値が凝ってる割にたいしたことやってなかったり拡張性が
悪い物だったりする。

844 ：仕様書無しさん：2007/10/08(月) 16:04:02

分からんなら分かる奴とかPGの取りまとめとかに聞け。
分からんからといって問題を放置されるのが一番タマラン。

845 ：仕様書無しさん：2007/10/08(月) 16:09:31

大きな関数をセンスで分割するというアプローチが既に誤り
目に見えない制約がたくさんあって、それを遵守すると機械的に
小さな関数群になる、という感じ

846 ：仕様書無しさん：2007/10/08(月) 16:16:32

こういうアクションで呼ばれた(たとえば、ボタン A が押された)ら、
「こうしてこうしてこうする」、というのを関数にして、
それぞれの「こうする」をさらに「こうしてこうする」にして…
というのを (OS なり何らかのライブラリなりの) API に達するまで繰り返す
というのを基本としたら、必然的に小さく収まるよなぁ

あー、何か俺自身感覚で分割してるような気になってきた

847 ：仕様書無しさん：2007/10/08(月) 16:47:51

>>844
すいません、今の職場、俺以外にPGいないんです。
社内間接部門で、他の人は仕様とりまとめて俺に卸してきます。コーディングは
Excel の自動生成マクロをちょっと手直しして使えるってれベルです。
プログラムは全部俺に任せるって言われてます。関数分割も含め、日々試行錯誤です。
OSSのソース読んだりして勉強してるつもりなんですが、外に出て実戦するのがいいのかなぁ。

848 ：仕様書無しさん：2007/10/08(月) 17:04:15

初心者が自己流だけでいくのは将来危険。
いろいろ回って経験積んだ人にまかせた方がいいと思う。
その経験積んだ人にまかせるのだって、ほんとは危険。
一人にやらせるってのがそもそも危険。

849 ：仕様書無しさん：2007/10/08(月) 17:21:53

プログラミングは危険。超危険。

850 ：仕様書無しさん：2007/10/08(月) 17:45:19

俺が今日作った関数500行ぐらいある。
疲れた。そして明日からももっと疲れるだろう。

851 ：仕様書無しさん：2007/10/08(月) 17:45:51

もはや釣りかネタとしか思えん

852 ：仕様書無しさん：2007/10/08(月) 18:10:51

>>801
本気でわからんので回答ください。

800 ：仕様書無しさん：2007/10/08(月) 09:40:32
>>796
見りゃわかるから、そんなコメントいらね！ってこと？
もしくは、 0 < cnt のほうが見やすいだろ！ってことか？

801 ：仕様書無しさん：2007/10/08(月) 11:29:35
>>800
そんなこともわからんのも
まずいと思う。

803 ：仕様書無しさん：2007/10/08(月) 12:16:56
>>801
や、すまん。俺も悩んだ。

853 ：仕様書無しさん：2007/10/08(月) 18:17:47

見りゃわかるからだろ
どうでもいいとこにコメント書きまくってる奴に限って
本当に必要な所にはコメントなかったりするんだよな

854 ：仕様書無しさん：2007/10/08(月) 18:22:39

たいてい関数は短くするけど
ロジック的なものじゃなくて力任せにいろいろ構成を書いていく部分のコードだと長くなる　300とか

855 ：仕様書無しさん：2007/10/08(月) 18:34:56

ライブラリとか低位レイヤの関数は短いよね？
業務レイヤになってくると分割が意味を成さないような処理もあるから
ちょっとだけ長くなるよね？　ね？(一連動作を明示する意味もある！？)

短いとか長いとか両極端に走っちゃだめだよね？　ね？

856 ：仕様書無しさん：2007/10/08(月) 18:50:47

>>855
本来、業務ロジックなんか一番短くなってしかるべき

857 ：仕様書無しさん：2007/10/08(月) 19:14:48

長い関数の中の一行を修正しなくちゃならんという時、
その一行で使われている変数が前後でどう使われているか
普通チェックするもんじゃない？
関数が短ければ追っかけなきゃならんロジックが減って
あとで楽できると思うんだが。

俺だったらhoge()っていう300行の関数作らず
100行ぐらいのhoge_a(),hoge_b(),hoge_c()を作って
それを順番に呼び出すだけのhoge()を作るなぁ。

858 ：仕様書無しさん：2007/10/08(月) 19:43:39

>>855
ログ吐く
処理1を呼び出す
結果を見てエラーがあればコードに応じて処理を書く
ログ吐く

ログ吐く
処理2を呼び出す
　・
　・
　・

みたいな感じで長くなることはあるな

859 ：仕様書無しさん：2007/10/08(月) 20:16:01

>>853
おｋ。納得した。

860 ：wolf ◆8VH3XAqjlU ：2007/10/08(月) 20:34:59

>>852

// cnt が 0 より大きかったら処理する
if (cnt > 0) {

コメントがここに書いてある６番目の心掛けなければイケナイ事
http://www.ambysoft.com/javaCodingStandards.html

6. Document why something is being done, not just what
何をしているかをコメントにするのではなく、何故そうするのかを書きなさい
に抵触はしていますね

861 ：仕様書無しさん：2007/10/08(月) 20:38:32

「他人に分からせる気はこれっぽっちもない」けど「懇切丁寧ぶったコードには見える」んだよ　ククク

862 ：仕様書無しさん：2007/10/08(月) 20:45:29

// cnt が 0 より大きかったら処理する
if (cnt > 0) {

ここの条件分岐が、実際の業務と直接リンクする場合は上のようなコメントを書くと思う。
そういうのはあり？たとえば「じいちゃんがココで死にそうだったら110番する」みたいな。

863 ：仕様書無しさん：2007/10/08(月) 20:48:57

でも0 ゼロだぞ
「○○がまだ残っている場合」とか
そういう書き方にならね

864 ：仕様書無しさん：2007/10/08(月) 20:52:58

>>862
それはありだと思う。
「（金額） cnt が 0 より大きかったら処理する」のように、cnt がもつ情報が類推できるような場合だよね。
ただし、それは他のコードやコメントと読み合わせてはじめて理解できるものじゃない？
コード例だけだと、類推のための手がかりがないから、論争になってるわけで。

865 ：仕様書無しさん：2007/10/08(月) 20:55:34

変数名がcntだから、count=「個数」であることは確か(なはず)なので、
金額は例としてはまずいな。

しかし、個数である場合に、
「あれば～」とか「残っていれば～」
などでなく本当に
「0より大なら～」
というコメントにすべき例を思いつかない。

866 ：仕様書無しさん：2007/10/08(月) 20:57:45

カウンタ絡みのテキトー変数名でcntがついても不思議じゃない

867 ：仕様書無しさん：2007/10/08(月) 20:58:05

つまり、cntが何を表すか、処理ってどんな処理か書けっって言いたいんだろう。
>>862　でいう「じいちゃん」とか「110番」って情報が抜けてる。

868 ：仕様書無しさん：2007/10/08(月) 21:01:41

// まだ在庫があれば、賞味期限を確認する
if (cnt > 0) {
　/*賞味期限確認*/
}

869 ：仕様書無しさん：2007/10/08(月) 21:20:24

// cntが0以上だったら処理する
// 19XX.X.X. レビューで修正
//if (cnt > 0 || cnt == 0) {
if (!(cnt < 0)) {

870 ：仕様書無しさん：2007/10/08(月) 21:21:05

おまいら、なんか丁寧な議論をしてて好感が持てるぞ。
要は内部的な単なる処理に自明なコメント付けるなってことだよね。

i=i+1; //iに1を加算する　みたいな。

871 ：仕様書無しさん：2007/10/08(月) 21:22:54

howじゃなくてwhatを残すんだろ
コメントの基本

872 ：仕様書無しさん：2007/10/08(月) 21:28:30

>>868
コメントを書きたくなったら変数名や関数名を考え直すんだ。

こんなかんじで。
if (zaiko > 0) {
　shoumikigen_kakunin();
}

873 ：仕様書無しさん：2007/10/08(月) 21:30:33

>>869
わろす

874 ：仕様書無しさん：2007/10/08(月) 21:39:53

>>869
レビュワーのレベルも知れるな。

875 ：仕様書無しさん：2007/10/08(月) 21:41:45

修正前の方がまだマシのような気が・・・

876 ：仕様書無しさん：2007/10/08(月) 21:43:17

指摘した人間の想定の遙か上をいくアホであったのかも

877 ：仕様書無しさん：2007/10/08(月) 21:44:09

>>869
レビュワーの主義が知りたい。

878 ：仕様書無しさん：2007/10/08(月) 21:45:30

>>869
自分は今までIFは肯定文と否定文両方必要だと思ってたけど
今いるところで、無駄な文は作るなと直された。
SQLだと否定文を書くのはNGだけど
今の規約ではJavaの方は否定文なら否定文だけ書かされる（当たり前だが）

if (!methodA()) {
// 処理
}

879 ：仕様書無しさん：2007/10/08(月) 22:11:53

ちょい上のほうで関数分割ネタがあるんだが、
今漏れが見てるソースにおもろいのがあった。
VB6ですまんが

Sub calc()
処理１
　・
　・
　処理１０
　Call calc2
End Sub

Sub calc2()
処理１１
　・
　・
　処理２０
　Call calc3
End Sub

Sub calc3()
　略

これは関数分割といっていいのか？ｗ

880 ：仕様書無しさん：2007/10/08(月) 22:43:55

>>879
分割なのかと言われると確かに分割してるなｗ

881 ：仕様書無しさん：2007/10/08(月) 22:49:44

>>879
そんな感じで分割(?)されてて、しかも連番の振り方が処理内容ではなく改修の順番だったというクソコードのメンテさせられたことがある。

882 ：仕様書無しさん：2007/10/08(月) 23:27:16

>879
calc2がcalc以外からも呼び出されるなら、まあ許せる範囲にはいるかもしれん

883 ：仕様書無しさん：2007/10/09(火) 00:26:20

ぱっと見てどれほどの量の処理なのかわかんないから、
どんどん続きの処理が出てきてウヴォアァってなるなー
メンテでそんなコード見たくないねぇ

884 ：仕様書無しさん：2007/10/09(火) 00:32:25

>>877
条件式は!と<さえあれば表現できるので、
わざわざ==や!=や>のような余計なものを使って
初心者を混乱させるべきでない
とか？

885 ：仕様書無しさん：2007/10/09(火) 00:34:16

4種類の単品マスターをセット組する処理で

単品マスターがカナとコードで検索が可能で
検索結果の並び順をカナ、コード、更新日時順で指定可能

24個のコピペ関数がKensaku1とかSearch2とかって名前で存在し、
cmdKensaku1で呼んでるのがKensaku4だった
ぐわーっとコメントアウトして書き直してしまった。

886 ：仕様書無しさん：2007/10/09(火) 00:37:26

>>885
俺、perlでそういうのに出会ったことがある。
正直あれは思い出したくない。

887 ：仕様書無しさん：2007/10/09(火) 00:51:31

あー。あるある。

888 ：仕様書無しさん：2007/10/09(火) 00:58:45

//if (cnt > 0 || cnt == 0) {

って結構見た目綺麗だよなぁ、と思ったりw
>=ってなんかキチャナイ気がするし

889 ：仕様書無しさん：2007/10/09(火) 03:30:10

左辺がもっと長かったら２回書くのは鬱陶しいよ
評価するために何らかの処理が走る場合は２回走っちゃうし（一時変数使えばいいけどやっぱ手数が増える）

890 ：879：2007/10/09(火) 05:50:29

>>880,882
一応きりのいいところできられてるっぽいが、
変数のスコープが狭くできているとかいうこともない。
calc2以下は前の関数から呼ばれることを前提に作られている。
関数分割のメリットはどこにあるのやらｗ

>>881
うっ・・・こっちのほうがまだましだったか

当時の事情はよくわかんねえんだが、たぶん、
関数の長さが長すぎるといけない、とかいうんで無理矢理ちぎった
というのがオチだろうと思います。

891 ：仕様書無しさん：2007/10/09(火) 08:48:12

case型構文があるときはどうすんの？　ちょんぎれないよね。

892 ：仕様書無しさん：2007/10/09(火) 11:22:48

ちょんぎるんじゃない、構造を見直すんだ

893 ：仕様書無しさん：2007/10/09(火) 12:14:08

case文ひとつで何百行にもなるのなら、その時点でおかしい。
ちょんぎるとかいうレベルじゃない。

894 ：仕様書無しさん：2007/10/09(火) 12:53:47

だって100とおりのcaseなら各中身が平均４行だって500行ぐらいすぐなるじゃない。
コマンドが何十種類とか。caseの数が多いこと＝設計ミスとは決めつけられないでしょ。

895 ：仕様書無しさん：2007/10/09(火) 13:01:03

決め付けはできないけど、大抵の言語でダメだよ

896 ：仕様書無しさん：2007/10/09(火) 13:03:01

>>893
つWindowsアプリのソースコード

897 ：仕様書無しさん：2007/10/09(火) 13:42:24

>>894
それはcase文ひとつで数行である、ってことでは？

898 ：仕様書無しさん：2007/10/09(火) 14:28:56

>>896
WndProc か?
LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wp, LPARAM lp) {
switch(msg) {
case WM_PAINT: return OnPaint(hWnd, wp, lp);
case WM_SIZE: return OnResize(hWnd, wp, lp);
default: return DefWndProc(hWnd, msg, wp, lp);
}
}
ってするな、俺は。
実際には WPARAM や LPARAM をそのまま渡したりはせずに
MSDNの記述に従って分割してから渡すけど。

仮に処理するウィンドウメッセージが多くて、
この case が 1000 個連なったとしても OK だろ、この場合は。

よくあるプログラミング講座みたいに case の中につらつら書くのはダメだ

899 ：仕様書無しさん：2007/10/09(火) 18:35:36

>>898
それって非常にありがちだけど、個人的にはそういう書き方は自己満足にしかなってないと思うなあ。
一度反省的に自分のそういうコードを見直してみて欲しいよ。

一箇所からしか呼ばれないコードを関数に括りだすことが本当に可読性に資するのか。
むしろ、コードを読む際にそこに飛ぶ手間を増やしているだけじゃないのか。

「caseの中につらつら書いた」コードが本当に読みにくいのか。
むしろ教条主義的にそう思い込んでるだけじゃないのか。

900 ：仕様書無しさん：2007/10/09(火) 19:00:35

抽象ってどういう意味か考えてみて欲しいね
「読まければ意味がわからない関数」は括り出す意味は無い
可読性をあげるためには、「今まさに関心のある」レイヤ以外に存在する
関数について、「読む必要性自体」を消し去る必要があるのだが

901 ：仕様書無しさん：2007/10/09(火) 19:10:34

「コードを読む際にそこに飛ぶ」のにそんなに手間がかかるのかｗ

902 ：仕様書無しさん：2007/10/09(火) 19:13:13

>>894
俺ならcaseマッチングのテーブルを挟んでループさせるな。
マッチングオブジェクトは当然処理関数への参照を持たせる。

マッチングしたら対象オブジェクトの処理を呼び出す。
C/C++なら普通に書ける関数テーブル。

処理部分はスマートになるし、定義部分ではコメント多用して
逆に分かり易く表現出来る。

VBはしらねーよw

903 ：仕様書無しさん：2007/10/09(火) 19:17:03

OOPLにおいては、
どうやって分岐するか、と分岐した先で何をやるか
は、分離しとかないと基本的にはOCP違反になる

904 ：仕様書無しさん：2007/10/09(火) 19:34:57

関係の無いメッセージに対する処理を脳内でスキップする方が
関数1個参照に行くよりよほど時間かかるよな

何のサポートもしてくれないエディタ使ってる場合はどうか知らんが

長大な関数は変数のスコープなんかで
気にしないといけないことも爆発的に増えるし

905 ：仕様書無しさん：2007/10/09(火) 20:53:01

>>902
状態遷移表の実装なんかで俺もソレ良くやるけど、
関数ポインタ(Cなんで)使うと、静的解析で処理が追い辛くなるのが難点かねぇ。

906 ：仕様書無しさん：2007/10/09(火) 21:03:31

こういうときデリゲートとかラムダ式があれば…
boost禁止だしのぅ

907 ：仕様書無しさん：2007/10/09(火) 21:11:55

>>904
分かってないね。

「関係の無いメッセージに対する処理をスキップ」する必要性は
各メッセージの処理を関数に括り出そうがなくならない。

ただエディタ上で「読み飛ばす」行数が減るだけの効果しかないんだよ。

それに、ウィンドウプロシージャのような定型的で分かりきった処理は
行数が増えてもコードの見通しは悪くならない。

実際試せば実感できると思うけど、
こういう場合はむしろ関数呼び出しによる抽象化の方がコードの不透明性を高めるから
読んでイライラする蓋然性が上昇するよ。

908 ：仕様書無しさん：2007/10/09(火) 21:23:47

>>907
わかってないのはお前だ。だまされたままで良いから周囲にあわせとけ。

909 ：仕様書無しさん：2007/10/09(火) 21:26:18

んー・・・凄い個人的な主観的な話になるけど、
caseとcaseの間がエディタの半ページ以内なら気にならない。
1つのcaseでエディタ1ページを超えると途端に読み辛くなる。

開発環境によってエディタの行数変わるんだけど
(WindowsだとVCかサクラ、Linuxだとemacsとか)、
俺は大体こんな感じ。

910 ：仕様書無しさん：2007/10/09(火) 21:33:48

>>907
ガラクタを無秩序に押入れに押し込むことを抽象化と呼ぶのなら
お前のいうとおりだろうな
関数名に連番とか振ってないだろうなｗ？

911 ：仕様書無しさん：2007/10/09(火) 21:48:45

>>910
＞ガラクタを無秩序に押入れに押し込むことを抽象化と呼ぶのなら
そんなトンデモな前提に立った議論ではない。

君とか904は、まあダメなプログラマにありがちだけど
暗黙のうちに「プログラムを書いている時点の視点」に立っている。

確かにプログラムを書いている時点に限定すれば、ほとんどの場合は
関数に括り出した方が読みやすいし、見た目にもスッキリする。
「caseの中につらつら書いた」コードなんて醜いし見難いように思われる。

ところが同じコードを一年後に読むと評価が逆転するんだなこれが。

912 ：仕様書無しさん：2007/10/09(火) 21:53:11

なにそれ、全然理由になってない

913 ：仕様書無しさん：2007/10/09(火) 21:54:05

>>910
>関数名に連番とか振ってないだろうなｗ？
関数名、変数名がすべて [A-Z]{2,3}[0-9]{5} なコードの保守ならやらされたことがある。
それはともかく、case 文の中身が10行超えたら、普通 state か command か chain of responsibility あたりを使わね？

914 ：仕様書無しさん：2007/10/09(火) 21:54:51

case 1:
{

} break;

case 2
{
って最初に作っておいたらスコープ付くしbreak強制になるから便利

915 ：仕様書無しさん：2007/10/09(火) 21:55:11

>>911
オブジェクト指向にOCPってあるんだけど、きいたことある？
いろいろ勉強して、実践して、その上でいってるのか心配になっちゃうんだけど

916 ：仕様書無しさん：2007/10/09(火) 21:58:03

デリゲートを条件に使われる定数をインデックスにして連想配列にぶちこむのは一種のストラテジーパターンらしい

917 ：仕様書無しさん：2007/10/09(火) 21:59:40

>>915
そいつのレスはムダに長いが、主張したいことは最後の1-2行だけ。
そこ見たらこれ以上そいつにかまう必要が無いことがわかる。

918 ：仕様書無しさん：2007/10/09(火) 22:11:46

>>899
> >>898
> 一箇所からしか呼ばれないコードを関数に括りだすことが本当に可読性に資するのか。

Testability

919 ：仕様書無しさん：2007/10/09(火) 22:22:07

>918
君の一言を待っていた

920 ：仕様書無しさん：2007/10/09(火) 23:55:45

( ﾟдﾟ )

921 ：仕様書無しさん：2007/10/10(水) 00:47:25

この類の話は
センスがない人にはいくら説明しても理解できないんだよね。
たぶん>>899,907,911は文系か元コボラ。

922 ：仕様書無しさん：2007/10/10(水) 01:30:46

>>921
今追いついたけど同意

923 ：仕様書無しさん：2007/10/10(水) 01:38:13

厳しいこといえば、センスとか言ってるやつもヤバイ
基本中の基本だ

924 ：仕様書無しさん：2007/10/10(水) 01:57:12

こういうやつらが消火の悪いスパゲティ作るんだろうな

925 ：仕様書無しさん：2007/10/10(水) 03:54:45

燃え盛ったときに消しにくいんだな

926 ：仕様書無しさん：2007/10/10(水) 04:32:11

負け組PGの揚げ足取り乙

927 ：仕様書無しさん：2007/10/10(水) 08:17:56

>>899
逆でしょw
武道みたいにプログラミングでもスタイルや「型」は大事だし、
それらはほとんどの場合正しいが、いつでも正しいわけじゃない。

意味を持った処理は関数に括り出して抽象化することによって読みやすくなる、
という「型」はほとんどの場合正しいが、いつでも正しいわけじゃないんだが、
自分の頭で考えられない教条主義者（＝「センス」を欠いた人間）にはそれが
判断できないし、そういう発想が頭をよぎっても抑圧してしまうんだね。

王様は裸だ、と言えないのと同じ心理的メカニズムが作用するからねw

928 ：仕様書無しさん：2007/10/10(水) 08:38:05

何が「逆」なのか、説明してくれ

929 ：仕様書無しさん：2007/10/10(水) 10:11:44

おまえら、当然ファウラーの「リファクタリング」を読んだ上で発言しているだろうな。

930 ：仕様書無しさん：2007/10/10(水) 11:43:05

>>929
教科書主義者乙

931 ：仕様書無しさん：2007/10/10(水) 12:09:26

> 教科書主義

932 ：仕様書無しさん：2007/10/10(水) 12:15:19

いくら教条主義はNGだからつって、そもそも教科書読んでねえやつは論外なわけだ

933 ：仕様書無しさん：2007/10/10(水) 15:16:54

同意

934 ：仕様書無しさん：2007/10/10(水) 21:36:24

>>927
あいかわらずムダな長文だな。自分にレスして楽しいか？

935 ：仕様書無しさん：2007/10/10(水) 23:40:23

俺には無意味な事を二度書いて、
最後に無関係なたとえ話をしている様に見える。

誰か >>927 をリファクタリングしてくれ。

936 ：仕様書無しさん：2007/10/10(水) 23:49:49

case毎の処理を関数に切り出すと読み辛くなるってのは、
caseの切り分け方がおかしい証拠に他ならんと思うのだが。

あと

>927
>意味を持った処理は関数に括り出して抽象化することによって読みやすくなる、
>という「型」はほとんどの場合正しいが、いつでも正しいわけじゃないんだが

の「正しくないケース」ってどんな時さ。
抽象化によって読み辛くなるのは、抽象化の仕方がおかしい時だけでしょ。

937 ：仕様書無しさん：2007/10/10(水) 23:50:25

>>935
#修正しておきました。

938 ：仕様書無しさん：2007/10/11(木) 00:07:05

>>937
全消しかいｗ

939 ：仕様書無しさん：2007/10/11(木) 00:39:54

>>936
>>898-を参照

940 ：仕様書無しさん：2007/10/11(木) 00:45:20

WTLのメッセージマップとか激しく便利だお

941 ：仕様書無しさん：2007/10/11(木) 19:34:57

>>936

正しくないケースを考えてみた。

1. >>927みたいな奴しかいない現場
2. 作成した関数を全て紙で管理している現場
3. 将来メンテする奴への嫌がらせ
4. リソースがカツカツ
5. そもそもサブロジックを切り出せない言語だ
6. コンパイラの限界に挑戦中

こんなもんか？

942 ：936：2007/10/12(金) 02:21:01

>941
納得してしまった。w

943 ：仕様書無しさん：2007/10/12(金) 09:24:34

>>941
>5. そもそもサブロジックを切り出せない言語だ
そうかN88-BASICだったんだ

944 ：仕様書無しさん：2007/10/12(金) 11:56:55

N88-BASICじゃ仕方ないなｗ

N88-BASICでも、変数名と戻り値代わりに使う変数名を工夫すれば
GOSUB との組み合わせで何とかなるかもしれんが
本質じゃない不毛なコードが大量生産されそうだ

945 ：仕様書無しさん：2007/10/12(金) 13:33:21

いろんな火災現場を転々としてるダメPGが言うのもなんだけど
どちらの書き方でも、どんなに拘りの秘伝のソースでもいいが
可読性の無いソースを書くのはやめて欲しい。。

>>944
BASICの頃でも、ON (式) GOSUB *Label...でサブルーチン化はしてたよ。

946 ：仕様書無しさん：2007/10/12(金) 13:59:28

>945
>可読性の無いソースを書くのはやめて欲しい。。

無理。
自分の常識は他人の非常識である場合が多い。

# だからflgで３値を返すなとあれほど･･･

947 ：仕様書無しさん：2007/10/13(土) 15:07:00

いやそもそも可読性が無ければ保守不能だし。「可読性が低い」だろ。
じゃあその可読性の水準を向上させるためにはどうすれば良いか。
という話になるけど。これは99%以上が独学だろ。
スレの上のほうに出てきた本を読んでおくのは当然。
OSSという容易に読めるコードもあるじゃないか。

948 ：仕様書無しさん：2007/10/13(土) 17:39:22

int what_length_willie( const string& name ) {
if( name.compare( str_me ) == 0 ){
return LENGTH_OF_MY_WILLIE;
}
return LENGTH_OF_YOUR_WILLIE;
}

949 ：仕様書無しさん：2007/10/13(土) 18:11:26

if(orz = 3){...}

950 ：仕様書無しさん：2007/10/13(土) 18:45:21

ﾊﾞﾛｽｗｗｗ

951 ：仕様書無しさん：2007/10/13(土) 23:45:20

よくあること。

952 ：仕様書無しさん：2007/10/14(日) 10:29:09

こそっとネタ投下。

以前の案件で、進捗が遅れているためにＵＴのお手伝いをすることに。で、ＵＴなんでソースも見てみる。
Ｃで書かれていて、１つの関数がえらい長い。まぁ、これはよくある話だと思っていたから、気にしていない。

あの、開発言語Ｃ＋＋なんですよね・・・

「クラス設計」くらいしろよグォラァ～

953 ：仕様書無しさん：2007/10/14(日) 10:33:20

C89ではコメントに//が使えないんだよぉ

954 ：仕様書無しさん：2007/10/14(日) 12:04:42

引数が全て値渡しになってた……参照渡しも知らんのかなぁ

955 ：仕様書無しさん：2007/10/14(日) 12:25:19

>>952
おもしろくない。ひとヒネリして投下しろ。

956 ：仕様書無しさん：2007/10/14(日) 12:29:01

>>952
int CWillie::what_length( const string& name ) {
　　if( name.compare( str_me ) == 0 ){
　　　　return E_LENGTH_OF_MINE;
　　}
　　return E_LENGTH_OF_YOURS;
}

957 ：仕様書無しさん：2007/10/14(日) 12:31:51

こうのがいいか

int CWillie::Length( const string& name ) const
{
　　if( name.compare( str_me ) == 0 ){
　　　　return E_LENGTH_OF_MINE;
　　}
　　return E_LENGTH_OF_YOURS;
}

958 ：仕様書無しさん：2007/10/14(日) 12:33:28

いや、こうか？

int CWillie::what_length( const string& name ) const
{
　　if( name.compare( str_me ) == 0 ){
　　　　return m_my_len;
　　}
　　return m_your_len;
}

959 ：仕様書無しさん：2007/10/14(日) 12:34:18

いや違うな、yourが入る時点でクラス設計が変か

960 ：仕様書無しさん：2007/10/14(日) 12:41:43

こうか

int CWillie::Length() const
{
　　return m_length;
}

961 ：仕様書無しさん：2007/10/14(日) 13:00:29

>>948-のコードは何が面白くてやってるの？
俺には正直サッパリ理解できん。

ウンコだチンコだ言ってれば嬉しくなっちゃう永遠の精神年齢12才ってこと？
しかし、それならこのスレとマッチしてないと思うんだけど。

962 ：仕様書無しさん：2007/10/14(日) 13:13:00

真面目にどうするのが理想か書いてただけ

963 ：仕様書無しさん：2007/10/14(日) 14:52:52

チラシの裏でやれよ

964 ：仕様書無しさん：2007/10/14(日) 18:13:55

int cal(int a, int b, int c)
{
　int d = 0;
　if (a == 1)
　　if (b < c) d = b; else d = c;
　else if (a == 2)
　　if (c > b) d = b; else d = c;
　else if (a == 3)
　　if ((b + c) % 2 == 0) d = (b + c) / 2; else d = (b + c) / 2 + 1;
　return d;
}

965 ：仕様書無しさん：2007/10/14(日) 18:19:55

int call(int a, int b, int c)
{

966 ：仕様書無しさん：2007/10/14(日) 18:25:25

int cal(int a, int b, int c)
{
　int result = 0;　　// 結果

　switch (a)
　{
　　case 1:
　　　if (b < c) result = b;
　　　else result = c;
　　break;
　　case 2:
　　　if (c > b) result = b;
　　　else result = c;
　　break;
　　case 3:
　　　// b+c が偶数の場合
　　　if ((b + c) % 2 == 0) result = (b + c) / 2;
　　　else result = (b + c) / 2 + 1;
　　break;
　}

　return result;
}

そもそもaがb,cと同列の扱いじゃなくて条件だからa,b,cなんて並べた変数名からしてイヤだよね

967 ：仕様書無しさん：2007/10/14(日) 18:51:17

?: つかえば？
それよりそのcase 1,2,3を個別の関数にしたほうが良さげだな。

968 ：仕様書無しさん：2007/10/14(日) 20:31:03

変数名の話なのか？

if (a == 1)
if (b < c) d = b; else d = c;
else if (a == 2)
if (c > b) d = b; else d = c;

処理同じやん

969 ：仕様書無しさん：2007/10/14(日) 20:43:23

>>968
そこに気付くとは…

970 ：仕様書無しさん：2007/10/14(日) 20:48:13

#define CAL_MODE_MIN 1
#define CAL_MODE_MAX 2
#define CAL_MODE_MIDDLE 3

int cal(int mode, int x, int y)
{
switch (mode)
{
case CAL_MODE_MIN:
return x < y ? x : y;
case CAL_MODE_MAX:
return x > y ? x : y;
case CAL_MODE_MIDDLE:
return (x + y) / 2 + (x + y) % 2;
default:
return ERROR;
}
}

971 ：仕様書無しさん：2007/10/14(日) 21:46:51

俺の前任者がやってたJAVAのソース。
a,b,c という3つの項目について、それぞれ4通りの分岐があったとき、
a,b,c は依存関係がなく、4通り×3項目＝計12の分岐になれば良いのに、
4×4×4＝64通りの分岐書いてやがったよ。if分のネストして良く頑張ったよね。
ゴッソリ消して書き直したけど。

972 ：仕様書無しさん：2007/10/14(日) 23:03:14

>>971
その手のやつで、項目ごとのビットフラグと独自定義の分岐番号を両方使っている
おバカ仕様のプログラムをメンテさせられたなあ。
ご丁寧に内部仕様書まであった。
項目を増やす度に作業量が指数関数的に増えていくって、どんだけ～w

8項目くらいまでは耐えたけど、16項目とかふざけた話になったので、さすがに
キレて全面改訂させてもらった。

973 ：仕様書無しさん：2007/10/15(月) 01:29:27

#define MAX_XXX_SIZE 255

typedef struct HogeHoge
{
hoge_str[MAX_XXX_SIZE];
hoge_str[MAX_XXX_SIZE];
......
} HOGEHOGE;

struct HogeHoge hoge;

//初期化
memset( (char*)&hoge.hoge_str , 0x00, MAX_XXX_SIZE);
memset( (char*)&hoge.hoge_str , 0x00, MAX_XXX_SIZE);
......

泣きたくなった。

974 ：仕様書無しさん：2007/10/15(月) 02:18:58

いや、コンパイル通らないだろ

975 ：仕様書無しさん：2007/10/15(月) 06:39:29

いや、名前の重複とかはクリヤしたとして、でしょ。
>>973は、memset( (char*)&hoge, 0, sizeof hoge ); でいいのに、とか言いたかったのかな。

976 ：仕様書無しさん：2007/10/15(月) 08:17:08

まず、構造体のメモリ領域をゼロフィルする必要があるかどうか、だな。

977 ：仕様書無しさん：2007/10/15(月) 08:52:12

hoge_str 型はどうなってんだよ？

978 ：仕様書無しさん：2007/10/15(月) 12:06:44

客より先にコンパイラに怒られるよな

979 ：仕様書無しさん：2007/10/15(月) 19:40:06

>>973はコンパイラさんだからな。

980 ：仕様書無しさん：2007/10/15(月) 19:58:24

struct HOGEHOGE {
name[MAX_NAME_LEN + 1];
ID[MAX_ID_LEN + 1];
・
　　　　・
　　　　・
}

struct HOGEHOGE hoge;

memset(&hoge, 0x00, sizeof(hoge));

ファイルに書くときとか、終端文字入れる分余分を定義したときに使う

981 ：仕様書無しさん：2007/10/15(月) 23:52:17

いや、コンパイル通らないだろ

982 ：仕様書無しさん：2007/10/16(火) 00:52:33

しーーっ

983 ：仕様書無しさん：2007/10/16(火) 01:09:01

>>980
型名がないとか、セミコロンがないとかは置いといて、、、
その [MAX_NAME_LEN + 1] って書き方は、俺の居る現場でも見る。
俺のところは　[100 + 1] ってリテラルになってるけど。。。

984 ：仕様書無しさん：2007/10/16(火) 08:41:10

>>983
名前の最大長＋１って書き方は、終端文字分ってことで、13とか書くよりは想像しやすいとは思う
あとリテラルよりは定数のがいいだろね

985 ：仕様書無しさん：2007/10/16(火) 09:12:04

次スレ立てよっか？

986 ：985：2007/10/16(火) 13:04:15

勝手に立てますた
ttp://pc11.2ch.net/test/read.cgi/prog/1192507427/
埋まったら移動ﾖﾛｽｺ