ヘタなコードの書き方

ヘタなコードの書き方 at TECH

[1からを表示]
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％を占めるという研究結果がある。

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

209:デフォルトの名無しさん
08/04/17 23:23:34
リファクタリングの本だとたしか10%と90%って数字だったな。
まあなんにせよ速度の最適化にはまず測定からだ。

210:208
08/04/17 23:31:49
>>208
ちょっと前の俺に反論。
高速化したい対象だけ注視しないで、UIやらなんやらを含む全コードを見れば
やっぱり極々一部が大半のCPUパワーを使っているような気がするぞ。

211:デフォルトの名無しさん
08/04/17 23:32:10
//Author ああああ

毎度、毎度ファイル先頭に1行
ってなんだよやめてくれよｗ

212:側近中の側近 ◆0351148456
08/04/17 23:33:18
(っ´▽｀)っ
こういう感じだね☆

処理時間の目標の設定(Plan)
↓
測定(See)
↓↑
処置(Do)

213:デフォルトの名無しさん
08/04/17 23:33:19
>>184
これ書いた人、ローカル変数の頭に全部"the"つけてるんだよね。こんな感じ:

#define UC unsigned char
#define CLEAR 0
static void Xxx_YyyClear( UC inXxxYyyName )
{
　　UC theXxxLocalYyyNameNo = CLEAR;

　　theXxxLocalYyyNameNo = inXxxYyyName;
　　xxxGlobalInfo[ theXxxLocalYyyNameNo ] = clearXxxYyyyInfo;
}

強烈でしょw 固有名詞は伏せたけど、実在のコード。
補完機能付きのエディタ使ってないのに、
使い捨てのローカル変数にこんな長い名前つけてて、なんともご苦労様なことで…

あ、関数名が(動詞+目的語ではなく)目的語+動詞になるのもへたくそっぽくない?

214:側近中の側近 ◆0351148456
08/04/17 23:39:17
(っ´▽｀)っ
で、コードコンプリートってどうなの？名著なん？

215:デフォルトの名無しさん
08/04/17 23:40:09
一番気になったのはこれだ
#define UC unsigned char

216:デフォルトの名無しさん
08/04/17 23:45:54
>>203
ネタ帳から貼ったの忘れてたよ。

217:デフォルトの名無しさん
08/04/17 23:51:58
>>215
名前もあれだけど、なんでtypedefにしないんだ。

218:デフォルトの名無しさん
08/04/18 00:02:48
>>213
>補完機能付きのエディタ使ってないのに、
こういう人たちは補完を使わない=出来る人間だと思ってる節がある。
全員分IDE買ってんのに「自分はEditor派なんで」。

・・・しかも当然遅い。

219:デフォルトの名無しさん
08/04/18 00:11:02
>>215
実際にはそれはプロジェクトのヘッダファイルに入ってるんで、
それはまた別の困ったちゃん。ちなみに>>171w

まあ、typedef知らないんだろうと思うよ。
そういえばconstやstaticも使ってなかったな。

220:デフォルトの名無しさん
08/04/18 00:13:34
>214
絶対読まなきゃ、というほどではないにしろ、読んでおくほうが望ましい。
ちゃんとわかってて読めばいい本ですよ。

221:デフォルトの名無しさん
08/04/18 00:22:37
なんか急にレベルが下がったな
女の陰口のようだ

222:デフォルトの名無しさん
08/04/18 00:34:52
とあるヘッダファイルから。

　　#ifdef　　GLOBAL_VALUE_DEFINE_XXX_COMM
　　　　//　グローバルを作る
　　　　#define　 GLOBAL_XXX　　　　　　　　//　GLOBAL→空白に変換
　　　　#define　 GLOBAL_XXX_VAL(v) =(v)　　//　GLOBAL_VAL(数値)→(数値)を設定する
　　#else
　　　　//　グローバルを使う
　　　　#define　 GLOBAL_XXX extern　　　　 //　GLOBAL→externに変換
　　　　#define　 GLOBAL_XXX_VAL(v)　　　　 //　GLOBAL_VAL→削除する
　　#endif

GLOBAL_XXX SomeStructAaa　　　varAaa;
GLOBAL_XXX SomeStructBbb　　　varBbb;
GLOBAL_XXX SomeStructCcc　　　varCcc;
...

ある意味懐かしい感じがする。

223:デフォルトの名無しさん
08/04/18 00:50:08
なぜかcaseラベルのある行だけ複数の文を書く人がいる。

switch(xxx) {
case XXX: var1 = ...; var2 = ...; break;
case YYY: var1 = ...; var2 = ...; break;
case ZZZ: var1 = ...; var2 = ...; break;
}

224:デフォルトの名無しさん
08/04/18 00:56:17
>>222
何でもかんでもって感じで多用されてたらうざいけど、使うこと自体は別にいいかなって思う。
それよりもプリプロセッサのネストが気になるｗ

225:デフォルトの名無しさん
08/04/18 01:02:16
多次元配列の定義で、最初のデータを書き終わるまで改行してくれない。

struct Xyz fooBarBaz[DIM_XXX][DIM_YYY][DIM_ZZZ] = {{{{1,2,3},
　　　　　　　　　　　　　　　　　　　　　　　　　　　// 中略
　　　　　　　　　　　　　　　　　　　　　　　　　　 {7,8,9}},
　　　　　　　　　　　　　　　　　　　　　　　　　　　// 数十行くらい続く

226:デフォルトの名無しさん
08/04/18 01:12:33
構造体の(ポインタでない)メンバにconstとかvolatileがついてる。

struct Xyz {
　　　　volatile int xxx;
　　　　volatile int yyy;
　　　　volatile int zzz;
};

つーか、文法的にはおkなのかなあ?

227:226
08/04/18 01:24:55
う、POD型な構造体に限定したほうがいいかな。
それにしたってvolatileはないけど。

228:デフォルトの名無しさん
08/04/18 01:27:21
>>223
縦に揃ってたら見やすいじゃん。
一貫性があれば異質な物にも気付きやすいし。

229:デフォルトの名無しさん
08/04/18 01:30:46
>>226
const int * p;なら意味あるよん。
規格呼んだわけじゃないけどそれ以外は関数のexternと同じように無視される気がする。

230:デフォルトの名無しさん
08/04/18 01:39:35
>>229
うん、だからポインタでないメンバと限定したわけだ。
(PODな)構造体のメンバがint * const memberとか宣言されてたらおかしいでしょ。

231:デフォルトの名無しさん
08/04/18 02:38:10
>>223
case hoge: の後が一文（特に代入だけ）の場合、
俺も改行しないで列挙するなぁ。複数の文はさすがにアレだけど。

232:デフォルトの名無しさん
08/04/18 03:14:02
縦に揃うときれいだからといって、同じ条件の三項演算子をズラズラ並べるのはカンベンして欲しい。

233:デフォルトの名無しさん
08/04/18 08:14:11
おまえら正しくは条件演算子ですよ
三項演算子の一種であるので
C言語の場合ほぼイコールだけど

234:デフォルトの名無しさん
08/04/18 08:23:39
>>230
>(PODな)構造体のメンバがint * const memberとか宣言されてたらおかしいでしょ。
別におかしくない。
初期化で値を設定して、その後変更するつもりがないメンバだろ？

235:デフォルトの名無しさん
08/04/18 14:26:49
>>226
そのコードに必要だったかどうかは実物見ないとわからないけど、
一般論で言えば意味あるに決まってんじゃん・・・

割り込みで変更される可能性のあるメンバとか、
メモリマップトIOのアドレス範囲を構造体で定義するとか、
マルチスレッドで他スレッドからもアクセスされるフラグ的なものとか、
そんなときに使う。稀といえばまれか・・・
案外モノ知らない人多いんだな～。

>>230
そのメンバには書き込んで欲しくないというときには、どう宣言せよと？

236:デフォルトの名無しさん
08/04/18 18:35:17
>>235
226が遭遇した事例では、メンバに付けるよりも
構造体の変数を宣言するときにvolatile付けるほうが適切だったんだと思う。

237:デフォルトの名無しさん
08/04/18 18:55:49
相手がvolatileを知らない前提で語ってるのがﾜﾗﾀ

volatile習いたてですか？

238:デフォルトの名無しさん
08/04/18 18:59:58
>>226はどうみても volatile を知らないわけだが・・・
＞つーか、文法的にはおkなのかなあ?
こんなこと書いてるし。

いや、「見かけたことはある」という程度には知ってるのか。

239:デフォルトの名無しさん
08/04/18 19:13:37
Google code search で、struct volatile を検索すれば
カーネル内のコードやら aKode やら山ほど出てくるね。

なぜポインタにしか使わないとかそういう誤解があるんだろう。

240:デフォルトの名無しさん
08/04/18 22:49:14
>>236
それだと今度は宣言する人が付け忘れちゃう可能性がなくない？

241:デフォルトの名無しさん
08/04/18 23:14:01
>>235,237,238,239
ISO/IEC 9899:1999 6.7.3.3
The properties associated with qualified types are meaningful only for
expressions that are lvalues.
ISO/IEC 14882:1998 3.9.3.2
A compound type is not cv-qualified by the cv-qualifiers (is any) of
the types from which it is compounded.

つまり、メンバにいくらconst/volatileを指定しても、
構造体全体としては指定されてないのと同じということだ。

仮にメンバごとにアクセスする時だけconst/volatileの効果があるのだとしても、
構造体まるごとで操作した時にその効果がなくなるなら、全然意味ないじゃんって話。
で、全メンバに同じCV修飾子をつけるなら、構造体自体を修飾したほうが素直だろってこと。

もっとも、const/volatileは文法的には型に対する修飾子なので、
メンバの宣言に使っても文法上は間違いではない。
記憶クラス指定子のように、オブジェクトに対する指定を行なうものだと
考えるのがわかりやすいかな。

>>230,234
C++のクラスならおかしくない。が、そういうconstメンバはコンストラクタでしか
設定できないから、CやC++のPOD型で指定するのはおかしいって話。

次ページ