ヘタなコードの書き方

ヘタなコードの書き方 ..

2:デフォルトの名無しさん
08/04/12 23:24:04
クラスの数だけインターフェースがある

3:デフォルトの名無しさん
08/04/12 23:31:14
if　(success　==　true)　・・・

とか、bool値のリテラルとの比較があると、コードが素人くさくなる。
(if　(success　!=　false)　みたいにfalseとの比較ならいいとかって話じゃなくてね)

4:デフォルトの名無しさん
08/04/12 23:37:29
/*************************************************
　*
　*
　*
　*************************************************/

サブルーチンごとに、先頭に、こういう罫線を囲んだコメントがついてるとか。
ひどくなると、サブルーチンの途中でもがんがん入れてある。

5:デフォルトの名無しさん
08/04/12 23:37:38
if not notNullCheck(notNullFlg) then

6:デフォルトの名無しさん
08/04/12 23:41:09
'　<<<------------　初期化　------------>>>
　：
　：
'　<<<------------　DB更新　------------>>>
　：

コメントにいらん飾りを入れる

7:デフォルトの名無しさん
08/04/12 23:43:25
基礎編
見れば分かるコメントを入れる

fp　=　fopen(path,　"r");　//　ファイルオープン

return　hogeLength;　//　hogeの長さを返す

　

8:デフォルトの名無しさん
08/04/12 23:48:39
言語依存なものばかりだな

9:デフォルトの名無しさん
08/04/12 23:49:29
グローバル変数の応用編

size　=　**;
func(table);

配列は引数で渡してるのに、配列に入ってるデータの個数はグローバル変数で渡すとかってコードを見たときは、
鳥肌たった。

10:デフォルトの名無しさん
08/04/12 23:59:41
Java、C++　あたりのサブルーチンの途中でも変数宣言できる言語でも、宣言は全部サブルーチンの
先頭で行う。

11:デフォルトの名無しさん
08/04/13 00:10:50
引数が３０個以上ある関数

12:デフォルトの名無しさん
08/04/13 00:20:22
//　ADD　START　M.YAMADA　2008/4/15
　:
　:
//　ADD　END

変更履歴みたいなコメントが大量にあるとか、変更前のコードとか削除したコードを消さずに
コメントアウトして残してあるとか。

13:デフォルトの名無しさん
08/04/13 00:25:06
>>12
それは言語の責任ではないしコードの問題でもない
バージョン管理システムに類するものの有無の問題だ

14:デフォルトの名無しさん
08/04/13 00:29:16
・暗黙の型変換(キャスト)
・省略可能な{}を省略してしまう(K&R)
・難解な演算子の使用法
　 (例) o = --o - o--;

15:デフォルトの名無しさん
08/04/13 00:31:47
int　xxx　=　0;
int　xxxx　=　0;
int　xxxxxx　=　0;
int　xxxxxxx　=　0;

↑こういうのじゃなくて

int　xxx　　　　　　　=　0;
int　xxxx　　　　　　=　0;
int　xxxxxx　　　=　0;
int　xxxxxxx　=　0;

↑こういういちいち桁を揃えてるほうが素人っぽく見える

16:デフォルトの名無しさん
08/04/13 00:34:57
>>13
コードの問題です。
コードの書き方と環境の問題は切り離せません。

17:デフォルトの名無しさん
08/04/13 00:42:26
・インデントがずれてる。
・関数が長い(制御のブロックが長い)
・削除せずにコメントアウトしてコードを残してる

のコンボで、どうしようもないコードをいじったことがある。

制御ブロックの最後の　}　がどこに対応してるか、目で追うのが大変すぎるから、
エディタの対応する括弧に飛ぶ機能を使おうとしたら、

//　if　(hoge　>　100)　{　　//　DEL　M.YAMADA　2000/10/10
if　(hoge　>　200　{　　//　MODIFY　M.YAMADA　2000/10/10

みたいなコードが途中に何行もあって、それも使えないでやんの。

18:デフォルトの名無しさん
08/04/13 00:48:20
>>14
>　 (例) o = --o - o--;

これは、下手なコードと言うよりバグだろ。

19:デフォルトの名無しさん
08/04/13 00:48:24
>>17
それは自動整形に通せよ
インデントのズレ修正とコメント削除はできるだろ

20:デフォルトの名無しさん
08/04/13 00:49:12
>>17
コメント内の括弧を対応させようとする間抜けなエディタを使うのを止めたらいい。

21:デフォルトの名無しさん
08/04/13 00:50:08
Cで。
文字列はかならず　memset()　で初期化。
かつ　NULL　を使うと上級者。

memset(s,　NULL,　sizeof　s);

22:デフォルトの名無しさん
08/04/13 00:53:13
>>20
素のviしかない環境で作業させられた。

つか、ふだんそういう機能が必要になる局面がないんで、つかってるエディタが、言語の
コメントを意識するかとか、考えたこともないけど。

23:デフォルトの名無しさん
08/04/13 00:57:11
>>19
しょうがないから、コメントとか、大量のデバッグprintはいったん削除して作業した。
勝手にコメントを削除していいような空気でなかったんで、動作確認したら、
変更箇所をもとのソースに書きもどしたけど。

24:デフォルトの名無しさん
08/04/13 00:58:03
>>22
それは作業環境の改善を要求するべきだったね。とりあえずvimかemacs入れてもらうとか。

少なくともSyntax Coloringするエディタは言語のコメントを意識してるかな。

25:デフォルトの名無しさん
08/04/13 00:58:36
>>22-23
それならばスレ違い

26:デフォルトの名無しさん
08/04/13 01:00:57
if　(cond)
　　return　true;
else
　　return　false;

27:デフォルトの名無しさん
08/04/13 01:13:19
職場の年寄りがVB.NETで仕事してるけど、やっぱ変数名は　intHoge　とか　lngHoge　とかやってる。
打ち合わせで、ハンガリアンやめましょー、みたいな話がでて、そうしようみたいになってたと思うけど、
伝わってなかったか。

ほかの人も、MSのクラスライブラリの作成ガイドラインみたいな文章に沿いましょうみたいな話に
なってたはずだけど、なぜか定数値だけは、HOGE_MAX　みたいな、Cのスタイルにこだわってたし。

28:デフォルトの名無しさん
08/04/13 01:44:16
>>27
ああ、あるな。

29:デフォルトの名無しさん
08/04/13 05:09:21
やる気の低下で1週間とか放置することがあるから汚いコードとは思いつつコメントだけは多めに入れてある

30:デフォルトの名無しさん
08/04/13 08:38:15
後で大変なことになるぞーと思いつつ、バカが考えたコーディング規約厳守だから俺にはどうにも出来ないorz

31:デフォルトの名無しさん
08/04/13 12:03:20
checkをchkとか、countをcntとか、単語を省略すると一気に素人くさいコードになるな。
とくにcntは、ネイティブはぜったいやらない省略。

32:デフォルトの名無しさん
08/04/13 12:10:19
じゃあこれらは何かの間違いか全部非英語圏の人間の書いたコードだな
URLﾘﾝｸ(www.google.com)

33:デフォルトの名無しさん
08/04/13 12:15:04
contine なんだかcontrolなんだかcountなんだかワカンネーよ

34:デフォルトの名無しさん
08/04/13 12:16:00
continueだったorz

35:デフォルトの名無しさん
08/04/13 12:17:27
少なくとも1ページ目に出てるのは contine でも control でもなさそうだ

36:デフォルトの名無しさん
08/04/13 12:20:57
ならば問う、cntの正体とはは何だね？明智君

37:デフォルトの名無しさん
08/04/13 12:57:41
変数名が　hogeInfo　とか　hogeData　もヘタクソ臭が。

38:デフォルトの名無しさん
08/04/13 13:11:10
>>37
LCCなんて時代錯誤は捨ててアンダーバーで区切るべきだよな

39:デフォルトの名無しさん
08/04/13 13:35:48
if (...) {
　...
}

// なにやら
// 非常に
// 長ったらしい
// 説明と
// 空白行
// の後に...

else if (..) {
↑ってうぉ？！繋がってんのかよ！！！

40:デフォルトの名無しさん
08/04/13 14:40:09
>>38
infoとかdataじゃ分かりにくいって話じゃないのかこれ。

41:デフォルトの名無しさん
08/04/13 14:43:48
hogeってそのまま書いてあるのか。そりゃひどいな。

42:デフォルトの名無しさん
08/04/13 14:44:37
わかりにくいっていうか、変数なんてデータが入ってるもんなんだから、いちいちDataなんてつけないでいいだろってツッコミ。

43:デフォルトの名無しさん
08/04/13 14:47:05
こういうコードは頭痛が痛いな。

44:デフォルトの名無しさん
08/04/13 15:00:36
>>42
かと言って例えば受信データを入れる変数を Receive にするのはもっとまずいと思うが。

45:デフォルトの名無しさん
08/04/13 15:08:10
>>42
もしくはdataじゃなくてnameとかlengthとか
意味がありそうな単語を付けるとかかな。

46:デフォルトの名無しさん
08/04/13 15:19:58
だから言語実装依存の話なんかしたって意味ねーんだよ

47:デフォルトの名無しさん
08/04/13 15:24:38
名前や長さというのは名前ではなく所属クラス自体に持たせる情報だな

クラスがあればだが

クラスが無い場合は名前に情報を持たせるしかないだろう

48:デフォルトの名無しさん
08/04/13 16:15:02
>>46
自分でスレを立てたらいいよ。"言語に依存しないコードの上手下手"とかそんな感じで。
ム板にしてはかなり盛り上がっているのだし、吠えても意味ない。

49:デフォルトの名無しさん
08/04/13 16:19:04
>>48
言語や環境を特定せずに「コードが下手」と言っても意味がないという指摘なのでは
Javaの論理をVBに持ち込んでも仕方がないし、PHPの書き方をC++で使っても無為だ

50:デフォルトの名無しさん
08/04/13 16:19:16
コメントの書き方とか、変数名の話とか、どこが言語実装依存かよくわからんけど。

51:デフォルトの名無しさん
08/04/13 16:21:14
>8 >46
>7 や >11 辺りは比較的言語に依存しないヘタコードだと思うが。

n = 65; // n に 65 を代入する

ウボァー

52:デフォルトの名無しさん
08/04/13 16:23:12
言語によっては、マジックナンバーを使うべしとか、グローバル変数をどんどん使うべしってのが
お作法になってりするのか。
たしかにN88BASICとかグローバル変数しかないし、HSPとか構造化されてないコードとか当たり前みたいだけど。

53:デフォルトの名無しさん
08/04/13 16:50:01
定番の話題だけど、比較で定数を左にもってくるやつとか

if　(100　==　n)　・・・

54:デフォルトの名無しさん
08/04/13 17:03:03
= とミスする可能性は排除するには、有りだな

55:デフォルトの名無しさん
08/04/13 17:19:59
最近のコンパイラは警告してくれるけどな。

56:デフォルトの名無しさん
08/04/13 17:21:58
代入と比較を間違えたらコンパイラが警告出すから、定数値を左にもってくるような不自然な書き方はしないってのが主流。

57:デフォルトの名無しさん
08/04/13 17:30:58
google　code　searchで検索すると

==\s*0　lang:c
1,870,000

0\s*==　lang:c
143,000

「定数が左」派は7%超えてるのか。
思ったより多いな。1%未満かと思ってた。

58:デフォルトの名無しさん
08/04/13 17:55:11
VB.netだけど
bFlag = i = 0
って式があって一瞬混乱したんだが、こういう場合には
bFlag = 0 = i
みたいに定数を左に持ってきて、条件式だって明示するのもいいかもしれないとふと思った。

59:デフォルトの名無しさん
08/04/13 18:23:13
おれは、

button.Enabled　=　(count　=　0)

みたいに括弧でくくってるよ。

60:デフォルトの名無しさん
08/04/13 19:11:01
代入演算子と等値演算子が同じなんて、言語仕様がバグってる。

61:デフォルトの名無しさん
08/04/13 19:25:23
左辺と右辺が完全に独立しているから、混乱することはないので問題ない、
それよりも、式のど真ん中で代入できたり、代入がない式でもエラーが出ない方が異常じゃないかと思いつつC++を15年使ってる。

62:デフォルトの名無しさん
08/04/13 20:15:16
「あとで(自分を含め)誰かが読んで何やってるかわかりにくいのがへたなコード」ってことでおｋ？

・相変わらず昔の名残で変数の宣言をメソッドの先頭でやって、後の方で使う
・同じ変数を、違う場面で(違う意味で)使いまわす

63:デフォルトの名無しさん
08/04/13 20:18:53
・同じ変数を、違う場面で(違う意味で)使いまわす
これ最悪だな

64:デフォルトの名無しさん
08/04/13 20:35:13
関数の中のコードをほんの数行変えてfunc2とかfunc3とかを量産するのはホントやめて欲しい。

65:デフォルトの名無しさん
08/04/13 21:19:10
>1 の条件すべて満たすコードばっかりのところで仕事してる。
関数が長いのに加えてその中に長大な#ifdef～#endifが無数にあって、一部はネストになってる。
もう人間が読めるようなものではない（がんばって読んでいるけどね）。

この仕事何年やってんだよお前ら。

66:デフォルトの名無しさん
08/04/13 21:30:33
>>60 きもちわるいよね

67:デフォルトの名無しさん
08/04/13 21:39:53
>>62
>　・相変わらず昔の名残で変数の宣言をメソッドの先頭でやって、後の方で使う　

C++やC#で、これプラスして、変数は必ず初期化するってルールでやってるもんだから、適当に0とかNULL
で全部初期化してたりするところもあるな。

コンパイラは未初期化の変数を参照したら警告出してくれるけど、それが台無しになってるっていう。

VB.NETは、初期化を省略したら勝手に初期化するって仕様だから、デフォでこの状態になってるけど。

68:デフォルトの名無しさん
08/04/13 21:57:39
VB.NETにもスコープ用の{}みたいなのが欲しいな。
スコープを意識するような文化が根付けば
メソッドの先頭で変数宣言することも減るかもしれない。
ついでにスコープごとでの処理の抽出もしやすくなり、
自然と各メソッドも短くなるかもしれない。

69:デフォルトの名無しさん
08/04/13 22:06:16
goto使いたくないからという理由で do {} while (0); でくくる。
キモいよ、キモすぎ。

70:デフォルトの名無しさん
08/04/13 22:10:53
・省略可能な{}を記述してしまう
・三項演算子を使わない

71:デフォルトの名無しさん
08/04/13 22:19:42
３項演算子は、書くときはすごい簡潔になってスゲーと思うんだが、他人が書いたのを読まされるときはさっぱり意味がワカンネエと感じる。

72:デフォルトの名無しさん
08/04/13 22:24:48
省略可能な {} ってなに？
if (a) {b = 1;} else {b = 2;} → if (a) b = 1; else b = 2; みたいなやつのこと？

73:デフォルトの名無しさん
08/04/13 22:27:20
>>69
それってdo whileの中で複数判定があって、そこでbreakさせるってこと？
別関数にしてreturnしちゃったほうが手っ取り早そうだな。

74:デフォルトの名無しさん
08/04/13 22:30:11
>>72
それは3項演算子を使わないのほうじゃないのか？

75:デフォルトの名無しさん
08/04/13 22:33:23
if ( a )
　b = 1; //省略可能
else
{
　b = 2; //省略不可能
　c = 1;
}
こういうことか

76:デフォルトの名無しさん
08/04/13 22:35:45
そうなんですよ、いろんな箇所でbreak。
モチベーションとしては呼び出し元にreturnするのは、そのサブルーチンの最後ってことにしたいらしい。
コード自身のクオリティーがそもそも高ければ、エラー処理程度のgoto文は普通にOKだと思いマッスル。

77:デフォルトの名無しさん
08/04/13 22:36:19
>>69
あるある。マイクロソフトのドライバのサンプルコードにそれが。

78:デフォルトの名無しさん
08/04/13 22:38:25
if　(cond)　{
　　n　=　0;
}

こういう、一行でもカッコをつけるべしってスタイルの人は、このスタイルが絶対的に正しいって
信じ込んでる場合が多いですな。

79:デフォルトの名無しさん
08/04/13 22:40:27
>>78
はい、そのスタイルは絶対神であります。

80:デフォルトの名無しさん
08/04/13 22:40:53
>>75さんに言うわけじゃないけど
if、elseに限らず、たとえ省略可能であっても {} は省略しないほうがいい。
動作チェック後、たった1行の修正しようとした新人PGがこれにはまったことがあった。
省略可能とはいえ、その後のメンテを考えればつけるべき。

81:デフォルトの名無しさん
08/04/13 22:42:51
if ( a )
　b = 1; //省略可能
　d = 1;
else
　d = 2;
{
　b = 2; //省略不可能
　c = 1;
}

気にしない。気にしない。

82:デフォルトの名無しさん
08/04/13 22:45:57
有名プロダクツのソースとか、定番の書籍とかでも、省略してるのはよくあるよ。

追加したときに、{}を付け忘れてハマるから省略すべきでないってのが理由だけど、
そんなので嵌るのって、10年プログラムやってて、一回あるかどうかだと思われ。

83:デフォルトの名無しさん
08/04/13 22:50:12
>>82
うん、Linux kernelソースなんかは全然ついてないね。

でも、プロプライエタリを複数人で開発してると、ソースの寿命ってそんなに短いわけじゃないから、
いつ新人が入ってきていじりだすか分からない。
事故は未然に防ぐという意味は十分あると思う。

84:デフォルトの名無しさん
08/04/13 22:51:42
>>82
そんな理由じゃなく、神には叛けないからだろ。

85:デフォルトの名無しさん
08/04/13 22:55:27
if ( a )
　b = 1;
これみたいに1行ならいいけど

for (i = 0; i < 100; i++)
　if (aaa (i)) {

　}
こんなのは外側のも囲わないと気持ち悪く感じる

86:側近中の側近 ◆0351148456
08/04/13 22:55:52
>>82
(っ´▽｀)っ
>10年プログラムやってて、一回あるかどうか
かなり高確率じゃないか。
こういうバグで数百億の損害を出すことだってあるんだよ。

87:デフォルトの名無しさん
08/04/13 22:55:57
俺は１行か２行以上か考えて変えるのが面倒くさいという理由で全部に付けてる。
変更で後から付けるのも面倒だし、変更で後から外すのも面倒だ。
とにかく頭を働かせるのが面倒だ。俺のチャンクは他人より少ないんだぜ。

88:デフォルトの名無しさん
08/04/13 22:59:44
2行を1行に修正した時に {} をとるってのもまぁ、律儀といえば律儀なんだろうけど変な気がする。
今のところそんな diff にはお目にかかったことがありません。

89:側近中の側近 ◆0351148456
08/04/13 23:03:09
(っ´▽｀)っがリーダーで、if文に{}をつけないメンバがいたら、

お前は今後の保守において、if文が2行になった時、
{}を付け忘れる奴がいないことを保証できるのか？

と問い詰めるね☆

90:デフォルトの名無しさん
08/04/13 23:04:00
>>85
おれは、制御されるコードが一行のときだけ{}　省略ってルールでやってる。
複数行の場合は省略したら、さすがに見難いと思った。
K&Rはガンガン省略してたけど。

>>86
まあ、10年に一度ってのは、適当だけど、linuxとかやってる人は影響ないって思ってるみたいだね。

>>83
MISRAとか、ループをbrackで抜けるの禁止とか、安全側に振ったら、いくらでも厳しくなっちゃうだろうね。

たとえば{}の位置論争とか、たいがいの人はどっちでもいいじゃんと思うだろうけど、{}の省略は、なぜか
省略しない派の人は、ぜったい自分が正しいと思ってる場合が多いって話。

91:デフォルトの名無しさん
08/04/13 23:06:29
> 複数行の場合は省略したら、さすがに見難いと思った。
具体的にどんなのよ？

92:デフォルトの名無しさん
08/04/13 23:08:00
>>91
>>85　のようなコード

93:デフォルトの名無しさん
08/04/13 23:09:47
>>90
自分が正しいと思ってるかどうかじゃなくて、実際に起こった事故の同じ轍は
二度と踏ませないという意味で説得力があるって話。

94:デフォルトの名無しさん
08/04/13 23:09:57
インデントで見やすくしとけよ。

95:側近中の側近 ◆0351148456
08/04/13 23:10:26
(っ´▽｀)っ
{}の省略のメリットってなんだろう☆
2文字減らせるってことかな☆
デメリットは2行になった時に{}を付け忘れても普通に動くってことだよね
テストで気づけよと思うかもしれないが、将来直す人に対して言うことはできないよ
{}を付け忘れるなとコメントを残す？それだったら{}つけよう☆

96:デフォルトの名無しさん
08/04/13 23:10:43
>>91
if　(・・・)　{
　　if　(・・・)
　　　　n　=　0;
}

こういう場合は内側のifは{}省略。外側は省略しない。

97:側近中の側近 ◆0351148456
08/04/13 23:12:29
(っ´▽｀)っ
と言いつつ(っ´▽｀)っも
if(条件A){
}
else if(条件B){
}
else{
}
ってやるけどね。
厳密に{}をつけるルールなら
if(条件A){
}
else{
　　if(条件B){
　　}
　　else{
　　}
}
だね☆

98:側近中の側近 ◆0351148456
08/04/13 23:13:48
(っ´▽｀)っ
だって、見やすいんだもん☆
条件が増えると
if(条件A){
}
else{
　　if(条件B){
　　}
　　else{
　　　　if(条件C){
　　　　}
　　　　else{
　　　　　　if(条件D){
　　　　　　}
　　　　　　else{
　　　　　　　　if(条件E){
　　　　　　　　}
　　　　　　　　else{
　　　　　　　　}
　　　　　　}
　　　　}
　　}
}
って感じで深くなっていく・・・

99:デフォルトの名無しさん
08/04/13 23:14:18
>>93
でも、じっさいでかいコードを書いて、実績上げてる人でも、いらねって思ってる人もけっこうな数いるわけで。
そうでないひともいっぱいいるし。
正直「どっちでもいい」レベルの話だとしか思えない。

>>95
メリットはコードが見やすくなる。

100:デフォルトの名無しさん
08/04/13 23:14:51
>>95
全然関係ないが、俺は未来にメッセージを送信できる装置を考案したぞ。
完成したら将来直す人と連絡するために使ってみるか？

101:デフォルトの名無しさん
08/04/13 23:15:55
>>97 >>98
厳密うんぬんの方はぶっちゃけどうでもいいんで、脳内で繰りひろげてください。
ただただキモいです。

102:側近中の側近 ◆0351148456
08/04/13 23:16:34
>>101
(っ´▽｀)っ
そりゃキモいさ☆
URLﾘﾝｸ(www.google.com)

103:側近中の側近 ◆0351148456
08/04/13 23:17:41
(っ´▽｀)っがキモいのはよくあること。配慮してくれないと☆

104:デフォルトの名無しさん
08/04/13 23:18:53
>>102
ごめん、おれ、あんたとはファーストエンカウントだ。
あんたのことはたぶん忘れないよ。終生キモいってことでインプットしといた。

105:側近中の側近 ◆0351148456
08/04/13 23:18:57
>>100
(っ´▽｀)っ
使ってみて使ってみて☆

106:デフォルトの名無しさん
08/04/13 23:21:08
読みにくいコードって確かに上に書かれているような
「書き方」の問題もあるけど「書き方」だけではない何かがあるよね。
なぜそれをしているのか分からないけど意味がある部分とか
論理的には正しいけど、簡潔に書かれていないとか。
う～ん、うまく表現できないけど。

107:側近中の側近 ◆0351148456
08/04/13 23:22:01
>>104
(っ´▽｀)っ
サンクス☆

108:デフォルトの名無しさん
08/04/13 23:27:18
>>99
興味本位で聞いちゃうけど見やすいってのは、
行数が少なくなるから？
文字数が少なくなるから？
{}がないことで処理が１行しかないと判定できるから？

109:デフォルトの名無しさん
08/04/13 23:28:06
>>106
最適化の問題かもな。
コメントで補えばいいだろ。

110:デフォルトの名無しさん
08/04/13 23:33:24
>>99
その「どっちでもいい」に足をすくわれた人間は、はたと気づく。
「ここの {} はあってもなくてもいいんじゃないですか？」と言われればちゃんと
自分の実体験からその必要性が説明ができる。
「どっちでもいい」と思ってる奴は今後も引き続き「どっちでもいい」でいいよ。

111:デフォルトの名無しさん
08/04/13 23:45:04
>>108
省略派の人は、省略すべきだと主張したりして、理由を言ったりしないから、一般的な理由はしらない。
お作法系の本でも、そういう議論はみた記憶がない。

個人的には慣れの問題。

>>110
コーディングスタイルって、どれか決定的に有利なのがあれば、2chで議論するまでもなく、とっくにそれに収束してると
思うんだよ。
有力な人たちの間でも考えが分かれてるような問題は、まあ「どっちでもいい」レベルなんだと思うよ。

112:デフォルトの名無しさん
08/04/13 23:45:25
>>78
残念ながらそれは正しくない。なぜコンパイルエラーにならないのか？不思議なくらいだ。
正しくは、こう
if(cond)
{
　　n = 0;
}

113:デフォルトの名無しさん
08/04/13 23:52:00
中間とって
if(cond) // {
　　n = 0;
// }
こうしとけばいいだろ。

114:108
08/04/13 23:55:29
>>111
最後の理由でないなら安心した。
付けることで思考の妨げになってるんじゃないかと心配してたが
そうでもないようで良かった。
（まあ複数行での括弧付きが読めるんだから当たり前か）

115:デフォルトの名無しさん
08/04/13 23:57:56
>>112
C#だと半強制的にそうなるな。

116:デフォルトの名無しさん
08/04/13 23:58:55
>>111がどの程度の規模のプロジェクトに関わっていて、また、
その中でどのポジションにいるのかわからないけど、
リーダーなどリスクに大して敏感な人は、その「有力な人たち」の一部が
危険性を孕んでいると認めているコーディングスタイルに対して
それを無為無策に放ったりはしない。

「どっちでもいい」と思うんなら別にもう「どっちでもいい」でいいよ。
これ以上は平行線だから。

117:デフォルトの名無しさん
08/04/14 00:01:37
>>115
VSの設定で変更できるよ。

118:デフォルトの名無しさん
08/04/14 00:02:09
お前らの書き込み見てるとどうも正しいコードの書き方について
論じているように思えてならない。

119:デフォルトの名無しさん
08/04/14 00:08:22
じゃあとりあえず
n = cond ? 0 : n;

120:デフォルトの名無しさん
08/04/14 00:15:21
if(...){
...
}
の様に右端に｛を書かれると、括弧の対応かなり読みにくい。こんな読みにくいコード書く理由があるのか？

121:デフォルトの名無しさん
08/04/14 00:20:34
じゃあとりあえず
(cond&&(n=0));

122:デフォルトの名無しさん
08/04/14 00:22:27
>>120
俺は昔そう書いてた。理由はCの本がそうだったから。
今では違う

123:デフォルトの名無しさん
08/04/14 00:25:01
>>120
ifがあるってことは{もそこにあるってことだから問題ない

124:デフォルトの名無しさん
08/04/14 00:25:59
ローカル変数を複数の用途に使いまわす

もかなりイライラ来るなあ

メンバ変数だと直させるが

125:デフォルトの名無しさん
08/04/14 00:29:46
XMLのノードは3階層までのアクセスに
限定させる
<a><b><c></b></a>

126:デフォルトの名無しさん
08/04/14 00:30:18
>>120
これは慣れの問題

127:デフォルトの名無しさん
08/04/14 00:36:42
俺はこれが読みにくい

if (...)
　{
　　...
　}
...

128:デフォルトの名無しさん
08/04/14 00:38:54
>>124

for (int i = 0; ...)

が許される言語なら同意

ま、C な人の一部は高級アセンブリだという宗教があって
どっちみちレジスタは使いまわすじゃんみたいなｗ

129:デフォルトの名無しさん
08/04/14 00:44:09
ループ変数は字面的に局所化されてるように見えるからいいんだが
そうでない変数をこねくり回されると死ねる

130:デフォルトの名無しさん
08/04/14 00:44:33
・明らかに何らかの判断結果を返している関数名が、executeXXXXX()
　逆に、処理を行っているのに checkXXXXXX()

131:デフォルトの名無しさん
08/04/14 01:09:57
普通に書け

132:デフォルトの名無しさん
08/04/14 01:22:31
バグを直してるうちにそうなっちゃうことがあるのは良くあること。

133:デフォルトの名無しさん
08/04/14 02:59:48
#define HYAKU 20

134:デフォルトの名無しさん
08/04/14 05:17:26
>>14
キャストと{}省略、難解な演算子はCなら比較的みんなやるだろ
そうだと言ってくれ…

135:デフォルトの名無しさん
08/04/14 05:26:18
おれはやらんなぁ～ウヒヒヒヒィ

136:デフォルトの名無しさん
08/04/14 22:46:24
>>134
やってるよ。単に>>14のスキルが低いだけだろ

137:デフォルトの名無しさん
08/04/15 02:34:56
・checkXXX() なんてメソッド名

何がどうなるとその結果になるのか意味わかんねーw
せめて isXYZ() とかにしてください、おながいします

138:デフォルトの名無しさん
08/04/15 05:41:54
統一されているかどうかだなあ
アレコレが混在していたらそれら一つ一つが「オススメ」であっても
ヘタに見える

139:デフォルトの名無しさん
08/04/15 08:02:07
CheckError()だと、エラー有りがtrue/falseのどちらか迷うが
IsError()だとtrueがエラー有りと考えなくても分かるってことだな。

140:デフォルトの名無しさん
08/04/15 10:51:20
変数名には w と v しか使わない。

int wwvwvvww;
char * wwvvwvww;
FILE * wwvwvwvw;

141:デフォルトの名無しさん
08/04/15 13:22:47
>>137
やべぇ、最近までのオレだ・・・
CheckErrorがふつーにあるｗ
いつもTrueかFalseなのか悩んでたんだよな
これからはちゃんとIsErrorにします・・・

142:デフォルトの名無しさん
08/04/15 14:34:04
呼び出し元でチェックの真偽を確認する時はisErrorと名づけて真偽値を返すようにして
checkErrorというネーミングの時は値を返さずエラーの場合に実行時例外を出すようにしてるなあ

143:デフォルトの名無しさん
08/04/15 20:18:52
変数名、関数名に日本語だらけ。
ウチの社長、他所からソース提供されたときに「読みにくい。日本語にしてくれ」と要求していた。

144:デフォルトの名無しさん
08/04/15 22:08:05
>>120

C++、JAVAなどのコーディング規約ではifの{を右に書くことになっている

ちなみにC#だと改行することになっている

145:デフォルトの名無しさん
08/04/15 22:12:02
>>144
プロジェクトでの規約じゃないのか？

146:デフォルトの名無しさん
08/04/15 22:13:39
まぁ統一されてればどっちでもおｋ

147:デフォルトの名無しさん
08/04/15 22:19:28
ブラケットはK&R派かGNU派かって認識だったな。
オフィシャルでコーディング規約があるなら教えて欲しい。

148:デフォルトの名無しさん
08/04/15 22:44:50
>>147
C/C++の世界で公式と言えばGNUのこと。
非標準はマイクロソフト。

149:デフォルトの名無しさん
08/04/15 22:50:21
ISOでもANSIでもいいけど規格化されたコーディング規約ってあるの？
C/C++の世界で公式といえばそういうものを指すんじゃないのか？

150:デフォルトの名無しさん
08/04/15 22:56:48
>>149
いいえ。
標準化委員の大多数がGNU関係者だから。

151:デフォルトの名無しさん
08/04/15 23:39:38
結局、そういうふうに書くやつが委員に多いと言うだけであって
オフィシャルじゃないってことか？

意味ねー。

152:デフォルトの名無しさん
08/04/16 00:01:44
>>144
>　ちなみにC#だと改行することになっている　

VSの設定いじれば、どっちのスタイルでも使えるよ。

153:デフォルトの名無しさん
08/04/16 00:06:13
コメントでも、ログでも、画面に出すメッセージでも、字の間にスペース入れて目立たせるやつ。

＊　＊　＊　対　　象　　デ　　ー　　タ　　更　　新　＊　＊　＊

みたいなの。
特にログでやると検索できねーだろ。アホか。

154:デフォルトの名無しさん
08/04/16 00:27:13
ワロタ

155:デフォルトの名無しさん
08/04/16 01:04:54
・無駄な括弧をつける
　if ((a >= 0) && (b <= 0) && (c != ((10 * 3) / d) + e)) {
・文字を詰める
　if(a>=0&&b<=0&&c!=10*3/d+e){

156:デフォルトの名無しさん
08/04/16 01:04:54
>>152
全員でやってないと、なにかの拍子に書き換えられちゃうんだよな。
デフォルトの力の前には無力だ。

157:デフォルトの名無しさん
08/04/16 02:55:47
各関数にreturnは1個というコード規約に振り回され難解なコードに化けたものを見たことがある。
return1個は慣れればどうってことないけどその人は初体験だったみたい。
ソースレビューはなかったらしい。

多重ネストでforから脱出するフラグがいっぱい♪

158:デフォルトの名無しさん
08/04/16 03:03:46
>>157
例外使ってないってことはCかな。

159:デフォルトの名無しさん
08/04/16 07:02:41
>>155
それは駄目なのか？むしろ括弧はつけろと思うが
演算子はつめてもいいんじゃないか？

160:デフォルトの名無しさん
08/04/16 07:13:25
>>155さんじゃないけど、おれもこれ程度のif文なら無駄な括弧は省きたい。
でも、レビューしたとき「なくてもいいのは知ってるけど、つける規約になってるからつけて」って言われてつけてる。

コンパイルは -Wall なんで、「ambiguous ...」みたいなメッセージをたまに見るところをみると
おれもまだまだダメちんのようです。

161:デフォルトの名無しさん
08/04/16 08:02:34
C系だと括弧は気にせず付けて、VB系だと括弧はなるべく付けないようにしてる。

162:デフォルトの名無しさん
08/04/16 18:14:03
無駄な括弧大好きで、if文は一行でも括弧付ける派の俺が言うのもなんですが
Javaでは
int a[];
よりも
int[] a;
として欲しい

163:デフォルトの名無しさん
08/04/16 22:50:53
・普通のコード
struct　Item　{
　　int　id;
　　int　size;
　　string　name;
}
Item　items[NUM];

・基本
int　id[NUM];
int　size[NUM];
string　name[NUM];

・上級者
struct　Item　{
　　int　id[NUM];
　　int　size[NUM];
　　string　name[NUM];
}
Item　item

164:デフォルトの名無しさん
08/04/16 23:36:51
>>163
基本って何の基本だ？
AoSよりSoAの方がいいという話は聞いたことがあるが、未だにメリットがわからない・・・

165:デフォルトの名無しさん
08/04/16 23:43:32
x >= 0 ? x += 100 : x -= 100;

はどうかな? 「素直にif文使えよ」と言っといたんだけど。

x += (x >= 0) ? +100 : -100;

ならなんとか許容範囲。

166:デフォルトの名無しさん
08/04/16 23:45:46
>>164
パディングの分だけ無駄領域が出にくいとか。
つーか、AoSとかSoAってのも初めて聞いた。

167:デフォルトの名無しさん
08/04/16 23:51:59
>>164
>>1　に載ってる基本レベルかなと思って。

168:デフォルトの名無しさん
08/04/16 23:54:11
>>165
> x >= 0 ? x += 100 : x -= 100;
gcc-4.1.2だとコンパイルできん。

169:デフォルトの名無しさん
08/04/16 23:55:53
名前空間が分かれてるのにわざわざプレフィックスを付ける
struct　Hoge　{
　　int　hoge_xxx;
　　int　hoge_yyy;
　　int　hoge_zzz;
};

struct　tmとかCの標準ライブラリでもやってるけど。

170:デフォルトの名無しさん
08/04/16 23:56:47
>>165
私は頭が悪いので少しでも考えないといけないソースは苦手です。

171:デフォルトの名無しさん
08/04/16 23:58:49
すべての行の右側にコメントが入っている。
FORTRANとかアセンブラの話じゃなくて、C++の話。

172:デフォルトの名無しさん
08/04/16 23:59:14
・なんでもかんでも>>163の上級者に従うコード

プログラムの律速はキャッシュミスにあるので、使用するアルゴリズム、処理によって
データ構造を適切に選ぶ必要がある。
また、組み込み系などメモリがシビアな時は、速度を犠牲にして空間効率を高めたりするので、
開発環境によっても自然、アルゴリズムとデータ構造は適切に選択しなければならない。

173:デフォルトの名無しさん
08/04/17 00:05:23
>>171
富士通だか日立だか忘れたけど、もと有名企業の社員で技術力には自信がありますとかHPでアピールしてる
フリーの人から仕事をもらったら、そういうコード書いてたよ。
こういうところがアマチュアと違うんだとか、本人は得意げだったけど。

174:デフォルトの名無しさん
08/04/17 00:22:22
>>173
書けばいいってもんじゃないんだがなあw
しかも書いてあるコメント見ると、>>7みたいなのがほとんどだった。

175:デフォルトの名無しさん
08/04/17 01:51:14
>>168
調べてみたが、C++ならおkだが、Cだとだめらしい。初めて知ったよw
つーか、>>170の言う通りだよなあ…

176:デフォルトの名無しさん
08/04/17 02:46:05
x += (x >= 0) * 200 - 100;
こういう書き方が玄人の証と考えていた時期が俺にもありました。

177:デフォルトの名無しさん
08/04/17 02:46:48
だいたいコードレビューでダメだしされます

178:デフォルトの名無しさん
08/04/17 03:57:32
x += ((x >> 31) & -200) + 100;

179:デフォルトの名無しさん
08/04/17 10:52:47
>>178
"Hacker's Delight"レベルなら許すんだがなあw

180:デフォルトの名無しさん
08/04/17 11:09:53
プロジェクトで指定されてもいないのに、
妙に大仰なファイルヘッダ書くのは素人くさいなあと思う。
ずれまくりだとは思うがこんな感じ。

//----------------------------------------------------------------------------//
//　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　//
//　　Sub System Name : Xxxxxx Module　　　　　　　　　　　　　　　　　　　　 //
//　　File Name　　　 : Xxx_Main.h　　　　　　　　　　　　　　　　　　　　　　//
//　　Engineer　　　　: xxxxxxxx xxx　　　　　　　　　　　　　　　　　　　　　//
//　　Created Date　　: yy.mm.dd　　　　　　　　　　　　　　　　　　　　　　　//
//　　Last Edit　　　 : yy.mm.dd　　　　　　　　　　　　　　　　　　　　　　　//
//　　Revision　　　　: nnn　　　　　　　　　　　　　　　　　　　　　　　　　 //
//　　Description　　 : Xxxxxx Module Local Define　　　　　　　　　　　　　　//
//　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　//
//　　Copyright (C) by xxxxxxxxxx Co.,Ltd. All rights reserved.　　　　　　　 //
//　　Author xxxxxxxxxx Co.,Ltd.　　　　　　　　　　　　　　　　　　　　　　　//
//　　機密文書:永久　　xxxxxxxxx Confidential　　(Critical:Eternity)　　　　　//
//　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　//
//----------------------------------------------------------------------------//

日付やリビジョンを人手で入力してたり、
日本語でおkなのにもかかわらず微妙な「英語」で書きたがるのもお約束かなあ。

181:180
08/04/17 11:26:37
今見たら、フッタにまでこんなのが書いてあった。

//----------------------------------------------------------------------------//
// 機密文書:永久 xxxxxxxxxx Confidential (Critical:Eternity) //
// この文書、図面、Source Code、及び、含有する全情報の所有権,著作権は //
// xxxxxxxxxxxxxx株式会社に属する。事前にxxxxxxxxxxxxxx株式会社の文書による //
// 許可無くして、xxxxxxxxxxxxxx株式会社の物品の製造以外の目的に、この図面、 //
// Source Codeを複写、複製及び使用してはならない。 //
// Copyright(c); xxxxxxxxxx Co.,Ltd. All rights reserved. //
// Use,duplication or disclosure restricted by the law & xxxxxxxxxx Co.,Ltd. //
//----------------------------------------------------------------------------//
// ****************************** [ XX_Common.h : EOF ] ******************************

別に法務部から何か言われたとか、上司から指示があったとか、
コーディング規約で決まってるとか一切なくて、本人の独断で入れたみたい。
こんなの書かなくても機密保持契約は有効だし、
会社の著作物であることは当然なんだけど、もしかしてわかってないのかなあ…

182:デフォルトの名無しさん
08/04/17 11:32:24
>>181
あれこれ理由はなくて、書いた本人が単にそういう様式で書きたかっただけだろ？
「ぷれぜんてっど　ばい　おれ」みたいな感じで

183:デフォルトの名無しさん
08/04/17 13:16:24
日本語の文中に、カタカナで書くのが普通な外来語を
英語表記で書くのってなんか馬鹿っぽいよね。＜Source Code
自意識過剰な人なのかもな。

184:デフォルトの名無しさん
08/04/17 14:29:44
ヘッダだけなら実害もないんだけど、そういうズレた自己アピールを成果物に盛り込みたがる奴は、
コードそのものでも>>176とか>>178みたいに「個性」を表現したがる。

そういう奴はコードレビューでいじめてやるのだが。

185:デフォルトの名無しさん
08/04/17 14:43:22
>>176はともかく、>>178はｲｲﾝｼﾞｬﾈ？速いんだし。
もちろんコメントつけてわかりやすくしといた方がいいけど。

全くもって速度がどうでもいい場所で
そういうコードばっかり考えて時間無駄にしてるならともかく、
コンパイラが最適化してくれない部分を
そういうテクで補うクセが付いてる人って、俺は羨ましいけどなぁ。
自分はなかなか思いつかんし。

>>178みたいなテクを考える人が減ってくのはちょっと寂しい。

186:デフォルトの名無しさん
08/04/17 14:50:57
>>184
もしかして逆アセンブルとかしてデバッグできない人？
すべてのケースで、またすべてのコンパイラで成り立つか分からないが、
多くの場合3項演算子使った最適化に有利。
そんなこと知らないとしたら、>>184みたいな人間にレビュー付き合わされる人間て可哀想。

187:デフォルトの名無しさん
08/04/17 14:51:51
>>185
真偽値を1,0と決め付けている点で五十歩百歩。技巧以前の問題なのだ。

188:186
08/04/17 14:52:36
あ、すんません。
>>185さんが言うように、すべてのケースにおいて3項演算子使えなんてことは毛頭言うつもりはないです。

189:デフォルトの名無しさん
08/04/17 14:59:41
>>178もどうかしかし
符号付きなら論理シフトになるか算術シフトになるか決まってないし
32ビットと決め打ちだし、そもそも普通のif文のほうが早い可能性もあるし

190:デフォルトの名無しさん
08/04/17 15:28:27
>>187
う？178のどこに真偽値が？
まぁどっちにしても環境を限定した書き方だから
処理系をまたぐであろうプコードでそんなの書けないだろうけど。

191:デフォルトの名無しさん
08/04/17 15:28:58
×プコード
○コード
orz

192:デフォルトの名無しさん
08/04/17 15:40:06
おまいら、アクロバティックな記述もいいが、オブジェクトの解放をしてない、なんてのもポイント高いですよ。
「システムを運用しているうちにサーバの応答が遅くなり、しまいには無応答になる。サーバを再起動すれば治るが、
数日でまた応答しなくなる」というクライアントの訴えを受けてサーバを調べた俺が見たものは……
メモリを埋めつくす数十プリニウスものexcel.exeだった。

193:デフォルトの名無しさん
08/04/17 15:53:59
三項演算子が「禁止」なのは、許可すると技巧に走るバカがいるから
三項演算子自体の可読性も性能も別段悪くないんだが…

194:デフォルトの名無しさん
08/04/17 16:22:18
>>185
>速いんだし。
x>>31　が　abs(x)　より速いという確証があるのか？
>全くもって速度がどうでもいい場所で
速度が問題になる箇所ならインラインアセンブラ使えって話だ。

>>187
>決め付けている点で
関係演算子の結果は、そう決まっている。
>>189
>論理シフトになるか算術シフトになるか決まってないし
こっちは処理系定義なんで、移植する気がないなら問題にはならない。
まあ個人的には、どっちもｷﾓいな。

195:デフォルトの名無しさん
08/04/17 16:24:50
abs(x)使うとどう書けるの？

196:194
08/04/17 17:47:52
abs(x)関係ない。すまん、読み違えてた。
元の>>178のコードだとふつーにifか三項演算子だ。

197:デフォルトの名無しさん
08/04/17 17:53:22
185だけど、論理式＋乗算(>>176)よりはシフト＋ビットごとのAND（>>178）
の方がさすがに速いだろうと思ったんだけど。違うの？
高速化に関しては初心者だけどさ。

＞速度が問題になる箇所ならインラインアセンブラ使え
そらそうだろうけど、ゲームなんかだと毎秒30～60回実行されるコードが
何万行とあるじゃん。チリも積もればなんとかで、手軽に条件分岐を減らせるなら
減らした方がいいと思うけど。俺の場合は上にコメント書く。

abs(x)使うやり方は気になるｗ　まさか((x - abs(x)) & -200)とか？

198:197
08/04/17 17:56:18
ぶｗ　すれ違いだし最後の式おかしいし・・・
なんかいけそうな気もするけど無理か。スレ汚しｽﾏｿ

199:デフォルトの名無しさん
08/04/17 21:07:25
もっと時間食ってるコードが絶対あるから、
簡単な計算は可読性重視、速度無視

200:デフォルトの名無しさん
08/04/17 21:25:48
名前空間が分かれてるのにくべつ用のプレフィックスとか付ける
struct　Hoge　{
　　int　hoge_xxx;
　　int　hoge_yyy;
　　int　hoge_zzz;
};

struct　tmとかCの標準ライブラリでもあるけど。

201:デフォルトの名無しさん
08/04/17 21:35:16
配列とかで大量に使うならともかく、ローカルのワークに使う変数とか、引数なんかでshortを使ってるやつ。

202:デフォルトの名無しさん
08/04/17 21:45:16
>>200
これは俺もよく見る。そのたび同じことを思う。

203:デフォルトの名無しさん
08/04/17 22:23:48
なんで>>169と同じ事を書いてんの
スルーされたから？

204:デフォルトの名無しさん
08/04/17 22:34:52
コピペによる予想外の冗長さを身をもって表現してくれたんだよ。

205:側近中の側近 ◆0351148456
08/04/17 23:06:24
(っ´▽｀)っ
処理時間をどうこう言ってる人がいるが、
保守性、可読性を優先させたほうがいいでしょう。
処理時間をどうこう言うなら、目標時間を定めてから。
1秒を0.95秒にしたところでユーザに喜ばれるだろうか？
こう言うと、
ちりも積もれば山となる、処理時間だって言える
ソースコード全てにおいて、スピードを考慮すべき
と答える人がいるが、
実は、ソースコードの5％が処理時間の95％を占めるという研究結果がある。
つまり、闇雲にスピードを追求してもあまり意味が無いってことだ。
むしろ、スピードを追求した結果、
保守性が低くなるどころがバグ満載では、本末転倒である。

(っ´▽｀)っ
処理時間と保守性、可読性についてもっと知りたい、考えたい人には、
コードコンプリート下巻をお勧めしよう。

206:側近中の側近 ◆0351148456
08/04/17 23:11:32
(っ´▽｀)っ
コードコンプリートは上巻を読まないと下巻は理解しづらいかもしれないね☆
上下巻併せて12,810円です。
上下巻ともに、広尾の都立中央図書館の1階開架に置いてあるようです☆

207:側近中の側近 ◆0351148456
08/04/17 23:13:39
(っ´▽｀)っ
っていうか、名著中の名著だから、ここの人たちはみんな読んだことがあるんだろうね☆
(っ´ω`)っ出しゃばってごめんね、いきててごめんね、

208:デフォルトの名無しさん
08/04/17 23:18:31
＞実は、ソースコードの5％が処理時間の95％を占めるという研究結果がある。

観念的な空論をとなえるのをやめてちゃんとプロファイルをとれば、
こんな流言に左右されずに適切な最適化を実施すること（あるいは実施しないこと）ができる。
ところで漏れが組んだシステムで↑みたいな極端な例は殆ど無かったなぁ。
実はかなり特殊な領域を対象にした研究なんじゃないだろうか。

次ページ