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

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

1:デフォルトの名無しさん
06/08/12 01:56:11
禁止ネタ（超既出）
・長い関数
・深いネスト
・グローバル変数
・goto
・memset
・malloc - free
・局所ブロック
・サンプルコードのtypo
・記述スタイル
・関数・変数名

過去スレ
その４：ｽﾚﾘﾝｸ(tech板)
その３：ｽﾚﾘﾝｸ(tech板)
その２：ｽﾚﾘﾝｸ(tech板)
初代　：ｽﾚﾘﾝｸ(tech板)

2:デフォルトの名無しさん
06/08/12 02:00:16
まだやんの？

3:1
06/08/12 02:01:37
Cネタはもう枯渇気味なので、他言語ネタ求む。

4:デフォルトの名無しさん
06/08/12 02:27:23
Perlとか、上手い下手以前に手馴れた奴が書いたコードは解読不能

5:デフォルトの名無しさん
06/08/12 02:38:17
某スレより。
perl -e 'print $_[int(rand(@_ = <>))]' hoge.txt
たったこれだけで、吐き気がする。

6:デフォルトの名無しさん
06/08/12 02:39:42
AAにしか見えないなｗ

7:1
06/08/12 02:45:27
Perlの解読不能ネタはさんざん既出なんですが・・・

このスレ的には新しいので、どうぞお続けください。

8:デフォルトの名無しさん
06/08/12 02:53:35
そうさせていただきます

9:デフォルトの名無しさん
06/08/12 03:09:29
perlのrandってsrandしないでいいんだなぁ

10:デフォルトの名無しさん
06/08/12 04:18:23
java で

// double-checked locking を使う

とか自信満々にコメントされたエセ singleton に遭遇した時。

11:デフォルトの名無しさん
06/08/12 06:48:16
>>10
というか、そもそもdouble-checked　lockingってJavaで上手く動かないから論外だよな。
URLﾘﾝｸ(www-06.ibm.com)

12:デフォルトの名無しさん
06/08/12 07:30:30
前スレとはうって変わって、為になりそうな予感

13:デフォルトの名無しさん
06/08/12 07:59:14
>>5
どうみても上手い下手の問題ではないので却下。
sedやawkで修行してくればPerlは天国に見えるよ

14:デフォルトの名無しさん
06/08/12 08:15:37
VC++ で ExcelのタイプライブラリのC++ヘッダファイルを自動生成したら、ロクにビルドを通らないシロモノだった件。

15:デフォルトの名無しさん
06/08/12 09:47:10
>>5
それ、intは無くてもいいな。
perl -e 'print $_[rand(@_=<>)]' hoge.txt

まあ、「不必要なものが付いてる」と、「可読性を考えずに削る」、
どちらが『ぱっと見ヘタ』かは判らないけど。

16:デフォルトの名無しさん
06/08/12 10:43:24 BE:49923252-2BP(200)
>>1　基本的なネタを延々とやることにこのスレの意義があるのに。。。

17:デフォルトの名無しさん
06/08/12 11:31:37
>>14
それは、バグとか仕様不良の類なので、スレ違い。

18:デフォルトの名無しさん
06/08/12 12:02:45
>>11
ぱっとみてアホレスですな。

10はdouble-checked lockingはダメ解法と踏まえた上でレスしてるのは明白なんだから
お前の「というか」とか意味不明すぎる。

何が"というか"だよ。
知識披露厨乙。

19:デフォルトの名無しさん
06/08/12 12:06:03
> ・局所ブロック
局所ブロックって、if とか for とか while なしで、{ } でブロック作るやつのこと？

20:まあ、釣られた俺もなぁ～。(w
06/08/12 13:20:30
お前が >>10 でないなら、「明白」なんてことは言えない。

お前が >>10 なら、double-checked locking はヘタとか言う
以前の話でスレ違い。

どちらにせよ、>>18 のレスは「ヘタな煽り」にしか見えない。

21:デフォルトの名無しさん
06/08/12 13:22:07
結論：オレサマイガイ　ミンナ　ヘタクソ

22:デフォルトの名無しさん
06/08/12 13:25:19
>>20
明白だってこともわからんアホですか。
しかもスレ違いと思ったけどレスしましたってアホですか。

ホントお前アホだなぁ…。

23:デフォルトの名無しさん
06/08/12 14:22:39
明日でも昨日でもいいじゃんかよ！

24:デフォルトの名無しさん
06/08/12 14:46:53
>>22
ププッ、顔真っ赤だぞオ・マ・エ (w

25:デフォルトの名無しさん
06/08/12 14:52:06
ここはいいモヒカン族の養殖場ですね

26:デフォルトの名無しさん
06/08/12 15:55:13
>>24
アホの典型的負け犬の遠吠えレス乙
言い返せなくなるとソレだよな。

27:デフォルトの名無しさん
06/08/12 16:18:06
int Gethoge {
　　if(hoge=TRUE){return 1;}
　　return 0;
}

28:デフォルトの名無しさん
06/08/12 18:01:15
変数宣言時にとりあえずnewしてるのは嫌いだ。

29:デフォルトの名無しさん
06/08/12 18:04:56 BE:359446098-2BP(201)
ふつー宣言と同時にnew

30:デフォルトの名無しさん
06/08/12 18:09:15
BEのキチガイがまたいるな・・・

31:デフォルトの名無しさん
06/08/12 18:18:21
JavaやC++で関数定義の頭に宣言が固まってるコードは頭が悪いと思う。

32:デフォルトの名無しさん
06/08/12 18:31:46
> 28
> 31
使う箇所で宣言すりゃ普通その場でnewじゃね？

33:デフォルトの名無しさん
06/08/12 18:36:36
>>14
Officeのタイプライブラリなどを同時にインポートすればよいだけ。

ただたしかに、
「"xxx.h"をインクルードする前に"yyy.h"をインクルードする必要があります」
ということとと同じことだから、下手といえば下手。

34:デフォルトの名無しさん
06/08/12 18:41:49 BE:359446289-2BP(201)
>>31
>>32
そうだよな。
使う直前に宣言して、その場でnew。

関数の先頭でまとめて宣言してるのが行儀いいって思ってるアホとかたまに見るな。

35:デフォルトの名無しさん
06/08/12 19:09:14
>>26
何を言い返す必要があるんだろう…。

どうやら、>>11 は >>10 の唯一の自慢に触れてしまったみたいだな。(w

>>34
> 関数の先頭でまとめて宣言してるのが行儀いいって思ってるアホとか
> たまに見るな。

昔の流儀が抜けないだけだろ。

36:デフォルトの名無しさん
06/08/12 19:11:18
今でも入門書にK&R勧めてるのを見かけたりするもんなー
正直、正気を疑うところだが

37:デフォルトの名無しさん
06/08/12 19:14:51
>>32
気になるのは
Child c = new Child();
c = parents.getChild();
というような記述。

38:デフォルトの名無しさん
06/08/12 19:21:33
使いまわしの話か？

39:デフォルトの名無しさん
06/08/12 19:31:38
想像だけど。

使い回してるんじゃなくて、宣言時にアサインしたnew Child()は結局使っても
いないんだろう。ところが、ブロック開始時に宣言する習慣が抜けず、なおかつ
宣言したらその場で初期化すべし、という金科玉条を守るために使いもしないオ
ブジェクトを割り当ててる。

40:デフォルトの名無しさん
06/08/12 19:34:24
それは下手どころか間違ってんじゃねーか
初学者とかならさておき、そんなコードを恒常的に書く奴いんのか？

41:デフォルトの名無しさん
06/08/12 19:54:46
CやPascalみたいに使う変数が固まってくれてる方が個人的には読みやすい

Option Explicitがついてない上に、include先のグローバル変数、
それも「strPath」みたいなごく普通の名前のグルーバル変数が
縦横無尽に飛び交っている。そんなVBSが今まで読んだ中でも最凶のコード

42:デフォルトの名無しさん
06/08/12 20:02:40 BE:174730875-2BP(201)
>>41
＞CやPascalみたいに使う変数が固まってくれてる方が個人的には読みやすい　

COBOLみたいに、プログラムの先頭で全部宣言してあれば最強ってことか。

43:デフォルトの名無しさん
06/08/12 20:02:44
>>40
間違ってるかどうかはともかく、問題が起きるとは限らないんだな。
だからブロック開始部分に限らず結構見かけるね。

44:デフォルトの名無しさん
06/08/12 20:20:04
金科玉条を守るためなら
とりあえず null で初期化すれば良いような。

45:デフォルトの名無しさん
06/08/12 20:21:42
最近どこかの質問スレで見かけたよ。
Class1 class1 = new Class1();
class1 = oldclass1;
と
Class1 class1 = oldclass1;
って何か違うんですか、どっち使うべきですか、って感じだった

46:デフォルトの名無しさん
06/08/12 20:27:54
>>35
何にも言い返す必要が無い癖に

> ププッ、顔真っ赤だぞオ・マ・エ (w

とレスしたのか？
口を開けば矛盾が出るな。どこまでアホなの？

47:デフォルトの名無しさん
06/08/12 20:28:18
Class1のコンストラクタにある副作用が
必要なら上、そうでなければ下。

48:デフォルトの名無しさん
06/08/12 20:35:46
>>47
そんな副作用が必要だったらそれはそれで下手だ

49:デフォルトの名無しさん
06/08/12 20:39:12
18,22,24,26,35,46 をスルー。
キーワードはアホと行末の(wです。

50:デフォルトの名無しさん
06/08/12 21:43:55
>>44
それにすら気づかないから、下手なコードなんだろう。

51:デフォルトの名無しさん
06/08/12 22:51:50
>>46
どこが矛盾してるんだろうか…。

>>22 があまりにも必死に見えただけなんだけど。

もしかして日本語もあまり得意じゃないのかな？ (w

52:デフォルトの名無しさん
06/08/12 23:16:19
もうすぐお盆なんだからそんなことで煽りあってると
ご先祖様に叱られるぞ

53:デフォルトの名無しさん
06/08/12 23:17:31
腹抱えて笑ってるだろうな無様さを

54:デフォルトの名無しさん
06/08/13 00:39:17
>>11
そういう趣旨だろ、>>10は。

55:デフォルトの名無しさん
06/08/13 00:41:55
>>48
それこそ、下手というより間違ってるな、だな。

56:デフォルトの名無しさん
06/08/13 01:07:45
>>45
つ *

57:デフォルトの名無しさん
06/08/13 01:12:57
いや、君の肛門さしだされても……

58:デフォルトの名無しさん
06/08/13 08:55:32
僕の肛門も無限ループしそうです

59:デフォルトの名無しさん
06/08/14 09:05:58
printf(hogestring);
↑
こういうコードを見た時。脱力する

60:デフォルトの名無しさん
06/08/14 10:25:00
>>59
勝手に脱力してろ、アホ

61:デフォルトの名無しさん
06/08/14 10:39:19
俺は脱毛した。

62:デフォルトの名無しさん
06/08/14 10:40:10
数日前、auの端末でそれ系のバグがあって話題になってたね。

63:デフォルトの名無しさん
06/08/17 11:39:26
単発コメントはゴミ以下。プログラム全体を奏でる壮大なシンフォニーであってほしい。

64:デフォルトの名無しさん
06/08/17 12:40:14
do_something(foo);
do_something(foo); // 何故か二回呼ばないと駄目

65:デフォルトの名無しさん
06/08/17 16:41:55
int kesuna[4000];
↑このkesunaは何処からも参照されてないのに
消したら本当に実行時エラーが発生して噴いた。
そんなヘタなコード。（実話）
何でだ？

66:デフォルトの名無しさん
06/08/17 16:51:06
おそらく、ローカルに作った配列で範囲はみ出してスタック書きつぶしてるんだろ。
kesunaがあるとそこを書きつぶすので実害にならない。

67:デフォルトの名無しさん
06/08/17 16:55:39
なるほど～

68:デフォルトの名無しさん
06/08/17 16:59:31
感心している場合じゃないぞｗ
こわいコードだな。

69:デフォルトの名無しさん
06/08/17 17:01:38
>>65
それってあれだよね。
VCとかだったらデバッガモードでは動いてたけど
リリースモードにしたら動かなくなったみたいなパターンだね。

70:デフォルトの名無しさん
06/08/17 17:44:27 BE:99846645-2BP(201)
決まったタイミングで実行時エラーが出るなら、潰しやすいバグだと思うが。

71:デフォルトの名無しさん
06/08/17 17:55:42
下手とバグは分けましょう。

72:デフォルトの名無しさん
06/08/17 18:33:28
retrun answer + 1;　　　// なぜか1少ないので1足して戻す

73:デフォルトの名無しさん
06/08/17 18:35:45
// 100未満のときに、なぜか1少ないということがわかったので、そのときだけ1足して戻す
if (answer < 100) {
　　return answer + 1;
} else {
　　return answer;
}

74:デフォルトの名無しさん
06/08/17 18:37:23
// 100～1000のときだけ、正しい値になることがわかったので、
// それ以外は1足してもどす
if (answer >= 100 && answer <= 1000) {
　　return answer;
} else {
　　return answer + 1;
}

75:デフォルトの名無しさん
06/08/17 18:37:58
// テストの結果、10,000以上のときも・・・

泥縄

76:デフォルトの名無しさん
06/08/17 18:43:11
>>72
あるある。

77:デフォルトの名無しさん
06/08/17 18:44:55
// free(p);　　　// ここでfreeすると何故だか落ちるのでコメントアウト

78:デフォルトの名無しさん
06/08/17 18:46:03
「なぜか」「なぜだか」がキーワードですなｗ

79:デフォルトの名無しさん
06/08/17 21:38:38
>>72-78
>>71

80:デフォルトの名無しさん
06/08/17 21:51:07
いや、バグ対処の仕方が激しく間違ってるんだろ。

81:デフォルトの名無しさん
06/08/17 22:29:37
ヘタなデバッグのやり方を披露するスレじゃないだろ。

82:デフォルトの名無しさん
06/08/17 22:31:16
ネタ切れなんだから、なんでもいいじゃｎ

83:デフォルトの名無しさん
06/08/17 23:45:29
普通に考えたら、上手に書けてんのにバグってるなんて珍妙な事態は無いはずだしなー。
そう思うと結構難しいな、このスレ。

84:デフォルトの名無しさん
06/08/17 23:56:27 BE:209677076-2BP(201)
ネットでちょっと探したら、ゴロゴロころがってるけど。　>　へたなコード

85:デフォルトの名無しさん
06/08/17 23:59:08
じゃ見つけて貼ってくれよ

86:デフォルトの名無しさん
06/08/17 23:59:35 BE:124808055-2BP(201)
こんなのとか。

URLﾘﾝｸ(www.tcp-ip.or.jp)

>/*　[参考]　推奨する方法
>class　Foo　{　　　　　　　　　　　
>　　　　int　i　;　　　　　　　　　　　　　　　　　　　
>...
>　　　　const　int&　get2()　{　return　i　;　}　　　　リタ－ンで返す場合

87:デフォルトの名無しさん
06/08/18 00:02:45
>>86
どこがどう下手なのか書きましょう。

88:デフォルトの名無しさん
06/08/18 00:04:44 BE:89862236-2BP(201)
>>87
ぱっとみて分かるようになりましょう。

89:デフォルトの名無しさん
06/08/18 00:06:07
>>86
最初につっこむのはむしろここじゃね？
>#include<iostream.h>
>....
>void　main()

90:デフォルトの名無しさん
06/08/18 00:07:29
>>86
つか、そのサイト、古いしむちゃくちゃなので、いまさら感がある

91:デフォルトの名無しさん
06/08/18 00:08:08
関係ないが/* */うぜー

92:デフォルトの名無しさん
06/08/18 00:15:25
>>88
ぱっとみても分かりません。説明してください。

93:デフォルトの名無しさん
06/08/18 00:26:30
突込みどころがいろいろあるだけに、まずどこに対して突っ込むのが正解かわからないな。

94:デフォルトの名無しさん
06/08/18 00:28:38
intの参照を返すって辺りか

95:デフォルトの名無しさん
06/08/18 00:34:53
constの参照返しといて自分がconst関数じゃないあたりとかもか

96:デフォルトの名無しさん
06/08/18 00:47:05 BE:89862236-2BP(201)
>>94
あと、クラス内部への参照を外に渡してるってのも。

97:デフォルトの名無しさん
06/08/18 00:52:25
>クラス内部への参照を外に渡してる

いつでも許される類のもんじゃ無いにせよ、それ自体は別に有りだろ。
一応const憑いてるしな。

98:デフォルトの名無しさん
06/08/18 03:39:11
このサイト、1999年だか2000年だかに作られた古いページだから。
当時このページ見つけたとき、その時でもなんじゃこりゃ感はあったｗ

内容が書き換わってるのか書き換わってないのか知らないけど、
一番の「下手」は、作成日時と更新日時を各ページに載せてないとこだな。

99:デフォルトの名無しさん
06/08/18 03:46:13
思ってたより新しいな。

100:デフォルトの名無しさん
06/08/18 10:19:15 BE:49923825-2BP(201)
〉97
いや、ほとんどの場合、無しだろ。
const付きでも。

101:デフォルトの名無しさん
06/08/18 10:29:11
>>100
ほとんどの場合ということは、例外もあるということですよね。
どのような例外ケースがあるのでしょうか？

102:デフォルトの名無しさん
06/08/18 10:43:55
古いサイトは古いままのが多いよな

103:デフォルトの名無しさん
06/08/18 14:18:43
昔のサイトは古いよな～
びっくりだぜ
それに比べて最近のは先進的だね。
サイコー

104:デフォルトの名無しさん
06/08/18 21:10:12 BE:279569287-2BP(201)
URLﾘﾝｸ(www.nmn.jp)
これなんか10年も前だな。

105:デフォルトの名無しさん
06/08/18 21:43:45
>>104
どこがどう下手なのか書きましょう。

106:デフォルトの名無しさん
06/08/18 21:49:06
誰も下手だとは言ってないだろ。

107:デフォルトの名無しさん
06/08/18 21:51:33
>>106
リンク先読むとこだったじゃないか、ボケ

108:デフォルトの名無しさん
06/08/18 22:22:24 BE:199692858-2BP(201)
URLﾘﾝｸ(next1.cc.it-hiroshima.ac.jp)

サンプルのインデントがメチャクチャ。
なんでかなと思ってソースを見てみたら、wordで出力したhtmlだった。

109:デフォルトの名無しさん
06/08/18 22:32:22
どんどん下手なコードから遠ざかっていくなぁ

110:デフォルトの名無しさん
06/08/18 22:39:55
宗教論争は盛り上がるんだけど
非難一辺倒なコードはヘタ以前に
致命的な間違い犯してる場合が殆どやしねえ。

111:デフォルトの名無しさん
06/08/18 22:41:19 BE:314515679-2BP(201)
じゃ、109が酒の肴になるようなヘタなコードを披露するってことで。

112:デフォルトの名無しさん
06/08/18 22:42:14
いや俺酒飲まないし

113:デフォルトの名無しさん
06/08/18 22:50:06
昔書いたソース見てくるよ。

114:デフォルトの名無しさん
06/08/18 23:09:10
//test = hoge1(hage～moge);
//test = hoge2(moge～hage);
test = hoge3(hage～hage);
//test = hoge4(moge～moge);

コメントアウトが残ってる事自体は別として
何が悪くて何がしたくて何が良くてhoge3を残したのか
hoge1~4の先を全部読むまで全くわからんし
そうじゃなくても可読性低下させるだけの古い
糞コードを糞しつこく糞こびり付かせてると吐き気がする。

しかも古いコードはコメントアウトして残しておくようにとか指示する糞野郎の下だと
糞がぼとぼと降り注ぐ中で自分も糞を生産するという地獄絵図だよな

115:デフォルトの名無しさん
06/08/18 23:27:35
古いコード・・歳を取ってしまった自分
残しておけ・・俺を捨てないでくれ

というメタファーに気がつけ。

まぁそれはともかく。
マジックナンバー満載の素敵コードのおかげで
徹夜のデバッグを余儀なくされると殺意沸くよね。
ヘタとか以前に死ねと思うコード。

116:113
06/08/18 23:33:19
さらーっと眺めてきた。
下手は下手だけど、思ったほど酷くない気がした。もっと下手なのみたことあるし。

いろんな文字列定数がハードコーディングされてて、後から弄りづらそう(VB)。
「エラー '55' 対策」とかコメント書いてるけど、何のエラーなのか分からん(VB)。
まるっきり手続き型言語みたいな書きかた(VB)。
ほとんどグローバル変数(Perl)。
探せばライブラリがいくらでもありそうなのを、頑張って車輪の再開発してる(Perl)。
GUIの処理が随分奥深いとこまで食い込んでる(Delphi)。
ビットフィールドの解析を配列読み込んで1byteずつしこしこ処理してる(Delphi)。
一行に纏めすぎ。if pbuf = nil then begin BlockRead(fh, buf, 512, AmtTransferred); pbuf := @buf; end;
200行くらいの、ほとんど同じ処理の関数が3つもある(計画性なく拡張したせいなのだが)。

117:デフォルトの名無しさん
06/08/19 00:15:48
>>115
殺人コードだな

118:デフォルトの名無しさん
06/08/21 21:55:00
某スレで汚いといわれたんで修正したんですが、まだ自身がないのでみてください。
URLﾘﾝｸ(up2.viploader.net)

119:デフォルトの名無しさん
06/08/21 22:22:01
過疎板で回転の速いうｐろだにあげちゃだめって何度も言ったのに…。

120:デフォルトの名無しさん
06/08/21 22:28:41
>>118
気になったところ。

using namespace std;　<-思わぬところで衝突するかも
if文　　　　　　　　　　　　<-必ず括弧を付けよう
fin.close();　　　　　　　　　<-勝手にやってくれるから書くだけ無駄

121:デフォルトの名無しさん
06/08/21 22:40:40
>>118
クラス名や変数名を見ても目的がわかりづらい。aとかbとか使うな。
何も書かれていないmain.hやgetメソッドの存在意義がわからん。
ヘッダが無いと動かないってわけでもないし
set書いたらgetも書かなきゃいけないというわけでもない。

122:デフォルトの名無しさん
06/08/21 23:12:53 BE:19969722-2BP(201)
>>118

>if(b)
>　　　b　=　0;
>else
>　　　b　=　1;

boolにはtrueとfalseを入れればいいじゃん。
値の反転はこうで。
b　=　!b;

123:デフォルトの名無しさん
06/08/22 00:30:27
>>118
重要なのにコメント化

124:デフォルトの名無しさん
06/08/22 00:32:04
> bool b(0);

boolにもコンストラクタってあったの? 知らなかった...
いつも
bool b = false;
と書いてました。

125:デフォルトの名無しさん
06/08/22 00:58:35
bool(0)は関数形式のキャスト演算子では?

126:デフォルトの名無しさん
06/08/22 01:18:13
>>124
C++では、そのように組み込み型のオブジェクトもコンストラクタ引数を指定するのと同じ構文で初期化できる。

127:デフォルトの名無しさん
06/08/22 01:23:30
見たことないの関数やらクラスがあるが必要もなさそう
C言語の関数？それとも昔の表記方法？wは全部不要じゃん？
wstring
wifstream
wcout
imbue
locale

128:デフォルトの名無しさん
06/08/22 01:24:05
locale("japanese")よりlocale("")の方が良いと思う。
あと0x0D,　0x0Aではなく'\r',　'\n'にしろ。（それでは良くない環境ならせめて'\x0a',　'\x0d'）

129:デフォルトの名無しさん
06/08/22 01:25:42
ここで指摘の多い様な、ぱっと見の下手なコードって
C++に集中してる気がするのは気のせいか？

適当に書いても適当に通っちまったり、オペレーターオーバーロードとかで
出鱈目やってもコンパイラ的には全然OKだったり、無法がまかり通るからなのかな…

130:デフォルトの名無しさん
06/08/22 01:48:28
Hoge::Hoge()
{
　this->isFuga = true;
}

よりも

Hoge:Hoge()
: this->isFuga(true)
{
}

が望ましい。

131:デフォルトの名無しさん
06/08/22 02:02:27
なんで？プリミティブななんとかが関係有る？

132:デフォルトの名無しさん
06/08/22 02:05:00
それ以前に何故にthisを明記するか。
voidは省略してやがる癖に。

133:デフォルトの名無しさん
06/08/22 02:07:57
>>131
コンストラクタ本体での設定は、初期化じゃなくて代入になる。
constメンバとか、参照メンバはこの方法じゃないと初期化できない。

134:デフォルトの名無しさん
06/08/22 02:14:04
>>133
まあ、普通に常識ではあるよな。
正直なところ基本型についてはどっちでやってもええやんとは思うが。
二重コンストラクタとか用意した方が取り回しの便利なクラスとかだと、
わざわざ無駄になる初期化部分を書くのが面倒ちい。

class Hage
{
int hige;
public:
Hage() { init(); }
void init() { hage = 0; }
};

とか。

135:デフォルトの名無しさん
06/08/22 05:08:27
>>129
コードがキレイかどうかを気にするのがC++プログラマに多いからじゃね？

136:118
06/08/22 08:53:29
>>120
わかりました、そうします。

>>121
まだちょっと実装不足です。

>>122
それがありました・・・orz

>>123
あれは実験コードで・・・今のもだけど

>>125
できるらしいです、Effective c++より

>>127
stringをマルチバイトでgetコマンドすると一バイトずつ読みバケるんで、
自分で処理するのにも自信ないのでc++のマルチバイト処理関数使ってます。
ちゃんと解説してる本やサイトなくてつらかった・・・

>>128
そういう方法で処理します。(enumハックでするとどうなるんだろう)

次にテンプレート化して提出します。え、そういうスレじゃない？

137:デフォルトの名無しさん
06/08/22 11:30:10
Effective C++なんて読むレベルの奴がこんな指摘されるはず無いのだが

138:デフォルトの名無しさん
06/08/22 14:24:07
うーん、いや実際に読んでるよ。読むだけ

139:デフォルトの名無しさん
06/08/23 01:36:00
MoreEffectiveもデザパタも読んでモヒカン入門した俺の頭のテカリ具合を見てくれ。
こいつをどう思う？

140:デフォルトの名無しさん
06/08/23 02:36:46
すごく…氏ね…

141:デフォルトの名無しさん
06/08/23 07:19:15
TYPOしたままやけくそで全部そのままTYPO名使ってるコード。
つーか置換しろよ…

142:デフォルトの名無しさん
06/08/23 08:54:23
検索する時困るんだよな。
確か stopFlag だったよなーと思って探しても見つからず途方にくれる。
実は stopFlug でした、とか。そりゃみつからねーや。

143:デフォルトの名無しさん
06/08/23 10:49:14
普通は見つからなかったらtypoだと思い"stop"で検索かける。

144:デフォルトの名無しさん
06/08/23 13:12:29
stapFlugだったりとか。

ちょっと長めの名前だと、補完使ったりコピペするので、
TYPOにしばらく気づかないことが多いな。

145:デフォルトの名無しさん
06/08/23 13:23:18
気付いたときには手遅れだったり。

146:デフォルトの名無しさん
06/08/23 13:25:49
typoはtypeのtypoだ、とまことしやかに説明している人がいた。

147:デフォルトの名無しさん
06/08/23 13:34:16
これまたリカーシブですね

148:デフォルトの名無しさん
06/08/23 20:46:08
一応クラスでは作り終わった？評価よろしくお願いいたします

URLﾘﾝｸ(maidx.net)

149:デフォルトの名無しさん
06/08/23 20:46:52
typoってどーゆーいみ？

150:デフォルトの名無しさん
06/08/23 20:52:07 BE:59908526-2BP(201)
昔fj見てたとき、なんでふつーに日本語で書かないんだろって思ってたよ　>　typo

151:デフォルトの名無しさん
06/08/23 21:15:11
typographical error

152:デフォルトの名無しさん
06/08/23 21:17:06
>>148

・識別子が全部小文字で非常に見づらい。
単語の区切りが明確になるようにアンダーバーを入れれ。
ローカル変数も然り。

・getdateinputinfってのが何なのかさっぱりわからんけど適切な命名ではないと思う。

・getstreamopenでなくてis_stream_open。
名前だけ見ると別の意味になる。

・コメントがなさすぎ。命名の微妙さとあいまって何をやってるコードなのかさっぱりわからん。

153:デフォルトの名無しさん
06/08/23 21:28:33
>>148
Error #503
Service Unavailable
BoostWeb BW4.2.16.1 Feb 24 2003 at bw03

154:デフォルトの名無しさん
06/08/23 22:50:17 BE:404376899-2BP(201)
>>148
>if(b){
>　　　value　+=　a;
>}else{
>　　　value　+=　a;
>}

これはバグ?

155:デフォルトの名無しさん
06/08/24 12:28:27
>>152
クラス名・変数名に迷ったら書き込むスレ。Part8
ｽﾚﾘﾝｸ(tech板)
ちょっと、行っています

>>153
即行消されたのか・・・

>>154
消し忘れです

一応やってみました
URLﾘﾝｸ(up2.viploader.net)
バグありでファイルを開いてインプットした後
閉じてもう一回読んだときファイルストリームができない・・・なぜ？

156:デフォルトの名無しさん
06/08/25 01:10:43
＞ファイルをとじらせるバグってる
日本語でOK。

157:デフォルトの名無しさん
06/08/28 01:53:12
開発で見かけた、Ｔ芝のコード。
関数の途中で数箇所return的な処理をする代わりにgoto使ってる。

void xxx()
{
:
if( ... )
{
goto END;
}

switdh( ... )
{
case xxx:
goto END;
:
}

END:
return;
}

・・・こういう目的限定なら使ってもいいのか？俺は使わないが。

158:デフォルトの名無しさん
06/08/28 02:09:36
その例なら普通に return した方が良い。

ただ、エラー処理が混じる場合は
goto を使った方がエレガントに書けるので
積極的に使えば良いという人も少なからずいる。
(goto排除原理主義者はこれを認めない。)

159:デフォルトの名無しさん
06/08/28 03:26:26
別に下手でも何でもないような。
まあ、行数多い中でやってるなら、分けろよとは思うかもしれないけど。

goto排他原理主義者って、なんであんなに頑ななんだろうね。
どう見ても使った方がいいだろって状況でも
grepかけて突きつけてきたりするもんなー。

多重ループん中から抜ける時とか、同じ条件のifだだ並べにしてる方が
三億倍はキモいと思うんだが、何がそこまで彼らの憎しみを駆り立てるのか。

160:デフォルトの名無しさん
06/08/28 04:27:43
なんでも極端にやるのはダメだよねぇ…
以前“短い関数”原理主義者を見かけたよ。
３行関数を大量生産したらかえって読みにくい。

161:デフォルトの名無しさん
06/08/28 05:52:50
C言語ならありかもしれないな。

C++では例外やアルゴリズムやオーバーロードがあるから
gotoは完全にいらない子だけどね。

162:デフォルトの名無しさん
06/08/28 06:42:02
アルゴリズムもオーバーロードも関係ないと思われ。
例外は確かにあるが、多重ループから抜けるのなんかに使ってたら、それこそヘタなコードだろ。
場合によっちゃJavaでだってバカにされるわ。

C++の例外は、そもそもデストラクション絡みの負荷がデカすぎて
使用を呑めない場合すらあるしなー。
Cで許されるのと同程度の使い方なら、C++で使ってたって何の問題もないと思うんだが。

163:デフォルトの名無しさん
06/08/28 07:09:16
アルゴリズム類の適用で多重ループ自体の出番を減らせられるのは分かるが、
なんでもかんでもそれで書いてたら、それはそれで馬鹿なコードだな

case文のラベル名指しで飛んでるようなコードは流石に有害指定してもいいとは思うが、
ぱっと見すぐわかる範囲で簡潔に使われてる程度で目くじら立てるのは…

164:デフォルトの名無しさん
06/08/28 13:10:51
よくあるのは、
:
:
return TRUE;
/* ↑ここまで正常系処理 */
error:
if (hoge) { hogeのリソースを解放; }
if (fuga) { fugaのリソースを解放; }
return ERROR;

みたいなやつ。hoge/fuga/...は一連の処理の最初にNULLで初期化しておく。

途中で処理が失敗したとき、どのリソースが割り当てずみかを気にせず、
末尾に飛べばいい。

165:デフォルトの名無しさん
06/08/28 13:11:41
TRUE/ERRORってのは変な組み合わせだな。てきとーに読み替えplz

166:デフォルトの名無しさん
06/08/28 14:16:05
>C++では例外やアルゴリズムやオーバーロードがあるから
なぜここにアルゴリズムが混じりますか？？

167:デフォルトの名無しさん
06/08/28 14:35:00
>>160
> 以前“短い関数”原理主義者を見かけたよ。

Kent Beckのことですね。

168:デフォルトの名無しさん
06/08/28 14:47:44
>>164

正常系のリソース解放を一緒にすると下のようになるんだろうが、なんか微妙
なようなそうでないような。

result = SUCCESS;
goto end;
/* ↑ここまで正常系処理 */
error:
result = FAILURE;

end:
if (...)
if (...)
return result;

169:デフォルトの名無しさん
06/08/28 20:30:04
>>162
なんでそんな例外を忌み嫌うのかよくわからん。

頭固いんじゃないの？

170:デフォルトの名無しさん
06/08/28 23:10:24
>>162
> C++の例外は、そもそもデストラクション絡みの負荷がデカすぎて
必要なことをしているだけじゃないの？
例外を使わなくたって、デストラクタを呼ぶ必要がなくなるわけじゃないでしょ？

正常系の場合に(結果的に)無駄となることをする場合もあるけど、
例外を使うことによるメリットを考えれば普通は我慢できるはずだけど。

171:デフォルトの名無しさん
06/08/28 23:10:48
>>169
え？多重ループから抜け出すのに例外使うの？

下手だなー。

172:デフォルトの名無しさん
06/08/28 23:54:37
>>170
C++の例外処理は相当重たい処理だよ。
だからこそ例外を使わないというコンパイルオプションがあるくらいなのに。

173:デフォルトの名無しさん
06/08/29 00:26:04
>>168
頻出なイディオムなのに簡潔に書けないもんだから
C++やその他の言語で try-catch が生まれたって流れなんでしょうね。
たまに C++ で書く時は finally 使えなくてムズムズする。
きちんとデストラクタ書けって話なんだけど。

174:デフォルトの名無しさん
06/08/29 01:03:40
>>167
Kent Beckに限らず、Smalltalkerはn行を超えるメソッド(関数)が
ポコポコ出来るなんて信じられない、という発言を真顔でするね。

175:デフォルトの名無しさん
06/08/29 03:48:20
多重ループじゃなくてイテレーションなら一発で抜けられるのにな

176:デフォルトの名無しさん
06/08/29 04:57:44
goto信者が暴れていたようだな。
そんなに早さを求めたいのならC++なんて使うな。

177:デフォルトの名無しさん
06/08/29 05:05:42
C++ではデストラクタ以外にリソース解放コードを書いてはいけない
よってgotoはいらない
逆にスコープアウト時の処理が書けないレガシーな言語には必要。
Javaはgotoがないのでご覧のとおり悲惨なことになっている

178:デフォルトの名無しさん
06/08/29 08:51:11
ループを脱けるために例外を使うなんて、意味論的にも変だっつーの。

ところで、
LABEL:
　for(～) {
　　for(～) {
　　　if (～) break LABEL;
　　}
　}

で、外側のforまで一気に break してくれる構文のある言語があったような木がするんだけど、なんだっけ？

179:デフォルトの名無しさん
06/08/29 10:01:15
ラベル付きbreakはJavaにはあるな。C♯は goto ラベルか。
Perlだとbreakじゃなくてlastだが、これもラベルがつけられる。

Rubyだと
catch(:identifier) do
throw :identifier
end
と書く。 # これは例外処理ではない。

180:デフォルトの名無しさん
06/08/29 10:02:43
D言語の言語仕様にはあったが実際どう動くかわからない

181:デフォルトの名無しさん
06/08/29 17:12:25
>>177
関数内のある処理のために確保した一時メモリ領域とかもデストラクタで解放するの？
C♯のfinally構文に慣れたせいかいまいち理解できない。
具体的にどう書くの？

182:デフォルトの名無しさん
06/08/29 18:00:12
>>181
つ std::auto_ptr
auto_ptrは腐ってるという意見もあるようだが。

183:デフォルトの名無しさん
06/08/29 18:10:39
phpは break n; でn段のネストから抜ける

184:デフォルトの名無しさん
06/08/29 18:20:49
「n段」ってのがPHPらしい仕様だよな

185:デフォルトの名無しさん
06/08/29 18:44:12
>>182
ほへー。
それを徹底するくらいなら例外かgotoで終了処理したほうがよほどスマートだと思うんだけどな･･･

186:デフォルトの名無しさん
06/08/29 19:48:14
>>182
auto_ptrはauto変数としてのみ使うもんだと思ってる。
移動コピーはcreate関数なんかに効率を落とさず対応するためのもので、
基本的にはコピーしない、と。

>>185
struct file {
FILE *f;
file(const char *path) { f = fopen(path, "r+"); }
~file() { fclose(f); }
};
int main()
{
file f("foo.txt");
// 何かする

} // close

187:デフォルトの名無しさん
06/08/30 01:08:06
標準では未だにauto_arrayって入ってないんだっけ。
いや、自分で書いても一瞬だけどさ…。

188:デフォルトの名無しさん
06/08/30 11:14:53
>>181
つ[More Effective C++]

189:デフォルトの名無しさん
06/08/30 21:01:50
>>181
C#使いなら、System.IDispose.Disposeに書くようなことをC++ではデストラクタに書くと言えば通じるだろうか。
ただしusingに相当するものはなく、自動変数ならスコープを抜けるときに呼ばれるという感じ。

190:デフォルトの名無しさん
06/08/30 21:03:20
すまん、IDisposableだったな。

>>186
auto_ptrを自動変数として使うだけなら、scoped_ptrでいいだろと思う俺。
今はまだBoostだから使用に抵抗を感じるのかもしれないけどね。

191:デフォルトの名無しさん
06/08/30 22:13:15
boost馬鹿は死んでいいよ

192:デフォルトの名無しさん
06/08/30 23:53:53
おまいが死んだら一番じゃん

193:デフォルトの名無しさん
06/08/31 00:30:09
try{
…
}
catch(Exception e){
　if(e instanceof HogeException){...}
}

もうね、アホカと。馬鹿かと。

194:デフォルトの名無しさん
06/08/31 00:36:44
・飛んでくる例外の共通の親はException。
・各例外を捕まえたときの処理は同じだが結構分量アリ。
・捕まえずに上にそのまま通す例外もある
みたいな条件が重なったときは結構困るな。

195:デフォルトの名無しさん
06/08/31 00:42:10
どういう場合にそういう状況に陥る？
設計しなおすと結構シンプルになったりしそうなんだが。

196:デフォルトの名無しさん
06/08/31 00:45:16
・飛んでくる例外の共通の親はException。 →当たり前。
・各例外を捕まえたときの処理は同じだが結構分量アリ。 →メソッド化しろボケ。
・捕まえずに上にそのまま通す例外もある →catchしてthrowするか、何もするな。

どこがどう困るんじゃと。

197:デフォルトの名無しさん
06/08/31 00:48:57
>>196
こいつ下手そう

198:デフォルトの名無しさん
06/08/31 01:05:51
そうでもないよ

199:デフォルトの名無しさん
06/08/31 01:12:26
>>197
こう書いたらｴｴﾔﾝっていってるだけなんだけど、だめ？

void exampleFunction()throws BarException{
　try{
　 //FooException,BarException,BazExceptionが発生する可能性あり
　}
　catch(FooException e1){
　 handleException();
　}
　catch(BarException e2){
　 throw e2;
　}
　catch(BazException e3){
　　handleException();
　}
}

200:デフォルトの名無しさん
06/08/31 01:24:53
>>196
Exceptionまでさかのぼらないと共通の親クラスが見つからない、
だから、まとめて捕まえるならExceptionで捕まえるか、
別々に書くかしないといけない、ということだね。

201:181
06/08/31 05:10:40
>>189
いや、C++も昔やってたからその辺のことはわかってるよ。
ただ一時メモリ領域もデストラクタで解放するっていうことに違和感を覚えただけ。

202:デフォルトの名無しさん
06/08/31 10:34:47
BarException をcatchする意味がないじゃん。

handleException() は、handleException(e1) とかで多胎にするよーな？

203:デフォルトの名無しさん
06/08/31 13:59:45
>>201
>一時メモリ領域
一瞬、スタック領域に取られたメモリの事かとおもた
じゃなかったら一時的かどうかはコンパイラには解らないから

204:181
06/08/31 15:12:31
スタック領域だったらそもそも解放とか気にする必要がないのではｗ
まあとりあえず自分の話題については>>182で一応の解決を見たのでこれ以上の問答は無用です。

205:デフォルトの名無しさん
06/08/31 21:21:42
例外も仕様の内だと思うんだけど。
なんでtry-catchなんて使うんだろうね。

ifとtryのどっちを使うのか明確にわけてあるプロジェクトにあたったことないな。

206:デフォルトの名無しさん
06/08/31 22:14:56
>>205
こいつ下手そう

207:デフォルトの名無しさん
06/08/31 22:39:56
>>206
おお！trycatchの適切な利用方法を説明してみてくれ。
なんかパっとしねぇの多いんだ。

208:デフォルトの名無しさん
06/08/31 23:30:19
>>202
rethrow する前にログったり BarException 固有の処理するけど
紙面の都合で省かれてるんだと思うことにしよう。

＞多胎
派生例外クラスにありとあらゆるケースの例外処理が書かれて
かえって可読性が下がる気がしなくもない。

209:デフォルトの名無しさん
06/09/01 00:23:55
当然のことだが、例外クラスはそれを使うクラスのことは知らない。
まさか、1クラスにつき1例外作るとか言うんじゃないだろうな。

210:デフォルトの名無しさん
06/09/01 00:34:41
そう。だから例外処理で多態は困難に感じる。

211:デフォルトの名無しさん
06/09/01 00:40:22
ここで「こいつ下手そう」発言君↓

212:デフォルトの名無しさん
06/09/01 00:42:04
>>211
こいつ下手そう

213:デフォルトの名無しさん
06/09/01 00:45:06
>>207
try {
resA->open(); // res: resource
resB->open();
resA->hoge();
resB->fuga();
resB->close();
resA->close();
}
catch () {
}

214:デフォルトの名無しさん
06/09/01 00:48:58
んなーこたーない

215:213
06/09/01 00:52:06
>>214
ん、俺？
俺いつもこうやってるよ。俺下手なのか？

216:デフォルトの名無しさん
06/09/01 00:52:40
ここでもやっぱり「こいつ下手そう」発言君↓

217:デフォルトの名無しさん
06/09/01 00:53:34
どう考えても213はおかしいだろ

218:デフォルトの名無しさん
06/09/01 00:53:42
>>213
見るからに例外安全じゃないコードだな。
close前に例外飛んだらout

もしRAIIだから大丈夫だとしたら逆にcloseを明示的に書いているのがダサい。

219:213
06/09/01 00:54:12
>>217
どこが？

220:213
06/09/01 00:55:14
>>218
あー、俺やっぱり下手だわ。
意味さっぱりわかんね。

221:デフォルトの名無しさん
06/09/01 00:56:35
>>218
エラーコードでいちいちエラーチェックするより、例外使ったほうがいいという例じゃないの？

222:デフォルトの名無しさん
06/09/01 01:00:20
>208-210
派生例外クラスじゃなくて、handleException を多態にするという意味では?

void handleException ( Exception& e ); // 共通の処理
void handleException ( BarException& e ); // BarExceptionだけの処理

try{
　//FooException,BarException,BazExceptionが発生する可能性あり
}
catch( Exception e ){
　handleException( e );
}

223:デフォルトの名無しさん
06/09/01 01:07:01
>>221
エラーチェックの話なら,
例外版は適切にRAIIとかfinally相当でリソースの後始末をするべき。
これだと例外を使うとリソースをリークするという話にしか見えん。

まともに例外を扱えないやつが例外を書くと危険極まりない。
下手糞の例外は下手糞のgotoよりはるかに凶悪

224:デフォルトの名無しさん
06/09/01 01:07:31
>>220-221
resA の open に成功して、resB の open に成功した場合、
resA のリソースが開放されないので例外安全にならない。
スコープ抜けたら勝手に開放される(RAII)のであれば
わざわざ close 呼んでるのが冗長。

225:デフォルトの名無しさん
06/09/01 01:11:43
>下手糞の例外は下手糞のgotoよりはるかに凶悪

まったくもってごもっとも。
つーか正直なところどんだけやってもC++の例外を使いこなす自信が持てん。

226:デフォルトの名無しさん
06/09/01 01:11:45
>>224
たぶん主張内容から推察するに
×　resBのopenに成功
○　resBのopenに失敗
だな。
主張内容は完全に同意。

227:デフォルトの名無しさん
06/09/01 01:16:58
>>222
実際にやってみたか？引数のオーバロードは多態ではないから
e が BarException でも共通の処理のほうに飛ぶんだが。

228:デフォルトの名無しさん
06/09/01 01:17:16
>>222
オブジェクト自身が振る舞いを知ってる場合が多態で
入り口(呼び出し側)でオーバーロード用意して
振り分けしちゃうのは多態とは言わないと思ってました。
実際のところどうなんでしょう？

>>226
ご指摘の通り。しかも223氏が本質的な発言先にしちゃってるし。
もう俺寝た方が良さそう。

229:デフォルトの名無しさん
06/09/01 01:23:53
>>228
お休み、よい夢をー。

230:213
06/09/01 03:26:07
あー、それは当然catch内でやる。213はtry{}の例。

231:デフォルトの名無しさん
06/09/01 03:41:27
catch内でリソースの開放処理をするのも上手くない。
その時点でcloseなどの解体処理が正常時と異常時の二箇所に分散するということが確定するから。
エラー処理を一箇所でやるための例外でその処理が分散したら本末転倒。
そんなんするならgotoでエラー処理するほうが開放処理が一箇所にまとまる分マシとさえ言える。

結局資源開放するならC++ならRAIIが定石(他言語ならfinally)

232:231
06/09/01 03:54:18
あと、resB->open()時に発生した例外と
hoge(),huga()で発生した例外で開放するリソースが変わるからさらに面倒だな。
open時だとresAのみ、それ以外だとresA,resBを開放する必要がある。
こんなのを手動で開放処理書いてたら俺は間違いなくどこかでミスる自信がある。

233:デフォルトの名無しさん
06/09/01 03:58:32
>　間違いなくどこかでミスる自信がある
うん、間違いなくミスってるよｗ
resA->open()時に例外が発生する事象を見逃してる。
このケースだと資源の解放はいらない。

234:231
06/09/01 04:02:32
うへぇ、本当だ。やっぱりミスってたかー...
うーん、こういう解体処理はRAIIに任せなきゃ駄目だなマジで

235:デフォルトの名無しさん
06/09/01 04:03:46
つまり例外は使うなってことでFA?

236:デフォルトの名無しさん
06/09/01 04:05:09
>>231
例外が有効な例を教えてくれ

237:デフォルトの名無しさん
06/09/01 04:07:57
こっちで。

例外処理
ｽﾚﾘﾝｸ(tech板)

238:231
06/09/01 04:12:41
>>236　>>213のケースをRAIIで書くと有効な例になるんじゃね？
try　{
　　　　Resource　resA(a->getResource());
　　　　Resource　resB(b->getResource());　
　　　　resA->hoge();
　　　　resB->fuga();
}catch(){
　　/*　エラー処理を記述　*/
}

どこにも開放処理はいらないし俺がミスる心配もない

次ページ