ヘタなコードの書き方

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

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型で指定するのはおかしいって話。

242:デフォルトの名無しさん
08/04/18 23:14:02
はじめてここにきたが
おれほとんどあてはまってる
みんなごめん

243:デフォルトの名無しさん
08/04/18 23:21:26
>>241
メンバ変数にアクセスするときに効果があるんだったらそれでいいんじゃないか？

244:デフォルトの名無しさん
08/04/18 23:31:12
だからstructまとめてコピーとかしたときにまずいって話でしょ

245:デフォルトの名無しさん
08/04/18 23:47:46
コピーも結局、暗黙でメンバ変数にアクセスしてるんじゃないか？

246:デフォルトの名無しさん
08/04/19 00:56:14
byte A = 0;
abs(A++);

行ったり来たり...

247:デフォルトの名無しさん
08/04/19 01:00:05
>>108
行数が少なくなる事で各メソッドの全体像を一瞥しやすくなる。
文字数はあまり関係ない。新規行および不具合のある行についてのみ横方向に解析するので。
{}がないことで処理が１行しかないと判定できる。これもデバッガ使用、机上デバッグ、リファクタリング等の際に有効に機能する。

システム保守等で取り扱うコード量が増える程この手の基本的な書き方が重要になってくる。

248:デフォルトの名無しさん
08/04/19 01:04:05
>>246
これは何？
意味分からない

249:デフォルトの名無しさん
08/04/19 01:20:45
int a = 0; for (;;) a = abs(--a);

250:デフォルトの名無しさん
08/04/19 01:33:58
>>247
＞{}がないことで処理が１行しかないと判定できる。
{}が無いのにうっかり処理を2行書いてしまった部分を見逃す危険性は無い？

251:デフォルトの名無しさん
08/04/19 02:03:55
for ();
このセミコロンは下に打っておかないと
１行追加するとき見逃す可能性があると思う
for ()
　;
こんな風に

252:デフォルトの名無しさん
08/04/19 02:22:23
>>250
処理をうっかり２行書いてしまった部分は変更を加えたのだからテスト対象になる。
また見逃してしまうようではシステム保守を担当できるスキルまで達していない事になる。
そもそも局所的にしかコードを把握していないようではシステム保守を任せることができない。

253:デフォルトの名無しさん
08/04/19 02:50:49
>また見逃してしまうようではシステム保守を担当できるスキルまで達していない事になる。

おまえはわかってないな
そういう奴が触る可能性を考慮して書くんだよ

一生そのプログラムの保守をする気があるとか、趣味でやってるとか、書き捨てなら話しは別だけど

254:デフォルトの名無しさん
08/04/19 02:56:41
>>253
わかってないのはおまえだよ。
そういう奴を育てる事も考慮して書くんだよｗ
ゆとりをもって取り組もうな。

255:デフォルトの名無しさん
08/04/19 03:03:52
その発想はなかった
保守担当が自分の部下ならそうするけど・・・
板違いになりそうだからやめとくか

256:側近中の側近 ◆0351148456
08/04/19 03:21:19
>>252
(っ´▽｀)っ
プロジェクトにはスキルの高い人もいれば低い人もいる。
今はスキルの高い人がいるとしても、将来はどうだかわからない。
プロジェクトにスキルの高い人がいるとしても、その人が保守を担当するとも限らない。
要員の都合でスキルの低い人に任せざるを得ない場合もある。
つまり、将来の保守は、どのようなスキルを持った人が担当するかわからない。
貴方が未来永劫保守が正しくなされるのを監視するのであれば問題ないが、
貴方はいつかは退職するでしょう？
貴方がいなくなったとき、保守はどうなるのかな？

257:側近中の側近 ◆0351148456
08/04/19 03:27:00
>>254
(っ´▽｀)っ
もし、その育てられた人が退職したらどうするの？

258:デフォルトの名無しさん
08/04/19 03:58:02
>>256 >>257
まず処理をうっかり２行書いてしまった人とテスト対象を見逃してしまった人は違う人物となり得る。
つまりコードを変更する事とその変更を検証する事は別の事柄だ。
コードを変更する人は>>247等を考慮して作業にあたれば良い。
変更を検証する人はテストケース等でテスト漏れを防止すれば良い。

それでもミス等は発生し得るのだから検証する枠組みを強化すれば良い事になる。
仮に個人のスキルに委ねた検証の仕組みしか提供できないのであればそれはその企業体自体の問題である。

259:デフォルトの名無しさん
08/04/19 07:28:09
>>249
a=a^1;

260:デフォルトの名無しさん
08/04/19 08:38:35
>>258
> それでもミス等は発生し得るのだから検証する枠組みを強化すれば良い事になる。

検証だけちゃんとやればいいという素人くさい意見有難う。(w

俺は、検証もがんばるし、そもそもミスを発生しにくいようにしたいから {} は
省略しない。

261:デフォルトの名無しさん
08/04/19 08:47:43
>>258
> それでもミス等は発生し得るのだから検証する枠組みを強化すれば良い事になる。

失礼なことお尋ねするようですけど、ちゃんとどこぞの会社で働いてらっしゃるんですよね？
ミスは発生しうるという考えが先行してるように見受けられますが、
なぜ、「ミスを起こさせないためにはどうするか」という発想に至らないのか不思議でなりません。

262:デフォルトの名無しさん
08/04/19 08:48:35
他の人も触る可能性があるなら {} つけといたほうがいいと思う

263:デフォルトの名無しさん
08/04/19 08:54:26
付ける付けないはそこまで重要じゃないだろ。
プロジェクトで統一されていることこそ重要。
{}付けるなら絶対にすべてに付ける。
{}付けないなら絶対にすべてに付けない。

264:デフォルトの名無しさん
08/04/19 08:56:42
>>263
重要とかそういうことじゃなく、それは決まりごとっていうんだ。
朝から強烈な電波、お疲れさまです。

265:デフォルトの名無しさん
08/04/19 09:14:53
>>263
すべてにつけないは無理だろう。
俺はすべっつけるけど。空文もな。空文の括弧には、意図した空文か判るようにコメント入れような。

266:デフォルトの名無しさん
08/04/19 09:14:54
決まり事は重要だぞ。
似たような処理が統一されたスタイルで書かれていれば
何も考えずに理解できるし、違う書き方で書かれた場所があれば
そこが特別だということが分かる。

267:デフォルトの名無しさん
08/04/19 09:19:44
決まりごとは守らなければならない、これあたりまえ。
おれは上で議論してるのは、なぜそれを決まりごとと決めなければならないのか、
そっちを議論してるんだと思ってたんだが？

268:デフォルトの名無しさん
08/04/19 09:22:30
うちだと1行に収まる場合以外はブロック化だな。

亀だけど。
>>173
大手ドロップアウト組はそんなもん。
WebSite見るとその頓珍漢なコードを掲載している傍ら、野菜作ってたり実家の手伝いしていたり。
まともな仕事を受注できなくても危機感もなければ研鑽する気もないから酷いコードのままの罠。

269:デフォルトの名無しさん
08/04/19 11:26:44

hoge(int aaa){

if(hogehoge(aaa)==-1) return -1

return 0;
}

見たいな感じでエラー処理したりしちゃう癖があるんだが
これは醜いのか？

270:側近中の側近 ◆0351148456
08/04/19 11:37:51
>>269
(っ´▽｀)っ
C言語？それならエラー時にリソース解放するの忘れないでね☆

271:デフォルトの名無しさん
08/04/19 11:57:11
「関数の出口はひとつにしろ」とか言う人もいるんだよなぁ

インデント深くなるし、わかりにくくなるから、エラー時はさっさとリターンしたいんだけど・・

272:デフォルトの名無しさん
08/04/19 11:59:30
おれはエラー時はさっさとgotoしちゃいます。

273:デフォルトの名無しさん
08/04/19 11:59:44
void someFunc()
{
if (error) goto Return;
...;
...;
Return:
;
}

274:デフォルトの名無しさん
08/04/19 12:01:41
goto文は多重ループを抜けるときにだけ使えって教えられたから

275:側近中の側近 ◆0351148456
08/04/19 12:20:24
(っ´▽｀)っ
そこでtry～catch～finally～ですよ

276:デフォルトの名無しさん
08/04/19 12:21:38
それはC++前提ね

277:デフォルトの名無しさん
08/04/19 12:22:16
>>275
Cならどうしてる？

278:側近中の側近 ◆0351148456
08/04/19 12:28:08
>>277
(っ´▽｀)っ
(っ´▽｀)っも>>273に似たようなもんだが

void someFunc()
{
　/* 主処理 */
　if (error) goto Catch;
　/* 主処理 */
　goto Finally;
Catch:
　/* エラー処理 */
Finally:
　/* 終了処理 */
　return:
}

279:側近中の側近 ◆0351148456
08/04/19 12:29:41
(っ´▽｀)っ
>>278だと、正常の場合でもエラーの場合でも
終了処理が確実に実行されるよね。

280:デフォルトの名無しさん
08/04/19 12:30:28
Catch、Finallyなんて変なラベルは使わない（見たこともない）けど、同じだね。

281:側近中の側近 ◆0351148456
08/04/19 12:32:22
>>280
|▽｀)っ
あえてラベル名は変えてある
(っ´▽｀)っの正体がばれるから☆

|彡☆ ｻｯ

282:側近中の側近 ◆0351148456
08/04/19 12:33:33
(っ´▽｀)っ
>>278の手法って結構メジャーなのかな？
書籍とかであまり見ないから。
(っ´▽｀)っが誰だか特定されちゃうと困るんだけどね。

283:デフォルトの名無しさん
08/04/19 12:34:11
そんなもったいつけてどうすんのｗｗｗ
どうせ、そんじょそこらのおっさんでしょ？ﾌﾟｹﾞﾗｯﾁｮ

284:デフォルトの名無しさん
08/04/19 12:34:15
コテうぜえ

285:側近中の側近 ◆0351148456
08/04/19 12:35:42
>>283
(っ｀Д´)っお・ね・え・さ・ん！！！
(っ´▽｀)っは永遠の16歳だよ。美少女だよ☆

286:デフォルトの名無しさん
08/04/19 12:39:04
お局さんに内部変換した。
貰い手がいないんなら、おれがもらってやるよｗｗｗ

287:デフォルトの名無しさん
08/04/19 12:42:12
でこの書き方はどうなんだ？

288:デフォルトの名無しさん
08/04/19 13:04:31
＞永遠の16歳
なんだ、永遠に女未満なのか。

289:デフォルトの名無しさん
08/04/19 13:04:50
ま、いいんじゃね？一般的かどうかということになると、goto使わない派がそれなりに多い現状からすると
マイナー(ただしマイナーの中のメジャー)だと思うけど。
1行だけのブロックを{}で括らない職業プログラマは逝ってよし。

290:デフォルトの名無しさん
08/04/19 13:11:18
>>289
考え方の問題だろうけど俺は使わん

291:デフォルトの名無しさん
08/04/19 13:24:33
手元にソースのあるプロダクツをざっとみて確認してみた。
if　で一行でも{}でくくってるか。

linux　くくらない
postgresql　くくらない
apache　くくらない
vim　くくらない
mozilla　くくらない
sqlite　基本くくるみたいだけど、くくってないところもある
mysql　くくらない

292:側近中の側近 ◆0351148456
08/04/19 13:39:09
>>289
>マイナーの中のメジャー
(っ´▽｀)っは側近中の側近だよ☆

293:デフォルトの名無しさん
08/04/19 14:13:01
>>291
オープンソースな人とと職業プログラマでポリシーが違うのは当たり前だから、
あまり参考にならない意見有難う。

294:デフォルトの名無しさん
08/04/19 14:13:48
>>293
「と」が余分だった... orz

295:デフォルトの名無しさん
08/04/19 14:15:24
確かに開発ペース＆品質なんかはオープンソース系の方が上だよな。

って事考えると職業プログラマってグダグダ議論するワリにアレだよな・・・。

296:デフォルトの名無しさん
08/04/19 14:23:41
オープンソースの場合は納期もないし責任もないのでそれはまた違った形になってくるのだろう

297:デフォルトの名無しさん
08/04/19 14:23:59
VC++　のランタイムのソースと、SunのJDKのクラスライブラリのソースはくくる派だな。

意外なことに　eclipse　はくくらない派だった。
Javaはくくる文化かと思ってたよ。

298:デフォルトの名無しさん
08/04/19 14:24:48
ちなみに以下のコードはある環境下でバグになるって事を認知してる？
　　　　if (a > 0) {
#define _DEBUG
printf("a = %d\n", a);
#endif
　　　　}

299:デフォルトの名無しさん
08/04/19 14:25:44
>>296
責任ないって言っても、バグっていいとか、保守性がわるくなってもいいとか思って、くくらないスタイルを
採用してるわけじゃないだろ。

300:デフォルトの名無しさん
08/04/19 15:03:30
>>298
そりゃそんなとこでdefineしたらおかしくなるだろ

301:デフォルトの名無しさん
08/04/19 15:04:50
>>296
納期があるから{}を必ずつけるのか。
俺には理解できない話だが、参考になったよw

302:デフォルトの名無しさん
08/04/19 15:06:38
>>298
ていうか_DEBUGって何? NDEBUGではなくて?
そんな環境依存の話されてもわかんない。

303:デフォルトの名無しさん
08/04/19 15:13:49
>>293
以前はクローズドで、後にオープンソースになったSolarisも、くくらない派だったよ。

304:デフォルトの名無しさん
08/04/19 15:13:55
#ifdefだろ常考

305:デフォルトの名無しさん
08/04/19 15:15:04
>>296
現実的な責任云々いいだすとオープンソースの方が責任重いと思うが、
web鯖にたとえるなら喪前はapache以上の普及率を誇る製品作ってるのか？

306:デフォルトの名無しさん
08/04/19 15:16:58
？

307:デフォルトの名無しさん
08/04/19 15:18:45
きっと296はWindowsOSの開発をしていてMSの社内ポリシーは{}を必ずつける、ってんだろ？w

308:デフォルトの名無しさん
08/04/19 15:19:46
オープンソースと責任を議論する人って一体？

309:側近中の側近 ◆0351148456
08/04/19 15:29:11
>>288
(っ´▽｀)っ
16歳の女の子といえば女子高生！
食べ頃じゃないのか？

310:デフォルトの名無しさん
08/04/19 15:41:57
ああごめん。#ifdefの書き間違い。
　　　　if (a > 0) {
#ifdef _DEBUG
printf("a = %d\n", a);
#endif
　　　　}
　　　　b = 1;
　　　　c = 2;
これをリリースモードでビルドするとa > 0の場合にのみb = 1が動作する環境に遭遇したことがある。
使用していたコンパイラが空ブロックにNOPを生成しないタイプだったのが不具合の原因だった。

311:デフォルトの名無しさん
08/04/19 15:45:27
書籍だと、

詳解UNIXプログラミング、UNIXネットワークプログラミング　くくらない
EffectiveC++　くくらない
Effective　Java　くくらない
プログラミング言語　C++　くくらない
プログラミング作法　くくらない

CODE　COMPLETE　くくる　(書籍中では、この件に関しては議論はしてない)
デザインパターン(GoF)　くくる

312:デフォルトの名無しさん
08/04/19 15:45:39
規格に準拠してないコンパイラなんてどうでもいいよ。

313:デフォルトの名無しさん
08/04/19 15:45:51
俺は不要な{}はつけない派だが、
そんな処理系固有のバグを得意そうに指摘しても意味がないと思うぞ。

314:デフォルトの名無しさん
08/04/19 15:48:10
紙媒体を引き合いに出されても困るんですけど。
よく「紙面の都合上…」ってをみるでしょ？

315:デフォルトの名無しさん
08/04/19 15:49:44
でもそういうバッドノウハウとして「{}をつけるべき」とか言ってる奴はいるかもな。
もはや常識であるdo{...}while(0)を知らずに

#define FOO(x) func1(x); func2(x)

みたいにして、痛い目にあったとか。

316:デフォルトの名無しさん
08/04/19 15:53:08
> これをリリースモードでビルドするとa > 0の場合にのみb = 1が動作する環境に
> 遭遇したことがある。

今時のコンパイラならリリースビルドだと普通 if() 分もろとも省略すると思うが。
どんだけしょぼいコンパイラなんだ？

# つーか、コンパイラのバグ回避はまた別の話だろ。

317:デフォルトの名無しさん
08/04/19 15:53:45
>>310
その情報って{}を付けるか付けないかと全く関係ないよね。
何が言いたいの？

318:デフォルトの名無しさん
08/04/19 15:55:06
>>316 >>317
もう触れないであげて。彼はいま自分の若さを再確認してるところだから。

319:デフォルトの名無しさん
08/04/19 15:56:45
>>314
とりあえず第三者が検証可能だから。
上のほうの「自分の経験では」とかだとアレだけど。

まあ、チョイスも偏ってるしあくまで参考までに。

320:315
08/04/19 15:56:50
おっと、do{...}while(0)だって立派なバッドノウハウだな < 自己ツッコミ

だが、へぼいマクロのために必ず{}で囲うべきだと強弁するなら、
そっちのほうがよほどワースノウハウというものだ。

321:デフォルトの名無しさん
08/04/19 16:14:16
>>317
if (a > 0) {
}
b = 1;
c = 2;
をコンパイルすると
if (a > 0)
　　　　b = 1;
c = 2;
と同じ挙動になったという話なだけ。
あくまで「ちなみに」レベルの話。

322:デフォルトの名無しさん
08/04/19 16:18:44
なんでそんな関係のない話を得意げに語るの？

323:デフォルトの名無しさん
08/04/19 16:35:47
>>309
体だけでしょ。心も知性も女未満。

324:デフォルトの名無しさん
08/04/19 17:04:02
Cは「プログラマは無謬」という前提で設計された事を
認めない（／知らない）人が多いところだね。

冗長な記述をいくら推奨しても「歪む」とは思わないの？

325:デフォルトの名無しさん
08/04/19 17:08:26
>>324
dmrはそんなこと言ってなかったよ。

326:デフォルトの名無しさん
08/04/19 17:09:02
～～ことを認知してる？
なんて偉そうに書いてるから俺も気になったじゃまいか。
ifステートメントは直後の１文（セミコロンが１つ見つかるまで）、
もしくは直後の１ブロック？（｛｝で囲まれた部分）までであるというのは
多分CでもC++でも標準規格ではっきり決まってることだと思うんだが、
その程度の仕様も守れないクソなコンパイラのアホなバグを
なぜ知ってなきゃならんのだｗ
技術者が信頼できない道具なぞ使うなと思うし、
使わなきゃならないならその環境が諸悪の根源なだけだろう。

327:デフォルトの名無しさん
08/04/19 17:12:21
本来であれば>>315のマクロ記述の方が不具合なのにそれを隠蔽してしまう「必ず{}で囲うべき」という思想がヘタの証。
>>321も最初から{}を省略する書き方であれば遭遇しない不具合だし。

328:デフォルトの名無しさん
08/04/19 17:14:47
プロトタイプ宣言を書くのはいいんだが、
仮引数を型だけ書く中途半端に古いスタイル。

int foo(int, int);

わざわざ仮引数名だけを消してて、ご苦労様と言いたくなる。
Quick-CとかMS-Cあたりの時代から進化していないらしい。

329:デフォルトの名無しさん
08/04/19 17:16:25
>>324
設計者の意図がどうあれ、そんなことを理解 { しない | できない }
奴等に仕事させないといけないので、{} は必須。

そう言うお仕事もあるってだけのことだ。

>>326
アホに構うな。

そこにしか突っ込めないなら、止めやしないが。

330:デフォルトの名無しさん
08/04/19 17:26:54
＞仮引数を型だけ書く中途半端に古いスタイル。
はぁ? 古いってどういう意味? プロトタイプ宣言は昔からパラメータ名を書いても書かなくてもいいんですが。
ついでに言えば、C++の場合は実体定義のときも省略できますね。

331:葉猫 ◆Jz.SaKuRaM
08/04/19 17:36:46
プロトタイプの引数に変数名入れるのは素人っぽいからﾔﾀﾞ

332:デフォルトの名無しさん
08/04/19 17:40:31
>>330
うんうん、そうだよね。文法的には正しいよね。
わざわざ情報量落してるあたりが馬鹿っぽいということとは無関係だもんね。

333:デフォルトの名無しさん
08/04/19 17:42:57
>>331
と考えてしまうところがヘタレな証拠

334:デフォルトの名無しさん
08/04/19 17:43:21
>>330は返り値がintの関数を定義するとき型名を書かないらしい。

335:デフォルトの名無しさん
08/04/19 17:44:28
それはc++とc99ではできなくなったはず

336:デフォルトの名無しさん
08/04/19 17:45:05
Cはプロトタイプと本体の定義で、名前が違っていてもエラーにならんからね。
書く人にやめろとは言わないけど、俺も書かない。

void　func(int　x,　int　y);

void　func(int　y,　int　x)
{
・・・
}

337:デフォルトの名無しさん
08/04/19 17:47:45
どっちかに統一してあればどっちでもええやん
#返り値がintの関数云々はともかく

338:デフォルトの名無しさん
08/04/19 17:49:29
引数名は省略できても書いた方がいい。

339:デフォルトの名無しさん
08/04/19 17:50:20
>>336
それは仮引数名の命名がおかしいだけであって、
仮引数名をつけない理由にはならないんだが。

340:デフォルトの名無しさん
08/04/19 17:53:29
>>339
引数に名前があっても、信用できるわけじゃないしって話。

341:デフォルトの名無しさん
08/04/19 18:29:52
コメントだって信用できないから、書かない方がいいって言う人？

# 書いてない方がマシなコメントもあるけどさ。

342:デフォルトの名無しさん
08/04/19 19:36:10
全ての文にコメントをつけろって会社で働いたことがあったが、あれは地獄だったな。

次ページ