ヘタなコードの書き方

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

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
全ての文にコメントをつけろって会社で働いたことがあったが、あれは地獄だったな。

343:デフォルトの名無しさん
08/04/19 19:47:37
>>342
俺にも覚えがあるな。こんなコメントが蔓延してなかったか？

// ほにゃらら履歴を走査する①
// ほにゃらら履歴を走査する②

ちなみに、そのプロジェクトにはコメントの体言止め禁止という不可解な規約もあった。

344:デフォルトの名無しさん
08/04/19 20:31:29
コメント等の説明文に関しては「…される」じゃなく「…する」と表現しなければいけない等のルールにも出くわした事もあるな
上のを例にすると「// ほにゃらら履歴を…に走査させる」はNGとか

345:デフォルトの名無しさん
08/04/19 20:44:21
コメントは日本語と英語を併記するって所もあったな。
めんどくさいからコメントはなるべく書かないようにしてた。

346:324
08/04/19 22:20:19
>>329
お気の毒です（笑）。いや、それでも。
それは「仕事でやる場合、そういう{指導|規約}が必要になる」
という事実を表明なさっているだけに思えますが。
#スレ違いと考えたら駄目ですかね

347:デフォルトの名無しさん
08/04/19 22:32:09
>>335
化石プログラマにはC++やC99なんて存在しないのも同然。

>>331
変数名（笑）
素人臭さを演出して皮肉っているんですね。わかります。

348:デフォルトの名無しさん
08/04/19 22:43:36
> 仕事でやる場合、そういう{指導|規約}が必要になる
> という事実を表明なさっているだけに思えますが。

まさにそうだが？

>>346 で何を言いたいのかよくわからん。

スレチだと考えるならそう考えておけばいいと思うけど、できたら
今後この手の話題にレスする時は「仕事以外では」と明記してもら
えると心置きなくスルーできるので助かるんだが。

349:デフォルトの名無しさん
08/04/19 22:51:44
まぁこの手のくだらん制限がかかるのは大体仕事絡み

350:デフォルトの名無しさん
08/04/19 22:57:42
>> 仕事でやる場合、そういう{指導|規約}が必要になる
>> という事実を表明なさっているだけに思えますが。
>まさにそうだが？

正直、極一部のヴァカの為にﾍﾝﾃｺなルールを導入する組織もどーかと思うが。

351:デフォルトの名無しさん
08/04/19 22:59:33
ごく一部というか毎年一定の割合で入ってきたり、派遣されてきたり

352:デフォルトの名無しさん
08/04/19 23:03:39
解っていた事ではあるがオープンソースが責任やら納期やらの話で{}を省略しているのではなくて、
仕事でやっている連中はレベルが低すぎるから糞ルールを導入せざる得ない。
とハッキリ言えばいいのになぁ。

なんかヘンテコなプライドがあるんだかないんだが。

353:デフォルトの名無しさん
08/04/19 23:14:51
>>350
> 正直、極一部のヴァカの為にﾍﾝﾃｺなルールを導入する組織もどーかと思うが。

じゃあもっといい方法があるのか？

---
> 仕事でやっている連中はレベルが低すぎるから糞ルールを導入せざる得ない。
> とハッキリ言えばいいのになぁ。

>>256, >>329 に書いてあるのに理解できてない >>352 に言われても...。

354:デフォルトの名無しさん
08/04/19 23:15:01
スレの主旨や話題にケチつける気はないんだが（これは>>348に対する皮肉でもあるがｗ）
どーも感心するほどの話が出てこないなぁとｵﾓﾀ。
自分は現役離れてフリーターやりながら作品作ってる身分なので偉そうなことは言えないが、
「会社の超下手糞なスタッフが読んでもわかるように」、みたいな今の日本特有？の
IT土方的環境を前提にしたら話がおかしくならんか？

ヘタなコードか上手いコードか、ってのは
仕事、趣味、オープンソース、個人グループ、などに関わらず議論できることであって、
何でもすぐ自分の立場だけで考えようとするのはアホだしプログラマとしても才能無いぞ。
クソルール作ってる連中と大して変わらんしな。

355:デフォルトの名無しさん
08/04/19 23:15:54
逆にオープンソースのように、ちゃんとみんなでソースをチェックしてやれば
そんな些細なミスなんて問題じゃなくなるってことじゃねえか？
ソースレビューすればすぐ見つかるようなことだろ。

356:デフォルトの名無しさん
08/04/19 23:26:57
> 何でもすぐ自分の立場だけで考えようとするのはアホだしプログラマとしても才能無いぞ。

自己紹介乙。(w

>>348 にも書いたが、できたら今後コテ付けてくれ、スルーするから。

357:354
08/04/19 23:29:03
何か勘違いしてるようだが346は俺じゃないよ。

358:デフォルトの名無しさん
08/04/19 23:29:17
>>355
まあ、それはそうだが、無駄な手間が増えるってことだからな

359:デフォルトの名無しさん
08/04/19 23:41:59
>>357
それはすまんかったが、どちらにせよ「仕事以外の話」と言うならわかるように
書いてくれと言うだけのこと。

> 仕事、趣味、オープンソース、個人グループ、などに関わらず議論できること
> であって、

とてもそんな議論ができるとは思えないから。

# 少なくとも「趣味」が入ったら何でもアリだろ？
# 七行プログラムみたいのが上手いコードと言い張る奴もいるだろうし。

360:デフォルトの名無しさん
08/04/19 23:53:33
＞とてもそんな議論ができるとは思えないから。
そう？>>7とか>>39とか>>124とかがまさにそういう議論（というより意見か）
だと思うんだけど。
＞# 少なくとも「趣味」が入ったら何でもアリだろ？
＞# 七行プログラムみたいのが上手いコードと言い張る奴もいるだろうし。
短いプログラムとしてなら上手いだろうし、可読性の点では最悪だろう。
それは趣味プログラマだからどうこうっていう話じゃなくね？

361:デフォルトの名無しさん
08/04/20 00:38:37
>>124 は「メモリきちきちの環境」とかだとむしろ推奨とか言い出す奴がいても
おかしくないと思う。

> 短いプログラムとしてなら上手いだろうし、可読性の点では最悪だろう。

{} にしたって、文法上不要なところは省くと短いプログラムとしては上手いだ
ろうし、(未熟なプログラマに対する) 配慮と言う意味ではは劣るだろ？

それを、トータルでどっちが上手いと言う議論をしても、短いプログラムと未熟
なプログラマに対する配慮の重要度が「仕事、趣味、オープンソース、個人グ
ループ、など」では違うから、結論なんかでないと思うよ。

362:デフォルトの名無しさん
08/04/20 00:49:34
>>361
！？
それは逆アセンブルした結果をみて言っているのか？

363:デフォルトの名無しさん
08/04/20 00:56:42
>>124 と関連するが、自動変数のスコープを限定するためだけの {} はあり？なし？

364:デフォルトの名無しさん
08/04/20 00:58:53
>>362
お前は何を言ってるの？

365:デフォルトの名無しさん
08/04/20 00:58:54
>>361
コンパイラの最適化時の賢さにもよるだろうけど、ローカル変数なら
別に使いまわしても使いまわさなくても吐くバイナリは同じだと・・・・
思ってるんだけど違う？ｗ
＞結論なんかでないと思うよ
いやそれでいいと思うんだけどなぁ。
ifステートメントとかの{}は、誰かも言ってたけど会社のコーディングルールで
決まってれば従えばいいし、一貫させることの方が重要だから
俺としては”さっさと終わっていい話題”だと思った。ｗ　
「このコードダメだよね？」「このコードうまいよねー？」みたいな話は
１．美的感覚を元にして話す
から面白いんであって、ここはム板なんだし
２．愚痴っぽいネガな理由持ち出してコーディング規則を語る
のは聞くに耐えんなぁ、と思っただけ。
音楽を聴くとき、あんたはアーティストがいかに不遇な環境で頑張ったかで良し悪しを決めるのかい？
先ほど書いた通りスレ主旨や流れにケチつけるのもアレだから、このくらいにしときまｗ

366:デフォルトの名無しさん
08/04/20 01:00:48
変数使いまわして意味があったのはインタープリタのBASICだけだと思ってたけど

367:デフォルトの名無しさん
08/04/20 01:26:49
>>365
> いやそれでいいと思うんだけどなぁ。

だったらスルーしとけばいいんじゃないかな。

> １．美的感覚を元にして話す

その美的感覚は人によっていろいろ違う。

君には、「愚痴っぽいネガな理由」としか思えなくても、他の人には
美的要素として重要なことだってあるんだし。

> 音楽を聴くとき、あんたはアーティストがいかに不遇な環境で頑
> 張ったかで良し悪しを決めるのかい？

仕事ならそう言うこともあるだろうね。

368:デフォルトの名無しさん
08/04/20 01:56:39
>>348=>>356=>>359=>>367？？さっきから何様なの？
＞その美的感覚は人によっていろいろ違う。
＞君には、「愚痴っぽいネガな理由」としか思えなくても
＞仕事ならそう言うこともあるだろうね。
なんていうか・・・色々と社会勉強してきてください；；；；
（ヒント：相対主義）

369:デフォルトの名無しさん
08/04/20 03:02:08
くだらん事で必死だな

370:デフォルトの名無しさん
08/04/20 03:58:45
上手なコード
ヘタなコード
fool proof なコード
のそれぞれに語る価値はあろうが、スレタイを前提とすると、このスレで"上手なコード"を語る意味はない。
であるからして"ヘタなコードだけどfool proofだから書かねばならぬ"というのを攻撃するのもスレ違いに思う。
"上手ヘタに関わらずfool proofであるべき"などと主張したい奴は別のスレを立てろ。

371:デフォルトの名無しさん
08/04/20 06:52:53
仕事でヘタコードを強要させられている愚痴ならともかく
仕事でヘタコードを制定しているアフォが自己肯定する為にこのスレで我侭言っている
だけだもんなぁ。

一番議論を邪魔しているのが自分だと気づけっての。

372:デフォルトの名無しさん
08/04/20 08:52:23
>>368-371
> だったらスルーしとけばいいんじゃないかな。
> だったらスルーしとけばいいんじゃないかな。
> だったらスルーしとけばいいんじゃないかな。

373:デフォルトの名無しさん
08/04/20 10:54:09
なんでそんな3回も連呼するほど必死なん？

374:デフォルトの名無しさん
08/04/20 12:35:18
むしろ下手なコードを奨励し、下手なコードを書く技術を向上させるための
議論をするスレだろ。
どうやったら上手に下手コードを実現するか。
さぁ議論再開。

375:デフォルトの名無しさん
08/04/20 12:37:36
おいおいｗ

376:デフォルトの名無しさん
08/04/20 13:02:55
>>373
今時必死か。

下手なレスの書き方を披露してるのか？ (w

377:デフォルトの名無しさん
08/04/20 13:51:03
ケンカはやめて（＞＜）

378:デフォルトの名無しさん
08/04/20 14:55:50
こういうのもヘタっぽい
if (b > c)
　　　　a = b;
else
　　　　a = c;

379:デフォルトの名無しさん
08/04/20 15:20:35
結局「{}は仕事で絶対必要」ｸﾝが暴れているスレになったな。

380:デフォルトの名無しさん
08/04/20 15:35:00
>>379とりあえず、職業プログラマにならないでね。
まわりの迷惑だからｗｗｗ

381:デフォルトの名無しさん
08/04/20 16:37:29
とりあえず漏れの会社は>>380の居るヘタコード強要会社ではないので安心だ。

382:デフォルトの名無しさん
08/04/20 16:39:27
おれも>>381がいるトンチキ会社じゃなくてほっとしたよ。

383:デフォルトの名無しさん
08/04/20 16:40:49
たぶん漏れの会社も>>380の居るヘタコード強要会社ではないみたいなので安心だ。

384:デフォルトの名無しさん
08/04/20 16:47:11
囲わないと後から文を付け加えたときに囲い忘れるかもしれないなんて、
「条件式で誤って代入演算子を書いてしまう」以上にありえないことだと思う。
それと違って、囲うかどうかはどっちでもいいと俺は思うしコンパイラも警告出すことでもないけどね。

ところで、1文だけのとき、普段は省略するけど、if - elseでは気持ち悪いから両方を囲っているんだ。
if (...)
{
　 /*複数文の処理*/
　 hage;
　 piyo;
}
else
{
　 hoge; //1文だけの処理
}
そうしていたら、それで最近、常に囲うほうで統一すればいいような気がしてきた。

385:デフォルトの名無しさん
08/04/20 17:04:49
囲い忘れたらインデントがずれるしね大体

386:デフォルトの名無しさん
08/04/20 17:22:34
>>384
> 囲わないと後から文を付け加えたときに囲い忘れるかもしれないなんて、
> 「条件式で誤って代入演算子を書いてしまう」以上にありえないことだと思う。

だよね～。

と、俺も思っていたが、実際にあるから怖い。

>>381 みたいな自信過剰の奴は時にとんでもないポカミスをするから、そう言う
奴をはじく意味でも彼等の言う「ヘタコード強要」は必須。

387:デフォルトの名無しさん
08/04/20 17:28:53
1.1行で書ける／書くのが自然な時は囲まない
2.それ以外は囲む

これでやってる。でも1.の場合があまり無いから結果的に殆ど囲まないなぁ。

388:387
08/04/20 17:29:47
1行ってのはifも含めてって事ね。
if(a) hogehoge;

389:デフォルトの名無しさん
08/04/20 18:00:56
>>386
１行のifを中括弧で括るのがヘタコードだなんて誰も言ってないようなｗ

390:デフォルトの名無しさん
08/04/20 18:07:45
>>388
大量に羅列する時などは一行に書いてしまうが、その時は {} で囲む。

正直、単発で一行にするのは勘弁して欲しい。
インデントがあれば、キーワードを見ずとも制御構造があることがわかるという利点がある。
また、デバッガで追いかける時に面倒くさいことになることがある。

391:387
08/04/20 18:28:17
>>390
うん、だから1.はあんまり使わない。

それと>>387で全く逆の事言ってた。殆ど「囲む」の間違いね。

392:デフォルトの名無しさん
08/04/20 18:33:19
前にも書いたと思うが、うちも>387と同様。
慣れた奴は書かなくてもいいと思うかもしれないが、
それを真似して慣れてない奴が間違うのが困るんだ。

393:デフォルトの名無しさん
08/04/20 18:45:44
>>392
「間違えるから成長する」という考え方は？

394:デフォルトの名無しさん
08/04/20 18:48:01
>>393
間違えて成長する奴なら、間違えなくても成長する。
間違えても成長しない奴は、いつまで経っても間違える。

395:デフォルトの名無しさん
08/04/20 18:48:19
>>392
無いカスだから間違える
これ全世界共通の常識

396:デフォルトの名無しさん
08/04/20 18:54:55
意味不明ｗｗ

397:デフォルトの名無しさん
08/04/20 18:57:04
括弧で括ろうが括るまいとプログラムの変更箇所に対してテストしてれば
どっちでも問題ないと思うが「括弧で囲まないと困る」ってのはなんだかな？って感じだ。

「慣れてない奴が間違える」はコーディングルール以前に
品質を維持するルールが存在しないアフォ組織に思えるが。

398:デフォルトの名無しさん
08/04/20 18:57:24
そんなところで間違って貰っては困る

399:デフォルトの名無しさん
08/04/20 18:57:41
if (a != 0)
　　a--; b = a;

みたいなのは紛れもなく糞

400:デフォルトの名無しさん
08/04/20 19:01:09
糞と言うか見辛いだろうが、そこで修正間違えるヤツはかなりマとしての適正を欠いているとｵﾓ

401:デフォルトの名無しさん
08/04/20 19:03:55
>>399
こんなの見た日には、メーリングリストで晒し者したい気分

402:デフォルトの名無しさん
08/04/20 19:05:25
if (a != 0)
　　a--; b = a;
if (c != 0)
　　c--, b = a;

どうぞ

403:デフォルトの名無しさん
08/04/20 19:07:20
一応、こういうコード書いた奴を少し問い詰めたくなる罠

もしかしたら凄い理由があるのかも知れないし。

404:デフォルトの名無しさん
08/04/20 22:37:58
成長しない見本 (w

>>397=>>258

同じ事を何回も書くんじゃねぇ。

405:デフォルトの名無しさん
08/04/20 22:51:58
なにが言いたいのか解らんが日本語が不自由な人なんだろうか？

406:デフォルトの名無しさん
08/04/20 22:54:56
たぶん、漏れのレスが絶対正義と信じて疑わない人なんだろ
成長しない人間にありがちな思考だ。

407:デフォルトの名無しさん
08/04/20 22:59:20
>>378にもご意見くださいな

408:デフォルトの名無しさん
08/04/20 23:00:05
プログラミングが好きでもないのに仕事で中途半端に高い立場になってしまって
毎日ム板でストレス発散してんのさきっと。
だから趣味グラマ＝実力皆無、非営利のコード＝無意味と決め付けてるのもうなずける。
自分が会社の外で勉強する気が無い（向上心がない）から他人もそうだと思い込んでるのだろう。
そらウンコルールも作りたくなるわｗ

次ページ