07/10/28 16:03:26
余裕の2get
3:デフォルトの名無しさん
07/10/28 16:03:38
インデント禁止
4:デフォルトの名無しさん
07/10/28 16:11:07
改行禁止
5:デフォルトの名無しさん
07/10/28 16:21:22
()禁止
6:デフォルトの名無しさん
07/10/28 16:30:23
if文の比較では定数は左に置くよな、常識的に考えて。
if(0==a){
処理
}
みたいに
7:デフォルトの名無しさん
07/10/28 16:32:04
if文なんて使ってるやつはばかです
8:デフォルトの名無しさん
07/10/28 16:35:08
include禁止
9:デフォルトの名無しさん
07/10/28 16:37:07
>>6
スペース入れろよ。
10:デフォルトの名無しさん
07/10/28 16:39:10
>>6
詳細は
ｽﾚﾘﾝｸ(tech板)l50
こっちを参照で。
11:デフォルトの名無しさん
07/10/28 16:39:35
必死だなｗ
12:デフォルトの名無しさん
07/10/28 16:59:53
>>9
スペース禁止
13:デフォルトの名無しさん
07/10/28 17:01:05
ｶﾞｯ禁止
ぬるぽ
14:デフォルトの名無しさん
07/10/28 17:04:46
WinMainっていうのは定型だし、無視される引数もありいちいち書くのは面倒臭い
というわけで
#define WINDOWS_APPLICATION_ENTRYPOINT(hinstance,lpcmdline,ncmdshow) \
int WINAPI _tWinMain(HINSTANCE hhnstance, HINSTANCE, LPTSTR lpcmdline, int ncmdshow)
というようなマクロを使って
WINDOWS_APPLICATION_ENTRYPOINT(hinst,lpcmdline,ncmdshow)
{
return 0;
}
と書くのはどうでしょうか？
コード内部で参照するパラメータ名は使用する側が自由に決めることができます
15:デフォルトの名無しさん
07/10/28 17:13:55
define禁止
16:デフォルトの名無しさん
07/10/28 17:26:27
NULL禁止
17:デフォルトの名無しさん
07/10/28 17:27:51
URLﾘﾝｸ(www.google.co.jp)
コーディングスタイルに意味があるとしたらそれはプロジェクト内で統一することのみで
どう決めるかはまったく問題ではない。
もちろん一定以上の知的水準と経験を持った人間が決めればの話だが。
18:デフォルトの名無しさん
07/10/28 17:33:54
goto奨励
19:デフォルトの名無しさん
07/10/28 18:00:20
>>17
> コーディングスタイルに意味があるとしたらそれはプロジェクト内で統一することのみで
誤読してるかもしれないが、コーディングスタイルの意義として、プロジェクト内でのスタイルの統一しかない
ということであれば、それに全く同意できない。
まず、可読性ありき。
20:デフォルトの名無しさん
07/10/28 18:44:05
もしコーディングスタイルを決める意義が「統一することのみ」だったら、
「一定以上の知的水準と経験を持った人間」が決める必要さえないしな。
21:デフォルトの名無しさん
07/10/28 18:53:14
それじゃあ、変数名いってみようか。
ハンガリアン記法はクソ。
変数定義の箇所に型情報は記述されており、
適切に実装されたスコープ内では充分に目に付く。
型情報をたどれないほどに変数定義から離れた変数は、
同時に関数などのクソ設計を匂わせており、クソ。
22:デフォルトの名無しさん
07/10/28 18:57:04
>>21
URLﾘﾝｸ(local.joelonsoftware.com)
23:デフォルトの名無しさん
07/10/28 19:04:11
> アプリケーションハンガリアン
> システムハンガリアン
シモニイすまんかった（´；ω；｀）
24:デフォルトの名無しさん
07/10/28 19:20:22
>>22
またMSがいらんことを・・・
25:デフォルトの名無しさん
07/10/28 19:27:55
１、２、ハンガリアン！
２、２、ハンガリアン！
26:デフォルトの名無しさん
07/10/28 19:31:21
>>22
それ読んだとき、めっちゃバグりそうな書き方だとおもったな。
内部で処理するときは、HTMLエンコードしないで処理して、表示のときに一括して、エンコーディングしたほうが
いいと思ったよ。
unsafeとsafeを混在させて処理してたら、いくらネーミングで工夫してもミスるだろって。
27:デフォルトの名無しさん
07/10/28 19:33:32
>>25 どぅわ～
28:デフォルトの名無しさん
07/10/28 20:22:40
joelなんか糞派登場
29:デフォルトの名無しさん
07/10/29 02:29:59
関数名、変数名は6文字以内。
30:デフォルトの名無しさん
07/10/29 13:10:06
//char a, *b, *const c, const *d;
char a, *b, *const c;char const *d;
char const *dを続けて宣言できないのが悔しい。
31:デフォルトの名無しさん
07/10/29 19:49:30
考えるときはマンダム
立った時はジョジョ立ち
32:デフォルトの名無しさん
07/10/29 20:24:41
牛乳は瓶の奴しか飲んではいけない。
飲むときは腰に手を当てること。
33:デフォルトの名無しさん
07/10/29 21:59:31
>>29
俺が就職したばかりの頃は、
リンカの制限で関数名は4文字までだった。
プリプロセッサは16文字まで対応してたから、
マクロ使ったりして工夫してたなぁ。
今考えると冗談みたいな話だ。
34:デフォルトの名無しさん
07/10/29 22:11:03
最初の文字がi, j, k, l, m, n の変数は整数型。他は実数。
35:デフォルトの名無しさん
07/10/29 22:51:24
>>34
文字列、真偽値は…？
つーかクラスオブジェクトは…？
36:sage
07/10/30 00:34:16
hsqscsName (html-safe, sql-safe, command-line-safe)
hsqscusName (html-safe, sql-safe, command-line-unsafe)
hsquscsName (html-safe, sql-unsafe, command-line-safe)
:
37:36
07/10/30 00:37:04
orz
38:デフォルトの名無しさん
07/10/30 00:41:26
今さらだけど>>6はどうかと思うな
見てから理解するのに時間がかかる
実際にあの方式使ってる人どのくらいいる？
39:デフォルトの名無しさん
07/10/30 00:43:46
>>38
コードサーチでオプソをググったら腐るほどいた
40:デフォルトの名無しさん
07/10/30 03:27:07
ヘアースタイルは7:3厳守。
41:デフォルトの名無しさん
07/10/30 05:24:12
エラーコードを解析する時は三白眼、効果音は
┣” ┣” ┣” ┣” ┣” ┣”
42:デフォルトの名無しさん
07/10/30 09:17:13
>>38
999:1くらいだと思う。もちろん1の方。
43:デフォルトの名無しさん
07/10/30 21:37:51
>>38
俺はデキる奴だぜー、と思い込んでるけど実際はそうでもない人が使いそう
44:デフォルトの名無しさん
07/10/31 01:39:14
< とか > とかの向きを揃える目的なら使っちゃだめか？
45:デフォルトの名無しさん
07/10/31 02:55:54
定数を左に置くのは、次の場合だけだな。
if (0 < x && x < 100)
本当はif (0 < x < 100)と書きたいけど、書けないのでその代用としてだ。
46:デフォルトの名無しさん
07/10/31 23:03:42
returnやsizeofの後をカッコでくくるかどうかって話はもう出た？
47:デフォルトの名無しさん
07/10/31 23:06:40
return の後の括弧は無し
sizeof の後の括弧は有り
48:デフォルトの名無しさん
07/10/31 23:06:52 BE:1262592768-2BP(125)
return はくくらないのにsizeofはくくりたくなるんだよな。。
49:デフォルトの名無しさん
07/10/31 23:08:24
習慣っつーか慣用句みたいな感じ
50:デフォルトの名無しさん
07/10/31 23:09:44
括弧つけるべきか否か迷う時間が勿体無いので、
なんでも括弧つけることにしてる。
51:デフォルトの名無しさん
07/10/31 23:45:58
return 0; ならいいとしても、return i * 2; みたいになると、括弧で括りたくなる。
52:デフォルトの名無しさん
07/10/31 23:52:18
昔、会社のコーディング規約決める時に、returnの後の括弧は無しじゃね？
って言っても、みんな、returnの後は括弧付けるって言って引かないから、
もう、どっちでも良い事にしちゃった。
53:デフォルトの名無しさん
07/11/01 00:30:32
実際どっちでもいいし
54:デフォルトの名無しさん
07/11/01 00:33:31
>52
燃料投下。
URLﾘﾝｸ(www.st.rim.or.jp)
55:デフォルトの名無しさん
07/11/01 07:23:14
やっぱりキチガイは一人だけだったか。
奴が来ないとこんなに静か。
56:デフォルトの名無しさん
07/11/01 08:35:41
交差点で１００円ひろおったーよー
57:デフォルトの名無しさん
07/11/01 21:05:04
ちびまるこちゃんだな。
58:デフォルトの名無しさん
07/12/20 03:21:44
なんでもかんでもみんな マスゲームを踊ってるよ
ピョンヤンの丘にはボカッと 巨大な銅像献上
いつだって 忘れない 金日成偉い人 そんなの常識
パッパパラリラ
ピーヒャラピーヒャラ おなかが減ったよー
59:デフォルトの名無しさん
08/01/21 02:38:32
>今さらだけど>>6はどうかと思うな
>見てから理解するのに時間がかかる
今更だが、
1. if ( hogehogeflag == 0 )
2. if ( hogeHoge( parameter_list ) > 0 )
3. while( ( c = fgetc( stdin ) ) != EOF )
とかよりは
1. if ( 0 == hogehogeflag )
2. if ( 0 < hogeHoge( parameter_list ) )
3. while( EOF != ( c = fgetc( stdin ) ) )
の方が大事なことが先に書いてあって分かりやすくて読みやすくね？
特に3.の場合なんか前者だと条件比較の意味を理解するのに最初fgetc()から←方向にcを読んで次に→方向に読み直してEOFを探さなきゃならんし。
それとも俺がそういうコミニティで育ったからか？
60:デフォルトの名無しさん
08/01/21 03:46:07
私は三つとも上のほうが読みやすいと感じる。
数字の 0 よりも、フラグとか関数呼び出しのが「大事なこと」だと思う。
コミュニティ次第なんだろうね。
ただ私なら、 3 は
for (;;) {
c = fgetc(stdin);
if ( c == EOF ) break;
...
}
みたいに書く。
61:デフォルトの名無しさん
08/01/21 04:45:23
出力（条件比較や返値）より入力（関数呼出や引数）が「大事なこと」だと思えば上のほう、
if ( hogeHoge( parameter_list ) ～
入力（関数呼出や引数）より出力（条件比較や返値）が「大事なこと」だと思えば下のほう、
if ( 0 < hogeHoge( ～
ってところではないかな。
定数と一時変数を使えば
err = hogeHoge( parameter_list );
if ( err == SUCCESS )
2 は 1 の問題に出来るな。
ただし 3 はイディオムなので、私でも>>60のように分解はしないな。
62:デフォルトの名無しさん
08/01/21 05:06:08
ん、制御とデータで分けた方が適切なのかな。
"hogehogeflag が", "hogeHoge( parameter_list ) が", "while 内で c に fgetc( stdin ) を代入" のように データ中心に考えれば上のほう、
1. if ( hogeh...
2. if ( hogeHoge( para...
3. while( ( c = fgetc( stdin )...
"0 の場合に", "返却値が 0 より大きければ", "while は c が EOF になるまで" と制御中心に考えれば下のほう、
1. if ( 0 == ...
2. if ( 0 < hogeHoge( ...
3. while( EOF != ( c = fgetc( ...
になるね。
63:デフォルトの名無しさん
08/01/21 08:38:08
定数左に置く人はfor文でもやっぱり左に置くの？
for (i = 0; N > i; ++i) みたいな感じに
64:デフォルトの名無しさん
08/01/21 09:58:03
>for (i = 0; N > i; ++i) みたいな感じに
そりゃ不等号の向きによるんでね。if文でも同じやろ。
for( i = 0; i < N; ++i )
for( i = N; 0 < i; --i )
定数右に書く人は"N より大きい"を if ( i > N ) って書くん？
気持ち悪くね？
65:デフォルトの名無しさん
08/01/21 10:11:40
それもそうだ。
66:デフォルトの名無しさん
08/01/21 10:38:05
>>64
不等号の向きが数直線だと思い込む方がどうかしている。
つまり0より大きいと0より小さいがならぶときに、
if (var > 0) ...;
if (var < 0) ...;
と書くか
if (0 < var) ...;
if (var < 0) ...;
と書くかの違いなわけだが。
例えば、このvarが関数呼び出しになっても後者のように書くということなのだろ?
それが気持ち悪いと思えないなら、私とは相容れない種類の人間だと言うことだ。
67:デフォルトの名無しさん
08/01/21 10:46:16
>>64
私はそれぞれ
for ( i = 0; i < N; i++ )
for ( i = N; i > 0; i-- )
if ( i > N )
って書く。
逆は気持ち悪いって感じる。
「 i が N より大きい」をそのまま書いたら i > N でしょ。
N < i は「 N が i より小さい」。
68:デフォルトの名無しさん
08/01/21 10:56:56
私は基本的には定数右派だが、不等号については後者かな。
やはり var < 0 ってのは直感的ではないし見ていて気持ちが悪いって感じる。
69:デフォルトの名無しさん
08/01/21 10:59:26
>>68
おお、これは新しい意見だ。
ついに、var < 0 が否定されたぞ。
70:デフォルトの名無しさん
08/01/21 10:59:59
>>68訂正
× var < 0
○ var > 0
71:デフォルトの名無しさん
08/01/21 11:04:38
私は < だろうが > だろうが関数呼び出し相手なら
if (0 <= func(
if (0 == func(
if (0 >= func(
だなぁ。
72:デフォルトの名無しさん
08/01/21 11:07:39
>>70
だろうな。
さすがに var < 0 を 0 > var って書く人はいないか。
いないよな？
73:デフォルトの名無しさん
08/01/21 11:10:36
よし纏めよう。
・定数右派
基本的に、常に定数が右。不等号の向きなんて関係ねぇ。
・定数左派
基本的に、常に定数が左。不等号の向きなんて関係ねぇ。
・不等号は数直線派
基本的に、不等号は常に左を小さく。定数の位置なんて関係ねぇ。
ダメだ、>71も恐らく例外があるのだろうし分類しきれない……
74:63
08/01/21 11:22:37
>>64-72
回答ありがとう
なるほどねー
1. 数直線に合わせる派
2.1. 評価対象を常に左に置く派
2.2. 評価対象を常に右に置く派
がいるみたいだね
…これ、どっかのMLの過去ログにもありそうだな
75:デフォルトの名無しさん
08/01/21 11:42:38
基本的に短い物が左。
そして変数同士の不等号は数直線派。
変数か定数かなんて関係ねぇ。
な俺は結果的に
即値 < 変数・定数 < 式 < 関数
な順番になるな。
定数左ってよりは即値左か？
画面が狭かった頃の規約の名残だな。
76:デフォルトの名無しさん
08/01/21 13:24:24
こんなものは理屈じゃなくて、数学の記法では普通 0=x でなく x=0 と書くというのが一番大きい気がするけどな
不等号は3項関係なら数直線だが2項関係ならやはり変数を左辺に書くのが数学でも一般的だと思う
77:デフォルトの名無しさん
08/01/21 13:59:49
その理屈だと関数が絡んだときにおかしくないか？
数学だとy=f(x)の方が一般的でないか？
78:デフォルトの名無しさん
08/01/21 14:12:06
>数学だとy=f(x)の方が一般的でないか？
その記法は定数相手には使わないような。
確かに y については y = f( x ) 的な書き方をするけど、f(x) については f(x) = a * x + y 的な書き方もするはず。
だからまあプログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、それでも変数と定数に限れば 0=x ではなく x=0 だろう。
これはもう理屈とか抜きに。
79:デフォルトの名無しさん
08/01/21 14:27:50
>>78
数学に限って言えば、
＞0=x ではなく x=0 だろう
これは状況によりけりだな。まぁ、
＞プログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、
は正しいと思うので、数学のルールは適用できないんだけどね。
80:デフォルトの名無しさん
08/01/21 16:34:55
&&とか||が絡むなら不等号の向きをそろえるけど
それ以外なら気にしないな。
81:デフォルトの名無しさん
08/01/21 16:36:21
またこの話か。去年さんざん「祭り」したのに。
もう秋田。
82:デフォルトの名無しさん
08/01/21 18:25:42
わざわざ来なくてもいいのに（笑）
83:デフォルトの名無しさん
08/01/21 18:34:21
基本的には数直線に合わせるけど、場合によっては変えるね。
言葉や数式で表現するとどうなるかを頭に置きながら
理解しやすい方を選択する。
84:デフォルトの名無しさん
08/01/21 20:01:32
Cプログラマの為に、ポイントをまとめたドキュメントを販売しています。
プロのプログラマでもあまりにレベルが低い人が多すぎます。
そんな人に限って、自分のレベルの低さを自覚していない、、、
本人は構わないかもしれませんが、その下についた新人プログラマは
たまったものではありません。（私が経験しました。）
今になって分かりました。
彼らもまた、理解できていなかったのです。
プログラミング言語の一番の習得の近道はきちんと理解している人にアドバイスをもらうこと。です。
私のC言語に取り組んだ7年間をすべてぶつけたつもりでテキストを作りました。
私の会社の後輩からは、どんなテキストよりもわかりやすかった！や、
今まで教えてくれていた先輩や、テキストたちが、ちゃんと理解できていないことがわかりました。
と、嬉しいコメントをたくさんもらいました。
そしてなにより、彼らの社内での評価がとても高いということが、私の誇りです。
興味がある方はどうか、下のサイトをみてみてください。
URLﾘﾝｸ(mori.eco.to)
85:デフォルトの名無しさん
08/01/21 20:04:01
ｳｾﾞｪ
86:デフォルトの名無しさん
08/01/21 21:33:16
みるまでもなくネタだろ
87:デフォルトの名無しさん
08/08/02 01:43:31
最近、カプセル化は要らん子な気がしてきた。
真面目に適用したところで可読性や保守性は上がるどころか下がることの方が多いし、
getter/setterを書くより、コメントやドキュメントをしっかり書いた方が良い気がする。
88:デフォルトの名無しさん
08/08/02 02:58:06
getter/setter が無いと、ついつい直接書き換えして
後の挙動が掴めなくなってしまう俺みたいな屑も居るので書いてくれて良い
89:デフォルトの名無しさん
08/08/02 09:35:09
つーか、そもそも下駄雪駄がある時点で間違いだろ。ちゃんと意味を考えたI/Fにするべきだ。
90:デフォルトの名無しさん
08/09/28 15:35:28
>>87
getter/setterがある時点でカプセル化に失敗してるよ
91:デフォルトの名無しさん
08/09/28 17:00:45
getter/setterだけでも、代入と取得のみに操作を限定できる利点がある。
メンバのアドレスを取られる心配がないだけでも幾らか安心感があると思うよ。
92:デフォルトの名無しさん
08/09/28 20:03:24
ブレークポインタもかけやすいしな。
だけとgetter/setterが多くなるとカプセル化の意義が薄れてしまうのも忘れてはならないね
93:デフォルトの名無しさん
08/09/29 03:59:22
設計から導き出されるのが、いい getter/setter
実装から導き出されるのが、悪い getter/setter
悪い getter/setter でも、将来の変更に備えて、無いよりマシ。
94:デフォルトの名無しさん
08/10/04 02:42:58
基本的な値はコンストラクタで受け取るだけで、その後はgetterのみ。
どうしても後から値を変更する必要があるとか、設定値の種類が多すぎる場合のみsetterを使うかな。
95:デフォルトの名無しさん
09/02/03 14:10:18
無限ループは
while(true){
}
って書くのが一番美しいと思うんです
96:デフォルトの名無しさん
09/02/03 14:28:30
for ("ever") {
}
97:デフォルトの名無しさん
09/02/03 19:29:38
>>95
それは意図しているのかそれともミスなのかが判断できない。
for(;;)
{
}
このほうが意図が明確
98:デフォルトの名無しさん
09/02/03 21:00:25
誘導されてきました
int* a;
int *a;
どっちのほうが見やすいですか？
99:デフォルトの名無しさん
09/02/03 21:32:24
int*型として考えるなら前者
変数自身がポインタと考えるなら後者
100:デフォルトの名無しさん
09/02/03 22:04:58
int* a, b;
とかやられるとヤヴァイから後者がいい
101:デフォルトの名無しさん
09/02/03 22:32:07
ポインタ型と普通の型をまとめて宣言しないでほしい
102:デフォルトの名無しさん
09/02/03 22:37:07
resありです＾＾
103:デフォルトの名無しさん
09/02/03 22:55:50
>100
こんなのコンパイルエラーで検出出来るだろJK
104:デフォルトの名無しさん
09/02/03 23:31:31
>>103
コンパイルに数分かかるプロジェクトを書いた事が無いのか
105:デフォルトの名無しさん
09/02/04 00:31:53
>>100
変数宣言分けるからどうでもいい
106:デフォルトの名無しさん
09/02/04 00:42:39
そもそも1行に2つも宣言しないよな
107:デフォルトの名無しさん
09/02/04 10:03:18
テンプレートではint*で１つの型なのに、>>100の例があるから困る。
でも俺はint* a;派。
108:デフォルトの名無しさん
09/02/04 10:55:18
結局、CもC++も書く私はint * a;で落ち着きましたとさ。
109:デフォルトの名無しさん
09/02/04 12:23:17
>>107
俺もint* a派。型を意識したりテンプレート使うとそうなるよね。
複数宣言はしない。行を分けてコメントを書く。だから>>100は無いものとしてC/C++で書いてる。
110:デフォルトの名無しさん
09/02/04 13:04:35
>>100
絶対賛成！
型がどうこういってるやつは、
typedef int *intpとかするがいい。
111:デフォルトの名無しさん
09/02/04 21:26:38
ポインタを typedef した時の const の挙動がなあ・・・
112:デフォルトの名無しさん
09/02/05 00:51:29
Code Complete には int *p にせよと書いてあったが、俺は >108 方式。
>>104
リンクまで込みでじゃなくて、一つのファイルをコンパイルするので？
そこ辞めてヨソ行った方がいいかも。
113:デフォルトの名無しさん
09/02/05 01:00:05
>>112
趣味で書いたやつでテンプレートをひどく使ってそういう事態になったことはあるが、
仕事なら絶対にできないな。
114:デフォルトの名無しさん
09/02/05 09:44:40
なんでC/C++は宣言の時、int *a, *b;という構文にしたんだろう？
キャストやテンプレートではint*を使うことになるのに。
スレ違いか。
115:デフォルトの名無しさん
09/02/05 17:16:21
>>114
*aがint型と読めるという話はよく聞く。
関数・配列が複雑に絡み合ったのも、そうやって解読していくし。
C++はCとの互換のため。
116:デフォルトの名無しさん
09/02/05 19:33:24
>>114
constへのポインタとconstポインタを
はっきり書きわけられることはメリット。
ぱっと見はわかりにくい文法だけど、
関数へのポインタとかも含めていろいろ
わかってくると、全体としては悪くないと
納得せざるをえないと思う。
117:デフォルトの名無しさん
09/02/05 20:44:49
>>116
それがどうした
118:デフォルトの名無しさん
09/02/05 21:24:38
>>116
const int* a, b;// aもbもconstへのポインタ
int* const c, d;// cもdもconstポインタ
こういう文法にして欲しかった。
関数へのポインタの宣言はかなり気持ち悪く感じる(typedefの挙動なんか特に)。
こっちもなんとかして欲しかった。
119:デフォルトの名無しさん
09/02/05 21:28:31
でも、ポインタを戻り値とする関数と区別するためにはやむを得ないんだよな・・・
120:デフォルトの名無しさん
09/02/07 04:21:07
>116
単純に記述量を減らすためかと。
例： int a = 1, *p = &a;
121:デフォルトの名無しさん
09/02/07 10:03:22
>>120
別の型を1行で宣言したいと思わない。
むしろint *a,*bがint* a,bで宣言できたら、1行で宣言する変数が１つ増える毎に1文字タイプ量が減ってありがたい。
122:デフォルトの名無しさん
09/02/07 10:16:16
>>119
関数へのポインタの宣言は例えばboost::function風に
void F(int);
function_ptr<void, int> a = &F;
これなら見やすい。
123:デフォルトの名無しさん
09/02/07 17:22:52
今でも、C++でBoost使えば、functionっぽく書ける。実際に使うかどうかは別として。
void f(int, double);
boost::mpl::identity<void (int, double)>::type* pfn = f; //void (*pfn)(int, double) = f;と同じ
まあ素直にtypedefすべきだな。
124:120
09/02/08 00:38:56
無名の構造体て書けなかったっけ?
そのポインタを宣言するのに必要な気がする。
struct ｛
｝ obj, *p;
125:デフォルトの名無しさん
09/02/08 00:41:41
それって、コンパイラが勝手に適当な名前を付けるやつだっけ
126:デフォルトの名無しさん
09/02/08 10:25:49
>>124
そのp使い道なくない？
型名が無名だから関数の引数に渡せるわけじゃないし、ヒープから確保することもできない。
127:デフォルトの名無しさん
09/02/08 12:50:57
インスタンスが２つあれば、その切り替えに使えるかもしれないが、
ま、そこまでするなら型名付けた方がいいと思う。
128:デフォルトの名無しさん
09/02/08 13:07:35
typedef struct ｛
｝ t, *p;
こんなのなら見るけど
129:デフォルトの名無しさん
09/02/09 21:09:40
>>99
C言語のこの仕様はポインタの理解をさまたげてくれたなあ・・・
Delphiは前者が前提なんだが、C挫折してDelphiやってはじめてポインタの概念がわかったよ俺は
ポインタって「なんとかのポインタ」で1つの型なんだ、と気づくまでにやたら時間がかかた。
130:デフォルトの名無しさん
09/02/10 12:22:29
ポインタ宣言に使う記号がアスタリスクなのもややこしいよね。
ポインタ絡みで間接演算子使うだけに。
131:デフォルトの名無しさん
09/02/10 12:28:56
if(flag){
}
if(flag == true){
}
どっちを選べばよいか･･･
132:デフォルトの名無しさん
09/02/10 12:34:02
>>128 構造体の typedef 禁止
133:デフォルトの名無しさん
09/02/10 13:29:14
>>131
前者に決まってる。論理定数との比較は無意味。
URLﾘﾝｸ(www.kouno.jp)
134:デフォルトの名無しさん
09/02/10 15:04:14
if(flag){
この間にいくつスペースを挟めばいいのかわからない
135:デフォルトの名無しさん
09/02/10 16:26:13
入れなくてもいいし、入れるのならif (flag) {がお勧め。
136:デフォルトの名無しさん
09/02/10 17:11:33
"if"の後に一個、
"("の後に一個、
")"の後に一個スペースを入れないと、
かつ、二個以上入れた場合、コンパイルできない
とかいう仕様だったらいいのに。
俺は末期か・・・
137:デフォルトの名無しさん
09/02/10 20:49:28
if の後に空白を入れるスタイルだと、
条件が二行以上に渡る場合に４タブで綺麗に揃う
138:デフォルトの名無しさん
09/02/10 20:52:17
>>136
MS信者？
139:デフォルトの名無しさん
09/02/10 20:53:07
if ( hoge) {
こうか？
バランス悪すぎ
140:デフォルトの名無しさん
09/02/10 23:27:25
>137
漏れはこう
if( 条件1
|| 条件2 )
141:デフォルトの名無しさん
09/02/11 00:28:58
既存のコードにあとから手を付ける場合は、出来るだけ合わせて書いてるな
142:デフォルトの名無しさん
09/02/11 01:38:12
最近はワイドモニタだから、右に長くなりがちだなぁ。
基本は>>140と一緒だが。
143:デフォルトの名無しさん
09/02/11 01:57:32
じじいに言わせると80桁を越すと犯罪らしいぜ
144:デフォルトの名無しさん
09/02/11 02:00:18
コーディング規約でも規定されない限り、横の長さはそれほど神経質に考えないな
ある程度は工夫するけど
145:デフォルトの名無しさん
09/02/11 03:22:49
モニタが大きくなるとかえって80桁とかに縛りたくなる。
横にいくつもウィンドウを並べてみるのに都合がいい。
146:デフォルトの名無しさん
09/02/11 06:14:45
端末エミュレータを三つ並べても100桁表示できるご時世だから、気にしてもねぇ。
そんな私はどちらかと言えばこっち。
if (条件1 ||
条件2) {
147:デフォルトの名無しさん
09/02/11 15:00:02
デバッガでトレースしやすいように１行で書いてる。
if (条件1 || 条件2 || 条件3 || 条件4 || 条件5 || 条件6 || 条件7 || 条件8 || 条件9 || 条件10) {
148:デフォルトの名無しさん
09/02/11 15:06:14
ソースコード関係ないけど、未だにWindowsのデスクトップの縦のアイコン数は、1024ｘ768時代の数だなｗ
でも最近Windows7使ってると、その傾向はなくなってきた（Vistaは常用したことない）
エディタは、文字数による改行なしで設定するのが俺のジャスティスだな
149:デフォルトの名無しさん
09/02/11 22:19:15
>>133
別に後者がいいとはまったく思わないが
trueとTRUEは違う
よってそのリンク先は根拠にならない
150:デフォルトの名無しさん
09/02/11 22:25:43
>>149
true でも TRUE でも以下の話は同じ。
> もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか
論理定数との比較自体が無意味。
151:デフォルトの名無しさん
09/02/11 22:26:58
((a == b) == TRUE)
↑これ何の冗談？ｗ
152:デフォルトの名無しさん
09/02/11 22:30:57
>>151
つまりそういう皮肉
153:デフォルトの名無しさん
09/02/11 23:00:51
>>150
それ、主題じゃないし
さらにその例はFAQそのものが不適切だ
論理定数との比較云々じゃなくて（そこは同意する）
そのFAQが違うだろって話ね
154:デフォルトの名無しさん
09/02/11 23:16:29
>>153
うるせぇなぁ。少しは応用しろよ。
>131 へのレスで挙げてるんだらこういうことだろ。
もし if(flag == true) が if(flag) より良いと思うのなら、なぜそこで止めるのか。
なぜ if(flag == true == true) を使わないのか。
155:デフォルトの名無しさん
09/02/12 01:10:46
処理上は無意味でも
if ( flag )より
if ( flag == true )のが
わかりやすくないか？
156:デフォルトの名無しさん
09/02/12 01:13:50
それじゃflagが２だったらとおらねぇだろ
157:デフォルトの名無しさん
09/02/12 01:16:11
それでいいじゃんｗ
2が入ること自体がおかしい
158:デフォルトの名無しさん
09/02/12 01:27:37
>>155
処理上は無意味でも
if ( flag == true )より
if ( flag == true == true )のが
わかりやすくないか？
159:デフォルトの名無しさん
09/02/12 01:41:46
trueはfalse以外が仕様だからそれじゃダメだっての。
if ( flag )
if ( flag != false )
これ以外は許されない
160:デフォルトの名無しさん
09/02/12 01:47:26
>>159
flag の型がちゃんと bool ならどっちでもいっしょ。
それよりも if ( flag != false != false ) のが（以下略
161:デフォルトの名無しさん
09/02/12 02:12:25
>>160
C言語だとダメなやつもあるから、0と0以外にしとくのが安全なスタイルってもんだよ。
比較演算の結果でてくる論理を比較するのもありだけどね。
assert( (p == NULL) != false );
162:デフォルトの名無しさん
09/02/12 02:15:40
>>161
わざわざ「flag の型がちゃんと bool なら」って書いてあるのに何言ってんの？
> assert( (p == NULL) != false );
ねーよ
163:デフォルトの名無しさん
09/02/12 02:33:29
いやいや、そこはこうでしょ
assert( (p == NULL) != false != false);ってのが(ry
164:デフォルトの名無しさん
09/02/12 02:47:00
だからさ、FAQの
> もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか
これがそもそもおかしい
おそらく原作者はジョークのつもりだったろうが、真に受けてるアホがいるからな・・・
165:デフォルトの名無しさん
09/02/12 02:58:25
Cの(ユーザー定義の)TRUEとC++の(言語の)trueの違いがわかってない奴がいるな
Cでif(flag==TRUE)は間違いだが、C++でif(flag==true)は書き方の問題だ
書き方の問題＝好みだよ
ここでif((flag==true)==true)を持ち出す奴はジョークが理解できないってことだ
166:デフォルトの名無しさん
09/02/12 03:50:19
>>164
で、何がいいたいの？論理定数との比較を擁護するつもりなの？
167:デフォルトの名無しさん
09/02/12 04:00:02
>>165
はなから技術的な正しさとか間違いとかを問題としてるんじゃない。
論理定数との比較に意味が無く、混乱の元でしかないから書くべきではないという話だ。
(... == true) も (... != false) も同じくらいに意味が無い。
168:デフォルトの名無しさん
09/02/12 04:43:58
意味あるじゃん
ある特定の人間にとっては見やすいという意味が
169:デフォルトの名無しさん
09/02/12 05:01:14
カスみたいな意味だな。
170:デフォルトの名無しさん
09/02/12 10:58:38
一番ダメなのは is～, has～, can～ などの自然に読み下せるように工夫した命名規則を
台無しにしてしまうこと。
if (x.isReady()) で済むところを
if (x.isReady() == true) だの
if (x.isReady() != false) だの
わざわざノイズを混ぜるのが許せない。
171:デフォルトの名無しさん
09/02/12 11:49:41
俺はif(flag)派だが、if(flag==true)なソースを見てもいちいち噛み付かないな
TRUEは明らかに不味いがtrueは見た目の問題、見易いかどうかは主観だからな
それをノイズと感じるのも自由だし、そんなのは人に押し付けなければどっちでもいい
それよりTRUEとtrueを混同して大昔のFAQを持ち出したり、
技術と好みの違いが分からない奴の方がスキル低いだろ
172:デフォルトの名無しさん
09/02/12 13:42:38
TRUEとの比較には問題があるなんて>>133なども当然理解しているだろ。
それは誰もが理解しているという前提で、本筋からそれるのでスルーしただけにしか思えない。
173:デフォルトの名無しさん
09/02/12 22:31:56
初見のソースでif( hoge == true ) と書かれていると、hogeがboolになっているか、
そうでなければtrue/falseの2値しか取り得ないのかチェックする手間が生じる。
初見じゃなくてもどうなってるかいずれ忘れるかもしれない。
（そんなの気にしないとかってのは論外過ぎる）
if( hoge != false ) も、万人がつっかえず読めるソースであるとは言い切れない。
174:デフォルトの名無しさん
09/02/13 00:20:00
もしかしてflagが２でも==trueなら通るのか？
175:デフォルトの名無しさん
09/02/13 00:35:12
flagに2が入っている時点で不具合だとしか思わない
bool型ならな
176:デフォルトの名無しさん
09/02/13 01:02:25
素直に!=falseにしとけよ。
177:デフォルトの名無しさん
09/02/13 04:07:26
>>172
理解してたらtrueに対してFAQ(TRUE)を持ち出さないだろ
178:デフォルトの名無しさん
09/02/13 10:51:29
ヘンなケースだけど if (flag) 形式は
うっかり bool の配列を渡してハマりそうになったことあるなぁ
bool array[2];
if (array)
みたいな
179:デフォルトの名無しさん
09/02/13 14:13:43
>>173
初見のソースでif(hoge==1)と書かれていると、hogeがintになっているか、
チェックするのか？しないだろ？
ただのいいがかりじゃねえか、おまえの頭が論外だよｗ
180:デフォルトの名無しさん
09/02/13 14:19:19
読み違えてるよ
181:デフォルトの名無しさん
09/02/13 14:23:58
hoge == 1 は何とも思わないが、 hoge == true を見つけたら bool 値に対する理解が
不十分な可能性を疑わざるを得ないだろうね。バグを探してるときならなおさら。
signed/unsigned が混在してたり、可変長引数にキャスト無しの NULL を渡してたり、
ループ変数に char が使ってあったりするのと同じ。言語仕様の不十分な理解から出る
バグのにおいがする。
182:デフォルトの名無しさん
09/02/13 14:37:11
hoge==true見つけただけで言語使用を理解してない可能性を疑うってどんだけレベルの低い環境なんだ
ところで181の挙げた例に細かいミスがあるんだが、普段の俺ならスルーしてあげる
だが181の論理によれば、俺からみたら181は言語使用を理解してないと疑わざるを得ない
183:デフォルトの名無しさん
09/02/13 14:38:48
言語使用→言語仕様
184:181
09/02/13 14:43:46
何かミスがあるというなら言語仕様を理解していないと疑われるのはしかたがないと思うけど、
できればはっきりと指摘してほしいところだね。
185:デフォルトの名無しさん
09/02/13 14:46:01
どうせハッタリだろ。
186:デフォルトの名無しさん
09/02/13 15:08:25
なんか話ずれてるけど
173はif(hoge==true)ならhogeがboolかチェックするんでしょ？
もうその時点でありえないんだけど、そんな底辺レベルの職場なら
if(hoge==1)でもhogeがintかチェックする必要がある、チェックしないのはダブスタじゃん
って意味だよね、違う？
普通の職場なら同僚やらオープンソースで
if(hoge==true)見つけても、「あらあら、このひとはtrueと比較しちゃうんだ」って思って終わりだよ
どんだけ病んだ職場で働いてるんだ、転職したほうがいいよ
187:デフォルトの名無しさん
09/02/13 15:25:30
>>186
hoge == true （あるいは hoge != false ） を書くような人は bool 型や if 文になどついての理解が
あやふやな可能性が高いので、同様に理解の不足から int == true などという間違いを犯している
可能性があることを推測できる。
hoge == 1 を見ただけではそのような推測はできない。
関連箇所でのバグを探してるんじゃなければスルーすることも多いだろう。それが普通だというのも
妥当な話だ。しかし、スレタイを読む限りここでそれを主張するのは無意味だろう。
188:デフォルトの名無しさん
09/02/13 20:14:16
あのさ,
if (is_true_this(x) || is_true_that(x)) {
}
ってコーディングを許してくれないのはなぜ?
仕様的に副作用がない事を要求されている関数使って、なんで
this_is_true = is_true_this(x);
that_is_true = is_true_that(x);
if (this_is_true || that_is_true) ....
って、かかんとあかんわけ?
189:デフォルトの名無しさん
09/02/13 20:15:31
関数が何返したのか分かりにくい
190:173
09/02/13 22:09:36
>179,182
if( hoge == TRUE )のケースを考えてみてよ。
hogeは本当にTRUEかFALSEしか取り得ないのか不安にならない?
漏れが指摘したいのはむしろこっちの方なんだよ。
if( hoge == true )の場合は気にし過ぎってのは素直に認める。
（コンパイルすりゃすぐ分かるというのはEnter押してから気付いた）
でもバグ発生時には疑うべき記述だと思う。
191:デフォルトの名無しさん
09/02/13 23:40:30
if ((!!flag == true) != false) {
flag = true;
flag = true; // 念のためもう一度
}
これくらいやっとけば安心
192:デフォルトの名無しさん
09/02/14 00:48:46
実際、trueやfalseと比較し捲くっているコードを整理したら、若干ではあるけど
所要時間に有意差が認められたからなぁ。
193:デフォルトの名無しさん
09/02/14 01:01:22
(1) if( hoge == TRUE )
(2) if( !!hoge == true )
(3) if( hoge == true )
(4) if( hoge )
最悪のケースを想定した場合、読み手が考え込む時間が一番短いのは(4)でしょ。
ifの動き、hogeの値、コーディングスタイル、ネーミング位しか悩める要素が無いんだから。
他は最悪、型とか脳内演算とかで、余計な思考時間を生んでしまう恐れがある。
194:デフォルトの名無しさん
09/02/14 01:35:45
true との比較では所要時間に差は出るだろうが
false との比較で差が出るのは最適化レベルがおかしいんじゃないのか
195:192
09/02/14 01:41:23
>>194
trueもfalseも纏めて整理したから、falseの有無で差があるかは確認していない。
196:デフォルトの名無しさん
09/02/14 01:42:04
あえて(2)を混ぜて誤魔化してないか？ｗ
197:デフォルトの名無しさん
09/02/14 11:27:41
trueと比較しない場合
>>178みたいなのでハマるくらい?
198:デフォルトの名無しさん
09/02/14 11:52:14
逆にboolをtrueと比較して困るケースの具体例、つか経験談ってある？
199:デフォルトの名無しさん
09/02/14 11:58:59
>>198
1以外の値が入ってるときとか。
200:デフォルトの名無しさん
09/02/14 11:59:12
>>198
>194
201:デフォルトの名無しさん
09/02/14 16:47:04
ちょっと違う話かも知れんが、
if (式) {
return true;
} else {
return false;
}
なんてプログラムを見ることがたまにある。
最初からreturn 式;にしろよ、って思う。
202:デフォルトの名無しさん
09/02/14 16:48:03
変更になりそうな箇所がおおいならそう書くこともある。
203:デフォルトの名無しさん
09/02/14 19:46:26
漏れはこうだなあ。
if (式) {
return true;
}
return false;
204:デフォルトの名無しさん
09/02/14 19:54:47
そういうのを書く時は最終的にtrueを返すようにしてるな
205:デフォルトの名無しさん
09/02/14 19:55:23
return (式) ? true : false;
206:デフォルトの名無しさん
09/02/14 21:41:18
>>205
これはないな。
207:デフォルトの名無しさん
09/02/14 21:58:37
式が関数でtrue/falseの意味が取り違える可能性があるような名前ならアリかもな。
208:デフォルトの名無しさん
09/02/15 16:12:23
>>205
俺もこれだけはやっちゃダメだろとは思う
マクロならそうなるけど
自分のことしか考えてないタイプ
209:デフォルトの名無しさん
09/02/15 17:18:59
static
_Boolean checkLevel(
double value,
double level,
_Boolean reverse )
{
if ( reverse == _False ) {
if ( level <= value ) {
return _True;
}
} else {
if ( value < level ) {
return _True;
}
}
return _False;
}
--
これ見たときはどうしてくれようかと思った。
210:デフォルトの名無しさん
09/02/15 17:55:06
設計書にそういう「ロジック」を書いてるんだろうなあ。。。
1. 引数は値、レベル、反転フラグとする。
2. 反転フラグが _False であれば、以下を行う。
1) ・・・
3. 上記以外の場合、以下を行う。
1) ・・・
日本人プログラマが10人いれば、8人は何も考えずにコーディングを行う。
1人は、「反転フラグて。。。呼び出し側で結果を反転させりゃいいのに。。。」とか思いながらコーディングを行う。
残りの1人だけが「なんで設計書にロジック書いてんだｗｗｗこの現場やべえｗｗｗ」と笑い、辞める。
211:デフォルトの名無しさん
09/02/15 18:11:22
>>210
設計書を書いた奴と相談するっていう選択肢が無いのが悲しいな。
212:デフォルトの名無しさん
09/02/15 20:05:55
_Booleanはどういう定義なんだよソレｗ
213:209
09/02/15 20:14:34
>>212
おっと、書き忘れてた。
＞typedef enum { _False = 0, _True = 1 } _Boolean;
だとさ。ちなみに、Sun-OSのcc(標準ではc99としてコンパイルする)を使っているのに
c99禁止と言う不思議なコーディング規約(と言っても明文化されていない)だし。
>>210
>209のコードに関しては、設計者=コーダーの可能性大。
214:デフォルトの名無しさん
09/02/16 05:43:24
"<="や">="を書くことが幼稚な気がして今まで避けてきたんだが
"<"や">"は小数を扱うのが正しい使い方で、
整数を扱う場合はイコールをつけたほうが直感的な気がする
for(int i=0; i<10; i++)
ってのが一般的で10回カウントするってのが直感的にわかるけど
なんというか、行って帰ってきて結果的にはあってるって感じで、
for(int i=0; i<=9; i++)
のが1から9まで1ずつカウントするって意味で
正しい使い方な気がする
215:デフォルトの名無しさん
09/02/16 05:47:32
１からじゃなくて０からでした
216:デフォルトの名無しさん
09/02/16 06:00:51
>>205が何でだめなのか、プログラミング初級者の俺に教えてくれ
無駄がなくてわかりやすいと思うんだが
217:デフォルトの名無しさん
09/02/16 07:21:32
1. 返り値がニ値しか取りえないなら、isHoge関数にすべき
2. 構文糖衣はあくまで糖衣
3. 流し読みする時に目に入り辛い
(最後の行だからいい？一カ所使われていると、
複数箇所使われている可能性が高いから、結局同じこと)
218:デフォルトの名無しさん
09/02/16 07:39:52
>>214
＞１からじゃなくて０からでした
こういう馬鹿が居るから直感的じゃないんだよ。
219:デフォルトの名無しさん
09/02/16 09:29:50
>>216
「? true : false」の部分が丸々冗長。
単純にこれを消しても同じ意味だよ。
220:デフォルトの名無しさん
09/02/16 22:36:57
式が bool 型ならそうだろうが
そうじゃなけりゃえらい違いだよ。
bool 型へのキャストは警告出すコンパイラがあるんで、
やむを得ず ? true : false としないといけない。
マクロ化したいけど、作ってもみんな使ってくれないし・・・。
221:デフォルトの名無しさん
09/02/16 22:44:33
強制的に bool にしたいなら !!(式) でいいだろ。
222:デフォルトの名無しさん
09/02/16 22:56:47
Cだったら、0か0以外にしとけばいいんだよ。
223:デフォルトの名無しさん
09/02/16 22:59:57
>>220
条件演算子なんか使わなくても、比較式入れとけばいいじゃん。
224:デフォルトの名無しさん
09/02/16 23:10:01
真偽値を比較するなんてとんでもない！
225:デフォルトの名無しさん
09/02/16 23:26:09
>>224
真偽値だったら、そのままreturnすればいいんじゃね?
#define true 0
#define false -1
↑みたいな変態的な定義でもされてたら、条件演算子もやむなしって気がするけど。
226:デフォルトの名無しさん
09/02/16 23:44:02
自分だったら!!よりは? true : false選ぶなあ。
227:デフォルトの名無しさん
09/02/16 23:48:27
>>225
bool hoge(int ch) {
return isupper(ch);
}
isupper の戻り値は真偽値（int 型の非0/0）だが bool ではない。
コンパイラによってはそのまま return すると文句言われる事がある。
228:デフォルトの名無しさん
09/02/16 23:58:38
>>227
いや、だから、真偽値以外だったら、比較にすればいいんじゃね?って話。
return isupper(ch) != 0;
229:デフォルトの名無しさん
09/02/16 23:58:49
>>225
それが標準だったらどんなに良かったかと常々思ってる。
230:デフォルトの名無しさん
09/02/17 00:03:33
>>229
trueやfalseが標準で定義されていて、
n > 0 みたいな比較式の結果と違う値になってたらよかったってこと?
231:デフォルトの名無しさん
09/02/17 00:15:34
>>228
真偽値を比較するなんてとんでもない！
ぶっちゃけ読み辛くてしゃーない。
232:デフォルトの名無しさん
09/02/17 00:23:21
>>231
ああ、それはそうだな。
Cライクな真偽値と、C++のboolを併用するときはしかなないのかね。
static_cast<bool> とかするとどうなるんだろう。
233:デフォルトの名無しさん
09/02/17 00:25:08
VC++はboolへのあらゆる直接的な変換は警告出した気がする
234:デフォルトの名無しさん
09/02/17 00:25:56
g++はノーキャストでも完全スルーなんだが
235:デフォルトの名無しさん
09/02/17 00:52:23
>>220
式が bool じゃなくて return するのに問題があるというのなら、
? の左に書くのだって同じ問題があるはずじゃないか。
やっぱり、? 以降は単純に冗長だよ。
236:デフォルトの名無しさん
09/02/17 22:58:25
だーかーらー、五月蝿い警告が出るコンパイラへの対策なだけだと言うとるに。
どのコンパイラでも警告でないならそのまま返したいさ、そりゃ。
237:デフォルトの名無しさん
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 {
// ～(条件についての記述は無し)
}