コーディングスタイルにこだわるスレ

コーディングスタイル ..

2:デフォルトの名無しさん
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).

次ページ