09/02/18 01:36:14
>>236
うるさいっていうかアホだろ。
return での bool への変換は警告するのに
? 演算子の前に置いたときの bool への変換は出ないとか、
意味がわからん。
そもそも警告を黙らせるためのコードなんか書いちゃいけない。
警告によって指摘された問題に対策しないといけない。
238:デフォルトの名無しさん
09/02/18 04:04:58
そりゃそうだ。C/C++に、?の左側に置いた式はbool型に変換されるなんて規則はないから
そこでbool型への変換だなんて警告が出るわけない。
239:デフォルトの名無しさん
09/02/18 04:33:49
>>238
何を根拠にそんなこと言うの？
C++ の ? は bool に変換して評価するよ。
5.16 Conditional operator p1
> The first expression is contextually converted to bool (Clause 4).
240:デフォルトの名無しさん
09/02/18 05:14:14
そうだったのか。
C99だけ見ていたが、こっちは、0と比較して云々となっていて、
_Boolへ変換するとは書かれていなかった。
C++もそんな調子だと思っていたよ、すまない。
241:デフォルトの名無しさん
09/02/18 13:47:17
C99 なら _Bool f(int x) { return x == 1; } でも比較演算自体は int だから警告が出るというのか？
それもアホだな。
242:デフォルトの名無しさん
09/02/18 14:45:41
そんなこと言ったら C99 では true も false も int 型なわけで。
結局のところ "? true : false" がまったく冗長なだけの記述には違いないね。
243:デフォルトの名無しさん
09/02/18 19:22:44
ECMAScriptなら冗長でないよ
244:デフォルトの名無しさん
09/02/18 21:31:42
どでもいいけど、システムハンガリアンって呼ばれてる
変数のタイプをプリフィックス/ポストフィックスとして
つける命名規則だけは絶対裂けるべきだ
一部に改訂が入って、使ってる型の定義が変わった場合の
メンテナンスはとんでもないことになる
245:デフォルトの名無しさん
09/02/19 00:03:28
下手に否定するより、よりベターな手法を教えてそっちに誘導した方が良い。
チーム全体に徹底させるだけの権限と統治力を持ってない場合は特に。
人は力強く押さないとあらぬ方向に進むが、引っ張れば割とすんなり思った方向へ進む。
246:デフォルトの名無しさん
09/02/19 12:32:31
>>244
WIN16→WIN32→WIN64の悲劇ですね。
247:デフォルトの名無しさん
09/02/19 21:33:35
WORD型やDWORD型なら、typedefを書き換えればいい
たぶん・・・
248:デフォルトの名無しさん
09/02/19 23:15:01
スタイルスレで聞きたいと思ったことが１つあるんだ。
C++のcppの方にソースを見やすくするために関数を小分けにしたものを
staticで記述して使ってるんだが、private関数にするべきかね？
249:デフォルトの名無しさん
09/02/19 23:28:51
>>248
privateにしなくてもいいんじゃね?
C++のprivateって、そもそもが美しくないし。
250:デフォルトの名無しさん
09/02/19 23:47:33
どっちかっていうと、外部にも派生クラスにも公開する気がない関数はクラスに含めるべきじゃないと思う。
クラスのインターフェイスとは関係ない、実装側だけの問題なら、実装側で完結してるほうが美しい。
static 関数なら、いくら変更しても外部には影響しないし。
251:デフォルトの名無しさん
09/02/20 00:02:01
継承したときにvirtualつけて使いたいけど、クラス外からは使われたくないものに
だけつけときゃいいのか。
252:デフォルトの名無しさん
09/02/20 00:02:30
static関数化できるものなら、Utilityクラスとかにして
外に出しちゃうのも良い鴨
253:249
09/02/20 00:05:44
staticって、クラスのメンバとしてか。。。
勘違いしてた。
254:デフォルトの名無しさん
09/02/20 00:16:57
メンバのstaticではなく実装用の小規模な補助関数ってことで。
255:デフォルトの名無しさん
09/02/20 01:12:07
>>248
.cpp ローカルな関数は static じゃなくて無名名前空間を使う。
private にすべきかどうかはクラスのメンバであるべきかどうかで区別する。
何も考えずに書くと private 関数の宣言をヘッダに書くことになるんで何かおかしな
感覚になるけど、 pimpl とかインターフェース継承とか使って隠せば問題ない。
256:デフォルトの名無しさん
09/02/20 01:22:53
なるほどね。いわゆるCのstatic関数ってのは推奨されてないのかな。
そこまで意識して気をつけようとも思わないけど、気が付くと疑問に思う。
257:デフォルトの名無しさん
09/02/20 01:25:22
>>256
関数や変数だけならいいんだけど、 C と違って .cpp ローカルな struct や enum も
グローバルに置いてると定義がかぶってアウトだから、なるべく無名名前空間を使う
癖をつけておいたほうがいいよ。
258:デフォルトの名無しさん
09/02/20 12:56:17
>>257
それだけなら別にアウトじゃない。
規格としてはダメかもしれんが。
ただ、メンバ関数はリンケージをファイル
スコープにできないから、無名名前空間が
絶対必須。
259:デフォルトの名無しさん
09/02/21 17:20:06
addとappendや、eraseとremoveの使い分けってどうしてる？
260:デフォルトの名無しさん
09/02/21 17:28:41
addは追加、appendは付加。
eraseは消去、removeは除去。ついでに言えばdeleteは削除。
まぁ、それでも巧く決まらないときは既存ライブラリの命名に倣ったりするが。
261:デフォルトの名無しさん
09/02/21 17:48:20
ロングマンで一通り調べてみた
appendは追記みたいな
順序付きリストの末尾に付け加えるということなのか
add⊇append
議論領域をUとすると
remove A from Bの操作の後はA B∧A∈Uだけど
erase A from Bの場合はA B∧A Uとまぁそんな感じ？
delteはcomputer上での操作を強調してあったけど
メモリから消えるって事だからプログラミングっていう議論領域だとeraseに近いのかな？
262:デフォルトの名無しさん
09/02/21 21:03:27
erase(A) はAによって識別される何かを削除する
delete(A) はAを削除する
remove(A) はAを取り除くが削除されるかどうかは仕様次第
263:デフォルトの名無しさん
09/02/22 13:37:57
append は後ろに追加するような意味だから
例えば map や set には使えない
でも add なら使えると思う
264:デフォルトの名無しさん
09/02/22 17:56:13
使われ方みると前 insert,後 appendで対って感じだな
265:デフォルトの名無しさん
09/02/23 13:48:14
ちなみに、先頭に加えるのは prepend っていう。
266:デフォルトの名無しさん
09/02/23 14:29:25
難しく考えないでAddFirst/AddLastでいいと思う
javaや.NETのコレクションではそうなってる
267:デフォルトの名無しさん
09/02/23 16:32:13
似た言葉をニュアンスの違いで使い分けたりするのはやめるべき
268:デフォルトの名無しさん
09/03/21 10:44:11
ははは
269:デフォルトの名無しさん
09/04/17 16:59:50
突然このスレにたどりついた俺は
if(hoge(var) == 0) じゃなくて、絶対 if (0== hoge(var)) 派だ
なぜなら左辺が変数のときに
if(var == 0) じゃなくて、絶対 if (var = 0) と書いてバグらせてしまう
奴がプロジェクトに出るからだ（中々見つけにくいんだな、このバグ）
後、関数の出口の return が必ず末尾の一つだけってプロジェクトに
参加したことがあるけど、処理の条件が変わっても、メモリリークが
出にくい構造になるのは良いと思った
270:デフォルトの名無しさん
09/04/17 17:10:55
> 後、関数の出口の return が必ず末尾の一つだけってプロジェクトに
> 参加したことがあるけど、処理の条件が変わっても、メモリリークが
> 出にくい構造になるのは良いと思った
これは結局ケースバイケースで、関数的（副作用がない）なコードが主か、
副作用とかバリバリか、で変わってくるよね。
あと、例外的な場合の処理にgotoを許すか、とか。
271:デフォルトの名無しさん
09/04/17 17:44:38
>中々見つけにくいんだな、このバグ
最近のコンパイラなら確実にwarning出すんでそうでも無い
272:デフォルトの名無しさん
09/04/17 22:26:29
ついでに言えば、比較対象が0ではなくて変数だったらやっぱり検出できないから殆ど意味がない。
273:デフォルトの名無しさん
09/04/18 01:02:21
RAII 使え、 const 付けとけ、って話でもあるな。
274:デフォルトの名無しさん
09/08/21 17:39:24
まぁOOPが不可能なプロジェクトなら、そういうリーク対策にも意味はあるかもしれんね
OOPが可能なら、RAII（厳密にはデストラクタによる資源解放）の徹底も可能だよな
275:デフォルトの名無しさん
09/08/31 12:09:43
>>269
C/C++で、zeroとの比較をするのであれば、
if (hoge(var) == 0)とぜすに、if (!hoge(var))の方が目的がはっきりする
比較する数値がたまたまzeroであるのなら、数字で比較すべきではない
定数化された変数を用いるか、#defineマクロで名付けられた定数を用いるべきだ
よって条件式に、数字が書き込まれている時点で何かおかしなコードであると思われる
276:デフォルトの名無しさん
09/08/31 12:32:58
>>275
しかしstrcmpの時ははゼロを扱っていいと思う。
277:デフォルトの名無しさん
09/08/31 12:38:20
おばかのきわみ > #define ZERO 0
278:デフォルトの名無しさん
09/08/31 12:55:27
>>276
その場合、BASE_CMPとか名付けて比較したほうが分りやすい予感
279:デフォルトの名無しさん
09/08/31 13:11:50
>>278
少なくとも俺は今、BASE_CMPナニソレ？(´･ω･`) ってなってるが。
280:デフォルトの名無しさん
09/08/31 13:12:58
>>278
CMP_OBJCTじゃね?
281:デフォルトの名無しさん
09/08/31 13:15:20
>>275
あほか。
「ゼロと比較する」という処理ならコードにそのまま書いたほうがいいだろｊｋ
282:デフォルトの名無しさん
09/08/31 13:22:58
#define STREQ(a, b) !strcmp((a), (b)) みたいなマクロに
283:デフォルトの名無しさん
09/08/31 13:28:21
>>282
それなら辛うじて許せるような気もするが、
strcmpくらいそのまま使えよ、ってのが正直なところ。
strcmp(a, b) < 0 // a < b
strcmp(a, b) > 0 // a > b
strcmp(a, b) == 0 // a == b
という、並べて書いた上での法則がせっかくあるのに。
284:デフォルトの名無しさん
09/08/31 18:55:48
>>278
わかりやすくねーよ。
イディオムはそのままにするべき。
285:デフォルトの名無しさん
09/08/31 19:01:39
strcmpの場合
比較対象と同等か、大きい、もしくは、小さいだから
>>282よりはマシだろ
286:デフォルトの名無しさん
09/08/31 19:04:58
>>285
意味不明(´･ω･`)
287:デフォルトの名無しさん
09/08/31 19:25:05
>>275
> if (hoge(var) == 0)とぜすに、if (!hoge(var))の方が目的がはっきりする
そんなバナナ
0との比較なら素直に==0、真偽値としての比較ならそのまま、ってのが普通の感覚だと
思うけどなぁ。まぁ最後は主観だからあれだけど。
0をマクロに入れるなんてのは論外。
288:デフォルトの名無しさん
09/08/31 19:51:24
NULLの分らんアホばっかだな
289:デフォルトの名無しさん
09/08/31 20:10:03
>>287
0との比較の「0」とは何かという話じゃないの？
290:デフォルトの名無しさん
09/08/31 20:14:06
>>288-289
お前ら二人は一体なにをいってるんだ？
291:デフォルトの名無しさん
09/08/31 21:11:58
NULL自体が要らないマクロ
292:デフォルトの名無しさん
09/09/05 23:12:56
初心者なんですが、if (cond == false)って書き方と
if (!cond)ってどちらにすべきですか？
ずっと後者だと思っていたのですが、前者もたまに見かけるので
わからなくなってしまいました。
293:デフォルトの名無しさん
09/09/05 23:50:59
>>292
論理定数との比較はそもそもナンセンスなので、前者は論理値に対する理解が
あやしい感じがする。
たいした理由じゃないんだけど、どちらかというと後者にしといたほうがいいと思うよ。
294:デフォルトの名無しさん
09/09/06 00:27:29
>>293
ありがとうございます。このまま後者の書き方を続けていきます。
295:デフォルトの名無しさん
09/09/06 10:41:39
その cond の名前が ablable とか enabled なら ! allowed のような書き方が良いだろう。
availability とか visibility とかだと、「可視性ですか？」 じゃ頭弱いみたいだから 「可視性は偽ですか」の方が分かりやすいと思う。
専用に enum 作れという話だけど。
296:デフォルトの名無しさん
09/09/11 19:06:43
//これはだめ
hoge(foo,bar);
//これはおｋ
hoge(foo, bar);
297:デフォルトの名無しさん
09/09/11 20:49:45
URLﾘﾝｸ(www.eetimes.jp)
1TBS って初めて聞いた。
298:デフォルトの名無しさん
09/09/11 21:31:02
>297
これ思ったけど、1TBSの方が図2のような間違いは簡単に検出できるような。
（単純に /;\s*{/ で検出できる。オールマンスタイルの場合、ツールによってはマッチしない）
でも個人的にはオールマンスタイルのが好きだけどな。
299:デフォルトの名無しさん
09/09/12 07:31:42
俺は1TBSくらいの黒っぽさが好みだな
もちろん黒すぎるのは辛いけど、オールマンだとちょっと白っぽく感じる
まぁこれはさすがに完全に好みの問題だろうと思うな…
300:デフォルトの名無しさん
09/09/13 02:47:08
そもそも筆者のコメントを打つ位置が気に入らない。 //行末に書くな
301:デフォルトの名無しさん
09/09/13 03:18:16
俺は//の後にスペースがないのが気に入らない
302:デフォルトの名無しさん
09/09/13 11:47:43
一番のツッコミどころは比較式の左辺に定数だろ。
303:デフォルトの名無しさん
09/09/25 00:36:47
そもそも
if(!x)
とか
if(!(z=x-N))
とかやることが多いから==使わないな。
304:デフォルトの名無しさん
09/09/25 07:48:41
条件式に関数呼び出しを書くなってルールもあったな
305:デフォルトの名無しさん
09/09/25 09:26:21
へぇ。どういう理屈でそんなルールが認められるのかさっぱりわからんな。
306:デフォルトの名無しさん
09/09/25 10:21:31
>>305
&& や || のショートカットと関数の副作用の関係
f0() || f1() || …
f0 が成立すると f1 以降が評価されないってのを知らないやつがいるそうだ
なので、こう書かなきゃいけない。とてもうざい。
v0 = f0(); v1 = f1(); …
if (v0 || v1 || …)
307:デフォルトの名無しさん
09/09/25 10:25:40
>>306
それ、 (s && strlen(s) > MIN) とかいう時はどうすればいいの？
308:デフォルトの名無しさん
09/09/25 10:59:33
int len = -1;
if (!s) {
len = strlen(s);
if (MIN < len) {
...
}
}
309:デフォルトの名無しさん
09/09/25 11:00:20
!sじゃなくてsなｗ 素で間違えた。
310:デフォルトの名無しさん
09/09/25 11:26:08
そんなルールおとなしく守ってるプログラマなんてほんとにいるの？
何なの？ばかなの？しぬの？
311:デフォルトの名無しさん
09/09/25 12:08:10
>>310
元請けにコードの監査部隊がいて意地でも書き直させる方法を取っていた
うざくってしょうがなかった
312:デフォルトの名無しさん
09/09/25 12:10:14
その監査部隊を短絡評価の講習要員にすればいいのに。
313:デフォルトの名無しさん
09/09/26 21:43:06
308の書き方だと、正しく読めない/書けない奴が居るから仕方が無い。
一方、漏れらに308の書き方を強制しても、せいぜい能率が落ちるだけ。
実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。
平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは
冷徹ではあるが正しい方策。
314:デフォルトの名無しさん
09/09/26 23:32:37
へぼいコーディングルールの話になると、その理論がよくでてくるけど、実際はコーディングルールを
決めてるやつがヘボいだけだろうな。ほとんどの場合。
それに「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論が、本当に正しいかすごい疑問だし。
315:デフォルトの名無しさん
09/09/26 23:42:03
まぁ俺の持論とは真逆だな
ウンココーダの頭数揃えても、精鋭一人にも劣る
316:デフォルトの名無しさん
09/09/27 09:34:49
> 実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。
> 平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは
> 冷徹ではあるが正しい方策。
「人月の神話」に燦然と挑戦しているな。
まぁそのような開発分野もあるんだろう。多分。
317:デフォルトの名無しさん
09/09/28 09:09:58
「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論は確かに疑問だが、
十分な精鋭を確保できるプロジェクトなんてほとんど無いんだから、大量のヘボが存在
するのは前提だと思う。
加えて上司も無能だと、そのヘボが逐次投入されてチームは恐竜に、プロジェクトは
タールの沼に。
318:デフォルトの名無しさん
09/09/29 21:53:42
>316
そうでもないと思うが。
1つのプロジェクトに投入する人員については、「人月の神話」の理論で良いけど、
複数のプロジェクトに人員を配置する場合は、>313の理論の方が適している。
308みないなルールは大規模なプロジェクトほど多く、小規模なプロジェクトほど比較的フリーだろ?
（逆な例もある事は承知している）
319:デフォルトの名無しさん
09/09/29 21:57:10
短絡評価が分からないだけならまだしも、「教えても理解できない」という人員なんか
さすがに切り捨てても困らないと思うけどな
320:デフォルトの名無しさん
09/09/29 22:31:14
簡単なコードを量産するような人海戦術プロジェクトでも、上位の2,3割だけ使って、
のこりはじゃまにならないように遊ばせておいても、あんがい生産性あがるんじゃないかって気もする。
321:デフォルトの名無しさん
09/09/29 23:13:59
>>318
人月の神話、読んでないか忘れてるだろ。
>>319
短絡評価に限って言えばその通りだけど、教えられても理解できない部分は人によって違うから。
>>320
論文報告を楽しみに待ってる。
322:デフォルトの名無しさん
09/09/30 00:10:59
どうでもいいけどstrlen()が返すのはintじゃなくてsize_tだよ
323:デフォルトの名無しさん
09/10/01 20:40:57
ストレンツォ容赦せん！
324:デフォルトの名無しさん
09/10/11 14:52:50
>>318
つまり、たとえば優秀なプログラマなら3ヶ月で終わる仕事を一年かけて
（原則同じくらいの人数で）やるけど、
同時に抱えられるプロジェクト数を増やして会社としてのスケールメリットを得るって話？
要するに節約できるのは総務だの人事だのの管理コストの話であって
プロジェクトそのものの効率は上がってないと思うが…
325:デフォルトの名無しさん
09/10/12 02:57:19
>324
プロジェクトの効率は上がらなくても、利益は上げられる罠。
場合にもよるが。
下手すりゃ投入人員と期間を増やせばその分儲かる。
糞ルールがまかり通ってる現場って、大体は上がこんな思想で動いてる希ガス。
326:デフォルトの名無しさん
09/10/12 03:57:31
まぁ、その思想を最高だと思って布教しようとしたりしなきゃどうでもいいけどな
327:デフォルトの名無しさん
09/10/17 11:55:45
javaで
public void XXX() throws YYY, ZZZ {
}
のthrows以下が長くなると80桁超えますけど見やすい折り返し方ないですか？
eclipseのデフォルトで整形すると
public void XXX() throws YYY,
ZZZ {
}
とやってくれましたけど見づらいな。
328:デフォルトの名無しさん
09/10/17 12:44:58
>>325
思想とか計算づくで、レベル低いんじゃなくて、ただレベル低いだけなんじゃないの?
効率が利益に結びつかないから、淘汰されないだけで。
329:デフォルトの名無しさん
09/10/18 21:42:59
>>324
保守要員みたいなところにエース級は投入せんだろ。
むしろ OJT で勉強させるために新人を。。。
330:デフォルトの名無しさん
09/10/20 11:51:05
>>327
行が長くなるときどう折り返すか
URLﾘﾝｸ(java-house.jp)
331:デフォルトの名無しさん
09/10/20 12:09:53
C++ 使っててカンマとか演算子の「前」で折り返して、演算子の類が行頭にくるように
してたんだけど、 Python 使い出したらそうもいかなくなって、今は微妙な気持ちです。
332:デフォルトの名無しさん
09/10/20 12:20:08
>>331
英語では普通、カンマやセミコロンなどは単語の後ろに空白なしにつける。当然、改行はその後。
演算子もそれに準じる。
333:デフォルトの名無しさん
09/10/20 13:57:32
>>331
（ ・∀・）人（・∀・ ）ﾅｶｰﾏ
.append(foo)
.append(bar)
.toString();
+ fooooooooooooooooooooooo
- (baaaaaaaaaar % baaaaaaaaz);
= {
11111111111
, 2222222222
, 3333333333
}
if (
(cooooooooooooooond)
|| (baaaaaaaar && bazzzzzzzz)
)
文末を見るより、文頭を見るほうが目の動きが少ない。
334:デフォルトの名無しさん
09/10/20 14:05:42
. を先頭にもってくるのは許せるが、 , を先頭にもってくるのが許せないのはなぜだろう。
335:デフォルトの名無しさん
09/10/24 22:25:29
if ～ else if ～ else の各節にコメントをつけたいとき、俺はこのように書いているんです。
// こういう場合はこう
if (...)
{
}
// こういう場合はこう
else
{
}
ところが、節を分断するのはよくないと言う人がいるんですね。それはそれで一理あります。
その人はこう書いている。
if (...) // こういう場合はこう
{
}
else // こういう場合はこう
{
}
このやり方だと、条件式が長くなったり複数行にわたると、ちっと面倒なことになる。
みなさん、if文のコメントはどのように書いていますか？
336:デフォルトの名無しさん
09/10/24 22:35:25
>>335
if にコメント付いてれば else へのコメントは冗長だろ？考えるだけ無駄。
337:デフォルトの名無しさん
09/10/24 23:21:52
冗長なんて言ったらコメントなんて書けなくなる。
それに複数のelse ifがある場合はコメントがあった方がいい。
338:デフォルトの名無しさん
09/10/25 00:16:58
>>337
お前はなんのためにコメントが書きたいの？
コメントを書くことが目的なの？
339:デフォルトの名無しさん
09/10/25 01:41:21
// コメント
if(...) {
}
else {
// コメント
}
340:デフォルトの名無しさん
09/10/25 02:39:09
>>339
俺もそれだ。
341:デフォルトの名無しさん
09/10/25 02:43:33
俺はこうだわ。space efficiant!!
if(...) { // コメント
foo();
} else if(...) { // コメント
bar();
} else {
foobar();
}
342:デフォルトの名無しさん
09/10/25 07:39:57
漏れは内容に応じて使い分けた方が良いと思うけど。
// 分岐全体について。
if( ... ){ // 式について。
// ブロック内の処理&実行条件の概要
}
else {
// ブロック内の処理&実行条件の概要
}
（例）
// ～と～を切り分ける
if( … // ～をチェック
&& … ) { // ～をチェック
// ～の場合、～する
}
else {
// ～の場合、～する
}
343:デフォルトの名無しさん
09/10/25 14:06:52
こうしてる
if(...) {
// ...なら～
} else {
// ～(条件についての記述は無し)
}