ヘタなコードの書き方

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

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

409:デフォルトの名無しさん
08/04/20 23:02:00
>>378
a = max(b, c);
a = b > c ? b : c;
の方がいいってこと？
どれでもいい気がしなくもないけどmax使った方が判り易いか。

410:デフォルトの名無しさん
08/04/20 23:08:52
>>409
そうそう。元のコードだと最低でも３行に目を通さないといけないからヘタな書き方だと思うわけ。
この場合はa = max(b, c);が素直だと思う。実際のa, b, cはもっと長い変数名なんだから。

411:デフォルトの名無しさん
08/04/20 23:14:00
しかし二つしか比較してないのにmaxってのもなぁ

412:デフォルトの名無しさん
08/04/20 23:17:25
え？こういうの書かない？
a = max(a, 0);

413:デフォルトの名無しさん
08/04/20 23:24:14
#define max(a, b) (a > b ? a : b)

414:デフォルトの名無しさん
08/04/20 23:29:11
普通、static int max(int a, int b) {return a > b ? a : b;}じゃないのか?

415:デフォルトの名無しさん
08/04/20 23:31:06
C++だとテンプレート版max()があったような。

416:デフォルトの名無しさん
08/04/20 23:32:58
俺は統一されてるのが好きだけど{}囲ってるけど、どっちもでいいな。
強要されるのはごめんだが。

ところでこいつを見てくれ、どう思う？
if(isA){
　if(isB)
　　if(isC)
　　　hoge1();
　else
　　if(isD)
　　　hoge2();
}

417:デフォルトの名無しさん
08/04/20 23:33:37
.NETにはEnumerable.Max<T>()が……

418:デフォルトの名無しさん
08/04/20 23:35:18
>>416
構文解釈しにくいなあ
elseはどこにかかっているんだろう

でも俺は{}でくくるのを強制されるのはゴメンだね。

419:デフォルトの名無しさん
08/04/20 23:35:38
>>416
レビュアーにケンカ売ってるのかな？とか

420:デフォルトの名無しさん
08/04/20 23:36:20
>>416
プログラミング作法かなんかで見たような気がする

421:デフォルトの名無しさん
08/04/20 23:40:56
>>416
そのインデントからすると単なるバグ。正しくはこう
if (isA)
　if (isB) {
　　if (isC)
　　　hoge1();
　} else
　　if (isD)
　　　hoge2();

422:デフォルトの名無しさん
08/04/20 23:43:58
いや、実はインデントをミスしただけかもしれない

423:デフォルトの名無しさん
08/04/20 23:45:31
>>416
Cだとelseって一番近いifにかかるよな？インデント間違ってないか？

424:デフォルトの名無しさん
08/04/20 23:54:10
>>423
スレタイを読め

425:デフォルトの名無しさん
08/04/20 23:59:21
>>424
と思った、ということじゃないのかな？

426:デフォルトの名無しさん
08/04/21 00:04:24
>>424
お前さんのツッコミの意図がわからん。

427:デフォルトの名無しさん
08/04/21 00:17:17
このスレも末期ですね

428:デフォルトの名無しさん
08/04/21 00:19:52
スレ違いだけど、おれの場合はグローバル変数を使い始めたら
糞コード生産開始の合図だわ。。

429:デフォルトの名無しさん
08/04/21 00:40:03
グローバル変数にはメリットもあるだろ。

430:デフォルトの名無しさん
08/04/21 00:45:58
perlでクライアントの2chブラウザ作ったけど見たい人いますか？
4時間ほどで作りました

431:デフォルトの名無しさん
08/04/21 00:48:17
日本語でおk

432:デフォルトの名無しさん
08/04/21 00:48:28
別にいいです

433:デフォルトの名無しさん
08/04/21 00:50:03
Pythonのお勉強 Part 25
ｽﾚﾘﾝｸ(tech板)
604 名前: デフォルトの名無しさん Mail: 投稿日: 2008/04/20(日) 20:46:14
perlで2chブラウザ4時間で作った～

ボク厨房！Pythonスレで自慢してみたのに、
誰も食いつかなかったからこっちに来てみたよ！＞＜

434:デフォルトの名無しさん
08/04/21 01:12:30
なんか流れを見てみると、自動インデント機能を使ってない人多いのかね?
(ちゃんと文法まで解釈するやつね)

>>416とかみたいなのは打ち込んでいるうちにおかしいってわかるから、
入力の手間を省くためというよりは、文法チェックのつもりで使ってる。

だから、そういう機能がない環境のやつほど
{}使いたがらせるんじゃないかと予想しているんだけど、関係あるかな?
かく言う自分はEmacsメインで{}強制はバカっぽく見える派。

435:デフォルトの名無しさん
08/04/21 01:17:56
一応確認するけど
ヘタだなと思ったコードを貼るのがこのスレの趣旨だよね？
まさかと思うけど>>374がこのスレの趣旨じゃないよね？

436:デフォルトの名無しさん
08/04/21 01:29:19
>>1を読め

437:デフォルトの名無しさん
08/04/21 01:57:32
>>435
374はネタだろ？
今までの流れからすると前者でおｋ

438:デフォルトの名無しさん
08/04/21 03:05:22
前者ならマ板だろ。
>>374で桶。
ここは技術板だ。

439:デフォルトの名無しさん
08/04/21 03:32:12
なんか、最近、技術って言葉を聞くとむなしくなる

440:デフォルトの名無しさん
08/04/21 07:19:20
俺は直感で書くとこうかなあ。
少し BASIC っぽい？

if(式) 文; else 文;

if(式) 文;
else {
}

if(式) {
} else 文;

if(式) {
} else {
}

441:デフォルトの名無しさん
08/04/21 07:34:19
それ珍しいなｗ
１つめはおいといて、個人的には
ifを囲うならelseも囲った方が、短くても同じ条件で分岐したものだと
認識しやすいと思う。
あと
} else {も、（賛否ありそうだけど）
}
else {
....
にした方が、行の最初に来るから認識しやすいかも？

442:デフォルトの名無しさん
08/04/21 08:30:17
あとネタ半分だけど
VC使っててあらゆるインデントを消すツワモノが居たなｗ
「どうせ一緒なんだから消してもいいじゃんｗ」
とのことだった。その人は今はCOBOLerだが。

443:デフォルトの名無しさん
08/04/21 09:57:28
変数名で悩まされるのはホント勘弁して欲しい。
int dynamic_static;
ってなんなんだよ･･･
一体何に使ってるのか気になってしょうがねえ。

444:デフォルトの名無しさん
08/04/21 10:03:47
>>443
そいつ、おちゃめだな

445:デフォルトの名無しさん
08/04/21 10:21:24
変数は大抵ローマ字で書いてる
int kao;
int me;
int hana;
みたいに

446:デフォルトの名無しさん
08/04/21 11:10:33
FILE*　fairu;
_Bool　raito_huragu;
とか？

447:デフォルトの名無しさん
08/04/21 11:12:37
int koreha_daijina_switch,tugini_daijina_switch;
float fudo_swith,syosuten;

死ねと思った

448:デフォルトの名無しさん
08/04/21 11:14:52
>>447
ネタでなくそんなコーディングがあるとは、いやはや

449:デフォルトの名無しさん
08/04/21 11:17:17
>>448
新人研修中で、実習させて提出されたコードの大半がこれ。
で極めつけが

課題.c 作成ファイル.doc <-Makefile

とかで渡してきやがった
文字コードがUTF-8(MAC)だし意味不明死ねと思った

450:デフォルトの名無しさん
08/04/21 11:29:01
>>449
新人研修とはよかったじゃないですか
今後業務で同じことをしないよう指導できるいいチャンスじゃないかな、しかも効率よく
教官の腕が試されてると思って頑張ってくらはい

451:デフォルトの名無しさん
08/04/21 12:27:15
>441
}
else {

は個人的には使わないなあ。

　　}

だけの一行ってのは、俺にはどうも
if～elseまで含めた、全体の終わりに見えてしまう。

452:デフォルトの名無しさん
08/04/21 20:06:52

if(cond)
{ //...
//...
} else
{ //...
//...
}

453:デフォルトの名無しさん
08/04/21 21:05:58
>>452
それ見たことある

454:デフォルトの名無しさん
08/04/21 21:10:12
上のほうの#ifdefと同じで環境依存だけどVC8で

#ifdef _DEBUG
if( FALSE ) ～;
#endif

上のthen行が実行されしまうんだ。

if( FALSE ) {
　～;
}

と、括弧でくくればちゃんと機能するんだけどな。
#ifdefとifの組み合わせでバグる処理系って実は多いのか？

次ページ