2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ぱっと見て「ヘタだなぁ」と思うコード その4

1 :仕様書無しさん:2006/07/09(日) 03:23:27
グローバル変数の話題は500以降で可

過去スレ
ぱっと見て「ヘタだなぁ」と思うコード その3
http://pc8.2ch.net/test/read.cgi/tech/1149986051/
ぱっと見て「ヘタだなぁ」と思うコード
http://pc8.2ch.net/test/read.cgi/tech/1141867015/
ぱっと見て「ヘタだなぁ」と思うコード その2
http://pc8.2ch.net/test/read.cgi/tech/1142741989/


2 :仕様書無しさん:2006/07/09(日) 07:40:52
にげと

てか500以降可って何だよw

3 :仕様書無しさん:2006/07/09(日) 08:44:44
グローバル変数の議論も定期的にやらないと理解出来ない・しようとしない奴が増えることが前スレでわかったからいいと思う。

4 :仕様書無しさん:2006/07/09(日) 11:09:21

全部のソースから読まれる大きいヘッダにグローバル宣言

変数名には g_xxx G_XXX など一目で分かる prefix をつける



5 :仕様書無しさん:2006/07/09(日) 12:07:16
>4
まだ500いってないから。
>1を百辺声に出して嫁。

6 :仕様書無しさん:2006/07/11(火) 19:29:04
hoshu

7 :仕様書無しさん:2006/07/12(水) 00:52:43
>>1が誘導もしないでいきなりマ板に移動するから閑古鳥が鳴いてんじゃん。
>>1は責任とってム板にもう一度立てなおせ。
んで、900近くまでいったらこっちに誘導してこい。

8 ::2006/07/12(水) 01:12:50
剥いたにはすれた手できなかった。
誰か後を頼む

9 :仕様書無しさん:2006/07/16(日) 21:45:19
With Hoge
  ’Hoge以外の処理
End With

氏ねって感じ。

10 :仕様書無しさん:2006/07/16(日) 22:06:19
さぁ今日も祭りだ祭りだ!
- - - - - - - - - - - - - -緊 急 招 集- - - - - - - - - - - - - - - - - - - -

          架空請求業者撲滅スレより緊急招集
     このスレに住む貴君には、栄えある勇者王になる権利がある。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    現在、下記スレにて架空請求業者撲滅の壮大な作戦が進行中
  よって、勇敢なる貴君に作戦に参加して頂きたい。これは義務ではない。
  だがしかし、貴君のキーボードとパソコン一つで世界を変えることができる。

  我 々 は 貴 君 の よ う な 勇 者 を 待 ち 望 ん で い る 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

          架空請求撲滅スレ
http://ex16.2ch.net/test/read.cgi/news4vip/1152976747/
まとめサイト(仮
http://vip2ch.com/click/index.html
                      〜我々は勇者を待ち望んでいる〜

11 :仕様書無しさん:2006/07/17(月) 09:37:46
ヘッダに変数の実体を宣言するのってイヤだなぁ。
ifdef で extern 宣言でもするの?

12 :仕様書無しさん:2006/07/17(月) 16:41:16
>>1の過去スレが3・1・2の順になっている件

13 :仕様書無しさん:2006/07/18(火) 03:04:01
一つの関数が9千行超えてる

文章にするとネタくさいが、実際に見た

14 :仕様書無しさん:2006/07/18(火) 07:37:35
>>13
どういう神経してんだw

15 :仕様書無しさん:2006/07/18(火) 09:33:50
>>13
そこまで行ったらもう「作品」だな。
ていうか、1000行超えたらもう俺は作品として認定する。


16 :仕様書無しさん:2006/07/18(火) 20:05:27
1つの関数では6千行弱までしかみたことないな。
まさか、9千行があるとはな。
1ソースなら2万5千行まであるがな。

表示とコンパイルができるVCはすごいと思った。
でも、VC6だとインテリジェンスがどうにかなって落ちたな。確かw

17 :仕様書無しさん:2006/07/19(水) 00:33:01
それを言うならインテリセンスですぅ

18 :69式フリーPG ◆hND3Lufios :2006/07/19(水) 00:58:44
>>11
だな。
ヘッダには定義のみ納めて欲しいな。

19 :仕様書無しさん:2006/07/19(水) 07:25:56
obj.fieldA.fieldB.method(obj.fieldA.fieldB.fieldC[A]);
obj.fieldA.fieldB.method(obj.fieldA.fieldB.fieldC[B]);
obj.fieldA.fieldB.method(obj.fieldA.fieldB.fieldC[C]);
obj.fieldA.fieldB.method(obj.fieldA.fieldB.fieldC[D]);
obj.fieldA.fieldB.method(obj.fieldA.fieldB.fieldC[E]);
obj.fieldA.fieldB.method(obj.fieldA.fieldB.fieldC[F]);
// 以下同文

先輩、そこはfieldBへの参照を変数に入れて使えば良いんです…
(まあそれ以前にループか何かに書き直せそうな悪寒満載だが)

20 :仕様書無しさん:2006/07/19(水) 09:15:49
君のコードねえ、上に飛んだり下に飛んだりして読みにくいんだよ。
「関数」とか言うやつ、使わないでくれる?

21 :仕様書無しさん:2006/07/19(水) 10:10:11
コボラーだ!コボラーがきたぞ!

22 :仕様書無しさん:2006/07/19(水) 11:25:04
goto 使って飛ばしまくってやる。

23 :仕様書無しさん:2006/07/19(水) 12:42:15
下手というか馬鹿なコードで

15: Private Sub func( aa as Integer )
20: Dim i As Integer
21:
22: For i = 0 to 20
23: if data[i] = aa Then
24: goto 30
25: else
26: goto 40
27: End if
28: next i
29:
30: msgbox "OK"
35: goto 50
40: msgbox "NG"
45: goto 50
50:
51: End Sub

先日ある現場で見た「俺はVBのプロフェッショナル」と言う48歳のおじさんの
書いたコード


24 :仕様書無しさん:2006/07/19(水) 13:05:35
下手とか馬鹿とか言うより、懐かしさを感じるコードだなあ。
昔々のBASICのコードを思い出す。
今のVBってこんな書き方しなくてもいいんでしょ?
VB知らないからわからないけっども。

25 :仕様書無しさん:2006/07/19(水) 13:09:25
>>23
N88BASIC!!


VBだけど

カンマ区切りのCSVデータを配列に分解するとき
Split関数を使わないプログラム

26 :仕様書無しさん:2006/07/19(水) 14:31:57
>>23
クラクラするな。


27 :23:2006/07/19(水) 14:49:25
>>25
これがBASICのソースを元に、VBに直したとかいうのならともかく
完全新規のソースだったので、クラクラというか「あれ今もしかして1989年?」とか
思ったぐらいだ。

ある会社のシステム部に一人で出向したのだが、そのプロフェッショナルおじさんは
今資料整理役になってます。

俺はBASIC風VBのソースをまともなソースに全部修正中・・・・

28 :仕様書無しさん:2006/07/19(水) 15:49:59
>23
これって、data[0]とaaの値の比較しか行われない(data[0]とaaが一致
しない場合26行でForループを抜けるので)と思うんだけど、それで動作
として、仕様通りなの?

配列要素の全てとaaを比較するのなら、25行、26行がなくて、29行目が
goto 40だと思うが?

>>23が書き直した「まともなソース」を見てみたい気がする。

29 :23:2006/07/19(水) 17:31:49
>>28
勿論仕様どおりではありませんでしたよ

だからそのプロフェッショナルさんは、現在資料整理係

30 :仕様書無しさん:2006/07/20(木) 01:27:07
char hoge[20];

/* 初期化 */
memset(hoge, NULL, sizeof(hoge));

31 :仕様書無しさん:2006/07/20(木) 10:20:33
>>30


32 :仕様書無しさん:2006/07/20(木) 10:27:43
NULLはゼロじゃねーとかそういう奴だな、うん。
実際にゼロかどうかは問題じゃなくって、概念上の使い分けができてないのが問題と。
でもってマにはこの辺粘着質的なまでにこだわる奴が多いと。

33 :仕様書無しさん:2006/07/20(木) 10:50:55
char hoge[20];

/* 初期化 */
memset(hoge, '\0', sizeof(hoge));

なら普通だと思うけどね

34 :仕様書無しさん:2006/07/20(木) 11:09:30
俺は

char hoge[20];

/* 初期化 */
memset(hoge, 0x00, sizeof(hoge));


派だな。

35 :仕様書無しさん:2006/07/20(木) 11:12:10
NHKスペシャル映像の世紀

「民族の悲劇果てなく」

36 :仕様書無しさん:2006/07/20(木) 16:22:15
おれは memset(hoge, 0, sizeof(hoge)); だなあ。

気分的にこのときに '\0' は使いたくない。
使っても同じだが、memset() だからな。
chrset() とかの関数があるなら '\0' を使うな。
同じだけど気分の問題。


37 :仕様書無しさん:2006/07/21(金) 00:41:49
ゼロ初期化したいならこう書け。

char hoge[20] = "";
int hoge[20] = {0};
struct Hoge hoge = {0};

malloc/new の時は仕方ないので許す。

38 :仕様書無しさん:2006/07/21(金) 00:44:45
newのときは必要ないんじゃね?
mallocはcalloc使うように

39 :仕様書無しさん:2006/07/21(金) 01:06:13
>char hoge[20] = "";
>int hoge[20] = {0};

それって最初の一個しかゼロは行ってなくね?

40 :仕様書無しさん:2006/07/21(金) 02:00:44
>>39
 char choge1[10]="", choge2[10];
 int ihoge1[10]={0}, ihoge2[10];
 int i;
 for(i=0; i<10; i++) {
   printf("char: %03d/%03d, int: %05d/%05d\n", choge1[i],choge2[i], ihoge1[i],ihoge2[i]);
 }

LSI C-86
char: 000/000, int: 00000/00330
char: 000/000, int: 00000/04057
char: 000/239, int: 00000/04057
char: 000/015, int: 00000/00000
char: 000/240, int: 00000/00000
char: 000/026, int: 00000/00000
char: 000/004, int: 00000/00000
char: 000/017, int: 00000/14592
char: 000/203, int: 00000/13056
char: 000/008, int: 00000/13620

41 :仕様書無しさん:2006/07/21(金) 02:03:29
むかしむかし、Windows3.1とか出始めの頃、UNIXのプログラム開発で

float InputBuffer[1000000];

こ、この配列は?
いやあ。それでも、論理的な最大値の半分くらいなんだよね
こんなでっかい配列取って大丈夫なんですか?
実機はメモリ16M積んでるんで大丈夫です
そ、そっすか

ちなみに、人がデータを手入力するためのワークエリアである


42 :仕様書無しさん:2006/07/21(金) 11:10:16
>>40
それってCの仕様だっけ。
不勉強で見た事がないんだ。

43 :仕様書無しさん:2006/07/21(金) 12:19:11
配列の初期化では、初期化の足りない要素は 0 で初期化されます。これは仕様です。

44 :仕様書無しさん:2006/07/21(金) 20:10:36
>>43
構造体は?

struct { int a, b; } x = {0};

で b が初期化される保証はあるの?


45 :仕様書無しさん:2006/07/21(金) 22:45:51
ttp://www.jisc.go.jp/app/pager?id=114709
の6.7.8に書いてある。

46 :仕様書無しさん:2006/07/22(土) 01:50:45
K&R日本語第2版だと付録A8.7(p273)辺りに詳しく書かれてます。

47 :仕様書無しさん:2006/07/22(土) 09:36:37
ほんとだ。載ってた。知らなかったーよ。ありがとう。

48 :仕様書無しさん:2006/08/12(土) 00:01:30
ここ次スレでよくね?

49 :仕様書無しさん:2006/08/12(土) 00:18:15
>>11,18
亀レスすまそ

実体ではなく定義だけ
ってどういうこと?

メンバ変数は先行宣言してポインタor参照にしろ
ってこと?

50 :仕様書無しさん:2006/08/12(土) 00:19:17
あほなコメント文

a = b + c; // bとcを足してaに代入

わかっとるんじゃい

51 :仕様書無しさん:2006/08/12(土) 00:22:37
ソースの中盤に突如現れる#define

constを知らんのか。

52 :仕様書無しさん:2006/08/12(土) 00:45:02
コメント皆無
インデント滅茶苦茶
コピペ満載
TextBox1.Text
TextBox2.Text
TextBox3.Text
TextBox4.Text
....

53 :仕様書無しさん:2006/08/12(土) 00:45:41
C++使ってると、普通にマクロが出ただけでゲって気分になりますな。
テンプレートにインライン関数、どこでも書ける定数のおかげで、
Cの悪しき慣習はほとんど根絶できてるはずだ。


なのにうちとこの会社のコードってば、なんだってこんなにマクロまみれなんだろう…
namespaceもショットガン乱れ撃ち状態だし…

もうぬるぽ。

54 :仕様書無しさん:2006/08/12(土) 12:09:07
実効処理とは全然関係無いコード
が無闇矢鱈と書き殴られているブツを解析させられたトキ

...まぢイヤガラセかと思ったYO!

55 :仕様書無しさん:2006/08/13(日) 00:13:16
>>53
ガッ

56 :仕様書無しさん:2006/08/13(日) 02:00:11
>あほなコメント文

// コンストラクタ

とかも見りゃわかるわいとは思うんだが、書かないのも不義理な気がする。
どうしよう?

57 :仕様書無しさん:2006/08/13(日) 02:02:45
可読性があがるんならいいんじゃねえか?

58 :仕様書無しさん:2006/08/13(日) 02:33:24
/*
* どう見てもコンストラクタです。
* 本当にありがとうございました。
*/

59 :仕様書無しさん:2006/08/14(月) 17:46:47
>>51続編
やはり、というか、案の定、引数付マクロとinlineが混在していた。

60 :仕様書無しさん:2006/08/14(月) 23:52:19
>59
boost見たら卒倒できるかもね。

#馬鹿と天才は紙一重

61 :仕様書無しさん:2006/08/17(木) 11:51:28
>>51
defineの有益な使い方を知らない初心者だね(^-^ll

62 :仕様書無しさん:2006/08/17(木) 23:26:40
むしろマクロは有益過ぎで困ります

63 :仕様書無しさん:2006/08/19(土) 22:53:34
メインをメインから呼び出している奴見た時眩暈がした。

void main(){
  何か処理;
  main();
  何か処理;
  main();
  return ;
}
もうね、何がしたいのかと小一時間

64 :仕様書無しさん:2006/08/19(土) 23:09:08
再帰

65 :仕様書無しさん:2006/08/20(日) 00:01:56
そんなもんは再帰とは言わんw

66 :仕様書無しさん:2006/08/20(日) 00:14:30
メモリリークとかバッファオーバーフローとか。

【適当にそれっぽい単語を羅列してみただけ】

67 :仕様書無しさん:2006/08/20(日) 09:15:20
>>63
そのコード、そもそもスタックオーバーフローで
落ちると思うんだが、書いた奴は動かしてすらいなかったのか?

68 :仕様書無しさん:2006/08/20(日) 09:41:39
>>67
気付けよ。ネタだっての

69 :仕様書無しさん:2006/08/21(月) 07:04:00
>>67
多分gotoスパゲッティじゃね?

70 :仕様書無しさん:2006/08/22(火) 02:06:05
何かの処理ん所にstatic変数をごちゃごちゃするところがあって、適当に抜けて帰ってくるんじゃね?


あほらしすぎて脱糞しそうだけど。

71 :仕様書無しさん:2006/08/23(水) 01:08:01
Cの組み込み系で

#define ADDR100 0x100
#define ADDR101 0x101
#define ADDR102 0x102
#define ADDR103 0x103
#define ADDR104 0x104
      ・
      ・
      ・



72 :仕様書無しさん:2006/08/23(水) 01:48:10
結構見るな…つか携帯ゲーム機のライブラリなんか今でもそんなだぞ。

型のサイズがゆらぐ可能性のあるenumとかを使いたくないんだろうけど、もうちっと考えろよと。

73 :仕様書無しさん:2006/08/23(水) 14:31:38
>>71
#define num_0000 (0)
#define num_0001 (1)
.
.
.
#define num_9999 (9999)

という定義があり、「数値は直接使わずコレ使ってネ」といわれ、しぶしぶ使っていた。
ある時、どうしても腑に落ちないバグが発生。有り得ないけど数値が突然狂って
動作がおかしくなったり、カウンタが一定値から増えなくなったりする。

原因

#define num_1111 (1111)
#define num_1112 (1111)
#define num_1113 (1111)

だから、訳のわからん定義使うなと・・・ orz

調べたらあちこちに誤りがあった。聞いたところ、全て手打ちだったらしい。Excelぐらい使えよと・・・・



74 :仕様書無しさん:2006/08/23(水) 15:08:57
>>73
すべて手打ちすんげー。
そんなもん、20行超えて打ち込むのなら、書き捨てでもプログラム書いて吐かせるだろうに。

75 :仕様書無しさん:2006/08/23(水) 15:22:19
それ以前に、この「ルール」の目的が謎……
まさか、定数がどこで使われてるかgrepするためか?

76 :73:2006/08/23(水) 16:05:42
>>74
それまでは数値で500以上使うことがなかったらしく、
「同じヘッダファイルを3年以上使っていて、一度も不具合が起きなかったため
 間違いがあるとは思わなかった」

・・・のように言われたよ。501以降、打ち込んだ人が疲れてたのかコピペミスか、
数値が入れ替わっている場所もあった。
もう全部作りなおしちゃるーと言ったのだが、「作り直しにより過去に動いていたものが
動かなくなったら困るので、全行調べて間違っているところを見つけて報告してくれ」と言われた。。
タブ編集後Excelにぶちこんで、数値でソートして、マクロで左辺値右辺値の異常を抽出して報告。
501以降は400以上の誤りがあったので、いちいち直しておれんーと、こっそり全て作り直した。5分程で。

>>75
他にも色々謎ルールがある現場だったよ。
そこの社員さんは「これが常識」と言い張る、他では笑い話にしかならないルールとかね。

77 :仕様書無しさん:2006/08/23(水) 17:55:11
>76
まさに、井の中の蛙エンジニアだな。他所の事情を知らない大手企業の
エンジニアに案外ありがち。


78 :仕様書無しさん:2006/08/23(水) 18:24:21
コーディングが下手以前に、規約が変なんだな。


79 :仕様書無しさん:2006/08/23(水) 19:39:44
VBだが

SendKeys

(゚д゚)

80 :仕様書無しさん:2006/08/23(水) 20:39:21
>>79


使い方次第なので、それだけでは何とも。

81 :仕様書無しさん:2006/08/23(水) 22:26:25
>>80

(゚д゚)
^^^^^^この部分がへただと思ったんあろ^^;)

82 :仕様書無しさん:2006/08/24(木) 09:59:28
>76
>そこの社員さんは「これが常識」と言い張る、他では笑い話にしかならないルールとかね。
kwsk

83 :仕様書無しさん:2006/08/24(木) 20:46:12
>>71
マクロネタか

#define BUFSZ256 256
#define BUFSZ256 512
#define BUFSZ1024 1024
#define BUFSZ2048 2048
まあ、こんなコードなんて日常茶飯事

#define OK 0
#deinfe NG 1
#deinfe ERROR -1
#define SUCCESS 0
・・・これはどう使いわけろと?

84 :仕様書無しさん:2006/08/24(木) 20:56:24
それなりに。

85 :仕様書無しさん:2006/08/24(木) 22:07:40
なんとなく。。

86 :仕様書無しさん:2006/08/25(金) 02:54:03
何が悪いと言われているんかわからない。

87 :仕様書無しさん:2006/08/25(金) 03:24:46
もう最近は上手い下手以前にマクロ見るだけで食欲が落ちるな。

88 :仕様書無しさん:2006/08/25(金) 09:01:06
return (SUCCESS + OK) * NG / ERROR * 3.14;



89 :仕様書無しさん:2006/08/25(金) 09:30:59
>>83
OKとNG逆ならまだ許してやってもいいが

90 :仕様書無しさん:2006/08/25(金) 10:24:11
>>83
前半は・・・ネタ作成時に2行目ミスったのか、2行目がネタなのかどっち?

後半は、よくある話。気分とかコメントに合わせるとかいろいろ。
同じ値の場合、文句言う香具師は結構いるが、defineは
数値だけではわかりにくいものを文字にしてわかりやすくしたり、
同一値定義のミスを減らす目的にも使われるから、その定義は間違いではない。


91 :76:2006/08/25(金) 10:30:31
>>82
kwsk書くと、身元や行っていた逝ってる会社がバレるので許せ頼むお願い

92 :仕様書無しさん:2006/08/25(金) 10:34:32
>>87
マグロなら食欲がわくけどな




ごめん、言ってみたかった。

93 :76:2006/08/25(金) 10:36:20
ひとつだけバラすと、

「VSSで1分以上チェックアウトする奴は仕事ができない奴」

と言われたことがある。その現場の常識。
VSSのチェックアウトは、ファイルをチェックインするための作業であり
チェックアウト状態を維持するのは他の人に迷惑がかかるので、
 変更⇒確認⇒チェックイン準備完了⇒チェックアウト⇒チェックイン
をスムーズにやるのが礼儀だ、といわれたよ。

じゃあ、チェックインしようと思ったときに(複数で共有している)ファイルが
更新されていた場合はどうするんですか?そのためのチェックアウトですよね?

と聞いたら、
 運が悪いと諦めて、最新を取得し、マージしてから
 コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト⇒チェックイン
こうやるのが常識だ、と言われた。

13年以上仕事し20社以上回ったが、あの会社のみの常識だった。
他の会社ではどうなるかって? 単なるネタというか休憩時間向けの笑い話だよ。


94 :仕様書無しさん:2006/08/25(金) 10:38:17
      +  +
      ∧_∧ +
  ガッ! ('(´∀` )
      人ヽ    つ
  Λ__ <  .と⌒_ノ
 (`Д´ V   ̄し' >>92

95 :仕様書無しさん:2006/08/25(金) 11:23:12
>>93
そういう連中には理屈が通じないんだねえ…

96 :仕様書無しさん:2006/08/25(金) 11:47:48
言語Java

ループごとに条件の一部がパラメータで変わるSQL文を
StringBufferで組み立てている。
ORM使えとは言わないから、PreparedStatementくらい
使ってほしい。


動かしてみたら果てしなく遅かった。

97 :仕様書無しさん:2006/08/25(金) 13:01:03
へたくそっていうかなんというか、
javaでTextUtilっていう文字列ユーティリーティを作って
もちろん全メソッドstaticにしたんだけど
わざわざTextUtil tu = new TextUtil();とインスタンス作っている
PG暦15年の人。

98 :仕様書無しさん:2006/08/25(金) 13:24:59
PGネタじゃないが、数人で同じMDBにアクセスする仕事のとき
「そのままアクセスするとロックが何とかっていうエラーが出るから」
と言って、サーバから手元にコピーして作業し、作業が完了したら
サーバにコピーし直すということをやっていた人たちがいた。
どうなったかのか知らない。

99 :76:2006/08/25(金) 13:29:36
>>98
そんな現場も見たことがあるような希ガス
>>93とは別で

で、見事にバージョンダウンとか起きまくり。どうなったか?


対策:
 このパソコン以外でMDBは編集するな。
 使いたい奴は、このパソコンから最新をフロッピーにコピーして持って行け

結果:
 そのPCの前に長蛇の列

100 :仕様書無しさん:2006/08/25(金) 13:58:09
コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒ファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒またファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒またまたファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒またまたまたファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒またまたまたまたファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒またまたまたまたまたファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒またまたまたまたまたまたファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒またまたまたまたまたまたまたファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒またまたまたまたまたまたまたまたファイルが更新されていた


 ヽ(`Д´)ノ



101 :76:2006/08/25(金) 16:12:06
>>100
それまだマシ

コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒ファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒またファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒またまたファイルが更新されていた
⇒運が悪いと諦めて、最新を取得し、マージ
⇒コンパイル⇒動作確認⇒チェックイン準備完了⇒チェックアウト
⇒完了、やったー!!
⇒「全員チェックイン終わりました」⇒よしテスト開始だ!
⇒さ〜て帰ろうかな〜〜  「76さんのバグひとつも直ってませんとの報告が」「な、なんだっt(AA略)」
⇒最新を取得⇒反映内容全部消えている・・・誰かがマージミスったらしい・・
⇒残業

・゚・(ノД`)・゚・。


102 :仕様書無しさん:2006/08/25(金) 17:42:35
1つのファイルを寄ってたかって編集するのがそもそも間違いな気が・・・
一体何の為のバージョン管理ソフト?

103 :仕様書無しさん:2006/08/25(金) 18:20:05
> 一体何の為のバージョン管理ソフト?

デグレさせた張本人を洗い出す為

104 :仕様書無しさん:2006/08/25(金) 19:15:34
ソース管理の話で盛り上がってるところをぶった切って悪いが
俺が今まで見た中での最凶はこれだな
とある上場企業に派遣されてるときに見たコードだが

void hoge()
{
struct S s1;
int dmy1[100]; // 消すな
struct S s2;
int dmy2[100]; // 消すな

何らかの処理

subhoge(&s1);
subhoge(&s2);

何らかの処理
}
void subhoge(struct S *s)
{
バッファオーバーフローな処理
}
---------------------
warning C4101: 'dmy1' : ローカル変数は 1 度も使われません。
warning C4101: 'dmy2' : ローカル変数は 1 度も使われません。
---------------------
いろいろつっこみどころ満載なプロジェクトだったが、これはびびったw。
ローカル変数のメモリ配置?最適化?なにそれ。



105 :仕様書無しさん:2006/08/25(金) 20:06:25
(特殊な環境下で)余分な変数を確保するというのは見るけどねえ・・・
ハードウェアのバグ対策らしいけど。

106 :仕様書無しさん:2006/08/25(金) 20:43:10
>>104
むうう??
命に関わるような製品じゃなければいいんだけど。

107 :仕様書無しさん:2006/08/25(金) 20:45:48
>>93
Eclipse使って会社全体でユーザ名一つのまま使ってるようなとこもある。
競合してマージ作業が必要になるのは当たり前のことだと思ってた。

108 :仕様書無しさん:2006/08/25(金) 21:54:34
If (セックスフレンド == サイバーテロリスト){
セキュリティホール = チンコ
}

109 :仕様書無しさん:2006/08/25(金) 22:33:27
うちのルールはこんなだ。
(1)チェックアウトせずソース取得 → (2)製造 → (3)単体テスト →
→ (4)チェックアウト → (5)マージ → (6)正常系のみ動作確認 → (7)チェックイン

(6)で取りこぼしたマージミスは、最悪結合テストで拾う方針。

110 :仕様書無しさん:2006/08/25(金) 22:35:23
せっかく管理ツール使ってるのにもったいないなあ。

111 :仕様書無しさん:2006/08/25(金) 22:36:14
つーかその使い方だったら使ってる意味ないよな

112 :仕様書無しさん:2006/08/25(金) 23:18:53
>>96
>ループごとに条件の一部がパラメータで変わるSQL文を
>StringBufferで組み立てている。
へぇ、どうやってやるの?
自分はオーソドックスにパラメータはPreparedStatementでやってるのしか
見たことない。

113 :仕様書無しさん:2006/08/26(土) 01:17:29
そして蛇蝎のごとく嫌われる共有チェックアウト。
なんでやねん。

114 :仕様書無しさん:2006/08/26(土) 01:47:59
別にDBアクセスなんて遅くたって使う側はこまりゃしねぇのに、
何故かDBが混雑してると画面操作のレスポンスまで遅くなるソフト
作ってる田中は普通に死んでねw

送信ボタン押したら、データが全部送れるまでスレッド作ってゆっくりやってくれりゃいいって
お客さん言ったのになんでエラーログだけ吐いて終わっちゃうように作っちゃうの?
お前、脳みそついてるのかよ?田○。お前だよ。誰がリアルタイムで反映させろつったんだよ。
無理に決まってんだろ、あのショボイ環境でそんなに早くできるわけねぇし、誰もそんなもの作れって言ってねぇよ。
○中。お前、そうやって人のいうこときかねぇから無駄な作業ばっかりしてんだぞ。
今日も田中、明日も田中、田中、田中、田中、もう今月は田中ばっかだなw

115 :仕様書無しさん:2006/08/26(土) 07:57:31
田中乙

116 :仕様書無しさん:2006/08/26(土) 10:51:20
>>114-115
板違い
http://ex13.2ch.net/heaven4vip/

117 :109:2006/08/27(日) 01:25:15
>110,111
使ってるのはVSSだからまぁ良いかと思ってたりする。

118 :仕様書無しさん:2006/08/27(日) 01:26:33
共有チェックアウトしようよ…
よほどのことが無い限り、マージでしくじる奴なんかいねーよ…

119 :仕様書無しさん:2006/08/27(日) 01:42:40
>>104
それくらいありがちだと思うオレはやばい?

y=ー( ゚д゚)・∵. ターン

120 :仕様書無しさん:2006/08/27(日) 01:54:47
119番ってあたりで消防車呼んで火消さないとイカンくらいにはやばいだろう。

121 :仕様書無しさん:2006/08/27(日) 02:11:52
>>93

> VSSのチェックアウトは、ファイルをチェックインするための作業であり
> チェックアウト状態を維持するのは他の人に迷惑がかかるので、

「共有チェックアウト?何それ?」とか言われそうだな。

122 :仕様書無しさん:2006/08/27(日) 02:17:36
VSS6.0以前の話を未だに引きずってんだもんなあ。
しかもそういう手合いは決して少なくないってのがまたなんとも。
奴らソースコードのUNICODE化とか考えたことあんのかな。

必要に迫られてVSSを一時的にでも切り捨てなきゃならなかった時期とかだって
あるはずなんだが、CVSだのSVNだのも使わないんだろうか。

謎過ぎる。

123 :仕様書無しさん:2006/08/27(日) 02:24:53
そろそろこのネタ続けたい香具師は移動しような

バージョン管理ツールの必要性 0x02
ttp://pc8.2ch.net/test/read.cgi/prog/1156073931/

124 :仕様書無しさん:2006/08/27(日) 02:51:02
はーい。
解散解散。

で、へたなコードってなんかあった?

125 :仕様書無しさん:2006/08/27(日) 16:53:37
if(hoge == true)

とか

if(hoge == TRUE)

とか、「ヘタ」というより「ヤダなぁ」と思った(;´Д`)

126 :仕様書無しさん:2006/08/27(日) 17:11:55
オレそれしばらく書いてたな
条件に比較演算子が無いのが落ち着かなくて
もちろん今は書いておりませんが

127 :仕様書無しさん:2006/08/27(日) 17:30:27
>>125
あべし「普通こう書きますよww?なんでだめなんですかww?」
カエレ

128 :仕様書無しさん:2006/08/27(日) 17:37:07
#define TRUE (1)

#define TRUE (-1)
が混在していると悲惨なことに

129 :仕様書無しさん:2006/08/27(日) 17:44:30
そもそもCでは0以外全部真だからhoge==TRUEなんて書く奴は問題外

130 :仕様書無しさん:2006/08/27(日) 17:47:50
あべし「でも==TRUEって付けたほうが解りやすくないですかww?」
シネ

131 :仕様書無しさん:2006/08/27(日) 18:22:24
え、駄目なんスか?じゃ、これからは !=FALSE にしときますね

132 :仕様書無しさん:2006/08/27(日) 18:36:34
TRUE以外の真になる値を排除したいとか?

133 :仕様書無しさん:2006/08/27(日) 19:44:34
enum BOOL
{
FALSE,
TRUE,
PURETRUE,
REALTRUE,
PEERLESSTRUE
};

とかになってんのかな。

134 :仕様書無しさん:2006/08/27(日) 22:31:28
そりゃ古いタイプのCならダメだろうけど、
今時のドトネトやJavaならいいんじゃないの?Boolで返ってくるなら。

135 :仕様書無しさん:2006/08/27(日) 22:32:41
だーかーらーbooleanに対してわざわざTRUEやFALSEと比較する理由がねーだろうがー

136 :仕様書無しさん:2006/08/27(日) 22:43:38
んなもんコンパイラで適切なもんに直してくれるんだ、
可読性高いほうがいいに決まってるだろ

== TRUE とか書かないやつって、今まであったやつの殆どが

 自己満足
 俺はデキる

って奴ばっかりだったな

137 :仕様書無しさん:2006/08/27(日) 22:49:00
>>136
おまえ初心者以下。クビ。

138 :仕様書無しさん:2006/08/27(日) 22:51:08
== TRUEと比較しておいて、その結果をTRUEと比較しないとは矛盾ではないかね?
と考えると、無限に比較しないといけなくなる。
全くの無駄。

139 :仕様書無しさん:2006/08/27(日) 23:17:43
>138
> == TRUEと比較しておいて、その結果をTRUEと比較しない
とはどういう意味ですか?
釣りでなく本気で教えてください。

140 :仕様書無しさん:2006/08/27(日) 23:21:59
(さらに、もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか)

141 :仕様書無しさん:2006/08/27(日) 23:22:20
(((XX == TRUE) == TRUE) == TRUE) 以下繰り返し

142 :仕様書無しさん:2006/08/27(日) 23:24:12
アホか。
hogeだけで条件判断できるのにわざわざそれを
hoge == TRUEと比較しなきゃいかんってことはhoge という式だけでは真か偽か判断できんと言うに等しい。
つまり
(hoge == TRUE) == TRUEと書かなければいかんということだ、そしてこう書かなければいかんということは
((hoge == TRUE) === TRUE) == TRUEと書かねばいかん事を意味する。
これが無限に続く事になるだろうが

143 :仕様書無しさん:2006/08/27(日) 23:25:37
#define TRUE 0
#define FALSE 1
こんなマクロが入っているなら==TRUEは必須でしょうな・・・


144 :仕様書無しさん:2006/08/27(日) 23:34:12
なんじゃそりゃー!

145 :139:2006/08/27(日) 23:46:02
そういう意味だったのかw

変数に入ってるブール値との比較なら
データ内容が本当にブール値か確かめる意味で
==TRUEもまぁ良いか、な気がするが

論理式の隣にTRUEは無いなーw

146 :仕様書無しさん:2006/08/27(日) 23:48:31
C言語に比較演算の結果がTRUEになるなんて仕様は無いんだが
なんの言語の話をしてるんだ?

147 :仕様書無しさん:2006/08/27(日) 23:50:10
余計なお世話だがC言語にはbooleanなどない。
しかも0だけが偽であとは全部真だ。
hoge==TRUEなどと書くのは愚の骨頂なのだ。

148 :仕様書無しさん:2006/08/28(月) 00:50:44
if(hoge == TRUE)
は好みの問題だと思ってたけど否定的に捉える人が多いんだな。
忙しいときはif(hoge)で暇なときはif(hoge == TRUE)で書いてたよ。
気をつけよう。

149 :仕様書無しさん:2006/08/28(月) 00:51:57
少なくともbooleanのないC言語で==TRUEと書くのはアホだ。

150 :仕様書無しさん:2006/08/28(月) 00:58:50
== 0 はどうでしょう?

151 :仕様書無しさん:2006/08/28(月) 01:05:47
== 0
== FALSE
== NULL

152 :仕様書無しさん:2006/08/28(月) 01:07:56
とりあえずWin32APIの定義するBOOLは1バイトの変数であって、
FALSEが0と決まっているだけでTRUEは0以外になる。
別にTRUEが1に定義されていないというわけではなく
関数の返すBOOLの値が1ではないということ
つまり

hoge = Win32APIの何か();
if(hoge == TRUE)

はバグる。マジで。

153 :仕様書無しさん:2006/08/28(月) 01:10:10
>>148
hogeにTRUEが入ると明示的に規定されてるなら、別に問題は無いけどね
C言語の論理値の仕様を考えれば避けるべき記述だし、あえてそう書く必要性も薄い

154 :仕様書無しさん:2006/08/28(月) 01:10:11
>>142
おもしろい

155 :仕様書無しさん:2006/08/28(月) 01:10:18
9.2:Isn't #defining TRUE to be 1 dangerous, since any nonzero value
is considered "true" in C? What if a built-in logical or
relational operator "returns" something other than 1?

A:It is true (sic) that any nonzero value is considered true in C,
but this applies only "on input", i.e. where a Boolean value is
expected. When a Boolean value is generated by a built-in
operator, it is guaranteed to be 1 or 0. Therefore, the test

if((a == b) == TRUE)

would work as expected (as long as TRUE is 1), but it is
obviously silly. In fact, explicit tests against TRUE and
FALSE are generally inappropriate, because some library
functions (notably isupper(), isalpha(), etc.) return,
on success, a nonzero value which is not necessarily 1.
(Besides, if you believe that "if((a == b) == TRUE)" is
an improvement over "if(a == b)", why stop there? Why not
use "if(((a == b) == TRUE) == TRUE)"?) A good rule of thumb
is to use TRUE and FALSE (or the like) only for assignment
to a Boolean variable or function parameter, or as the return
value from a Boolean function, but never in a comparison.


156 :仕様書無しさん:2006/08/28(月) 01:11:04
The preprocessor macros TRUE and FALSE (and, of course, NULL)
are used for code readability, not because the underlying values
might ever change. (See also questions 5.3 and 5.10.)

Although the use of macros like TRUE and FALSE (or YES
and NO) seems clearer, Boolean values and definitions can
be sufficiently confusing in C that some programmers feel
that TRUE and FALSE macros only compound the confusion, and
prefer to use raw 1 and 0 instead. (See also question 5.9.)

References: K&R1 Sec. 2.6 p. 39, Sec. 2.7 p. 41; K&R2 Sec. 2.6
p. 42, Sec. 2.7 p. 44, Sec. A7.4.7 p. 204, Sec. A7.9 p. 206; ISO
Sec. 6.3.3.3, Sec. 6.3.8, Sec. 6.3.9, Sec. 6.3.13, Sec. 6.3.14,
Sec. 6.3.15, Sec. 6.6.4.1, Sec. 6.6.5; H&S Sec. 7.5.4 pp. 196-7,
Sec. 7.6.4 pp. 207-8, Sec. 7.6.5 pp. 208-9, Sec. 7.7 pp. 217-8,
Sec. 7.8 pp. 218-9, Sec. 8.5 pp. 238-9, Sec. 8.6 pp. 241-4;
"What the Tortoise Said to Achilles".


157 :仕様書無しさん:2006/08/28(月) 01:16:10
つか、マジでWin32APIのBOOLは8とか10とか32450とか普通に返ってくるから気をつけろよ。

return (BOOL)size;

ってやっても0以外を1にしてくれるわけじゃないし、C言語的にもあってる。
C++のboolは ture falseが1 0って決まってた気がするけど。

158 :仕様書無しさん:2006/08/28(月) 01:17:08
この原文厨が!
貼り付ければいいってもんじゃないぞバカモン!!

159 :仕様書無しさん:2006/08/28(月) 01:17:27
間違えたw
32450じゃなくて32とか4とか50な。

160 :仕様書無しさん:2006/08/28(月) 01:28:39
黙ってコンパイラ様の言いなりになっとけば、間抜けコードの半分は殺せるよなあ。

161 :仕様書無しさん:2006/08/28(月) 02:05:31
俺は頭にIsが付いてない限りは != FALSE付けるようにしてるけどな。
if (IsHoge) {
if (hoge != FALSE){


162 :仕様書無しさん:2006/08/28(月) 02:30:22
>>142
アホか。
セミコロンだけで文できるのにわざわざそれを
セミコロン、改行しなきゃいかんってことはセミコロンだけでは文か判断できんと言うに等しい。
つまり
セミコロン、改行、改行と書かなければいかんということだ、そしてこう書かなければいかんということは
セミコロン、改行、改行、改行と書かねばいかん事を意味する。
これが無限に続く事になるだろうが


163 :仕様書無しさん:2006/08/28(月) 02:55:48
>>150,151,161
0(FALSE)と比較することは問題ない。
TRUEと比較する場合とは違って、同じ結果をもたらす。
if(hoge) は if(hoge != 0) と同義だ。従って if(hoge != FALSE) とも同義だ。

>>136
> んなもんコンパイラで適切なもんに直してくれるんだ、
> 可読性高いほうがいいに決まってるだろ


試しにコンパイルしてバイナリを比較してごらん。
3 は1,2 と同じバイナリには絶対ならないから。

 1. if(hoge)
 2. if(hoge != FALSE)
 3. if(hoge == TRUE)

164 :仕様書無しさん:2006/08/28(月) 03:28:40
>>136を普通に

== TRUE とか書くやつって、今まであったやつの殆どが

と読み違えてた。
いま見て目を疑った。

いや、あのほら。ネタだよね?
ね?
ね?

165 :仕様書無しさん:2006/08/28(月) 05:42:41
ぱっと見るまでもなくゴミスレ

166 :仕様書無しさん:2006/08/28(月) 05:54:43
FALSEとの比較も不要だ。
偽の場合の条件なら

if(!hoge) {...}

で充分。

167 :仕様書無しさん:2006/08/28(月) 06:00:40
while(*t++ = *s++);

どこにTRUEだのFALSEだの入れる?

168 :仕様書無しさん:2006/08/28(月) 06:15:47
ifやその他の条件式は0と非0の区別しかない。
FALSEもTRUEも代入の時にのみ使用する。
そんだけだアホどもが。

169 :仕様書無しさん:2006/08/28(月) 06:43:44
while( (*t++ = *s++) == TRUE )

これだから子供は・・・

170 :仕様書無しさん:2006/08/28(月) 06:47:15
>>169
いやおまえ、ほら、その、なんだ。
そもそもぱっと見て評価順依存って時点でネタコードだって気づけよ。
ていうか、頭沸いてるだろお前?
普通なら>>168でFAだと思うんだが…

171 :仕様書無しさん:2006/08/28(月) 06:50:51
while( (*t++ = *s++) != FALSE )

TRUEと比較するなとあれほど

172 :仕様書無しさん:2006/08/28(月) 06:54:06
ブーリアンとの比較以前に、>>167は普通ヘタコードだよな
美しいとか思う奴もいるのかも知れないが

173 :仕様書無しさん:2006/08/28(月) 07:05:45
>>168
C FAQ に書いてあるな。
TRUE,FALSEは代入値、引数、戻り値にのみ使用しろ。
比較には決して使うな、と。

A good rule of thumb is to use TRUE and FALSE (or the like) only for
assignment to a Boolean variable
or function parameter,
or as the return value from a Boolean function,
but never in a comparison.


174 :仕様書無しさん:2006/08/28(月) 07:10:13
>>135
でもあべしは書いた方がみやすいって言ってるんでしょ?・・・@
で、それに対してCならダメダメだって話でしょ?・・・A
で、それに対してJavaならいいんじゃない?って話なわけじゃん?・・・B
で、>>136が書く必要ないって言ってるんでしょ?・・・C
書く必要ないけど@の言い分を満たすならBならOKじゃない?Cである必要はないと思う。

175 :仕様書無しさん:2006/08/28(月) 07:36:58
>>157
なるほろ…そういうもんか
あんまりAPIとか弄らんし普段は別言語で
C弄るのプラグインぐらいだから今度から気ィ付ける

176 :仕様書無しさん:2006/08/28(月) 11:15:00
>>170
メール欄見て、トイレで泣こう!

177 :仕様書無しさん:2006/08/28(月) 11:17:14
>>174
あべしを出している時点で、全ての常識が通じないことを考慮しる。


過去に出会ったあべしのPGの7割が、ポインタを理解してなかったなぁ。
 「え、だってコンパイル通りましたよ」
とか、動かした瞬間即落ちするんじゃこのボケ!

178 :仕様書無しさん:2006/08/28(月) 12:12:09
酷いスレだがマ板でやっていることに一筋の良心を感じた

179 :仕様書無しさん:2006/08/28(月) 12:48:34
#define TRUE 1
#define FALSE (-1)

180 :仕様書無しさん:2006/08/28(月) 13:17:06
次は、半端に「真は非0、偽は0」だけ知ってる香具師が、
&&や||の結果の利用について云々すると見た。

181 :仕様書無しさん:2006/08/28(月) 19:16:39
#define TRUE (!FALSE)
#define FALSE (!TRUE)

182 :仕様書無しさん:2006/08/28(月) 20:19:47
>>167はコンパイルエラーに100万ペソ。

183 :仕様書無しさん:2006/08/28(月) 20:36:32
>>182はあべし並

184 :仕様書無しさん:2006/08/28(月) 22:36:01
warningは2箇所出るな

185 :高卒アニオタ中年:2006/08/28(月) 23:26:57
>>171
 せっかくだから、
  while( (*t++ = *s++) != '\0' );
 とか書いてもらえないだろうか。


186 :仕様書無しさん:2006/08/28(月) 23:52:18
つまらん

187 :仕様書無しさん:2006/08/28(月) 23:56:54
  while( (*t++ = *s++) != NULL);
 なんてどうよ。

188 :長きにわたる宗教戦争に今終止符が!:2006/08/29(火) 00:02:19
#define IS_TRUE(exp) ((exp)!=0)
#define IS_FALSE(exp) ((exp)==0)
#define SET_TRUE(exp) (exp=1)
#define SET_FALSE(exp) (exp=0)

189 :仕様書無しさん:2006/08/29(火) 00:19:01
天才現る。

190 :仕様書無しさん:2006/08/29(火) 00:24:28
しかし、typedefで地獄行く!(細木風)

191 :仕様書無しさん:2006/08/29(火) 01:00:51
>>185-187
言語的には185が一番自然なんだが
つか、'\0'と0を厳密に区別する香具師って絶滅したんじゃw

192 :仕様書無しさん:2006/08/29(火) 02:22:47
>>191
t と s が char* だなんて誰も言ってないと思うが

193 :仕様書無しさん:2006/08/29(火) 07:49:43
ぱっと見て誰もがstrcpyのコードという前提で話しているのに一人突っ込む空気を読めてないなぁと思うレス

194 :仕様書無しさん:2006/08/29(火) 08:57:36
ろくにK&Rも読んでない素人が釣れましたなw

195 :仕様書無しさん:2006/08/29(火) 10:35:39
>185
流れ的には
  while (((*t++ = *s++) != '\0')==TRUE);
だろ

196 :仕様書無しさん:2006/08/29(火) 11:05:25
>>191
>'\0'と0を厳密に区別する香具師って
ノシ

197 :仕様書無しさん:2006/08/29(火) 12:42:23
(*t++ = *s++)
   ↑↑

(((’-’*)))) ウズウズ

198 :仕様書無しさん:2006/08/29(火) 12:48:28
どうした>>197

199 :仕様書無しさん:2006/08/29(火) 13:31:02
>>198
>>197もK&R読んでないんだろうな。

200 :仕様書無しさん:2006/08/29(火) 15:50:25
>>197
代入したのがTRUEかどうかって話をしてると解釈したが違うのか?

201 :仕様書無しさん:2006/08/29(火) 16:24:30
漢なら whlie (*t++ = *s++) {...}


202 :仕様書無しさん:2006/08/29(火) 19:10:18
流れをぶった切って悪いが

Hoge* pHoge = new Hoge;
if(!pHoge) ...

とかいうのはどうなのよ?
ちなみに俺は

if(pHoge == NULL) ...

と書くのがイイ!と思ってるんだが

203 :仕様書無しさん:2006/08/29(火) 20:16:10
>>202
例外使おうぜ。

204 :仕様書無しさん:2006/08/29(火) 21:24:43
↑ヘタクソ

205 :仕様書無しさん:2006/08/29(火) 21:36:13
コンストラクタが例外を投げるのはどうかねぇ

206 :仕様書無しさん:2006/08/29(火) 22:01:29
コンストラクタから例外を投げて、問題が出るから、回避するのはへたくそ。

207 :仕様書無しさん:2006/08/29(火) 22:03:56
>>193
思い込みでバグを量産してそうだなw

208 :仕様書無しさん:2006/08/29(火) 22:12:15
釣り禁止

209 :仕様書無しさん:2006/08/29(火) 23:26:52
>>205
時代遅れ

210 :196:2006/08/29(火) 23:29:18
>>202
俺も流石に C++ で NULL 使おうとは思わん。

211 :仕様書無しさん:2006/08/30(水) 00:28:37
>>205-206
いや、>>202の話題ではメモリ不足でコンストラクタ動いてないだろ

212 :仕様書無しさん:2006/08/30(水) 01:34:10
NULLがゼロで確定したのっていつの話だったっけ。
俺ももうNULLなんて全然使ってないよ。

void* p = 0;

....

if(!p)
{
// do anything.
}

って感じだ。

213 :仕様書無しさん:2006/08/30(水) 09:15:11
>>212
というかC言語はポインタに 0 を代入したら該当する値に変換してから
入れるということになっているが、大半の実装ではそのまま 0 を入れて
いる、ということだな。


214 :仕様書無しさん:2006/08/30(水) 09:21:48
>>212
NULLは最初から0番地のアドレス。
ポインタ変数には整定数の0だけは代入できて、それがNULLである。

215 :仕様書無しさん:2006/08/30(水) 10:31:17
整数ゼロをポインタに変換するとNULLが意味する値になるだけで、
それがアドレス0番地とは限らないだろ。

216 :仕様書無しさん:2006/08/30(水) 10:37:11
続きまして、

mallocした領域は必ずfreeするべきか?

をお送りします。

217 :仕様書無しさん:2006/08/30(水) 10:56:25
>>216
スレ違い

218 :仕様書無しさん:2006/08/30(水) 11:02:25
じゃぁ

fopenしたファイルは必ずfcloseするべきか?

ってのは?

219 :仕様書無しさん:2006/08/30(水) 11:14:52
空気読めない香具師が居る件について。に変更で。

220 :仕様書無しさん:2006/08/30(水) 11:19:46
空気読めないのは許すが、K&R読めない奴は許せん。

221 :仕様書無しさん:2006/08/30(水) 11:30:29
てかそれぞれ脳内文脈で好き勝手に書き散らしていて全然かみ合っていない件

222 :仕様書無しさん:2006/08/30(水) 11:32:30
>>216
>>218
お前が実際にあったヘタなコードを挙げれば、そこから話題が広がるかもしれないな。
でもここはアンケートをとる場所じゃないってことぐらい、わかるだろ?


223 :仕様書無しさん:2006/08/30(水) 17:54:09
今更だが>>83
#define BUFSZ256 256
#define BUFSZ256 512

224 :仕様書無しさん:2006/08/31(木) 01:34:03
>>220
こう言っちゃ何だが、K&Rもいい加減古すぎて今更なあって気もするぞ。
読みやすい本でも無いしな。
原典だ聖典だと持ち上げる奴はいくらでもいるが、改行スタイルまで右に倣えする必要もないだろうし。
つーかきょうびC自体が以下省略。
今から人に薦めるなら、まだプログラミング言語C++とかの方にするなー。

225 :仕様書無しさん:2006/08/31(木) 06:30:55
このスレちょっと読み返してみるだけでK&R読めない奴らがいっぱいだな。

226 :仕様書無しさん:2006/08/31(木) 10:40:12
くにお & りき ????

227 :仕様書無しさん:2006/08/31(木) 13:24:15
FFの開腹魔法

228 :仕様書無しさん:2006/08/31(木) 17:10:49
>>227
なんて強力な攻撃魔法

229 :仕様書無しさん:2006/08/31(木) 17:21:34
呪文名は「ストマク」だろうか

230 :仕様書無しさん:2006/08/31(木) 18:54:02
クエイクとの合成魔法で、ストマックエイク!!!

231 :仕様書無しさん:2006/08/31(木) 19:00:10
Javaにて。
boolean b;
・・・
if (b == true) {

232 :仕様書無しさん:2006/08/31(木) 19:55:40
芸術だな

233 :仕様書無しさん:2006/08/31(木) 21:35:13
いったい何行あるんだ?なにがあったんだ?

234 :仕様書無しさん:2006/09/01(金) 08:54:15
>230
お腹急降下しそう

235 :仕様書無しさん:2006/09/01(金) 19:22:34
boolean b;
...
if( b != false && true == b ) {
俺ならこう書くぜ







・・・

236 :仕様書無しさん:2006/09/01(金) 19:24:02
好きにしろ

237 :仕様書無しさん:2006/09/01(金) 19:33:15
if ( (...(b == true) == true) == true) == ...) と書かないとだめだよな。

238 :仕様書無しさん:2006/09/01(金) 19:35:23
そうめんつるつる

239 :仕様書無しさん:2006/09/01(金) 20:53:16
boolean isTrue( boolean b ) {
  return isTrue( b == true );
}

240 :仕様書無しさん:2006/09/01(金) 21:47:57
if (isTrue(hoge == true) == true){
...
}


241 :仕様書無しさん:2006/09/01(金) 21:49:24
>>212
NULLがただの0になったのはC++から。
それまでは適当だったり((void*)0)だったりしたような。

ちなみに、おれはNULLは使う派。ポインタのところに0と書く人の気が知れない。

242 :仕様書無しさん:2006/09/01(金) 21:52:29
まったく、K&Rすら誤読してる奴らが多いな
ポインタが取れる値はゼロかなにかのオブジェクトの値に限定されていて、
ゼロのアドレスは有効なオブジェクトのアドレスとは一致しないことは確定してた。
結局、NULLは単なるゼロ番地だったってことだ。
だからifの条件部では常に条件の不成立として使って問題ない。

243 :仕様書無しさん:2006/09/01(金) 22:37:42
まあ、例え問題あるっていう奴がいたとしても俺は

if(!pUnko)

なんだけどなw
だって、初期化が

memset(pUnko,0,sizeof(UNKO));

だしw

244 :仕様書無しさん:2006/09/02(土) 01:37:12
>>241
ごめん、俺もうC++しか使ってないんだ。
NULLを0で書くのも、C++のスタイルに合わせただけ。
生Cにはもはや戻れんし、戻らんだろうから、気にしてない。

245 :仕様書無しさん:2006/09/02(土) 01:40:42
俺も

if(!pChinko)

だが、続く

memset(pUnko,0,sizeof(UNKO));

の意味がわからん。
何を主張したいんだ?

246 :仕様書無しさん:2006/09/02(土) 01:45:05
お子ちゃまなだけでそ

247 :仕様書無しさん:2006/09/02(土) 01:49:38
ちんことかうんことか大好きだよね、お子ちゃまは…
俺も大好きなんだけどさ。

248 :仕様書無しさん:2006/09/02(土) 01:57:02
俺たちが作るものなんてみんなウンコだ、それを持ち運んだり
磨いたり、トグロの巻き方を考えたりしてるだけだ。

249 :仕様書無しさん:2006/09/02(土) 02:08:14
でもマンコは見たこと無い奴が多すぎる罠。

250 :仕様書無しさん:2006/09/02(土) 06:12:02
淫ターネットのおかげでマンコ飽きるほど見ました

251 :仕様書無しさん:2006/09/02(土) 08:35:33
>>245
構造体の中にもポインタがあり、その初期化と長年の経験から予想。

252 :仕様書無しさん:2006/09/02(土) 21:33:28
>>242
>結局、NULLは単なるゼロ番地だったってことだ。
NULLは0だが、それがCPUアドレスの「ゼロ番地」だとは言ってなかったはずだ。
そのあたりは処理系依存だろ。

253 :仕様書無しさん:2006/09/02(土) 22:04:41
K&R読み直してこい

254 :仕様書無しさん:2006/09/03(日) 03:07:17
K&Rだとゼロ番地って書いてあるが、
http://www.kouno.jp/home/c_faq/c5.html
だとゼロは単なる予約定数だな。

ポインタへのゼロ代入の解釈はコンパイラがやるため、コンパイラが理解できるキャストじゃないと
誤動作を生じる可能性がある、ということなのか。
たとえばポインタ自体ををmemsetとかでゼロクリアした場合、クリアされたポインタが
ぬるぽになるとは限らない、という理屈の様に思える。

C++はこの辺が整理されてぬるぽ=概念上はゼロから、実値としてもゼロになったってことなのか?
教えて、モヒカンの人。

255 :仕様書無しさん:2006/09/03(日) 03:14:38
 /||  <だガッ断る
( ゚Д゚)<流石モヒ毛様ぬるぽだけは見逃しませんね

256 :仕様書無しさん:2006/09/03(日) 05:26:58
>>253
K&Rは規格ではない。今となっては古文書だとさえ言える。
鵜呑みにしてえらそうに言わないようにな。

257 :仕様書無しさん:2006/09/03(日) 09:49:37
ここでいうK&Rとは初版のことなのか、ANSIのハンコがついてるほうなのか。
両方?

258 :仕様書無しさん:2006/09/03(日) 15:11:19
いくらなんでも初版のわけないだろ

259 :仕様書無しさん:2006/09/03(日) 20:02:28
最近みた馬鹿コード
マルチスレッドで、
while (flg) {

260 :仕様書無しさん:2006/09/03(日) 20:44:59
>>259
でも中に

PeekMessage
TranslateMessage
DispatchMessage

が入ってたら、また、違う結果なんでしょ?
それだけじゃ吊るし上げとして十分じゃない。よってお前も馬鹿。

261 :仕様書無しさん:2006/09/03(日) 21:22:20
ぱっと見下手な煽りだなあ。

262 :仕様書無しさん:2006/09/03(日) 21:27:43
つーか制御系なら頻出とまで言わんでもよくあるロジックだしな

263 :仕様書無しさん:2006/09/03(日) 23:28:39
>>259
つか、何が問題?
変数名が馬鹿まるだしってんならわかるが、マルチスレッドがどうした?

264 :仕様書無しさん:2006/09/04(月) 01:45:25
スレッドの同期にむき出しのboolean使ってるとか、そーいう話と違うのか?
実際に問題になったのを見たことは無いが、噛み付く奴は多そうだな。

265 :仕様書無しさん:2006/09/04(月) 08:12:05
マルチプロセスでグローバル変数書き換えている馬鹿コード見たことはあるけどな
マルチプロセスのプロセス内条件判定で、どっちのプロセスからもいじれる
グローバル変数を使うなよと・・・

266 :仕様書無しさん:2006/09/04(月) 09:12:48
>>265
どうでもいいが、おまいプロセスとスレッドの区別付いてるか?


267 :仕様書無しさん:2006/09/04(月) 11:02:23
>265
ぱっと見なくても「ヘタだなぁ」と思うコードの作成者ですか?

268 :265:2006/09/04(月) 12:05:10
4時間で二人しか釣れなくて残念でした

269 :仕様書無しさん:2006/09/04(月) 12:20:23
釣りもヘタなんだな

270 :仕様書無しさん:2006/09/04(月) 12:35:22
つられた人が必死になってるね

271 :仕様書無しさん:2006/09/04(月) 12:46:51
ちょっと笑えんなそのレスは
哀れ

272 :仕様書無しさん:2006/09/04(月) 22:31:16
>>259
用途によってはそういうコードも書く。
前提条件なく言われても「それで?」としか思えない。
下手と思う理由が欲しいとこではあるな。

273 :仕様書無しさん:2006/09/05(火) 08:22:45
コードは一見ヘタげだが、バグ少ない&作りもよく理解してる
人ってちょくちょくいるよな。

上手げだけど強烈なバグを出す人もいるし、世の中不思議が多いぜ。

274 :仕様書無しさん:2006/09/05(火) 11:49:02
int cunt = 0;とかあった・・・orz

275 :仕様書無しさん:2006/09/05(火) 11:57:06
>>274
cuntって、意味わかって書いたのかな?
http://dic.yahoo.co.jp/dsearch?enc=UTF-8&p=cunt&dtype=1&dname=1na&stype=0&pagenum=1&index=01798300

276 :仕様書無しさん:2006/09/05(火) 13:54:01
これはひどい

277 :仕様書無しさん:2006/09/05(火) 14:23:56
int a;
a=a;

・・・何がしたいんだろうか?

278 :仕様書無しさん:2006/09/05(火) 15:46:47
デバッグ用のコード(Breakpoint用)が残っているとか。



・・・「ヘタだなぁ」コードから、「ボクの解析できなかった、私の理解できなかったコード」の
スレに変わりつつあるようだな

279 :仕様書無しさん:2006/09/05(火) 19:41:33
>>273
MBAもってる奴が優秀な経営者になるわけじゃない。
文芸評論家が作家のような小説を書けるわけでもない。

そういうことだ。

280 :仕様書無しさん:2006/09/05(火) 21:25:59
「上手い」と思われそうなテクニックや記述を頭でっかちに吸収してるだけの奴も多い。

以前一緒に仕事した某ソフトハウスなんかその典型だった。
ドキュメントも綺麗だし、ソースも立派、でもバグまみれ。

281 :仕様書無しさん:2006/09/05(火) 21:43:34
>>275
お前ばかか。そこがネタなんだろが。

282 :仕様書無しさん:2006/09/06(水) 10:22:48
>>275
お前ばかだろ。

283 :仕様書無しさん:2006/09/06(水) 13:42:54
>282
てへ

284 :仕様書無しさん:2006/09/08(金) 01:25:34
まあ、NULLというのは0の定数みたいなものだからな。

285 :仕様書無しさん:2006/09/08(金) 02:26:50
つまりこういうことなんだが、

static const int NULL = 0;
int ZERO = 0;

void* p = reinterpret_cast<void*>(0); // ぬるぽ
void* p = reinterpret_cast<void*>(NULL); // ぬるぽ
void* p = reinterpret_cast<void*>(ZERO); // ぬるぽくさいけどぬるぽじゃないかもしれない

あまり理解されてない傾向。
したところでどうってネタでもないが。

286 :仕様書無しさん:2006/09/08(金) 12:55:33
      ∧_∧
── =≡( ・∀・)  ≡    ガッ     ∧jio∧
─ =≡○_   ⊂)_=_  \ 从/-=≡ r(    )
── =≡ >   __ ノ ))<   >  -= 〉#  つ
─ =≡  ( / ≡    /VV\-=≡⊂ 、  ノ  ←>>285
── .=≡( ノ =≡           -=  し'
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|
                  | 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
                  |      仕  様  変  更


287 :仕様書無しさん:2006/09/08(金) 13:21:23
//$sql = "select username from usertable where userno = $no";
$sql = "select username from usertable where userno = $no";

どうした?何があったんだ?

288 :仕様書無しさん:2006/09/08(金) 18:18:22
下の行の説明じゃね?

289 :仕様書無しさん:2006/09/08(金) 18:20:18
>>287
コメントぐらい大目に見ろよ

それぐらいで慌てていたら、

「動いたら奇跡」「動いてはいるけど、将来必ず大変な目にあうので直すこと 1991.12」とか
読めないぞ

290 :仕様書無しさん:2006/09/09(土) 06:08:10
>>287
変更しようとしてコピッタものの忘れててそのままチェックインしたのではないかと

291 :仕様書無しさん:2006/09/09(土) 10:05:54
>290
おまえ,マジレスて・・・w

292 :仕様書無しさん:2006/09/09(土) 12:26:00
>>289
>動いてはいるけど、将来必ず大変な目にあうので直すこと
そのコメント、俺も時々やらかすわorz

293 :仕様書無しさん:2006/09/09(土) 15:46:56
>>289
○○年問題に対応してませんみたいなのはOK?

294 :仕様書無しさん:2006/09/09(土) 18:53:22
//華麗にスルー

295 :仕様書無しさん:2006/09/09(土) 23:43:15
全体的に統一感が無いのがイヤだ

Hoge* pHoge / Hoge *pHoge
とか
if文等の中括弧の位置
とか
インデント
とか
コメントの書き方/位置
とか...

きっと他の事に関しても
ダブルスタンダードなんだろうなぁ
と感じてしまう

296 :仕様書無しさん:2006/09/10(日) 00:12:02
>295
滅茶苦茶な使い方は嫌だが、使い分けならする。

例えば2項演算子の両端は、俺の場合基本的に
==はつけて、それ以外は離す。(==でつけるのは=と区別したいが為)
但し長い式の場合は結合度が高い物はつけて、低い物は離す。

…インデントの統一感って2タブか4タブか8タブかって事か?
後でブロック一段追加した時に面倒だからそのまま、ってのは
たまにやるがそういうこと?

297 :仕様書無しさん:2006/09/10(日) 01:53:40
離して書けよここ
誰だくっつけて書いた奴


俺か。


298 :仕様書無しさん:2006/09/10(日) 02:14:52
>==はつけて、それ以外は離す。(==でつけるのは=と区別したいが為)

そこまで明確に理由付けて使い分けたことねぇなあ。
感覚的にがーっときてばーっとなってアッー!ってなもんだ。
見直してみたら結構揺らいでるのかも知れん。
反省したもんだか、どうしたもんだか。

299 :仕様書無しさん:2006/09/10(日) 02:35:30
>>298
>>==
>=の書き間違いかと思った。ちゃんと>使えや。

300 :仕様書無しさん:2006/09/10(日) 04:10:46
>>299
書いた後で俺も思った。
が、そんなコンパイラみたいにかっちりしないでもいいやんか。
へらへら。

301 :仕様書無しさん:2006/09/10(日) 04:23:36
>>295
つまるところ「ヘタだなぁ」と感じるの?それ。

俺はあんまり細かいこと言う奴を見ると「使えなさそうな奴だなぁ」と感じる。

302 :仕様書無しさん:2006/09/10(日) 04:37:59
あんまり揺らぎが酷いと、書いた奴の思考論理そのものが疑わしく思えることは
無いではないかな。

303 :仕様書無しさん:2006/09/10(日) 04:45:03
>>301
プログラマなのに細かいところに注意が向かないやつは
頼むからプログラムを書かないでくれ。バグのもとだ。

304 :仕様書無しさん:2006/09/10(日) 04:48:52
他人のコード読んでてもあんま >>295 の言ってるようなことは気にならんけどなあ

305 :仕様書無しさん:2006/09/10(日) 04:49:03
そうだ!俺の書いた清潔なコードを汚さないでくれ!
つまらないことでトラブル起こして、俺の仕事の邪魔をしないでくれ!


糞でも食らってろって感じだな。

306 :仕様書無しさん:2006/09/10(日) 04:51:12
昔からあって複数人が編集したソースも多い。
そのへんの統一感は求めるだけ無駄。

307 :仕様書無しさん:2006/09/10(日) 04:51:35
確かにスペースを空けるくらいはしてほしかった。
だが、「>」の使用を勧めるのはどうかと思う。

308 :仕様書無しさん:2006/09/10(日) 04:56:42
どうでもいいが、んな時間に結構レス数が増えてて驚いた。

309 :仕様書無しさん:2006/09/10(日) 04:58:47
だが俺とお前しかいないというオチ。
勿論目的は尻の穴。

310 :仕様書無しさん:2006/09/10(日) 05:00:11
checkstyleがウルセー、
漏れのコード、真黄黄

へたなんだろうか?

311 :仕様書無しさん:2006/09/10(日) 05:05:21
>>309
大丈夫だ、俺もいる。

312 :仕様書無しさん:2006/09/10(日) 08:59:48
ところでみんなVCの警告レベルっていくつで組んでる?
俺、警告レベル4の警告ってあんまり取る意味感じ無いんだ。

313 :仕様書無しさん:2006/09/10(日) 09:56:33
>312
趣味でやってるならいいんでない?

仕事でそう思うなら去れ!

314 :仕様書無しさん:2006/09/10(日) 10:03:21
>>313
てか、VCのソースからいって警告レベル4は相手にしてねぇじゃんw
標準テンプレートライブラリからもボロボロ出るんだけど?

315 :仕様書無しさん:2006/09/10(日) 10:04:33
マジックナンバー使いまくりのプログラム
何のためにその値と比較してるのか書けよ

316 :仕様書無しさん:2006/09/10(日) 10:15:52
>>297
ちゃんと離せよ!
可読性って言葉知らんのか?

if(a==b){c();ab(a);b!=2?d(b):ab(d);while(d!=a){e(d)}

こんな感じで、普通なら数行に渡っているはずのコードが横に最大250バイトずつ
書かれているソースを見たことがある
main()のみでそれが200行


317 :仕様書無しさん:2006/09/10(日) 10:26:38
>>316
それ、キチガイが書いたんじゃね?

318 :316:2006/09/10(日) 10:55:58
自称「少ない行数で多機能なプログラムを書けるイカした俺」な、ある会社のあべし。


319 :仕様書無しさん:2006/09/10(日) 11:20:06
コードをたくさんのソースファイルに分けたり関数をやたらと作るのはやめてください。
君のコードはあっちにとんだりこっちに飛んだりしてとても読みにくい。
それだけを見れば済むように一本のファイルにまとめて下さい。
main関数だけを見れば済むようにして下さい。
共通関数などもってのほかです。これはCVSにあげるんですよ?



320 :仕様書無しさん:2006/09/10(日) 11:49:08
Javaじゃ1メソッド1クラスって考えがある罠。
でも1クラス1ファイルではない罠。
でも今のPJのソースも結構ファイル細かく分けてる。
ソース追うのめんど草。

でも関数作るのはかまわんだろ。見やすくなる。
それがあっちこっちに作られたものでなければ。
たとえば、
main()
{
kansu1(); //○○をする
kansu2(); //××をする
kansu3(); //△△をする
}

う〜ん、みやすす(^ω^)

321 :仕様書無しさん:2006/09/10(日) 11:52:55
とてつもなく巨大なmain関数、ifのネストも深い深いw

322 :仕様書無しさん:2006/09/10(日) 12:37:08
スクリプトみたいなソースがみやすいって奴、時々いるよな

323 :仕様書無しさん:2006/09/10(日) 14:57:04
>322
スクリプト使い同士でも読めないコード書く奴居るけどね。
例えばPerlerとかPerlerとかPerlerとか。

324 :仕様書無しさん:2006/09/10(日) 14:58:53
>>323
perlは言語仕様的にそうなりやすいって聞くけど実際そうなの?

325 :仕様書無しさん:2006/09/10(日) 15:01:24
perlの場合9割は何書かれてるか解析するより一から書いたほうが早い

326 :仕様書無しさん:2006/09/10(日) 15:04:52
>>319が釣りなのはもちろんだが、>>320も釣りか。
…まさかマジで書いてるんじゃないよな?

327 :仕様書無しさん:2006/09/10(日) 15:11:54
>326
>>319はてっきり↓の誤爆だと思っていたが違ったのかw

この会社辞めようと思った腐れ上司の一言0x1B
http://pc8.2ch.net/test/read.cgi/prog/1153400438/

328 :仕様書無しさん:2006/09/10(日) 15:13:41
>>326
馬鹿な子ぼらーと一緒に仕事したことがあるのならば理解出来たかもしれないけど
子ぼらーはホントにこんなこと言うよ。


329 :仕様書無しさん:2006/09/10(日) 15:19:38
htmlだから微妙にスレ違いだが、1文字ずつ丁寧にテーブルでレイアウトされた
有り得ないソースを見たことがある

納品先からクレームがきて上司が土日使って直してた

330 :仕様書無しさん:2006/09/10(日) 15:37:56
void unko()
{
  int stat = 0;
LABEL_BEGIN:
  switch(stat){
  case 0:
      ・
      ・
      go to LABEL_XXXX;
      break;
  case UNKO_CHINKO:
      ・
      ・
      go to LABEL_XXXX;
      break;
  case
     ・
  }
LABEL_XXXX:
  すんごいながい処理
  go to LABEL_BEGIN;
LABEL_XXXX:
  めっさながい処理
LABEL_XXXX:
  超長い処理
LABEL_XXXX:
  ・
}
unko関数だけで20000行ぐらいいく。序盤のswitch文は2000行ぐらいで終わる。
ステータスがかわるたびにLABEL_BEGINにもどって何か処理をして
またLABEL_XXXXの処理をいくつか経由して元の場所に戻ってくるw

331 :仕様書無しさん:2006/09/10(日) 15:39:18
>329
何そのhtml簡易難読化ツール

332 :仕様書無しさん:2006/09/10(日) 17:00:31
>>330
構造化プログラム以前の人だと、そんなコード書いたりするな。
某RPGのキャラクタのスクリプト解釈周りがそんなコードで吹いたことがある。
ファミコン時代の人とかにしてみれば、そんな変なコードじゃないのかもな。

333 :仕様書無しさん:2006/09/11(月) 02:03:30
>>330 のはヘタというより半分職人芸だな。

334 :仕様書無しさん:2006/09/11(月) 13:38:46
>>333
だがメンテはしたくない件

335 :仕様書無しさん:2006/09/11(月) 23:23:50
>>329
昔ファミベか何かでそんなコード書いてた。
小学生の頃のはず…。
スタック256バイトしかないんで迂闊にFORとかGOSUBとか使えん。


336 :335:2006/09/11(月) 23:25:22
アンカー間違えた。6502の世界に逝って来る。

337 :仕様書無しさん:2006/09/11(月) 23:40:26
ふぁみべといえば、ふぁみべのとっしんとかいうのがいたな、むかし

338 :仕様書無しさん:2006/09/12(火) 17:38:59
319はただ単にソース解析できないへたれ
こういう馬鹿が一つの関数(メソッド)にアホみたいに300行とか書いてるんだろうな

339 :仕様書無しさん:2006/09/12(火) 19:43:34
>>338
根谷間時礼巣

340 :仕様書無しさん:2006/09/12(火) 20:03:36
>>332
>某RPGのキャラクタのスクリプト解釈周りがそんなコードで吹いたことがある。
yaccかlexで吐いたコードだったらあり得る。

341 :仕様書無しさん:2006/09/12(火) 23:39:16
>>330
そんな貴方にctrl+A → Del


342 :仕様書無しさん:2006/09/13(水) 20:15:39
perl使ってると面倒で一つの関数が長くなってく

343 :仕様書無しさん:2006/09/13(水) 21:51:41
>>330
それは何かツール使って自動生成したソースなのでは?
yacc とか lex とか (bison とか flex とか)、物凄いの作るぜ。


344 :仕様書無しさん:2006/09/13(水) 21:56:43
>>323-324
自分で書いたのを後で見てもすぐに理解できない。
それが Perl クオリティ。

かなり気を付けて書けばいいだけなんだがな。
いろんなことできちゃうからな。


345 :仕様書無しさん:2006/09/13(水) 23:30:35
>>343
めっちゃハンドメイドだって。
すっげ、手作り感あるもん。
インデントにタブとスペースがめちゃくちゃなハーモニーをかもし出してるし。

346 :仕様書無しさん:2006/09/14(木) 01:18:54
確かにyaccとかlexとか俺の書いたCゲロッパー(ツールの名前)とかは
そんなコードを吐き出すんだが、手で書く奴もいる。
下手だなあとかじゃなくって、技術の世代が違いすぎて手に負えない。
書いた当人が保守する限り性能的には優れてるのがまたなんとも。
まあ、言いたかないけど、職人芸のひとつだよね。
弟子はつかなそうだが。

347 :仕様書無しさん:2006/09/14(木) 06:52:14
>Cゲロッパー
くわしく

348 :仕様書無しさん:2006/09/15(金) 02:29:53
いや、まんま。
ゲームのキャラクタ達の状態遷移をへっぽこなスクリプトもどきで
記述できる様にしただけ。
へっぽこなんで、スクリプト内で定義できる関数もどきは
そんな風なコードになる。
C++向け版はクラス内クラスに放り込むようになってるんだが
なんでか今でもC版が生き残ってる。

なんてマジレスはちっとも求められて無いと思いました。
引き続きスレをお楽しみください。

349 :仕様書無しさん:2006/09/21(木) 15:22:04
boolean flag = true;
while(flag){
   :
  (何らかの処理)
   :
  if(…何らかの条件…){
    flag = false;
  }
}


350 :仕様書無しさん:2006/09/21(木) 19:02:12
>349
どの辺が下手なんだ?
俺何度か書いてる気がするから参考にしたいな。

351 :仕様書無しさん:2006/09/21(木) 19:10:45
while ( ! 何らかの条件) { ... } と書けと言うことかと。

JavaでThreadのrunで無限ループさせてるのを止めようと思うと
この手のflag変数に頼るしかないんだけどな。

352 :仕様書無しさん:2006/09/21(木) 19:38:33
>>351
>while ( ! 何らかの条件) { ... } と書けと言うことかと。
いやそれ >>349 と等価じゃないから。
do 〜 while だろ。

353 :仕様書無しさん:2006/09/21(木) 19:45:02
ネスト次第だが、breakで抜けろと言いたいのかな?
何がどう下手なのか、>>349にしかわからないあたり・・・




349が............. ヘタ....

354 :仕様書無しさん:2006/09/21(木) 21:01:18
あー、確かに do 〜 while だわ。

355 :仕様書無しさん:2006/09/21(木) 21:58:38
一行IF文にしてない・・なわけないか

356 :仕様書無しさん:2006/09/21(木) 22:58:54
if文の後に何か処理入れれば>>349になる

357 :仕様書無しさん:2006/09/22(金) 01:00:23
flagって変数名がつっこみどころじゃねーの?

358 :仕様書無しさん:2006/09/22(金) 11:54:27
>>357
クマー?

359 :仕様書無しさん:2006/09/22(金) 14:15:16
>>349
do {
   :
  (何らかの処理)
   :
} while(!…何らかの条件…);

こう書けってことでFA?

360 :仕様書無しさん:2006/09/22(金) 16:42:21
349の無駄な判定1回省いてくれる最適化する処理系ってあったりする?

361 :仕様書無しさん:2006/09/22(金) 18:44:48
日本語でおk

362 :仕様書無しさん:2006/09/23(土) 06:24:31
定数指定のforループとかで、最初の判定をジャンプで飛ばす処理系はある。
>>349のwhileを飛ばす奴がいるかは知らんが、考え辛いかもしれないな。
最近のCPUなら分岐予測の餌食になって消えそうなコストだとは思うが。

363 :仕様書無しさん:2006/09/29(金) 12:01:56
多階層ループだったら普通にフラグだよな?
もしくはgoto

364 :仕様書無しさん:2006/09/29(金) 20:42:50
普通にgotoだろうなー。

365 :仕様書無しさん:2006/10/01(日) 20:07:30
ABESHI abeshi;

366 :仕様書無しさん:2006/10/20(金) 17:30:11
SQLひとつ発行するごとにコネクションから生成しては破棄。
PreparedStatementなんて使ってない。
テーブル内のデータが、全部文字列。

言語はJava。

367 :仕様書無しさん:2006/10/20(金) 19:01:18
何万件あろうと
SELECT * FROM TABLE
してコード内で選択射影

368 :仕様書無しさん:2006/10/20(金) 23:45:26
>>366
贅沢な使い方だな。
>>367
もっと贅沢だな。w


369 :仕様書無しさん:2006/10/20(金) 23:47:19
そういや数字しか入らないのに平然と文字列で行くテーブル設計をした人いたなあ。
なんなんだろう? COBOLERなのか?
Oracle には桁指定できる NUMBER ってのもあるというのに。


370 :仕様書無しさん:2006/10/20(金) 23:48:08
>368
>367 を実際にやるCOBOLerを知ってる。ネタにならねぇ…

371 :仕様書無しさん:2006/10/21(土) 07:31:32
SQL文を覚える気がゼロってことか?

372 :仕様書無しさん:2006/10/22(日) 20:01:34
>>369
数字も日付も、バイナリデータすら文字列なとこもあるしな。
日付や数字の項目に"てすと"とか入っていてもまったく気にせず
動作し続けるシステムを見ると、純粋に感動できる。

>>371
覚える気も何も、自分が分かってないことを分かってないからな。
誰かが言ってやらんと変わらないだろう。


373 :仕様書無しさん:2006/10/23(月) 07:58:19
SQL以前にRDBをわかってない、分かってない以前に、分かろうともしない。
という人が多数派な現場だと、全部文字列はあたりまえ、
DBなんてリリース直前に決めればいいだろという恐ろしい提案が通ったりします。
今作ってるシステムは結局DB登録システムでしょ?と言っても不思議な顔をされる。

374 :仕様書無しさん:2006/10/23(月) 12:57:25
>>367
前に別会社から引き継いだVBのソースで、そういうSQL発行しているのがあったなあ
 SELECT idx FROM TABLE
で8万件から取り出し、idxのリストを作り、クリックされたら
 SELECT * FROM TABLE
で8万件から抜き出し、バッファに溜めたものからidxの番号のデータを取り出し、
画面で変更がかかったら、
 SELECT * FROM TABLE
で取り出し、idxと同じ番号のデータを更新し、、、

あまりの糞さに、WHERE文使った処理に書き直したら、起動からデータ更新まで
当時のPCで1件につき30分かかっていた処理が30秒弱になって、客からむちゃくちゃ感謝されたことがある。


375 :仕様書無しさん:2006/10/23(月) 14:40:36
>>374
それまでずっと30分で我慢して使ってたのか。
お客さん可哀想過ぎ。


376 :仕様書無しさん:2006/10/23(月) 14:50:25
常人の100倍近い生産性を誇る天才ハカー現る

377 :仕様書無しさん:2006/10/23(月) 14:56:47
正に「無知は罪」だな。


378 :仕様書無しさん:2006/10/24(火) 09:16:59
For i=1 To DtCnt
 If SelID=Dat(i).ID Then
  SelDat=Dat(i).Data
 End If
Next i


だから見つかった後にぐるぐる回しても無駄だっての。

379 :仕様書無しさん:2006/10/24(火) 10:11:49
C言語でこんなのを見たことがある。

for (i = 0; i < strlen(s); i++) {
// ...
}

ま、今時のコンパイラなら最適化するかも知れないけどね。
ループの中で s の指す先を変更していたら最適化できなくて
毎回 strlen() 呼び出されるだろうね。


380 :仕様書無しさん:2006/10/24(火) 11:58:27
>>379
他スレッドから弄られる可能性もあるんで
そーゆーのは最適化され内気ガス

381 :仕様書無しさん:2006/10/24(火) 12:21:23
まったく富豪プログラミングの概念を理解できない
骨の髄まで貧乏の染み付いたオッサンばっかりなスレだなここは

382 :仕様書無しさん:2006/10/24(火) 12:40:57
>379 に関連だけど
for(i=0; str[i]; i++)
ってどう思う?

383 :仕様書無しさん:2006/10/24(火) 12:51:40
>>382
str配列の上限を考慮していないので危険だね。

384 :379:2006/10/24(火) 17:31:08
>>380
マルチスレッドじゃないプログラムだったのが唯一の救いか。


385 :仕様書無しさん:2006/10/24(火) 17:34:58
>>382
微妙だな。>>383の言う通りではあるが、C言語の場合は文字列の最後を
0にする慣習あるしな。まあ str が文字配列とは書いてないわけだが。



386 :仕様書無しさん:2006/10/24(火) 19:58:08
>>379
実はsが変更されることを予期した処理だったという可能性があるかもしれな。

387 :仕様書無しさん:2006/10/24(火) 21:49:18
>>379
strlen()の定義をコンパイラは仮定しない(できない)だろう。
# するコンパイラがあったらそれはやりすぎだと思われ。
よって、コンパイラは最適化しない。

>>380
ポインタの場合、ループ内に別のポインタがあればそれが同じ領域を指している
可能性があるために、コンパイラは最適化できない。
# これは、マルチスレッドかどうかにまったく関係がない。
詳しくは、C99でrestrict修飾子が追加された理由を調べてみ。

388 :仕様書無しさん:2006/10/25(水) 01:24:12
>>387
可能性の話だが、strlenは組み込み展開される処理系もあるのだし、
ループ内でsが弄られてないなら最適化されないこともないこともない…気がする。
ほんのり。なんとなく。気持ち程度。お茶漬。

まあどの道forの中にソレがぶちまけられてるのは、それなりにビビるな。
動きゃなんでもいいのかも知れんが、ほどがあるッつーか。

389 :仕様書無しさん:2006/10/25(水) 15:55:24
金勘定が絡むのに計算がdouble。

390 :仕様書無しさん:2006/10/25(水) 23:32:37
グローバル変数の嵐。

しかも排他してないし。
それをレビューで指摘したら逆切れ。
「いままで問題おきてないからいいじゃないですか」

もうなにも言うまい。

391 :仕様書無しさん:2006/10/25(水) 23:33:56
>>389
精度足りないの?

392 :仕様書無しさん:2006/10/25(水) 23:58:31
>>391
俺の総資産を計算するにはdoubleじゃ精度が足らん。

393 :仕様書無しさん:2006/10/26(木) 00:27:07
>>389
丸められた誤差をかき集めて自分の口座に振り込むわけか。

394 :仕様書無しさん:2006/10/26(木) 03:53:01
常に四捨五入切り捨て

395 :仕様書無しさん:2006/10/26(木) 22:08:53
>>392
丼勘定でもだめか?
下の方の桁のはした金なんてくれてやれ。

396 :仕様書無しさん:2006/10/26(木) 22:19:24
つうかヘタじゃなくてバグですから

397 :仕様書無しさん:2006/10/27(金) 02:13:33
1. 同じデータが複数ファイルに分散。
2. 更新のたびにそれを全て書き換え。
3. バグっててたまに途中で落ちて更新が半端に終わる。
4. 画面Aと画面Bで違う値が表示される。
5. コールセンターに真夜中に電話が入る。
6. コールセンターから俺の携帯に電話が掛かる。
7. 朝まで対応。
8. プログラムは当然スパゲティ。
9. orz


398 :仕様書無しさん:2006/10/27(金) 08:57:26
>>392
うんうん。0.1は2進数で循環小数になるからね。


399 :仕様書無しさん:2006/11/01(水) 21:48:39
>>1
if文ばっかり。

400 :仕様書無しさん:2006/11/01(水) 23:02:24
>>387
最適化するんじゃないかな?

401 :仕様書無しさん:2006/11/02(木) 01:17:52
すぐ一時変数使うやつ、

・・・つーか友人・・・

402 :仕様書無しさん:2006/11/02(木) 01:20:25
それはそんなに悪くないでしょ。
なんでも一文に押し込むよりは。

403 :仕様書無しさん:2006/11/02(木) 01:38:49
>>401


404 :仕様書無しさん:2006/11/02(木) 02:52:20
へ?
一時変数普通に使って何か問題があるのか??

405 :仕様書無しさん:2006/11/02(木) 03:04:56
必要ならしょうがないが
bool x;
if (y > 0) {
  x = true;
} else {
  x = false;
}
func(x);
みたいなのをみると func(y > 0); にしろといいたい。

406 :仕様書無しさん:2006/11/02(木) 03:06:29
そうする必要がないところまで・・・とか言いたいんだろうけど
問題があるとは思えんってのが正直な感想

a = xxx();
if (a == 0) {
  〜
}

じゃなくて

if (xxx() == 0) {
  〜
}

と書け
みたいな?
違うかもしれんけど

407 :仕様書無しさん:2006/11/02(木) 03:14:31
>>404
1関数がクソ長くて一時変数を色んな用途に使いまわされると
結構残念だと思うよ。一時変数が外部変数なのよりはマシだけどさ。
C言語で1関数が1000行超えててtempなんて変数名があると本当に残念だよ。
1000行超え自体だけでは残念て言えない今の職場もどうかと思うけど

408 :仕様書無しさん:2006/11/02(木) 03:15:10
>>405は確かに微妙だとは思うが、目くじら立てるほどのことでもねー気はしないでもないかな。

409 :仕様書無しさん:2006/11/02(木) 03:18:08
>C言語で1関数が1000行超えててtempなんて変数名があると本当に残念だよ。
>1000行超え自体だけでは残念て言えない今の職場もどうかと思うけど

まあなんつーか、職場そのものが残念だな、それは。

関数内で適当に中括弧切って、寿命整理して使ってるわけで無くって

int nullpo(int a)
{
int temp;

...以下千行tempもaも大活躍…
}

とかのパターンなんだよな?
よく見かけるっちゃ見かけるが、まあ、残念だよな。

410 :仕様書無しさん:2006/11/02(木) 03:26:25
>>405
このケースは最初は
func(y > 0);
って書いてて意味わからんって指摘受けて渋々直した可能性もある。

クソコード読むよりも、周りのレベルとか修正元のクソコードに合わせて
自分がクソコード書かなきゃいけないときのほうがキツイ

411 :仕様書無しさん:2006/11/02(木) 03:40:21
三項演算子使うなとかな。
三項演算子を数珠繋ぎで四連してる奴とかは、それはそれで問題だが。


ところでひとつ教えてくれ。
tcshのソースん中に、

int f = 0 > value;
Node * p = a[f];

みたいなコードがあったんだが、これはお前ら的にどうなのさ。
ちなみに二分木の左右を辿るコード。
古式ゆかしいというか典型的というか、俺的には別に超OKな感じなんだが、
論理演算の結果を01固定で考えるのはアウトでつか?

412 :仕様書無しさん:2006/11/02(木) 03:45:55
アウトだな
int f = (0>value) ? 1 : 0;
面倒でもこうしてくれ

413 :仕様書無しさん:2006/11/02(木) 03:50:02
三項演算子読みやすいと思うんだけどなあ
ダメってとこも多いしな

414 :仕様書無しさん:2006/11/02(木) 03:50:34
いや、俺に言われても。
ただ、tcshなんて環境選ばずどこにでも移植されてるよーなもんのコードの中が
こんなんだったんで、少し驚いたってだけなのさ。
下手っつーか単に確信犯(故意犯)なだけなんだろうけど。

ちなみにその辺書き直そうとすると、コードのレイアウトがガラっと変わって
量も処理も結構増えそうな気配だった。
きょうび流行らんのだろうけど、いわゆる「ハッカーのコード」なんだろーな。

415 :仕様書無しさん:2006/11/02(木) 04:00:14
>>411
>論理演算の結果を01固定で考えるのはアウトでつか?
アウトと言いたいけど、C言語なら01固定であることが保障されてるしいいんじゃない?
ただ何故こう書いて動くかをクドイぐらいコメント入れとかないとあとあとで
トラブルの火種になりそう。職場のレベルにもよるけど

416 :415:2006/11/02(木) 04:07:00
>>415はやっぱダメだ。コメントで逃げるぐらいなら>>412のほうがよっぽどいい。

417 :仕様書無しさん:2006/11/02(木) 04:14:06
もっと言うなら、

Node * p = 0 > value ? left : right;

とかにするべきなんだろうな。
件のソースは二分木の親と左右のノードを3つのポインタ配列に持っていて、
回転操作を効率よく回していたのだけれど、ソースは極めて簡潔ながら、
ロジックは複雑なものだった。
少なくともぱっと見で何やってるかはわからないレベル。

これを上みたいにベタ書きするのとで、実行効率に差が出るのかは正直わからん。
きょうびのコンパイラ事情考えると、ベタ書きのほうが速かったりしそうだし、
流行らないだろうなーと思ったよ。

418 :仕様書無しさん:2006/11/02(木) 04:17:17
そこでくる、と。
・三項演算子は使ってはいけません


んなことゆーやつ('A`)シネ

419 :仕様書無しさん:2006/11/02(木) 08:27:42
>>410
> クソコード読むよりも、周りのレベルとか修正元のクソコードに合わせて
> 自分がクソコード書かなきゃいけないときのほうがキツイ

だよな…orz

420 :仕様書無しさん:2006/11/02(木) 09:06:11
Win の API のコードってどう思う

421 :仕様書無しさん:2006/11/02(木) 11:04:58
>>390
>いままで問題おきてないからいい

ある意味正論なんだがなw
前に「この変数の記述はおかしい、この関数は素人っぽい、この処理はもっと最適化できる」と
言って、リーダーに許可も取らずにある機能を自分流に書き換えたやつがいた。

確かに理屈で言えば、そいつの言うとおりである。

しかし動いているものを書き換えるというのはリスクが伴うことをそいつはわかってなかった。

ま、そいつが悪いんだが、結局そいつが書き換えてはアップ、書き換えてはアップと
誰も知らないうちに機能を少しずつ改変していってくれたおかげで、
動いていたものが突然動かなくなったり、データ吹っ飛んだりという大惨事が起きて
泊り込みとか3週間帰れないとかいうのが発生。

原因調査して突き止めた時のそいつの一言は
 「確かに修正はミスったが、こんなプログラムのまま運用を続けるなど愚の骨頂だ」

クレーム→そいつの会社の社員30名引き上げ→賠償請求→そいつは結果的に負債背負ってクビ、となったけどなw

422 :仕様書無しさん:2006/11/02(木) 13:10:42
>「確かに修正はミスったが、こんなプログラムのまま運用を続けるなど愚の骨頂だ」
せりふはかっこいいな。

しかしなんでそいつが負債を負うんだ?
一人の勝手で本番環境の機能を入れ替えられるような体制自体に
問題があるんじゃねーの?

そいつは将来のさらなる大惨事を未然に防いだのかもしれないぞ…

423 :仕様書無しさん:2006/11/02(木) 13:25:51
訴えれば勝てるだろうな、そいつ

424 :仕様書無しさん:2006/11/02(木) 14:39:04
>>411
それ、C言語? Cって初期化の順序の保証ってあったっけ?
f が不定値の時に p の初期化が動いたら終わりだよな。


425 :仕様書無しさん:2006/11/02(木) 15:35:11
>>424
C言語の基礎も知らんのによくそんな見当違いのコメント書く気になるもんだ。感心する。
「ラーメンって麺類だったっけ?
 もしパンの一種だっら汁に入れたときドロドロになって終わりだよ」
とか言ってるのと同じレベルだぞ?


426 :仕様書無しさん:2006/11/02(木) 20:09:21
よかった。424が何を言ってるのかわからんかったのは正常なんだな

427 :仕様書無しさん:2006/11/02(木) 21:42:48
本当は「そんなに簡単に修正出来てしまうような管理体制の方が、愚の骨頂」
なのだろうが

428 :仕様書無しさん:2006/11/02(木) 21:43:19
>>425
どこが見当違いなんだ?


429 :仕様書無しさん:2006/11/02(木) 22:02:48
>それ、C言語? Cって初期化の順序の保証ってあったっけ?
>f が不定値の時に p の初期化が動いたら終わりだよな。

Cでは>>411のように宣言されたローカル変数の初期化の順序は宣言された順に
行われると決められている。

グローバル変数の場合規格上は未定義だが、
>ちなみに二分木の左右を辿るコード。
って書いてあるからそれもないだろう。

比較演算子の値が0,1のいずれかであるというCの規格を利用したコードは
(正しく動くが)コーディングスタイルとして妥当かどうかとか話してるときに、
ピントはずれな事実にも反する前提をおいて「〜終わりだよな」なんて批評してるから、
「見当違い」と書いたわけです。


430 :仕様書無しさん:2006/11/02(木) 22:18:42
>>429
0か1かについては他の人が書いてるから書かなかっただけなのだが。


431 :仕様書無しさん:2006/11/02(木) 22:38:54
なんつーか前提が違うとどうしようもないよな
よくあるけど

432 :仕様書無しさん:2006/11/02(木) 22:40:10
関数の戻り値の意味がてんでバラバラな奴

if (func1())
{
エラー処理
}

if (!func2())
{
エラー処理
}

とか、ぱっと見混乱する。
そういや、戻り値がBOOL型で非0、0、-1のどれかを返すWin32 APIとかあったな。

433 :仕様書無しさん:2006/11/02(木) 23:47:16
BOOL型は、名前がBOOLなだけで、真偽値を表すものではないからな〜
変態な命名法というだけだね。

434 :仕様書無しさん:2006/11/03(金) 00:05:09
.iniファイルに格納された数値を
Stringで読み込んで
キャストもせずにBooleanに放り込む

そんなVBAを押し付けられたことがある。

435 :仕様書無しさん:2006/11/03(金) 00:13:45
なんでCは本当の真理値としてのbool型を導入しないの

436 :仕様書無しさん:2006/11/03(金) 00:26:26
面倒だから

437 :仕様書無しさん:2006/11/03(金) 00:34:18
>>435
言語仕様を変えたら、それはもはや「Cのようなもの」で「C]ではない。
「Cのようなもの」でよければ>>435がいうようなアレもあるんじゃないの?

438 :仕様書無しさん:2006/11/03(金) 00:45:33
C99には入ってんじゃねーのか?
つーかCに文句あるならC++使え。

439 :仕様書無しさん:2006/11/03(金) 01:19:54
拡張子cppにするだけだから問題ないよね。
一行コメントだって使えるようになるんだし

440 :仕様書無しさん:2006/11/03(金) 01:29:46
C99 は bool でなく _Bool 型があって
入る値は 0 1 のみって仕様だったかな

んで #include "stdbool.h" すると
bool を _Bool として typedef されて
定数 true false が 1 0 と定義されるって感じ

441 :仕様書無しさん:2006/11/03(金) 01:56:21
どうせC99の時点で言語仕様は変更されまくってるし
コンパイルには-std=c99フラグが要るのだから、
中途半端なことせず言語でサポートするboolを導入したバージョンも出せよと。

442 :仕様書無しさん:2006/11/03(金) 01:59:12
それなら素直にC++使えって話なんだろうな。
C99の拡張は、過去のCの資産と齟齬起こさないのが前提なんだろうし。
__func__なんて、ベンダ独自に実装してる__FUNC__に気を使ってなのか小文字だったりするあたり、察しろというか。

443 :仕様書無しさん:2006/11/03(金) 02:33:32
C99ではぶらさがり文がブロックに置き換えられるため
旧来のCと動作が異なるコードが存在するというトリビア

444 :仕様書無しさん:2006/11/03(金) 02:48:32
ぶら下がり文ってなーに?

445 :仕様書無しさん:2006/11/03(金) 04:07:55
鉄棒大好きな文菜(ふみな)ちゃんのこと

446 :仕様書無しさん:2006/11/03(金) 13:46:30
ぱっと見てというスレタイからだと・・・

やっぱりboolの比較かなぁ

どうしても演算子が書きたいなら、
せめて否定にしてほしい

447 :仕様書無しさん:2006/11/03(金) 14:10:59
じゃあ二重否定で

448 :仕様書無しさん:2006/11/03(金) 14:44:52
true == booleanVariable だの
false == isXXX() だの

しかもXXXが略字で、英文法的にも意味がわからなかったりしたり、
メンバにアクセスしないのにstaticじゃなかったり、  あああもう

449 :仕様書無しさん:2006/11/03(金) 17:43:01
>>448 とか >>405 みたいな書き方する奴ってのは

   if ( /* ここは関係式じゃないといけない */ )

とでも思ってるんだろう。

450 :仕様書無しさん:2006/11/03(金) 18:27:13
恐ろしいな

451 :仕様書無しさん:2006/11/03(金) 19:14:41
staticかどうかってメンバにアクセスするかどうかで決めるものなのか?
言語によるかもしれんけど

452 :仕様書無しさん:2006/11/03(金) 19:42:27
>>451
まあ、俺が見たパターンだと全部が
クラスのメソッドすべてユーティリティメソッドなのにstaticになってなかったって感じかな。

そのユーティリティメソッドを使うためにはわざわざインスタンス作らないといけないの(^ω^)

453 :仕様書無しさん:2006/11/04(土) 01:12:00
>>452
そのための((type*)NULL)->mf()ですよ。

454 :仕様書無しさん:2006/11/04(土) 10:04:16
>>452
DIコンテナとかつかってると、そんなクラスばっかりになるぞ。
ステートレスなクラス万歳って感じだ。

455 :仕様書無しさん:2006/11/04(土) 21:00:27
>>346
>下手だなあとかじゃなくって、技術の世代が違いすぎて手に負えない。
>書いた当人が保守する限り性能的には優れてるのがまたなんとも。
おまえ、いいこと言うな。

456 :仕様書無しさん:2006/11/04(土) 21:59:07
>>410
そんな細かい粒度で指摘がはいるだけマシ。
VBなんてやってた日にゃ野放し状態ですよ…orz

457 :仕様書無しさん:2006/11/04(土) 22:03:42
>>421
その賠償請求は多分違法。
たとえどんな誓約書を入社時に書かされていたとしても、まともな弁護士雇って訴えればどうにかなる。

まぁ、無視してもいい気がするけどww
そいつが律儀に支払いしてるようならアドバイスしてやれ。

458 :仕様書無しさん:2006/11/04(土) 23:00:44
他人の書いたコードを勝手に直すって
よくそんなリスクの高いことをやる気になるよなー。
ペアプロとかリファクタリング環境が整っているなら良いけど…。

459 :仕様書無しさん:2006/11/05(日) 00:48:11
どこぞで聞きかじったキーワードをひけらかすのも大概にね。

460 :仕様書無しさん:2006/11/05(日) 08:56:11
>>458
やっぱりペアプロの環境を整えるためには
まずは、新人女を発掘しないとな。

それが一番のリスクだ。

461 :仕様書無しさん:2006/11/05(日) 08:57:10
>>457
421は被害を受けたほうだろうから、421にアドバイスするのはありえないだろうwww

文脈読めないひと?

462 :仕様書無しさん:2006/11/05(日) 09:28:54
大抵のコーディングは許せるが
長い関数だけは読むのが苦痛だ。

463 :仕様書無しさん:2006/11/05(日) 12:09:58
しかもローカル変数が違う意味で使いまわされてたりなw

464 :仕様書無しさん:2006/11/05(日) 14:08:44
>>457
誓約書云々ではなく、無断(業務外)で>>421に被害を与えたんだから
賠償は当然だろ。
権限のある指示者の命令下で作業を行ったんだったら
>>457の言うとおり賠償責任はないんだろうけどね。

465 :仕様書無しさん:2006/11/05(日) 14:37:22
>>464
>誓約書云々ではなく、無断(業務外)で>>421に被害を与えたんだから賠償は当然だろ。
明らかに業務とみなされるし、雇用者と被雇用者間ならまだしも、同僚が直接”賠償”請求ですかww


466 :仕様書無しさん:2006/11/05(日) 15:09:50
>>432
そもそも
if(func1())とかいうのが嫌い

if(func1()==0)とかにして欲しい

467 :仕様書無しさん:2006/11/05(日) 16:25:22
>>466
そんなの絶対いや。

468 :仕様書無しさん:2006/11/05(日) 16:27:00
>>466
そもそも
if(func1()==0)とかいうのが嫌い

if(func1())とかにして欲しい


469 :仕様書無しさん:2006/11/05(日) 17:24:20
可読性を上げる意味で
func()の返り値がunsignedであっても

if(0 < func())

とか書くことはある…か、な?

これって下手コード?

470 :仕様書無しさん:2006/11/05(日) 17:32:17
>>414
>ちなみにその辺書き直そうとすると、コードのレイアウトがガラっと変わって
>量も処理も結構増えそうな気配だった。
>きょうび流行らんのだろうけど、いわゆる「ハッカーのコード」なんだろーな。

遅レスだが、一つ教えてくれ。

「ならば、"どうしろ" というの?」

本来難しい問題ならば、
それなりに複雑でボリュームのあるコードを書くのが
現代風だっていう話なのか?


471 :仕様書無しさん:2006/11/05(日) 17:42:57
>>469
このifに引っかからない場合にどうするの?

472 :仕様書無しさん:2006/11/05(日) 18:30:14
>>466
>>449

473 :仕様書無しさん:2006/11/05(日) 19:23:56
なにこのスレ。Cのくだらなねぇ話題ばっかじゃねぇか。C++使えよ・・・・

474 :仕様書無しさん:2006/11/05(日) 19:26:23
>>473
おめぇ、ずいぶんしょんべんくせぇな
どこ乞食だ?

475 :仕様書無しさん:2006/11/05(日) 21:31:23
ぢゃあ逆に問う

true == 1なのか?

476 :仕様書無しさん:2006/11/05(日) 22:27:59
>>475
言語によって異なるので一般化できない。とりあえずC++を想定してる。
そうですよ。



477 :仕様書無しさん:2006/11/05(日) 22:32:09
>>473
このスレに言語の決定権のある人間がどれだけいるというのか

478 :仕様書無しさん:2006/11/05(日) 22:42:31
だから、比較演算子は否定から入れとあれほど(ry

479 :仕様書無しさん:2006/11/06(月) 01:34:15
>>470
コード自体は簡潔であっても、移植性を欠いてまでロジックを押し込むことはないってことだと思われ。
他の人間が読んでも読みやすく、コンパイラが妥当に解釈してくれるので性能に差が無い、
そういうラインを探すのが現代風というか、そうでないのが過去の話なんだろう。
一般論だな。

480 :仕様書無しさん:2006/11/06(月) 03:19:56
条件式に ==0 と書いても耐えられるのは ==1 とか ==2 が並列してありえる場合だけだな。
あとは百歩譲って strcmp。

481 :仕様書無しさん:2006/11/06(月) 08:12:24
数値としてのゼロ、と明記したいなら ==0 と書くが
NULL や真偽値の判定なら書かないな。

strcmp は始め悩んだが ==0 にしてる。
真偽値かって言うとちと違うし。

482 :仕様書無しさん:2006/11/06(月) 23:23:44
きちんと意図が表れやすい方が好ましい。
つまり、読みやすい方が好ましい。

書くのはあなたでしょうけど、読むのは誰ですか?
それは読みやすいのですか?

483 :仕様書無しさん:2006/11/06(月) 23:26:55
読む人間が偏屈だったりするからなぁ。

484 :仕様書無しさん:2006/11/07(火) 03:16:54
あるあるあるあるある
何書いても文句言われるなら、いっそ何書いても構わんだろうと

485 :仕様書無しさん:2006/11/07(火) 06:51:44
>>482
>それは読みやすいのですか?

読みやすさを数値で測る方法が見つかったら考えてやるよ。


486 :仕様書無しさん:2006/11/07(火) 13:01:35
読みやすさ度 2.3

487 :仕様書無しさん:2006/11/07(火) 13:10:38
視力0.2

488 :仕様書無しさん:2006/11/07(火) 22:50:22
>>485
君は美味しい、甘いなどと感じるときにいちいち数値が見えているのか。
実はおっぱいに目が行っているだろう。

489 :仕様書無しさん:2006/11/07(火) 23:50:08
他人のおっぱいなぞ興味はない

490 :仕様書無しさん:2006/11/07(火) 23:54:51
自分のおっぱいに興味があるのか。

491 :仕様書無しさん:2006/11/08(水) 08:07:52
そうだ

492 :仕様書無しさん:2006/11/08(水) 08:41:36
#   _  ∩
# ( ゚∀゚)彡 おっぱい!おっぱい!
#  ⊂彡

493 :仕様書無しさん:2006/11/08(水) 13:43:59
no comment

494 :仕様書無しさん:2006/11/08(水) 21:58:54
1. コメントに変更履歴(変更理由、変更者、変更日)、 ファイルの先頭ならまだしも変更箇所に
2. 古いコードがコメントで残してある
3. コメントならまだしも、#if 0 〜 #endif でアウトしてたりもする
4(重要). バージョン管理システム使っていながらこの状態

495 :仕様書無しさん:2006/11/09(木) 12:04:16
>>494
あべしでは、古いコメントは全て残すように教育されているはず。だから、
////////////2003.09.24. 変更
////////////if( hoge == mage ) {
if( hoge == moge ) {
//////////2003.12.22. 変更
////////a = func( b );
a = func( b, c );
////////////2003.09.24. 変更
////////////a++;
a--;
///////2005.3.3. 変更
///////a += 2;
////2006.1.4. 変更
////c++; }
//2006.2.2.変更
//c++; b++; }
}

みたいなソースばかり。しかも開発時の報告資料には必ずコメントを含んだステップ数が入る。

496 :仕様書無しさん:2006/11/09(木) 12:41:55
>495
専用エディタが要るな…w

497 :仕様書無しさん:2006/11/09(木) 13:20:43
>495
>開発時の報告資料には必ずコメントを含んだステップ数が入る。
コメントは「ステップ」じゃないしw

498 :495:2006/11/09(木) 14:13:40
>>497
俺に言われても知らんw あべしに以前「コメント行数はカウントしないでください」と言ったら
目を見開いて真剣に「なんですかそれ?そんな面倒な集計方法聞いたことありませんよ??」とつっかかってこられた。

そーは言っても、ステップ数5960とかでコード行数32とか200とか、そんなのばっかりだったからねぇ・・・

499 :仕様書無しさん:2006/11/09(木) 17:19:29
そもそも、ステップ・・・。わかってるだろうから、・・・言うまい・・・。

500 :仕様書無しさん:2006/11/09(木) 17:24:02
>>466
> if(func1()==0)とかにして欲しい
俺もそう思う。func1の戻り値を何と比べているのかを明確に記述して欲しいよね。
省略した場合、わかってるから省略しているのか、
わかってないから、省略してしまったのかの区別がつかんw

501 :仕様書無しさん:2006/11/09(木) 23:20:20
上手下手を感じる以前に目を疑ったコード
(識別子などは変え、一部略しています)

switch(foo){


502 :仕様書無しさん:2006/11/09(木) 23:24:05
途中で送信しちまった

switch(foo){
 case L1:
  foo();
  ...
  break;
 case L2:
  bar();
  ...
  break;

if(hoge){
 case L3:
  break;
}

 case L4:
  break;
 ......
}

こんなん。

503 :仕様書無しさん:2006/11/09(木) 23:27:10
おーこれは上物だな

504 :仕様書無しさん:2006/11/10(金) 03:42:11
>>502
ちなみに、if(hoge)行のhoge式が評価されることはあるの?
# そこがネタ?

505 :仕様書無しさん:2006/11/10(金) 07:32:00
if(foo())
   if(bar())
       baz();
else
   qux();

でバグじゃないコード。
一体何の嫌がらせだ。

506 :仕様書無しさん:2006/11/10(金) 09:11:56
>>505
それのネストが深くてインデントを途中であきらめた物が回ってきたことがある。
最初にやったことは、全部プリントアウトしてIF-THEN-ELSE-ENDIFの対応関係を
マーキングしていくこと。
最初のネストのELSEを4000行目くらいで見つけたときは、マジで切れた。

ヘタにも程がある。

507 :仕様書無しさん:2006/11/10(金) 10:14:38
思わず「オカエリナサイ」と言いたくなる。

508 :仕様書無しさん:2006/11/10(金) 10:43:56
>>506
たまらんな・・・・
ヘタとかいう以前に自分で保守できにくいっつうのがわからんのだろうか

エラー処理してても一気に飛ぶから判定しにくいだろうし

509 :仕様書無しさん:2006/11/10(金) 10:53:52
>>502
目からウンコが落ちた

510 :仕様書無しさん:2006/11/10(金) 11:17:13
>>504
ないだろうな。

しかし、こんな風に書いてもコンパイルエラーも警告も出ないところがC言語のすごいところか・・・。


511 :仕様書無しさん:2006/11/10(金) 13:40:40
警告を出すか出さないかはコンパイラの問題であって、言語の問題ではない。

512 :仕様書無しさん:2006/11/10(金) 17:21:32
フレームワーク使ったJSPにメソッドがいた。

やってることは略名称取得。
同じ物が他の沢山のJSPに。

えーっと、略名称じゃなく名称出したくなったら
全部のJSP書き直しですか?


513 :仕様書無しさん:2006/11/10(金) 20:12:56
>>506
整形ツールでインデントだけでも正しくしてからやればよかったのに

514 :仕様書無しさん:2006/11/10(金) 20:20:48
>>502
hogeが常にfalseだと、コンパイラが削除してくれるとか?


515 :仕様書無しさん:2006/11/11(土) 00:06:25
>>512
リファクタリング機能で一発

516 :仕様書無しさん:2006/11/11(土) 00:08:18
>>505
Pythonのコードか、あるいはHaskellか。

それでもありえない罠wwwwwwwwww

517 :仕様書無しさん:2006/11/11(土) 03:40:10
>>513
そんなものが開発環境にあれば苦労はしない…
汎用機の世界は時間が止まったような人外魔境に見える。

518 :仕様書無しさん:2006/11/11(土) 05:43:49
別に汎用機の開発環境になくてもさ、
PCで動く整形ツールはたいていの言語にはあるんだから
ソースをPCに持ってきて適当に整形すればよかったのに。

519 :仕様書無しさん:2006/11/11(土) 06:07:26
汎用機やってる連中の解せないところは、その辺の融通の利かなさだよな。
まあ、会社もろとも融通利かなくて、ソースを持ち出せない可能性も大なわけだが。
このご時世、なんでそんな連中が食いっぱぐれ無いのか大いに疑問だ。

520 :506=517:2006/11/11(土) 08:18:51
機械的な整形ではもはやどうにもならない汚さだったから。
COBOLなのにカラムが無限にあるかの如き書き方だった。
でも不思議とバグが無かったので、整形はPMに阻止された。自動はおろか手動でも。

バグ無しで作ったやつはネ申かと思ったが、論理演算子や一次元配列の使い方さえ
碌に理解できずに拒絶した只のバカで、このソースは神様の悪戯だった。(w
PMもそんな低レベルに合わせるからいけないのだけど。汎用機が泣くよ。

実感としては、融通利かないっていうより異空間にいる感じだな。
俺は適合できなくて終に大学病院送りになったよ。orz

521 :仕様書無しさん:2006/11/15(水) 11:25:59
>>519
やりたがるやつが少ないから需要の方が大きいままで、だから稼げるのでは?
少々バカで効率悪くても居なくなってしまうよりはましだから飼っておくとか。


522 :仕様書無しさん:2006/11/17(金) 00:45:27
>少々バカで効率悪くても居なくなってしまうよりはまし

世の中上の方は大体そんな理屈で動いてるよな。
まあ、いいんだけどさ。

523 :仕様書無しさん:2006/11/23(木) 04:37:49
そいつの方が給料がいいとちょっと腹立たしいよな。
まあ、いいんだけどさ。

524 :仕様書無しさん:2006/12/06(水) 21:13:37
pA=malloc(1048576);//余裕を持った確保

いや、幾らなんでも確保しすぎだろうと。

525 :仕様書無しさん:2006/12/06(水) 22:22:14
<font class="red">

どっから突っ込めばいいんだ。
明日からこんな感じのHTML数百枚をStrictに修正だ…

526 :仕様書無しさん:2006/12/06(水) 22:29:27
汎用機なんて全く触った事無いJava男だが、ちょっと話聞いただけでどんだけずさんなのか分かるな。
まぁ つωT`)ヾ (゚Д゚ )…イ`

それはいいとして、最近汎用機やってました。Javaやりたいです。とかいうヤツが続々、派遣されて来るんだ。
で、そいつらのソース見たら、どいつもこいつも大概ベタ書き。

汎用機が大変だったのは分かるがその魔境地帯をJavaで、埋め込むんじゃねー

527 :仕様書無しさん:2006/12/06(水) 22:34:54
いや、別にStrictにする必要はないだろ。

528 :仕様書無しさん:2006/12/06(水) 22:39:34
>>526
その手のソースを見てると、JavaがN88-BASICか何かに見えてくるから、不思議だよ。(w

529 :仕様書無しさん:2006/12/07(木) 00:49:07
String str = new String(""); @Java

ウチも最近、Findbugsを入れたおかげで、こういうコードを書いたバブル入社ヘタレを
容赦なく晒すことができるようになりました。

530 :525:2006/12/07(木) 01:19:32
客が「次の機能刷新が入る前に直しておきたい」って言い出したんだから仕方ないだろ。
今暇だし金にはなるんだけど、どうにもやる気が出ない。

531 :仕様書無しさん:2006/12/07(木) 01:23:26
>>524
それはせめて 0x100000 と書いて欲しい。
そもそも意味の無い数字なんだろうけど。

532 :仕様書無しさん:2006/12/07(木) 02:02:19
ifの式が真偽値か参照以外になっているコードを見るとダメだなぁと思うよ。

if(i++)とかif(ret = foo())とかクソ!クソ!クソ
※fooは数値を返す関数

533 :仕様書無しさん:2006/12/07(木) 10:04:07
参照はいいのか。

534 :仕様書無しさん:2006/12/07(木) 12:43:39
>>525
><font class="red">
その発想はなかったわ

535 :仕様書無しさん:2006/12/07(木) 18:50:41
>>529
>String str = new String(""); @Java
どのあたりが「ヘタレ」なの?教えてくだちい。

536 :仕様書無しさん:2006/12/07(木) 20:45:54
>>535
Java はダブルクォーテーションで括った文字列は String クラスのインスタンスだ。
(だからたとえば "abc".charAt(1) とかできる。(この場合 'b' が返る))。

なので文字列定数を new String() で作ることは余程の事情がない限りはしない。
その必要がないからだ。(但し勝手に最適化されて参照先が同じになることはある
ので書けば必ず無駄なコードが作られるとは限らない)。


537 :仕様書無しさん:2006/12/07(木) 22:11:00
>>536
よー分からんけど、これでいいってことかい?

String str = ""; @Java

てか、これ以外書いた事ねぇや。


538 :仕様書無しさん:2006/12/07(木) 22:28:52
>>537
あとで再代入することが「確実な場合」は
"" を代入する意味が「全くない」のでやめたほうがいいよ。

539 :仕様書無しさん:2006/12/07(木) 22:38:58
>>538
うん、そんなときは使わんって。使い方には色々あるんだから。
そうじゃなくてnew String()の記述が要らんって事よね?

540 :仕様書無しさん:2006/12/08(金) 02:25:37
俺C++厨だからうっかりnew String("")ってしちゃいそうだわwww。
つか最近C#で同じことやってコンパイルエラーと数分格闘しちまった。

よく知らんがJAVAはコンパイル通るんか?


541 :仕様書無しさん:2006/12/08(金) 06:12:51
c#ならstring.Emptyにしろよ

542 :仕様書無しさん:2006/12/08(金) 06:30:04
>>526
派遣会社のWebページ見てみ。

専門なり大学なりを卒業して、何年もフリーターやってる奴とか元乞食とかを
数ヶ月、VB、C#かJavaを社内教育+経歴偽装して売り出してるから。

特定派遣(請負社員)ですらない、一般派遣(特に20代の県外からの派遣)は特にヤバイ。
派遣ですら食えないヤバイ奴の巣窟

543 :仕様書無しさん:2006/12/08(金) 11:13:36
>>540
  String str;
だけでインスタンスができちゃう、と考えるのが
真の C++ 厨さ。

544 :仕様書無しさん:2006/12/08(金) 11:54:21
>>528を見て吹いたwwwwwww

545 :仕様書無しさん:2006/12/08(金) 12:05:42
>>539
Javaの教則本の最初の方だけ見て書くとそういうの書きそうだな。

546 :仕様書無しさん:2006/12/08(金) 14:20:58
いいよほとんど実害ないから、例外もみ消すアフォよりは

547 :仕様書無しさん:2006/12/08(金) 22:13:29
>>546
例外もみ消しなぁ。スキルの低い奴ほどやらかす傾向あるな。


548 :仕様書無しさん:2006/12/08(金) 22:18:55
>>547
そんなのただの作り話だよ。ほんとにやるヤツいねぇ。
とか思ってたら今度来た派遣の30代PGがほんとにやってたよ(゚д゚)

しかも、やんわりダメですよ〜って言ったのに、こういう処理をしてるプログラムは前の現場では〜とか
意味の分からない例を持ち出された。
もうどうでもよくなって、ほったらかし。


549 :酔いちくれ ◆J0rwikii8c :2006/12/08(金) 22:33:35
おれのしってるプロジェクトでは、例外時に出力するメッセージを
DBに読み込みに行くようにしてるのだが、DB接続時の例外処理で
同じようにDBにメッセージを検索にいっていた。

550 :仕様書無しさん:2006/12/08(金) 23:26:21
>>548
スキルの低いやつがバグ隠しによくやる。
エラーが出るからなんとかしろ、といわれて何とかした結果がそんなだったりする。
そういう風に育ってしまったら直らん直らん。

>>549
ワロタワロタwwwwwww

551 :仕様書無しさん:2006/12/09(土) 11:13:18
逆にお前らが言う天才的などコードってどんなのよ?

552 :仕様書無しさん:2006/12/09(土) 11:19:28
天才的なコードなんてイラネーヨ。

553 :仕様書無しさん:2006/12/09(土) 12:03:15
仕事のコードでDuff's deviceなんか見た日には……


554 :仕様書無しさん:2006/12/09(土) 17:43:24
アビーが書いたコード。

555 :仕様書無しさん:2006/12/09(土) 18:55:44
>>552
同感。
普通に書いてくれればよし。


556 :つか:2006/12/09(土) 19:59:08
nemespace komaneti_space
{
partial class par_class
{
int i_hoge1;
}
partial class par_class
{
int i_hoge2;

}
partial class par_class
{
int i_hoge3;
}

}

557 :仕様書無しさん:2006/12/09(土) 20:31:08
ソラリスのオプンソース見てたら
けっこうGoTo使っててビビった まぁそんなアホな用法ってわけでもないんだけれど。

558 :仕様書無しさん:2006/12/09(土) 21:04:39
GoToも適切に使えてるならいいんじゃない?
絶対的禁止ってわけじゃない。


559 :仕様書無しさん:2006/12/09(土) 21:14:55
☆社会の寄生虫、派遣会社をぶっ壊せ!やつらは背広を着た893だ!

私は今ここに要求する!派遣法を改善・改正せよ!
サラ金真っ青の30%、40%超の暴利を搾取し労働者から毟り取る。

 派遣会社の搾取率を10%未満に規制しろ!
 派遣会社の搾取率を10%未満に規制しろ!
 派遣会社の搾取率を10%未満に規制しろ!
 派遣会社の搾取率を10%未満に規制しろ!
 派遣会社の搾取率を10%未満に規制しろ!
 派遣会社の搾取率を10%未満に規制しろ!
 派遣会社の搾取率を10%未満に規制しろ!
 派遣会社の搾取率を10%未満に規制しろ!
 派遣会社の搾取率を10%未満に規制しろ!

ついでに薄利で中小の乱立する派遣会社に消えてもらって
 派遣は大規模派遣会社のみが薄利多売でやる商売にしろ。
そうすれば労働者の手取りも増えてニートやフリーターも減るだろう。

【漫画DB】第0弾フリーザ様に学ぶ派遣会社搾取問題
http://www2.ranobe.com/test/src/up16740.jpg

560 :仕様書無しさん:2006/12/09(土) 21:39:57
goto禁止で例外が飛ぶ。
はーこりゃこりゃ。

何事も思考停止が一番よくないと思うわけですよ。

561 :仕様書無しさん:2006/12/09(土) 22:52:22
>560
gotoと例外は違いますよ?もちろんCにはgotoしかないけど、
C++ならgotoはないでしょ。CとC++を同列に考えている時点で思考(ry

562 :仕様書無しさん:2006/12/09(土) 23:10:16
BOOLを返す関数なら、==FALSE、==TRUE イラネ。
intを返す関数は、==0、!=0つけた方が(・∀・)イイ!!
従って、str系の関数で、if (strcpy(a,b)) {・・・}は非常にムカツクw

563 :仕様書無しさん:2006/12/09(土) 23:10:43
on error goto

564 :仕様書無しさん:2006/12/09(土) 23:42:18
>if (strcpy(a,b)) {・・・}は非常にムカツクw

可読性が落ちるわけでなし、別に構わないと思うが
個人的はifのあとに空白つける奴が多いのが非常にムカツク

いらんだろ、あれ
きょうび検索にだって影響なんかするもんか

4タブに合わせてんだよ!って主張する奴がいるが、
ならforとswitchにまで付いてんのは何でなんだと

565 : :2006/12/10(日) 00:09:03
>>564
なんでムカツク?
普通だろ。

お前の思考回路の方がムカツク

566 :仕様書無しさん:2006/12/10(日) 00:13:29
で?

567 :仕様書無しさん:2006/12/10(日) 00:48:07
>>564
そもそもstrcpyは真偽値返す関数じゃないだろうーが

つーか空白の個数やタブなんて小さい問題だし、ツールでいくらでも補正可能だろ

568 :仕様書無しさん:2006/12/10(日) 01:00:31 ?2BP(1011)
>>564
という事はあなたの考えが少数派という事です。
その事実を認めて物を考えましょう。

569 :仕様書無しさん:2006/12/10(日) 02:47:26
>>562
禿げ同
たまにif (CreateFile(...))とかやってハマってる馬鹿とかいるし

570 :535:2006/12/10(日) 03:11:41
>>536
どーもありがとー。
Stringオブジェクトはnewするな、きわめて冗長だから、っつー話なんですね。

>>540
おれもおれも。w
だが、C++はそれがいい。

571 :仕様書無しさん:2006/12/10(日) 03:31:42
C++のstd::stringってmutableなんだよねえ
JavaとかC#とかがimmutableなもんで
どうしてもimmutableっぽく扱ってしまう・・・

572 :仕様書無しさん:2006/12/10(日) 09:03:26
if (a>b) {
return true;
} else {
return false;
}


573 :仕様書無しさん:2006/12/10(日) 10:04:40
ブビだが、
Functionの呼び出しが全て go sub になってたソース見た。

574 :仕様書無しさん:2006/12/10(日) 10:45:23
同じく VB だけど、
ループとか if, case で表現できるものを、goto で実装してるソースがあった。
しかし、場所によっては do 〜 until ループを使ってたりする。

575 :仕様書無しさん:2006/12/10(日) 13:01:45
>>572 (*゚∀゚)ニヤニヤ

576 :仕様書無しさん:2006/12/10(日) 20:33:18
>>573
それ動かないだろ?

577 :仕様書無しさん:2006/12/10(日) 22:24:45
>>576
まともな井出使ってれば普通に動くと思うぞ。
そもそも関数の概念の説明に使われるくらいなんだから。

ただreturn値の指定方法が気になる。kwsk>>573

578 :仕様書無しさん:2006/12/11(月) 01:36:06
>>577
>>576タソは、gosubがgo subになってるって言いたいんだよぉ。わかった?^^

579 :577:2006/12/11(月) 02:28:28
>>578
たしかそれでも動く仕様のが昔あった気がしてな。
なんかなかったか?

580 :573:2006/12/11(月) 11:56:53
go sub .......orz
人間コンパイルエラーしてもーた。

つか、VB6でGoSubなんて使えるのをこのコードで初めて知った。

>>577
グ ロ ー バ ル 変 数 に決まっているじゃないでつかww


同じシステムの別のコードは、Subが一個しかなく、
サブルーチンは全て GoTo ラベルで記述されてて、
1ファンクションが2000行くらいのだった。

581 :仕様書無しさん:2006/12/11(月) 16:17:45
>562
Win32APIで,BOOL型なのに返す値はTRUE(1)/FALSE(0)/-1だったり・・・

582 :仕様書無しさん:2006/12/11(月) 16:49:13
boolじゃないんだから、BOOLはゼロか非ゼロかだけ守ってりゃいいだべ。

583 :仕様書無しさん:2006/12/11(月) 20:39:45
>>579=577
えっとぉ、N80Basicは、Go ToでもOKってやつでつかねぇ?w

584 :仕様書無しさん:2006/12/11(月) 20:42:45
>>581 それは藻前の勘違い?
んでも、Trueを使わずに!FALSEで判定すれば、もーまんたいo(^-^)o

585 :仕様書無しさん:2006/12/11(月) 20:48:52
>>581,584
つーかそれがBOOLの仕様だろ!!
まさかVCの実装で
#define TRUE 1
ってなってるからってそれを仕様だと思ってたりしてないよな?


586 :仕様書無しさん:2006/12/11(月) 21:42:35
それなんてGetMessage?

587 :仕様書無しさん:2006/12/11(月) 21:44:38
そういうものにBOOLという名前を付ける神経がいかれてる。


588 :584≠581:2006/12/11(月) 22:41:14
>>585
だからぁ、、、
#define FALSE (0)
#define TRUE (!FALSE)
なんてことは、言われなくてもわかるがな。

if (isError() == TRUE) {}; //動くわけねぇだろw
if (isError() != FALSE) {}; //書き方が気にイラネ
ってこと。

589 :仕様書無しさん:2006/12/11(月) 22:55:18
if( !!isError() == TRUE )

だよな!!


590 :584≠581:2006/12/11(月) 23:02:47
(゚Д゚)ツマンネ

591 :仕様書無しさん:2006/12/11(月) 23:48:25
GetMessage
メッセージ取得成功:TRUE
WM_QUIT取得:FALSE
エラー:-1

そしてwizardが吐き出すコードはwhile( GetMessage() )…。('A`)ナニコノクソコード

592 :仕様書無しさん:2006/12/12(火) 03:19:20
昔の名残だな。
つか、今のWizardもそんなコード吐くのか?
MSDNに

警告 GetMessage 関数は、0 以外の値、0、-1 のいずれかを返します。したがって、次のようなコードは避けてください。
while (GetMessage(lpMsg, hWnd, 0, 0)) ...

って思いっきり書いてあったんだが…

593 :仕様書無しさん:2006/12/12(火) 14:22:17
客:このソフトに○○機能を追加してください。
漏れ:わかりました。ソースコードはこれですか?
客:そうですね。ではよろしくお願いします。
漏れ:誰だこの超ヘタくそなコード書いたのは・・・5年前の漏れかorz
客:(こいつに任せて大丈夫だろうか・・・。)

594 :仕様書無しさん:2006/12/12(火) 15:32:25
>593 は 5年の間に「下手なコードを見抜く能力」が上がった訳だ
それは良いことだと思うぞ

595 :仕様書無しさん:2006/12/12(火) 17:26:08
割と○年前の自分が書いたコード見ると吊りたくなるって人多いんじゃね?

 ∧||∧   
(  ⌒ ヽ 自分に腹が立つ……
 ∪ 。ノ   
  ∪∪

596 :仕様書無しさん:2006/12/12(火) 18:58:21
>>595
こないだ7年前のコードを読んだんだが、
整理されていて読み易い構造だった。

 ∧||∧   
(  ⌒ ヽ 退化してんじゃん…
 ∪ 。ノ   
  ∪∪

597 :仕様書無しさん:2006/12/12(火) 19:53:06
いつの間にここは首吊りスレになったんだ

598 :仕様書無しさん:2006/12/12(火) 22:33:57
>>593 ワロタ

599 :仕様書無しさん:2006/12/13(水) 01:47:20
自分が5年も前に書いたコードなんてリファクタリングしないと使えないな

600 :仕様書無しさん:2006/12/13(水) 11:11:58
小学生の頃初めてさわったときに
if(a==TRUE)
なんてやってたな。
俺はkusobaka

601 :仕様書無しさん:2006/12/14(木) 17:50:39
過去の自分って、大概格好悪く恥ずかしい

602 :仕様書無しさん:2006/12/14(木) 18:08:32
>>600
kusakabeかとオモタ

603 :仕様書無しさん:2006/12/14(木) 22:16:05
過去の自分を見つめるのはいい事だと思うんだ。

俺も客に申し訳ないくらいしょぼいコード書いてたなぁ。。。


604 :仕様書無しさん:2006/12/15(金) 09:16:10
日々勉強ってことだよな。
でも意外と今の新人が自分と変わらないレベルだったりすると…

605 :仕様書無しさん:2006/12/15(金) 10:56:18
>>601
成長してれば自然とそう思うよな。^^


606 :仕様書無しさん:2006/12/15(金) 11:32:45
>>595
若い内は覚える速度も速いので作られるソースの変化も激しいが、
歳を取ると段々と変化が遅くなる。20才の時のソースと25才の時の
ソースは雲泥の差だったりするが、30才の時のソースと35才の時の
ソースは大差なかったりする。


607 :仕様書無しさん:2006/12/15(金) 14:44:23
>>604
書ける奴は書けるんだよなー。
十も歳違うのにコードに大して差がなかったりすると、流石にへこむ。
あるいは、目に見えないところでそれなりに差がついてるのかもしれないが…

608 :仕様書無しさん:2006/12/15(金) 17:46:22
>>600
kusobakaでも、保守できる素敵なコードと思えば良い。
実際、if(a)でもif(a==true)でも、コンパイラが馬鹿じゃなきゃ、生成されるものは同じでしょ。
なら、誰でもわかるソースの方が優秀だと思うけどな。
自分しか使わない触らないなら、話は別だけど。

609 :仕様書無しさん:2006/12/15(金) 18:30:34
心配性な俺はこのくらい書いてしまう時がある
hoge = IsHoge();
if(hoge == true)
{
 //Hogeのときの処理
}
else if(hoge == false)
{
 //Hogeじゃないときの処理
}
else
{
 //何かIsHogeがありえない戻り値返してきた
 AfxMessageBox("やべえwww");
}


610 :仕様書無しさん:2006/12/15(金) 18:58:41
それは流石にパラノイア。
C言語の挙動自体まったく理解してなかった頃の俺のコード見てるみたいで
なんか恥ずかしいから撤回してくれ。
じゃないと俺が死ぬ。

611 :仕様書無しさん:2006/12/15(金) 19:01:26
論理値をリテラルと比較するような莫迦は
  int a, b;
  if ((a == b) == true)
これくらいやらんとな。

612 :仕様書無しさん:2006/12/15(金) 19:02:28
>>608
aがC++のboolやJavaのbooleanならそれでいいけど、
>>600のは多分BOOL(int)なのでやばいって話だと思われ。

613 :仕様書無しさん:2006/12/15(金) 19:04:29
Makefile にこっそり -DTRUE=2 とか入れちゃう。


614 :仕様書無しさん:2006/12/15(金) 19:06:01
ちょwww

615 :仕様書無しさん:2006/12/15(金) 19:08:49
>>613
そしてCVSに痕跡残しちゃうwww

616 :仕様書無しさん:2006/12/15(金) 19:10:59
リポジトリを直接いじって痕跡削除。


617 :仕様書無しさん:2006/12/15(金) 19:13:35
そしてリポジトリを破壊。
仕方ないので鯖を物理的に破壊。
ばっくれのコンボ。

618 :仕様書無しさん:2006/12/15(金) 19:56:41
>>610
実際、このIsHogeが俺が自分で書いた関数ならここまで気にしないさ

このくらい人を不安にさせるコードを書く人が以前にいたんだよ
ドキュメントに戻り値はtrue又はfalseって書いてあるのに訳判らん値戻したり
自分でその関数使う時もif(IsHoge==true)で評価したりif(IsHoge==false)だったり
場所によってまちまちで訳判らん誤作動起こしまくってた

619 :仕様書無しさん:2006/12/15(金) 20:06:30
>>618
変なの居なきゃ、そんな苦労も要らないんだけどねぇ…
仕事してると、冗長かもしれないけど誰でも読めるコード>綺麗で簡潔なコードだね。

620 :仕様書無しさん:2006/12/15(金) 21:07:53
if ((((((a == b) == true) == true) == true) == true) == true)


621 :仕様書無しさん:2006/12/15(金) 22:36:29
>>619
そうはいっても1画面ですむコードを1k、2kと書かれた日にゃー。

622 :仕様書無しさん:2006/12/16(土) 22:05:14
やっぱ同じ処理の繰り返しが多いコードかなー


623 :仕様書無しさん:2006/12/16(土) 23:17:12
(1)、(2)、(3)、(4)は処理内容はそれぞれ全然違うんだが、処理内のエラーチェックは
ほとんど同じで、全てベタ書きでコピペとか、結構ありがちだな

if (コードがAの場合){
  // (1) 200行ほどの糞コード
} else if (コードがBの場合) {
  // (2) 200行ほどの糞コード
} else if (コードがCの場合) {
  // (3) 200行ほどの糞コード
} else {
  // (4) 200行ほどの糞コード
}

あと、超多重ネスト
if()
 for()
  if()
   while()
    if()
     if()
      for()
       if()
        if()
         if()

とか、何の冗談かと…

624 :酔いちくれ ◆J0rwikii8c :2006/12/16(土) 23:36:01
>>623
くそコボラーが血迷ってCなんかに手を出すとそうなる。


コボラーは一つのcファイルのに延々と下手すれば1メガ以上
mainに書き連ねる。

625 :仕様書無しさん:2006/12/16(土) 23:39:21
int val;
str = String.valueOf(val);
if(str.equals("0")){
}

626 :仕様書無しさん:2006/12/16(土) 23:57:13
>>624
その遺伝子は近年、携帯Javaアプリ屋に隔世遺伝したよ。
1メソッド2000行超、1クラス5万行超って……

627 :仕様書無しさん:2006/12/17(日) 00:11:49
>>626
携帯アプリは仕方がない。
パフォーマンスを稼ぐ都合上、
インライン化やクラス数の抑制を行わなければいけないからな。

もっとも、それを言い訳にしている節もあるから、どうと言い切れんが

628 :仕様書無しさん:2006/12/17(日) 00:17:52
ソースファイル丸ごとコピペしてきて、
使わない関数やグローバル変数がコメント化すらされないでそのまま残ってるソース。
理由を聞いたら、どうもそいつには使われてるかどうかが判断がついてないらしい。
ヘタというよりコード書いちゃいけないレベルだな。

629 :仕様書無しさん:2006/12/17(日) 00:18:30
>>627
javaで、それはないんじゃないの?

1メソッド2000もアホだけど、5万行の1クラスって・・・

javaのoopの意味ないじゃん・・・

630 :仕様書無しさん:2006/12/17(日) 00:40:48
>>628
もし使われているならば、外したらコンパイルすら通らなくなるはずだし。
ものを知らないか、自分でものを考えることができんのだろうな。

631 :仕様書無しさん:2006/12/17(日) 01:38:25
Linux 用C言語ソースでこんなの発見。

system("touch hoge");

どうやら utime() 関数を知らなかったようだ。
(Solaris とかでも昔からある、というか、UNIXの標準的な関数だと思ったが・・・)
てかPOSIXの関数かこれ。


632 :仕様書無しさん:2006/12/17(日) 06:15:01
>>624
そうだな。
コボラの書いたネスト20個とか見たことある。

633 :仕様書無しさん:2006/12/17(日) 10:50:21
switch case 文で、
caseの数値に、10進と16進が混在しているのに唖然。

634 :仕様書無しさん:2006/12/17(日) 13:47:20
そもそもcaseラベルに即値を書くなよと

635 :仕様書無しさん:2006/12/17(日) 14:00:47
>>629
昔のiアプリやってたから分かるけどそれはしょうがないよ。クラス増やすとそれだけで
数kバイトjarのサイズが増えるから。

サイズ制限がきついからどうしても1つのクラスに大量に処理を書かなきゃならんかった。
jarファイルの上限が32kバイトとかもうアボガド。

まぁ最近のはだいぶ増えてきてるらしいけどね。

636 :仕様書無しさん:2006/12/17(日) 14:19:22
>630
ひょっとすると、リフレクションしまくりだったりしてw

637 :仕様書無しさん:2006/12/17(日) 14:24:02
>>630
コピペってきたソースはコメントアウトすら必要ないぜw
使うもん以外全部削除しとけ。不具合の元だ

638 :仕様書無しさん:2006/12/17(日) 16:31:09
>>630
大規模だったり、高度なプログラムになると
単純にコンパイラだけを頼りにはできない罠。

高度なものの例だと関数が仮想化されてたり、ちょっと考えただけでも
コンパイルは通るけど実行時に致命的なバグが発生するものはたくさんある。

大規模なものの例だと
特殊なデータを受け取ったときだけ必要なプログラム等は要求仕様によって
いる場合もあればいらない場合もあるし、実際はもっと複雑になる場合が多い。
要はケースバイケースだろ。
決めつけるのはいかんと思うぞ。



639 :仕様書無しさん:2006/12/17(日) 17:04:18
>>637
そもそも、必要なものだけコピペしろ…と思うよ。


最低でも関数単位、できればロジックだけとかにしてね
後で尻拭いしないともいけない人の身にもなってね。


640 :仕様書無しさん:2006/12/17(日) 17:05:58
>>635
505系と506系は確か30KBが上限だったかと。
700系と900系と901系は100KBが上限の筈だが。

641 :仕様書無しさん:2006/12/17(日) 17:06:58
>>638
その高度なものや大規模なものを整理して使えないなら止めとけw

642 :仕様書無しさん:2006/12/17(日) 17:09:19
>>634
リテラル値の方が関数の返り値より実行速度が上がるわけだし、
十分なコメントが付いていればいいのではないか?

と言いかけて、定数表記の方がマシだなぁと思ってみる。

//ところで「即値」って響きがすごく懐かしいんですが、そちらでは常用しているのでしょうか?

643 :仕様書無しさん:2006/12/17(日) 17:27:31
immediateは即値って言わんか?

644 :仕様書無しさん:2006/12/17(日) 17:58:47
>>641
正論だが、実際の開発現場では諸々の事情で
そうはなっていないコードが大多数な訳で、
お前のように必ず理想的なコードを書く人間だけではない限りは
机上の空論に近いと思うがね。

理想と現実の違いを考えても、尚且つ
お前は妥協なく理想的なコードを必ず書くなら、
もう言う事は何もないよ。



645 :仕様書無しさん:2006/12/17(日) 18:21:57
>>644
あぁ、俺は理想と現実の違いを考えても、尚且つ
妥協なく理想的なコードを必ず書けるよw

もう何も言うなよな。



646 :仕様書無しさん:2006/12/17(日) 19:09:45
>>645
日本語、大丈夫か?
書けると書くじゃ意味が全然違うぞ。

かなりの自信家のようだから技術は持ってるんだろうけど、
これからずっと妥協なく理想的なコードを書くというのは
人間業じゃないくらい荒行だぞw

そういう事を易々と宣言するのも精神年齢が低そうだけど
必ず書くなら、言う事は何もないよ。



647 :634:2006/12/17(日) 19:32:50
ちなみに、某社のカーナビのソース。

648 :641:2006/12/17(日) 21:29:02
>>645
代執乙です。

>>644
>正論だが、実際の開発現場では諸々の事情で
>そうはなっていないコードが大多数な訳で、
>お前のように必ず理想的なコードを書く人間だけではない限りは
>机上の空論に近いと思うがね。
そんな環境じゃ当然、一人で組んでるわけではないよな?
それでも担当範囲とかあるんだろ?
まずは御前が整理しなけりゃ掃除ははじまんねーんだよ。
やる気ねーやつはすぐ机上の空論とかぬかすからな…。
いずれ使いまわし出来ねーだれも手がつけられないコードになるんじゃね?

>理想と現実の違いを考えても、尚且つ
>お前は妥協なく理想的なコードを必ず書くなら、
>もう言う事は何もないよ。
少しでもマシなコードにする努力はしてるぜ。
組むだけ組んでバックレ前提プロジェクトでもな!

649 :仕様書無しさん:2006/12/17(日) 22:38:07
>>648
それができるプロジェクト規模/開発残り時間があるなら誰も苦労はしない

650 :仕様書無しさん:2006/12/17(日) 22:51:03
こういう話になると、限られた中で少しでも理想に近付こうとする人間と
届かない理想など最初から目指さない人間の水掛け論にしかならんなぁ。

651 :仕様書無しさん:2006/12/17(日) 22:53:40
>>642
お前の使ってるC言語はcaseラベルに関数書けるのか
すげえなw

652 :644:2006/12/17(日) 23:18:27
>>648
妄想が強烈すぎて、まともな返答は難しくなってきたが
仕事はコンセンサスを取りながら進めているし、
やる気もあるし、
バックレ前提の仕事でもないし、
掃除が始まらないって
お前は何を言ってるんだ?
それよりも、自分だけはしっかりコードを組もうとしてるから
コードの品質が悪くても特別に免罪みたいな
俺様思考を読み取れるが、
お前は多少は他の人よりも優秀なんだろうが
お前の俺様思考に迷惑を受けた人も過去にいただろう。

たまにはその事を思い出して
その俺様思考をどうにかしろ。



653 :仕様書無しさん:2006/12/17(日) 23:38:57
時間さえいくらでもくれるというなら、自身を持ったコーディングだけし続けられるけどね。
妥協と妥協しないで時間かかることを比較して、「妥協を選べ。時間がない。」と言われたら妥協せざるを得ないな。
理想に燃えると、神様が一日を72時間にしてくれるわけじゃないしね。
趣味でやってんじゃなく仕事なんだしな。今の話の流れって、趣味でやってる人の話なの?

654 :仕様書無しさん:2006/12/18(月) 00:00:41
>>653みたいのが突然動き出すエレベーターのコードを書いたんだろーなー。

655 :仕様書無しさん:2006/12/18(月) 00:47:31
>>653
でもさ。普通、仕事って常に「妥協を選べ。時間がない。」だろ?

で、俺の見る限りでは、
そういう「仕事」ばかり10年以上やってきた人の知識って、
一般的に恐ろしく低レベルで止まってしまっている様に
見受けられるんだが、そこら辺はどうよ?


656 :仕様書無しさん:2006/12/18(月) 01:37:12
1日を72時間にすることはできんが、優秀なプログラマとそうでないプログラマの間には
しばしば3倍どころでない生産性の差があるというのもまた真なり。

将来の数十時間を節約するために現在の数時間を投資するか否か、結局「先を読む力」に
かかっているということだろう。上手く読めれば褒められ、読めなければ罵られる。
とはいえ、褒められることはあまりないけどな。
「デスマーチ」などの言葉に代表されるように、失敗したプロジェクトは人の記憶に残り、
成功した(特に問題が起こらなかった)プロジェクトは忘れ去られるから。

657 :仕様書無しさん:2006/12/18(月) 01:49:39
>>654
「動けば良いから三日で全部仕上げろ、あちこちからコピペしてきたコードあるから、それはそのまま使え」
とか言われたらそうなるだろうね。
「納得できる仕事をさせてくれ」って言っても「三日以内で仕上げられるなら好きにしろ」だと、どうしようもない。
どんな仕様か詳しく知らないコードを使い回すのは、怖すぎるから嫌だけどね。

>>655
職場だけで勉強させて貰える環境なら良いが、そうでなければ休みを使って自分で勉強することになる。
責任感や好奇心やモラルや向上心が低い人は、レベルが低いままだろうね。
俺はまだ技術は低いかもだが、向上心は失ってない。

>>656
短い時間で高いレベルのものを吐き出すことが出来るようになりたいとは、日々思ってるよ。
頑張る。

658 :仕様書無しさん:2006/12/18(月) 01:57:12
> そういう「仕事」ばかり10年以上やってきた人の知識って、
> 一般的に恐ろしく低レベルで止まってしまっている様に
> 見受けられるんだが、そこら辺はどうよ?

同意。そしてマに限ったことじゃない。
コボラがしばしば叩かれるのはこのせいかと思われ。

10年経たずに、10分で妥協の仕方だけを考えるようになる。
せめて半日くらい「どうやったら妥協を少なくできるか」を考えて欲しい。

659 :仕様書無しさん:2006/12/18(月) 02:21:30
>>658
そんな人ばかりじゃないと思うんだけどなぁ…
個性出しにくい言語だけど、仮にもマなんだから、言語仕様にだけ捕らわれた思考はしないんじゃない?
いや…生粋のコボラじゃないから、知らないけどさ。

660 :仕様書無しさん:2006/12/18(月) 02:39:57
今まで、一緒に仕事したことある子ぼらは5人ぐらい。
そして内訳は
  まったく使い物にならないクズ・・・2人(34歳、36歳)
  知識はあまり無いが、そこそこまとも(普通に大丈夫)・・・1人(38歳)
  知識はそれなり、それなりに仕事できる・・・1人(42歳)
  かなり使える。一緒に仕事してて嬉しい・・・1人(40歳)

意外にまともな人とばっかり仕事してるかもしれん。


661 :仕様書無しさん:2006/12/18(月) 02:45:43
>>656
優秀な人とそうでない人の差が大きく違うのは同意だが
褒められるはまだしも、罵られるって
職場環境としてかなり問題があると思うぞ。
少なくても平均以上の人とは協力すべき。

というか、他人を罵倒してなんぼという価値観は
素直に同意できないな。



662 :仕様書無しさん:2006/12/18(月) 02:58:21
>>660
比率的にどこもそんなもんじゃないのかね?
へたなコードを書く人も多いのかもしれないけど
経験も長いだろうし、SEとしての知識は結構あるんじゃないの?

完全にスレ違いだけどなw



663 :仕様書無しさん:2006/12/18(月) 04:37:04
Dim lngInt As Long

664 :仕様書無しさん:2006/12/18(月) 09:00:10
>659
勿論ちゃんと考えられるマなら
COBOLでもきちんとしたコードは書けるだろうが
そういうマは基本的に別の言語に走ると思う

関数の定義出来ない環境多いしさ
知れば知るほど呆れる言語なのよ

665 :仕様書無しさん:2006/12/18(月) 11:40:03
まあ・・・そんなにCOBOLのことを責めるなや。
単なる化石なんだから。言語自体に罪はないよ。
問題はその言語を使いつづけるという決意にあるのだろうな。

666 :仕様書無しさん:2006/12/18(月) 12:03:49
>652
漏れは以前掃除をしようとしたら「テスト工数無いからダメ」と言われた。
「動いてるものはいじるな」が基本の世界もあるって事だ。

# そんな方針でOS書いてるからSUNに性能2桁も引き離されて最終的にアボーンだったわけだが。


667 :仕様書無しさん:2006/12/18(月) 16:33:54
※ 念を押しておくがJava

if(hoge(foo) != false){ ...

もう見慣れたと思っていたが、やはり一瞬眩暈がした。
書いた人は直観主義者なんだろうと思っておく。

668 :仕様書無しさん:2006/12/18(月) 18:05:30
二重の嫌がらせ
または、ちょっとしたジョーク

ジョークだと思っとけば良い

669 :仕様書無しさん:2006/12/18(月) 18:57:52
>>667
直観主義者なら
if(hoge(foo) == true) {} else { ...

と書くんじゃあるまいか


670 :仕様書無しさん:2006/12/18(月) 19:34:11
>>669
頭の中で(偽じゃなかったら)と考えたものをそのままコードにした辺りが、直感主義なんだと思ってみた

671 :仕様書無しさん:2006/12/18(月) 20:03:31
>>663
ハンガリー人が卒倒しそうだなw

672 :仕様書無しさん:2006/12/18(月) 21:06:10
ハンガリー人との因果関係を教えてくれ
気になって眠れん

673 :仕様書無しさん:2006/12/18(月) 21:47:39
if ( ( B == A ) && ( Y == X ) )

どうなんでしょう?
上の中括弧つけろといわれたんだけど
論理演算と比較演算のプライオリティは半ば常識だと思ってたんだけど。。。

674 :仕様書無しさん:2006/12/18(月) 21:57:44
>>673
単に見やすさじゃね?

675 :仕様書無しさん:2006/12/18(月) 21:57:48
いや、比較演算は所詮引き算だし、論理積の方が順序が上がる可能性がなくは無いと思うぞ。
仕様に因るが。

676 :仕様書無しさん:2006/12/18(月) 21:58:04
可読性の問題でしょ

677 :仕様書無しさん:2006/12/18(月) 21:58:31
wっうぇww4秒差ww

678 :仕様書無しさん:2006/12/18(月) 21:59:40
>>675
引き算なのか?

679 :仕様書無しさん:2006/12/18(月) 22:02:04
>>678
アセンブリ言語を良く使う人にとっては常識。
引き算して、桁貰いがあるか、答えが0か、それ以外か とかで大小を判別する。

高水準言語ばっかりやってると分からんだろうが。

680 :仕様書無しさん:2006/12/18(月) 22:04:04
>>679
とりあえずスレ違いなので誘導。
http://pc8.2ch.net/test/read.cgi/tech/1148402614/

681 :仕様書無しさん:2006/12/18(月) 22:11:30
>>680
やった事に否定はしないが、ム板かよ。

682 :仕様書無しさん:2006/12/18(月) 22:18:05
なるほど、俺の中では無いほうが(かっこの頭とケツを追っていくのが苦手で)判りやすいと思ってたんですが、
実際は逆なのですね。ありがとう。

>>679
それは初耳でした。奥が深いものですね、

683 :仕様書無しさん:2006/12/18(月) 22:41:43
誰が見ても(他言語の仕様と混同しちゃう人もいるかも…いや、居ないだろうけど世の中広いし居るかもしれない)、優先度がはっきりするように()付けとく方が、他の人が保守したり手を付けるときにミスが減りやすい…………かもしれない。
まぁ、おまじないだよね。
i+p*3+num*2+iとかでも、四則演算の優先度なんてわかりきっててもi+(p*3)+(num*1)+iとしといた方が、間違いが起こりにくい…………と良いなぁ、みたいな。
ミスとかじゃなく、わかってやってるからねって意思表示と、パッと見の見やすさ。

684 :仕様書無しさん:2006/12/18(月) 23:06:25
>>631
utime()よりtouchのほうが簡単だろ。。

685 :仕様書無しさん:2006/12/19(火) 00:00:24
なんで、俺のコーディングルールがこのスレに沢山書いてあるの?


686 :仕様書無しさん:2006/12/19(火) 00:32:04
>>684
>>631は「というか、UNIXの標準的な関数だと思ったが・・・」
ってさも当然のように言って、自分が優れている事を誇示したいだけだから。

687 :仕様書無しさん:2006/12/19(火) 00:44:59
C言語の演算子の優先順位は一部直感的に違和感あるのがあるので
それで他人がはまってたの見て以来、括弧は極力つけるようにしてる

688 :仕様書無しさん:2006/12/19(火) 02:15:20
そうだね。たしか段階数は14だか17だったね。
自分はそんなもの記憶できる人間じゃないし

689 :仕様書無しさん:2006/12/19(火) 04:33:17
>>631
俺んとこの後輩が書いたのみたいだw perlだけど。

system("cat hoge");

とかなんかは普通にやる。

俺が書いておいたシェルスクリプトが、

system("bash hoge.sh");

で起動されていたのを発見したときはヘコんだ。


690 :仕様書無しさん:2006/12/19(火) 08:20:16
でも、有り物のツールを応用するって、むしろ好ましいスタイルじゃね?

691 :仕様書無しさん:2006/12/19(火) 09:28:26
いやいや、問いに解答しただけでスレ違いはないだろ。

692 :仕様書無しさん:2006/12/19(火) 12:50:45
>>691
遅レスするなら、安価つけなよ。
仕様ってわけじゃないから、強制はしないけど。

んで、同意。
レスに質問来て答えたら「スレ違い」と言われ、誘導されたのが違う板とか、あまりに亜空間過ぎて笑えた。
意味不明なGOTO文みたいだし、>>680のコード(判断処理と誘導)が下手すぎる。

693 :仕様書無しさん:2006/12/19(火) 15:02:28
>>675 の時点でトンチキ見解だしなあ。

694 :仕様書無しさん:2006/12/19(火) 15:09:35
仕様がおかしいなんてのは、アフリカではよくあること

695 :仕様書無しさん:2006/12/19(火) 18:11:50
>694
日本から見て西とか北西のとある国では、もっとだ

696 :仕様書無しさん:2006/12/19(火) 18:34:21
とある国では
仕様がおかしいどころか、仕様が無い
その時々で、都合が良い仕様を捻り出す
誰にも通じない、誰にも認めてもらえない仕様

最凶

697 :仕様書無しさん:2006/12/19(火) 19:41:45
わざわざ西に行かなくても、日々そんな状況ですが何か?

698 :仕様書無しさん:2006/12/20(水) 01:30:16
SendMessage
こんなクラス名があると萎える。
クラス名は名詞にしろと。
MessegeSenderだろと。


699 :仕様書無しさん:2006/12/20(水) 07:45:34
>>698
所謂機能分解ってアンチパターンだな。
おそらく設計書の段階で「メッセージ送信」というアクティビティが定義されていたのだとおもわれ。

700 :仕様書無しさん:2006/12/20(水) 11:22:56
「送信に使うメッセージ」だと直感してしまった

701 :仕様書無しさん:2006/12/20(水) 12:24:56
VCでビルドできません!!!

702 :仕様書無しさん:2006/12/20(水) 15:29:15
>>698
Winのこと?

703 :仕様書無しさん:2006/12/20(水) 18:52:37
>>700
俺も。
SendMessageってメソッドとして見たら
「メッセージを送る」メソッドだけど、クラスとして見たら
「送信するメッセージ」のクラスだよな。
どんなメンバ持ってるのか知らんけど。

704 :仕様書無しさん:2006/12/20(水) 21:17:23
>>698

名称なんてどうでもいいよ、アメリカ人じゃないし。

中身が分かりやすければ名前なんざ適当でいい。

それが嫌なら自分で命名規約作ってプロジェクトメンバーに周知徹底させろ。

既存メソッドも全部その命名規則に改名させろ。

もちろん、そんなのに会社がコストかけるわけねーから、

休憩時間もしくはサービス残業でやれよ。

後、過労死されたりしても会社に迷惑かけるから死ぬなよ。

それと当然分かってると思うがそのくだらん名称変更で劣化やバグ埋め込んだら責任取ってクビな。

705 :仕様書無しさん:2006/12/20(水) 21:29:44
SendMessageAction extends ActionBase

とかだったらまだ分からんでもない

706 :仕様書無しさん:2006/12/20(水) 21:49:34
char *str = {'s', 't', 'r', 'i', 'n', 'g'};
// 実際はもっと長い文字列

意 味 わ か ん ね え
何で普通に文字列リテラルで初期化しないのか…

707 :仕様書無しさん:2006/12/20(水) 21:51:42
'¥0'がないのなら、C文字列じゃなくてあくまで文字の配列なのかも
しれない。


708 :仕様書無しさん:2006/12/20(水) 22:00:46
>>707
そうだな。俺もそう思うかもしれない
でもそのずーーーーーーっと後でprintfしてるんだぜ…
出力は勿論stringフフフフフフフフフフフフフフフフフフ

709 :仕様書無しさん:2006/12/20(水) 22:07:09
わろすフフフフフフフフフフフフフフフフフフ

710 :仕様書無しさん:2006/12/20(水) 22:22:48
そりゃひでえフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフ

711 :仕様書無しさん:2006/12/20(水) 22:24:45
わかった、grepできないようにしたいんだ。

712 :仕様書無しさん:2006/12/20(水) 22:31:36
じゃあ '\0' も入れろやw

713 :仕様書無しさん:2006/12/20(水) 22:52:20
707さんと同じ感想だったのに、そんな落ちかorzフフフフフフフ

714 :仕様書無しさん:2006/12/20(水) 22:54:06
>>712
よし、コメントは隅っこに小さく書けばいいんだな。

// 21時以降の通話は(ry

715 :仕様書無しさん:2006/12/20(水) 22:55:14
フフフフフ

716 :仕様書無しさん:2006/12/20(水) 23:34:18
ワロタフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフ

フって\0が見つかるまで永遠につづくんかね?

717 :仕様書無しさん:2006/12/20(水) 23:35:57
printfの定義からすればそう

718 :仕様書無しさん:2006/12/21(木) 01:00:48
これは酷いフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフ

719 :仕様書無しさん:2006/12/21(木) 01:03:26
ここはフフフインターネッツですねフフフフフフフフフフフフフフフフフフフフフフフフ

720 :仕様書無しさん:2006/12/21(木) 01:28:02
フフフフフフフフフフフフフフフプフフフフフフフフ

721 :仕様書無しさん:2006/12/21(木) 01:45:28
いつまでやってんだよハゲフフフフフフフフフフフフフフフフフフフフフフフフフフフフ

722 :仕様書無しさん:2006/12/21(木) 01:53:52
>>704
いや、命名規約とかの問題じゃなくて。
クラス名に動詞を使ったりする人は、
オブジェクト指向がわかってないんだなー。
って思うんだよ。

そーゆー人の設計、大概ぐだぐだだし。。。

723 :仕様書無しさん:2006/12/21(木) 02:03:33
命名規則が適当で一貫性のない人は、コードも行き当たりばったり。
識別子名にスペルミスが多い人は、コードの中身もずさん。
これは9割方真実である。

724 :たかとし:2006/12/21(木) 02:09:33

ばっくれるために意図的にコードを適当に書いている場合もあるぞ

725 :仕様書無しさん:2006/12/21(木) 04:40:41
>>706
'\0'を入れないことでprintfする際に長い文字列が表示されることを期待していて
かつ本当はもっとそれよりも長い文字列なんだよ、といいたいんでは

726 :ドッブルギャンガフフフフフフフフ:2006/12/21(木) 09:51:40
やぁ。久しぶり。

727 :仕様書無しさん:2006/12/21(木) 10:11:44
>>726
遊んでた頃はなんでこんな名前になってんだと思ってたけど
プログラムある程度わかった今だから笑える事だな。

メモリは大抵の処理系では0xCCで初期化されてるのかな。

728 :仕様書無しさん:2006/12/21(木) 11:09:36
VCのデバッグモードだけだろ

729 :仕様書無しさん:2006/12/21(木) 11:34:46
>726
RO?

730 :カタシムリ:2006/12/21(木) 12:41:14
>729
呼んだ?

731 :仕様書無しさん:2006/12/21(木) 12:45:03
フフフフフフフフ

732 :仕様書無しさん:2006/12/21(木) 13:59:56
>>703
何が問題なのか一瞬分からなかったが、クラス名ね。うんわかった。

733 :かにニッパ:2006/12/21(木) 20:26:51
>730
やっぱりそうか

734 :仕様書無しさん:2006/12/21(木) 20:27:48
ごめん。くだらんネタでageちった。死んで詫びる。

735 :仕様書無しさん:2006/12/21(木) 20:59:51
0xccってヒープじゃなかったっけ?フフフフフフフフフフフフフフフ

736 :仕様書無しさん:2006/12/21(木) 21:31:45
ヒープは.0xcdじゃね?

737 :仕様書無しさん:2006/12/21(木) 23:47:41
0xccは 11001100

738 :仕様書無しさん:2006/12/22(金) 00:34:01
C++ってあんましおぶじぇくと嗜好しないほうが使いやすいよな・・・
Javaでいいや。

739 :仕様書無しさん:2006/12/22(金) 00:39:23
例外処理が書いてないコード。あと、すぐ上に似たメソッドがあるのに
影響範囲増えるからとかめんどいとかの理由でコピペして名前と処理をちょっと変えるだけのコード

740 :仕様書無しさん:2006/12/22(金) 15:52:04
>>739
言語や使用している箇所にもよりけり。


それだけじゃぁね〜・・・。



741 :仕様書無しさん:2006/12/22(金) 20:01:06
影響範囲を全てフォローしきれん状況もあるしなフフフフフフフフフフフフフフフ

742 :仕様書無しさん:2006/12/22(金) 20:57:19
影響範囲を変えることで仕様変更やバグ潰しの為の工数がフフフフリ

743 :仕様書無しさん:2006/12/22(金) 21:56:41
winのapiでもexのついたやつがたくさんあるな。

744 :仕様書無しさん:2006/12/23(土) 00:23:33
いっそのこと、WindowsEx

745 :仕様書無しさん:2006/12/23(土) 02:57:28
Windowsフフフフ

746 :仕様書無しさん:2006/12/23(土) 07:19:48
ShiftJIS禁止

747 :仕様書無しさん:2006/12/23(土) 13:46:03
>>739
似てると同じじゃ大違い

748 :仕様書無しさん:2006/12/23(土) 16:42:04
Object checkNull( Object o ) {
    if( o == null ) {
        return null;
    }
    return o;
}

void foo( String s ) {
    if( checkNull( s ) == null ) {
        return;
    }
    // :
    // : 処理
    // :
}

749 :仕様書無しさん:2006/12/23(土) 17:06:09
ヘタつーか最適化されて消えそうなコードだな。


750 :仕様書無しさん:2006/12/23(土) 21:51:57
MFCのコードってヘタで最適化されて消えそうなコードが多いよね。
Microsoftの技術者の中でもトップクラスの人たちが書いてるにもかかわらず。

751 :仕様書無しさん:2006/12/23(土) 21:59:56
ヒント:メンテしやすさ優先

752 :仕様書無しさん:2006/12/23(土) 22:37:40
そう思ってる奴は頑張って勉強してトップクラスの人たちの負担を減らしてあげてくれ

753 :仕様書無しさん:2006/12/23(土) 23:01:19
やーだね

754 :仕様書無しさん:2006/12/24(日) 00:02:40
まー、最適化されて消えるようなコードでも、読みやすさに貢献するような
ものならいいんだけどねぇ。


755 :仕様書無しさん:2006/12/24(日) 02:19:26
        / ̄ \
    __0⌒>   ヽ
   /   ∩⊂ニニニ⊃∩
 /     | ノ      ヽ
|     /  ●   ● |  メリークリクマース!
|     |    ( _●_)  ミ
|    彡、   |∪|  、`\
|   / __  ヽノ /´>  )
 \  (___)   / (_/
   \   |      /
     ̄ ̄|  /\ \
       | /    )  )
       ∪    (  \
             \_)


756 :仕様書無しさん:2006/12/24(日) 07:18:52
むしろ最適化で消してもらうのを目的で冗長に書いたりすることもあるような、ないような

757 :仕様書無しさん:2006/12/25(月) 11:54:16
>>750
>Microsoftの技術者の中でもトップクラスの人たちが書いてる
ように見えるか?あれが?

758 :仕様書無しさん:2006/12/25(月) 12:18:28
コーディング規則が無いかのようなコードを書くなんて
よっぽどな技術と自信に裏打ちされたものだと思ってましたが何か?

1文字、2文字変数が多いなんて
誰からもレビューを受けず、誰からも注意されないなんて
よっぽど偉い人たちなので誰も言えなかったものだと思ってましたが何か?

いきなりクラスをmemsetで0クリアなんて
C++に精通したプロふぇっ所なるしか出来ない業だと思ってましたが何か?

759 :仕様書無しさん:2006/12/25(月) 12:53:33
いえ。何も。

760 :仕様書無しさん:2006/12/25(月) 16:18:38
クラスとインスタンスの区別ができていない>758に拍手!

761 :仕様書無しさん:2006/12/25(月) 17:32:18
std::vector<musaiclass*> vpmusai;

いやぁぁぁぁぁ

762 :仕様書無しさん:2006/12/26(火) 10:26:03
>>761
何がいやなのか判らん。

763 :仕様書無しさん:2006/12/26(火) 14:08:34
musaiclassだからじゃね?

764 :仕様書無しさん:2006/12/26(火) 14:16:43
kakkoiiclassなら問題ないってことか

765 :仕様書無しさん:2006/12/26(火) 14:44:16
vpmusaiを破棄してもmusaiclassのデストラクタが呼ばれないから?

だとしたら面倒臭がりってだけか。

766 :仕様書無しさん:2006/12/26(火) 15:21:47
C++しばらくやってないんだけど
vector<musaiclass&>
はアリだっけ?


767 :仕様書無しさん:2006/12/27(水) 00:21:20
×  vector<musaiclass&>
○  vector<kakoiiclass&>


768 :仕様書無しさん:2006/12/27(水) 10:28:40
>>766
インスタンスが別管理になるけど、それでよければアリ。

769 :仕様書無しさん:2007/01/02(火) 22:44:56
>>761
メンバとしてならありかもな。
単体ではちょっと。

770 :仕様書無しさん:2007/01/11(木) 01:34:31
http://pc10.2ch.net/test/read.cgi/prog/1163062263/28-33

771 :仕様書無しさん:2007/01/18(木) 00:16:09
string(string(FOO)+string(BER));
vector<vector<vector<vector<boo>>>> v;

772 :仕様書無しさん:2007/01/18(木) 15:28:14
>>771
そもそもコンパイル通らないし。

773 :仕様書無しさん:2007/01/18(木) 18:17:40
int i,j;
をループ変数以外に使う奴。

774 :仕様書無しさん:2007/01/18(木) 23:17:06
まず i, j, k ときて、流石に l を使うのは気が引けたのか
ii, jj, kk。「おいおいまさか……」と思ったが、期待を裏切ることなく
iii, jjj, kkk, ……

775 :仕様書無しさん:2007/01/18(木) 23:24:19
i0, i1, i2, i3, i4, i5, i6, i7, i8, i9, ia, ib, ic, id, ie, if, ・・・

776 :仕様書無しさん:2007/01/19(金) 00:35:23
array[ hoge[ i + j ][ foo(j) ] ]

配列要素の中に別の2元配列やら処理がイパーイ



777 :仕様書無しさん:2007/01/19(金) 02:14:30
>>776
arrayよりhogeのほうが容量がでかかったりする悪寒。
間接参照構造なんか作らずhogeにデータ入れたらええやん、みたいな。

778 :仕様書無しさん:2007/02/06(火) 22:00:36
Try
  …(数百行のコード)
Catch
  MsgBox("予期せぬエラーが発生しました。")
End Try

779 :仕様書無しさん:2007/02/06(火) 22:07:21
vbに限らずそれはよくある

780 :仕様書無しさん:2007/02/07(水) 00:13:06
>>778はVB6だと

Private Sub Hoge()

On Error Goto ErrTrap

 ・・・(数百行のコード)

Exit Sub

ErrTrap:

 MsgBox("予期せぬエラーが発生しました。")

End Sub

781 :仕様書無しさん:2007/02/07(水) 00:54:09
>>778-780
あるあるあるwww

782 :仕様書無しさん:2007/02/07(水) 06:52:13
UIにあたる上位階層では、例外をキャッチして何かしらの
アクションをせねばならぬと思う。

しかし・・・しかし、下位階層で全ての関数で例外を握りつぶしたり、>778>780
のような実装をしている時は、殺意が芽生える。

例外テスト時とか悲惨な結果になる。

783 :仕様書無しさん:2007/02/07(水) 18:36:51
>>782
下層で、MsgBox("エラー")なんてやられると殺意覚えるな。

784 :仕様書無しさん:2007/02/07(水) 20:18:51
>>783
梶@IW の女性社員はそれがデフォでつよw

785 :仕様書無しさん:2007/02/07(水) 21:47:45
女は観賞用で、仕事にしゃしゃりでてきてほしくないな。

786 :仕様書無しさん:2007/02/08(木) 00:01:49
ブスならいいのか

787 :仕様書無しさん:2007/02/08(木) 01:37:22
ブスは存在禁止

788 :仕様書無しさん:2007/02/08(木) 02:44:52
>787
ピザデブは虹でも追いかけてろよキモイから。

789 :仕様書無しさん:2007/02/08(木) 08:56:58
>>788
ブスがキレた!!

790 :仕様書無しさん:2007/02/08(木) 13:37:41
>789
どうせピザデブどもは下層でも

Private Sub Hoge()

On Error Resume Next

  ・・・(数百行のコード)

On Error Goto 0

End Sub

とかやってるんだろ?クズが。

791 :仕様書無しさん:2007/02/08(木) 13:40:58
>>790
ブスがまたキレた!!

ブスはぶいびー限定らしいwww

792 :仕様書無しさん:2007/02/08(木) 13:55:55
VB
ブビ!!

793 :仕様書無しさん:2007/02/08(木) 15:19:08
>791
どうせピザデブどもはwebアプリでも

#!/usr/local/bin/perl

eval {

 ・・・数百行のコード

};

sub hoge
{
eval {

 ・・・数百行のコード

};

}

とかやってるんだろ?クズが。

794 :仕様書無しさん:2007/02/08(木) 15:40:27
ノリのいいブスだw

パールを選択するところもw

795 :仕様書無しさん:2007/02/08(木) 19:41:03
ブスは生存禁止

796 :仕様書無しさん:2007/02/08(木) 20:27:58
>794
ピザブタにパールじゃ何にも出来ない罠。

>795
ピザデブの生存は禁止しないがタコ部屋から出てくんな。

797 :仕様書無しさん:2007/02/08(木) 20:54:09
ぱっと見てどうかと思う>パールってカナで書くヤツ

798 :仕様書無しさん:2007/02/08(木) 20:58:19
>797
仰るとおり。ピザブタに言ってやってくれ。
まあ忠告もブタに真珠だろうけどな。

799 :仕様書無しさん:2007/02/08(木) 21:06:03
ブスがこのスレに居ついてるwww

800 :仕様書無しさん:2007/02/08(木) 21:15:13
こうまで必死なのはやっぱり、自分が呼ばれたと思って
>>788 でうっかり返事しちゃったからなのか。

801 :仕様書無しさん:2007/02/08(木) 21:35:51
ブスってたいてい性格もブスなんだよな

802 :仕様書無しさん:2007/02/08(木) 22:08:02
>>801
確かにww

ここに居ついてるブスも、文字だけで不快になるドブスwwwww

803 :仕様書無しさん:2007/02/08(木) 23:10:18
おまえら小学生か

804 :仕様書無しさん:2007/02/09(金) 08:57:36
さぁ、さぁ、空気を読みつつ面白いクソソースをさらして
いこうじゃないか。

ブスの次ネタに期待あげ。

805 :仕様書無しさん:2007/02/09(金) 12:31:31
 この前見つけたピザデブのクソコード

int hoge(int var, char *foo){
 int checkval;

 ・・・数十行のコード

/*---1999.08.14 連携の問題で動かない。リリース前にコメント外す By ピザデブ ---*/
/* checkval = other_modules_function( boo, puu ); */

 ・・・数十行のコード(checkvalは使ってない)
}

もうとっくにリリースしてるんですが、どうしてコメント外さないの?
ってか、使ってない復帰値拾ってるし。結局使わなかったならコメント自体消しとけYO。
こんなソースメンテするのヤダ。ピザデブは人の話を聞かないんだから。
しかし仕事だからやらねばな。orz

806 :仕様書無しさん:2007/02/11(日) 00:04:52
うちの10年選手のコード。
ちょっと書いたらあとはコピペ全部コピペしようとする。
別プロジェクトなのだが、一緒に仕事はしたくない。

if(IsAAA == true)
{
  Zura++;
  ZuraSyori(Zura);
  ReturnValue = HageSyori(1, 2, 3);
  if(ReturnValue == 4)
  {
     Zoumou(6);
     return 4;
  }
}
else {
  ZuraSyori(Zura);  
  ReturnValue = HageSyori(1, 2, 7);
  if(ReturnValue == 4)
  {
     Zoumou(2);
  }
}

return ReturnValue;



807 :仕様書無しさん:2007/02/11(日) 00:09:03
ハゲかよ

808 :仕様書無しさん:2007/02/11(日) 00:12:57
>>807
そう、30中盤で結構いっちゃってます。
タマに生えている毛みたいな感じでちょっと卑猥です。

809 :仕様書無しさん:2007/02/11(日) 00:30:04
>>806 ひまなんでリファクタリングしてやったぞ。

{
 if(IsAAA) {
 {
  return Ikumou(++Zura, 3, 6);
 } else {
  return Ikumou(Zura, 7, 4);
 }
}

muda Ikumou(Zura, ke, abura) {
 ZuraSyori(Zura);
 ReturnValue = HageSyori(1, 2, ke);
 if(ReturnValue == 4) Zoumou(abura);
 return ReturnValue;
}

810 :仕様書無しさん:2007/02/11(日) 04:37:43
//2の補数を計算する
(十数行のコード)

バグがあったので俺が
a = -a;
というように直した。

811 :仕様書無しさん:2007/02/11(日) 12:04:02
テラワロスw

812 :仕様書無しさん:2007/02/11(日) 16:01:52
ひまな>>809
{
 if(IsAAA){
  ++Zura;
  ZuraSyori(Zura);
  return Ikumou(3, 6);
 }else{
  ZuraSyori(Zura);
  return Ikumou(7, 4);
 }
}

muda Ikumou(ke, abura) {
 return HageSyori(1, 2, ke, abura);
}

muda HageSyori(fuke, kusi, ke, abura) {
 ...
 if(ReturnValue == 4) Zoumou(abura);
 return ReturnValue;
}
のコードとどっちが下手かの話がしたい

813 :仕様書無しさん:2007/02/12(月) 23:53:43
σ(・_・)の仕事場の話。
やっぱり「禿げ」はダメだなぁ。なんて言うか…美しくない…コードも頭皮もw
「禿げ」に限ってコピペ厨って思うのは、私だけ???

814 :仕様書無しさん:2007/02/13(火) 09:11:51
>>813
なんというか、仕事をする上ではハゲはイケメンよりずっと得。

チビ・デブ・ハゲは二十代でも見た目が部長クラスに見えるから
嘘でも威厳があるんだよね。
実力より5割増しで評価されてるような感じ?

漏れの部署のチビ禿げもコピペ厨。しかもVB6しかできない。

815 :仕様書無しさん:2007/02/13(火) 12:15:38
チビ・デブ・ハゲに加えて社長の息子とあっては、誰も口出しが出来ないウチの会社。

816 :仕様書無しさん:2007/02/15(木) 01:06:30
char buf[200];
unlink(FILE);
fp=fopen(FILE,"a+");
memset(buf,0,200);
sprintf(buf, "%d.", hoge );
sprintf(&buf[6], "%s\n", hoge2);
_write( _fileno(buf), buf, strlen(buf) );

どうしてくれようかと思った・・・

817 :仕様書無しさん:2007/02/15(木) 19:23:38
>sprintf(&buf[6], "%s\n", hoge2);
プレフィックスの文字数が決まってるならやりたくなる気持ちも解らんでは無い


818 :仕様書無しさん:2007/02/15(木) 19:52:28
いや、その前にここだろ。
_fileno(buf)
bufにファイル番号なんてねーよww

819 :仕様書無しさん:2007/02/15(木) 20:47:44
何故コードの後にあるものをその前に

820 :仕様書無しさん:2007/02/16(金) 10:39:20
>memset(buf,0,200);
これ入ってる時点でダメグラマ確定だろうに。

821 :仕様書無しさん:2007/02/16(金) 11:21:45
>>820
それはどうして?

822 :仕様書無しさん:2007/02/16(金) 11:40:03
>>821
直後にデータ(しかもNULターミネート文字列)を書き込むことにしか
使ってない領域をゼロフィルして何の意味があるのかと。


823 :仕様書無しさん:2007/02/16(金) 11:40:32
memset(buf,0,sizeof(buf));
にしろってことだろ。

824 :仕様書無しさん:2007/02/16(金) 12:05:37
char buf[200]={""};


825 :仕様書無しさん:2007/02/16(金) 12:12:22
>>824
その初期化って何か気持ち悪くて好きじゃない。

826 :仕様書無しさん:2007/02/16(金) 12:17:05
そうですか。
で?

827 :仕様書無しさん:2007/02/16(金) 12:58:16



828 :仕様書無しさん:2007/02/16(金) 15:36:15
>>816
そもそも、文字列中に '\0' が入るってどーゆーファイルなんだ。

829 :仕様書無しさん:2007/02/16(金) 15:36:43
あ、いや排卵な。失敬。

830 :仕様書無しさん:2007/02/16(金) 15:46:43
痔もちのこぼらー乙。

831 :仕様書無しさん:2007/02/16(金) 18:18:15
>>824
それコンパイルエラーじゃね?

832 :仕様書無しさん:2007/02/16(金) 18:32:52
>>831
文字列の初期化で問題なし。
こんな初期化しないけど。。

833 :仕様書無しさん:2007/02/16(金) 18:57:03
>>832
なるほど、確かに問題ないようだ。
使わない構文はドンドン忘れていくモノだなぁ…(こんなの覚えてなくていいけど)

834 :仕様書無しさん:2007/02/16(金) 19:55:47
>>828
フフフフフ

835 :仕様書無しさん:2007/02/17(土) 00:29:57
>>834
数間違えてるよ。
フフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフ
だよ

836 :仕様書無しさん:2007/02/17(土) 01:11:45
どうでもいいよフフフフフフフフフフフフ

837 :仕様書無しさん:2007/02/17(土) 01:43:31
>数間違えてるよ。
ぬるぽってるのに数もなにもないんじゃね

838 :仕様書無しさん:2007/02/17(土) 01:44:18
ガッフフフフフフフフフフフフ

839 :仕様書無しさん:2007/02/17(土) 13:50:02
>>813-814

ハゲ=コピペ厨でおk?


840 :仕様書無しさん:2007/02/17(土) 14:52:57
おkフフフフフフフフフフフフ

841 :仕様書無しさん:2007/02/17(土) 15:40:22
おまいら '\0' 忘れすぎw

842 :仕様書無しさん:2007/02/17(土) 16:07:10
アラアラウフフ

843 :仕様書無しさん:2007/02/17(土) 16:07:23
ここもフフフフスレになってるし・・・フフフフフフフフフフフフ

844 :仕様書無しさん:2007/02/18(日) 16:43:13
>>842
禁止フフフフフフフフフフフフフフフフフ

845 :仕様書無しさん:2007/02/18(日) 22:37:58
>>822
コーディング規約で決まってるから

846 :仕様書無しさん:2007/02/19(月) 10:29:39
その規約決めた奴に理由を聞きたいところだな。


847 :仕様書無しさん:2007/02/19(月) 11:32:55
>>846
「変数を初期化するのは当たり前だ」
という返答がくるよ。

848 :仕様書無しさん:2007/02/19(月) 20:34:29
以下、何が当たり前なのか議論が始まります

849 :仕様書無しさん:2007/02/19(月) 20:55:14
先発として「mallocしたメモリはfreeするのが当たり前」君が登場。


850 :仕様書無しさん:2007/02/19(月) 21:33:01
exit前にfreeするべきかどうか論争が再び。

851 :仕様書無しさん:2007/02/19(月) 23:14:00
あたたり前 の検索結果 約 1,060 件中 1 - 10 件目 (0.50 秒)

852 :仕様書無しさん:2007/02/19(月) 23:21:10
送りがなの本則の話がしたいのかな? 最小の語尾のみをかな書きするのが
本則だが、この場合は「当てる」という言葉もある関係上「た」から送る
ことになっていたり。


853 :仕様書無しさん:2007/02/19(月) 23:23:43
当たりで問題ねーだろハゲ
なんで中途半端に平仮名にしてぐぐってんのこのハゲ

854 :仕様書無しさん:2007/02/20(火) 00:06:12
おまいらがデバッグしているそれはソースじゃねーぞ。

855 :仕様書無しさん:2007/02/20(火) 00:11:58
そーすか

856 :仕様書無しさん:2007/02/20(火) 02:52:29
そーっすよ

857 :仕様書無しさん:2007/02/20(火) 03:13:33
その根拠のソースは?

858 :仕様書無しさん:2007/02/20(火) 03:45:11
そ〜すねぇ

859 :仕様書無しさん:2007/02/20(火) 18:07:05
俺の手が入ったコード

860 :仕様書無しさん:2007/02/28(水) 16:08:36
条件文を必ず1行で書きたがる奴がいて、どうやら1行で書けない奴は頭が悪いと思っているらしい。
可読性を重要視する俺は意味的に別な判定は次ブロックにしたりするんでこいつといつも衝突する。
何がそんなに気に食わないんかねぇ。




182 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)