C/C++ Coding Style Thread - 暇つぶし2ch

C/C++ Coding Style Thread at TECH

1:デフォルトの名無しさん
04/10/02 12:28:23
C言語、C++言語のコーディングスタイルについて
クールに語るスレッドです

2:デフォルトの名無しさん
04/10/02 12:32:32
特にこれから学習する人は、まだ独自の癖が付く前に
ｺﾞﾗｧされにくいコーディングスタイルを身につけましょう

3:デフォルトの名無しさん
04/10/02 12:41:43
#include <2c.h>

main(){
return 0;
}

4:デフォルトの名無しさん
04/10/02 12:44:41
int count, temp, data;
カンマの後にスペースを置き、空白の美を堪能する

if (foo > 10){
if, whileの直後もスペース推奨。関数との差別化を図る

5:デフォルトの名無しさん
04/10/02 12:53:32
if (...)
{
}
else
{
}

と書く奴はキモイ

6:デフォルトの名無しさん
04/10/02 12:58:03

>>4
int count, temp, data;
これは以下のようにするように推奨しているけど少数派かね。
int count= 0; //変数の意味を記述
int temp = 0;
int data = 0;
理由は、編集のし易と
int *a,b;とあったときにbをポインタと勘違いするミスを防ぐため。

7:デフォルトの名無しさん
04/10/02 12:58:19
if (...) {

} else if (...) {

} else {

}

クール。グルービー

8:デフォルトの名無しさん
04/10/02 13:26:35
if (...)
{ // ここにコメント
}
else
{ // ここにコメント
}

9:デフォルトの名無しさん
04/10/02 13:32:21
>>6
私もそのようにすることを推奨している。

10:デフォルトの名無しさん
04/10/02 13:32:50
>>6
ちなみに、ポインタは
int *a;
よりも
int* a;
を推奨している。

11:デフォルトの名無しさん
04/10/02 13:36:22
>>10
変数宣言構文の意味を勉強してから出直しな。

12:デフォルトの名無しさん
04/10/02 13:36:51
>>10
へ？　なんで？

13:デフォルトの名無しさん
04/10/02 13:37:03
>>11
出直すのは君の方ね。

14:デフォルトの名無しさん
04/10/02 13:37:50
if( ){

}
else if( ){

}
else{

}

これ、知ってからずっと愛用。
カッコの対応関係が見やすい。

15:デフォルトの名無しさん
04/10/02 13:38:05
まさか
int *a;
で、aの型は？って聞かれたらint型だなんて言わないよね。

16:デフォルトの名無しさん
04/10/02 13:45:11
if () {
　hoge; // 詰まってて見にくい
}

if () {
　　　　　　　// 空いてて見にくい
　hoge();
}

if ()
{
　hoge();　// 安心
}

17:デフォルトの名無しさん
04/10/02 13:48:44
>>10
そういうやつがいるから
int* a,b;
のbをポインタだと勘違いするやつが出てくるんだよ・・・

18:デフォルトの名無しさん
04/10/02 13:52:41
>>17
だから、
int a, b, c;
という書き方はせず、
int a;
int b;
int c;
という風に書くというルールの下、
int* a;
int* b;
int* c;
という風に全て書けばaが何型か明記したことになる。
int *a;
int *b;
int *c;
という書き方はaが何型か明記していない。
ちなみに、このルールから言うと、
int* a,b;
という書き方は許されないから、間違うことはない。

19:デフォルトの名無しさん
04/10/02 13:54:24
int*a
は a が int* 型だという意味ではなく
*a が int 型だということは理解してる？

20:デフォルトの名無しさん
04/10/02 13:57:32
>>19
それは理解しているが、ポインタは用途が違う事が多いので、
扱いを変える必要がある。
ゆえに明記する。

21:デフォルトの名無しさん
04/10/02 14:12:13
>>18
そのルールを守っているプロジェクト内ではそれで完結できるが、
そいつが別のルールの(一行で複数宣言を許す)プロジェクトに移ったとき、
17みたいのを見て勘違いしないか？
文法を理解してないそいつが120%悪いが、世の中出来るやつばかりじゃないからな・・・。

22:デフォルトの名無しさん
04/10/02 14:16:31
>>21
もちろん、int* a;のような記述もコーディングルールの一部だから、
別のルールに従う必要があるときはそのルールに従うべきだよ。
int *a;と書かないといけないルールだったらそうすればよい。

23:デフォルトの名無しさん
04/10/02 14:18:32
勘違いしててもコンパイラの型チェックで引っかかるんで気づくんじゃない？

引っかからないようなコンパイラ使ってるプロジェクトなら、それこそ「アホはコード触るな」で。

24:デフォルトの名無しさん
04/10/02 14:19:49
だれかemacs用の2chスタイルを定義してください。

25:デフォルトの名無しさん
04/10/02 14:22:41
>>16
でも、そんなお前でもループは

while(1){
}

とか　

for(;;){

}

だろ？

26:デフォルトの名無しさん
04/10/02 14:27:48
if ( hoge ) {
;
} else {
;
}

27:デフォルトの名無しさん
04/10/02 14:28:28
>>25
ときどきスペース空けてくれ

28:デフォルトの名無しさん
04/10/02 14:29:30
っていうか、これに従え
URLﾘﾝｸ(www.sra.co.jp)

29:デフォルトの名無しさん
04/10/02 14:34:38
俺も昔は>>8派だったけど、コードコンプリート読んでからぶらさがり型に変えたよ。

30:デフォルトの名無しさん
04/10/02 14:50:52
>>25
Java では if や while もそう書いてるが
C++ では全部>>16

31:デフォルトの名無しさん
04/10/02 16:12:35
for (int i=1; i<10; i++)
1+2-3*4/5

　　↑
どっちが見やすいですか？
　　↓

for (int i = 1; i < 10; i++)
1 + 2 - 3 * 4 / 5

32:デフォルトの名無しさん
04/10/02 16:19:08
>>31
for (int i=1; i<10; i++) 1+2-3*4/5 ;

33:デフォルトの名無しさん
04/10/02 16:20:05
>>31
後者

34:デフォルトの名無しさん
04/10/02 16:23:07
>>31
+ - の前後はスペース入れる
* / の前後は入れない。

35:デフォルトの名無しさん
04/10/02 16:25:45
>>34
それいいな

36:デフォルトの名無しさん
04/10/02 16:27:54
for ( int i = 1; i < 10; i ++ ) 1 + 2 - 3*4/5;

37:デフォルトの名無しさん
04/10/02 16:30:45
f(void)
f()
どっち？
Cでは意味が異なるんだっけ。
C++限定で。

38:10の主治医
04/10/02 16:32:58
10=18は重度な精神疾患です
以下処方箋

int* aでもかまわないのですが

int* a, b, c;
とか書かれるとその人はbやcもint*型と誤解しているのでは？と悪い印象をあたえます

素直に
int *a, b, c;
と書きなさい

39:デフォルトの名無しさん
04/10/02 16:37:05
宣言数が少ないならそれでいいけど、その他変数とポインタ変数とは使い道が
違うので、結果的に分けて宣言することが多くなると思う。

ただポインタは全部分けて書くっていうのはちょっとわからん。
> ｽﾚﾘﾝｸ(tech板:971番)

40:デフォルトの名無しさん
04/10/02 16:39:34
C++だと変数は必要になったタイミングで宣言できるから、
複数まとめて宣言する必要が無いんだよな。

41:デフォルトの名無しさん
04/10/02 16:41:29
Cだってブロック作ればどこにだって宣言できるもん！

42:デフォルトの名無しさん
04/10/02 16:42:12
>>38
全く直されるいわれはない。
これはスタイルの問題であり、開発者がコード見た時により見やすくするためのもの。
一行ごとに一つの変数を定義するというあらかじめ定義されたルールがある以上、
int *a,b,c;
なんていう書き方は許さないのだから、当然
int* a,b,c;
などとは書けない。
と何度も同じ事を書かないといけないのか？
int *a;なんていう書き方の方が全然素直ではない。
int型のポインタとint型を同じ行で定義するのは意味的に良くない。

43:デフォルトの名無しさん
04/10/02 16:43:17
↑ヴァカ？

44:デフォルトの名無しさん
04/10/02 16:45:23
＞結果的に分けて宣言する
＞int型のポインタとint型を同じ行で定義するのは意味的に良くない

まあ要するにこういうことだわな。
たまたま出来るからやりたければやればいいんじゃないのという。

45:デフォルトの名無しさん
04/10/02 16:46:53
int a, b, c;

と宣言しておいて
aは使う段階になったら

*(int *)a

とする
これで完璧

46:600
04/10/02 16:46:55
int *a = NULL;
*a がintなのにNULLで初期化というのも妙だしな。
int* a = NULL;
ならばしっくりくる。

47:デフォルトの名無しさん
04/10/02 16:47:55
>>44
>>42と>>39をいっしょにするなよ
>>39はポインタ変数の役割が他のIntと違うから別個に宣言すると言ってるだけ
>>42のほうは int と int* が別物だと考えている

48:デフォルトの名無しさん
04/10/02 16:49:02
>>47
全く理解できない
それより、病院いけ？

49:デフォルトの名無しさん
04/10/02 16:50:55
46=47
そんな理解でC/C++使わないでくれ

50:600
04/10/02 16:51:52
>>49
>46=47
そんな理解でレスしないでくれ

51:デフォルトの名無しさん
04/10/02 16:56:47
とりあえず >>43,48,49 はトリップつけてよ。
面倒だから。

52:デフォルトの名無しさん
04/10/02 17:00:32
>>int* a;
えー？！
じゃ、関数ポインタは
int(*) a(void) = NULL;
って書くんですか？

53:デフォルトの名無しさん
04/10/02 17:04:37
「変数名」と「他のもの」は離して書くよ。
関数ポインタならこうする

int (* fncptr)(void) = NULL;

54:デフォルトの名無しさん
04/10/02 17:09:08
>>53
> 「変数名」と「他のもの」は離して書くよ。
じゃあ
int * a;
って書けばいいんじゃない？

55:デフォルトの名無しさん
04/10/02 17:11:54
CとC++ならスタイルも変わってくると思う
Cなら
int *a, *b, *c;

C++なら使うときにひとつずつ
int* a = new int(hoge);

56:デフォルトの名無しさん
04/10/02 17:18:18
>>50
で、君はどこスレの600?

57:デフォルトの名無しさん
04/10/02 17:25:22
>>56
バカ、このスレの未来から来たんだよ。

58:デフォルトの名無しさん
04/10/02 17:28:33
もしかしてドライもんのおともだちだったりするんだ…

59:デフォルトの名無しさん
04/10/02 18:39:00
int a = val; を
int a; と a = val; を一緒にした書き方の延長線上で見てしまうと、

int *a = ptr; が
int *a; と *a = ptr; では、辻褄が合わなくなるので、

int* a = ptr; と書くようにすることで、
int* a; と a = ptr; が最初のと同様の見方が出来るからじゃないの？

宣言時の *a と代入時の *a では
括弧を省略できるため見た目同じでも
意味するところは異なるのが原因だと思うけど...

代入時は *(a) とでもする？

60:デフォルトの名無しさん
04/10/02 18:51:41
int* a, b, c;

61:デフォルトの名無しさん
04/10/02 18:59:02
>>59
>宣言時の *a と代入時の *a では
>括弧を省略できるため見た目同じでも
>意味するところは異なるのが原因だと思うけど...

アフォ。
ではこれをどう説明するんだよ。

int a[] = {123, 345, 567};

62:デフォルトの名無しさん
04/10/02 19:35:01
今時int *aなんて書いてるのはおっさんCプログラマでしょ。
C++の勉強のためにWebでいろんなコード見てきたけど、ほとんどint* aだよ。
参照もint &aなんて書いてるのかな？

63:デフォルトの名無しさん
04/10/02 19:59:00
昔はint* aだったけど最近はint *aにするようにしてる
昔は単純なプログラムしか組めなかったからどっちでもよかったけど
constとか関数ポインタ、多重ポインタとか使うようになるとint *aのほうが都合がよくなる

64:デフォルトの名無しさん
04/10/02 20:54:19
int * a;
最強。

65:デフォルトの名無しさん
04/10/02 20:58:59
const int*と int const*って違いがよく分からん

66:デフォルトの名無しさん
04/10/02 21:12:49
a[b]とb[a]の違いみたいなもんだ。
俺はint constだけど、世間一般ではconst intのほうが主流かな。

67:デフォルトの名無しさん
04/10/02 21:31:14
constの位置が違うと全然違う意味だから

68:デフォルトの名無しさん
04/10/02 21:34:13
>>67
（・∀・）ﾆﾔﾆﾔ

69:デフォルトの名無しさん
04/10/02 21:41:47
char *const
char const*

70:デフォルトの名無しさん
04/10/02 21:42:38
最強は
char const * const

71:デフォルトの名無しさん
04/10/02 21:44:38
最強はvoid const*だろ

72:デフォルトの名無しさん
04/10/02 21:48:03
int *a,b,c;
決定

73:デフォルトの名無しさん
04/10/02 22:59:11
>>70
> 最強は
> char const * const

だな。const char * const だと、どうしてよ？って思っちゃうし。

74:デフォルトの名無しさん
04/10/03 01:04:37
突然ですが、三項演算子
(cond)
　? foo
　: bar;
です。ハテナとコロンは揃えます。
いじょ。

75:デフォルトの名無しさん
04/10/03 01:08:22
3項演算子って結局はif文と同じコンパイル結果になるから、一行で書かないなら
if文で書いた方がわかりやすいと思う。
3項演算子の利点は一行で最小限の文字数で書けるところだと思っているけれど。。

76:デフォルトの名無しさん
04/10/03 01:13:19
俺もそう思う。

77:デフォルトの名無しさん
04/10/03 01:24:24
if-else文と違って値を返すのが三項演算子の特徴なんじゃないの？
フロー制御だけならif-elseでいいけど。

78:デフォルトの名無しさん
04/10/03 01:27:58
値を返すならなおさら一行で書かないとややこしくなる気がする…

79:74
04/10/03 01:47:19
失礼。値は返します。
一列だとコロンが埋もれてしまい見た目に探すのがつらいです。
（異論あるんだろーな。。）

80:デフォルトの名無しさん
04/10/03 01:59:37
>>74
> です。ハテナとコロンは揃えます。

演算子の記号が行先頭にくるように改行するのはGNUコーディングスタンダードの
条件文の書き方に通じるものがあるね。
if (condA
&& condB
&& condC)
ってやつ。

81:デフォルトの名無しさん
04/10/03 08:02:51
>>42

> int型のポインタとint型を同じ行で定義する
間違い。

>>45
最悪。

82:デフォルトの名無しさん
04/10/03 09:03:09
>>45
最高。

83:デフォルトの名無しさん
04/10/03 09:17:54
>>77
禿同
値を使わないのなら三項演算子ではなく if-else を使うべし。
値を使う場合、if-else で書いた場合についても考えてみて、
複雑さが同程度だったら if-else を使う方が好ましい。

84:デフォルトの名無しさん
04/10/03 09:31:48
代入する値をわける場合とか、
if だと分岐したとき代入し忘れがあって怖い。
?:なら確実に代入できるので極力?:にしてる。
長くなりそうなら関数に抜き出して?:でディスパッチする。

checkstyle で使うなと起こられるのがつらい。

85:デフォルトの名無しさん
04/10/03 09:49:14
printf("....%c", .... eol?'\n':',');
みたいな使い方は？

86:デフォルトの名無しさん
04/10/03 10:03:58
>>85
便利だよねえ。

87:デフォルトの名無しさん
04/10/03 10:18:19
三項演算子使わないとreturnが増殖したりする所で使わないのはアフォだ

88:デフォルトの名無しさん
04/10/03 10:20:01
引数が長いときは
rhs.assign(
　　　　make_transform_iterator(lhs.begin(), thef)
　　　,　make_transform_iterator(lhs.end() , thef));←最後の「);」これをここにいつも書いてんだけどどうよ？

vector< vector<int> >←「vector<int>>」のエラー対策の為に空けるスペースを先頭にも空けるて揃えるのがお気に入り。

89:デフォルトの名無しさん
04/10/03 10:23:41
漏れなら
rhs.assign
(
　　make_transform_iterator(lhs.begin(), thef),
　　make_transform_iterator(lhs.end() , thef)
);

90:デフォルトの名無しさん
04/10/03 10:24:40
でも引数2個くらいなら
rhs.assign(make_transform_iterator(lhs.begin(), thef),
　　make_transform_iterator(lhs.end() , thef));

91:デフォルトの名無しさん
04/10/03 10:41:10
ぶっちゃけ、*の位置や改行なんかどうでもいい。
変数・関数名やスコープの最小化のほうが重要。

92:88
04/10/03 10:44:01
>>89
最初そう書こうかなと考えたこともあったんだけど
やたらと空白が目立って全体を眺めたら関数名との繋がりが希薄にかんじて････却下したんですよね。

>>90
それでも悪くは無いんですけど、
make_の開始位置が上と下じゃ揃わないから途中から書くのをやめました。ここじゃズレてましたけど・・・

最後の「));」を「) );」こうしてもいいですけどなんかしっくりこないんですよね。
じゃ改行か？と言ったら>>89に言ったような美徳センスが付きまとっていまいちなんですよね。

やっぱり個人差なのかな。

93:デフォルトの名無しさん
04/10/03 10:45:52
>>91
お前はナ。

94:デフォルトの名無しさん
04/10/03 10:53:17
URLﾘﾝｸ(www.01-tec.com)
ここを参考にしながら書くのがよろしいかと

95:デフォルトの名無しさん
04/10/03 10:55:46
>>94に書いてあった
ブラケットでスコープわけって普通に使われてんの？

func()
{
　{
　　int a, b;

　}

　{
　　int c;

　}
}

96:デフォルトの名無しさん
04/10/03 11:10:26
>>95
俺は普通に使ってるけど

97:デフォルトの名無しさん
04/10/03 11:12:46
私もふつうに使っていますよ

98:デフォルトの名無しさん
04/10/03 11:16:30
ほんとだ。スコープ分けてるＹｏ。
96 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 11:10:26
>>95
俺は普通に使ってるけど

97 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 11:12:46
私もふつうに使っていますよ

99:デフォルトの名無しさん
04/10/03 11:16:46
わたくしも使っております　　　　（21歳　家事手伝い）

100:デフォルトの名無しさん
04/10/03 11:17:22
また山崎か。

101:デフォルトの名無しさん
04/10/03 11:18:43
>>95
普通だけど、私は使っていない

102:デフォルトの名無しさん
04/10/03 12:39:59
クラシックCの場合
int get_hoge_fuge(args...)
みたいな関数の命名ですが、特にget,setで始まる場合は
アンダースコア _ 入れるかどうか迷うんですよね。
私はいちおう「入れる派」なんですが
ライブラリにあるやつとか ex.) getchar, gethostbyname, ...
のきなみ続けて次の単語書いちゃってるし、
外は雨降りだし、Javaの人はいいなぁって思う今日この頃。

103:デフォルトの名無しさん
04/10/03 12:52:27
getHogeFugeって書けば解決

104:デフォルトの名無しさん
04/10/03 12:56:21
Shift同時押しは微妙にタイプ速度を下げるので大文字禁止、アンダーバーも禁止。
括弧は仕方が無いがもっと打ちやすいところにほしい。

105:デフォルトの名無しさん
04/10/03 12:59:47
>>104
シフトキーを使うのも億劫になる程の
タイピング量が必要になるコードの方を
まずは禁止すべきだな。

106:デフォルトの名無しさん
04/10/03 13:34:56
>>103
ラクダ記法はJavaコーディングスタイルだったっけ。

107:デフォルトの名無しさん
04/10/03 13:40:37
コメントの
/*
*
*/
と
/*
　*
　*/
どっち？
アスタリスクが縦に揃うほうがいいなあ。

108:デフォルトの名無しさん
04/10/03 13:48:33
>>107
CやC++ではDoxygenに対応したコメント記法をするのが良いと思います。
後でDoxygenにかけることも考慮して。

109:107
04/10/03 13:57:08
>>108
doxygenって初めて知ったよ！
いいじゃん！
俺もこれからそうする！！

110:デフォルトの名無しさん
04/10/03 14:24:57
>>107
/*
comment
*/

Doxygen なら

/*!
\brief comment
*/

111:デフォルトの名無しさん
04/10/03 14:25:25
スペースが抜けてた
/*
　　comment
*/

Doxygen なら

/*!
　　\brief comment
*/

112:デフォルトの名無しさん
04/10/03 14:29:41
doxygenはjavadocスタイルの方が宮須行きがする。
\や!より@の方が目に優しい気がするような気がしないでもないかもしないかな、という気がした気がした。

113:デフォルトの名無しさん
04/10/03 15:00:36
自分も＠派。
JISだと'￥'になるのが悪いのかな。
'＼'なら'／'との組み合わせで見やすいのかも。

114:デフォルトの名無しさん
04/10/03 15:06:34
日本以外の人たちって \ が＼なんだよな・・・。
目立たないし、文字列のなかでエスケープに使われてると激しく見にくくないかな・・・。

115:デフォルトの名無しさん
04/10/03 15:28:36
>>114
慣れるとそうでもない。TeXとか使っていると\の方が違和感があるかも

116:デフォルトの名無しさん
04/10/04 01:52:56
visualC++もバックスラッシュだよね（？）
確か...？

117:デフォルトの名無しさん
04/10/04 17:15:41
\よりもバックスラッシュのが好きだなあ。
特にパスの区切り文字としては見た目、\より直感的な気がします。
Win では \\ の代わりに / もパスの区切り文字として
使えるんですよね。タイプが楽だし気に入っているんだけど
ソースのポータビリティを考えたら、使わんほうがいいんでしょうね…。

118:デフォルトの名無しさん
04/10/04 17:50:38
>>117
一部のAPI（PathXXX系）が対応してないから使わないほうが無難だね。
Perlとかだと /＼r＼n/＼n/ とか読みにくくね？

119:デフォルトの名無しさん
04/10/04 20:35:15
別に読みにくくないよ?
日本のユーザ以外は皆バックスラッシュなわけだし。
むしろ、￥に慣れた人が英語情報を見るとそんなとこでもひっかかったりして
余計にとっつきが悪くなるんじゃないかと変な心配してしまうんだけど。

Unicodeで文字コード世界統一のはずなのに、日本だけ世界と一部違うものが
Unicodeとされているというのもなんだか悲しいよう。

120:デフォルトの名無しさん
04/10/04 21:11:37
為替レートとか外国で表示するとき\どうしてんだろう？

121:デフォルトの名無しさん
04/10/04 21:25:59
大体の場合0xA5がYEN　SIGNだから、

122:デフォルトの名無しさん
04/10/04 22:07:37
今に至っては\の役割はもう無いね。
これからはバックスラッシュに変えていくべきだと思うんだけど。

123:デフォルトの名無しさん
04/10/05 02:24:18
Unicode?
たんにフォントの問題だろ

124:デフォルトの名無しさん
04/10/05 02:28:44
文字集合。

125:デフォルトの名無しさん
04/10/05 04:33:16
0x5CがYEN SIGNとして使われてしまうのはフォントの問題では済まないよ。

そのように使われないならその問題なくて
「日本人はなぜかバックスラッシュが見たくもないほど嫌いらしい。
どれくらいかというとバックスラッシュの代わりに円記号を表示させるくらい
嫌いらしい。」という程度の話になるけど。

126:デフォルトの名無しさん
04/10/05 05:53:06
アホですな。

127:デフォルトの名無しさん
04/10/22 02:31:16
みなさん、キャストは、

static_cast とか、reinterpret_cast　とか、使ってますか？

C++的に言えば、使った方がいいんだが、どう考えてもCキャストのほうが読みやすい。

128:デフォルトの名無しさん
04/10/22 03:41:06
使ってはいる。けれども同意。

129:デフォルトの名無しさん
04/10/23 02:08:15
>>127
Cスタイルキャストは禁止してる。
理由は以下のとおり。
・Cスタイルキャストは強力すぎる
・Cスタイルキャストは見つけにくすぎる
・Cスタイルキャストは dynamic_cast できない

ちなみに、どう考えたらCスタイルキャストのほうが読みやすいことになるのかわからない。

130:デフォルトの名無しさん
04/10/23 02:47:22
書きにくいってのならわかるね。
字数多いし。むしろ書きにくいから(ry

131:デフォルトの名無しさん
04/10/23 09:23:45
Cスタイルキャストに警告を出すコンパイラってあるかね？

132:デフォルトの名無しさん
04/10/23 11:17:07
あるよ。

133:デフォルトの名無しさん
04/10/26 23:47:46
dynamic_castをほとんど使ったことがない俺は
たぶん何か間違ってるんだと思う。

134:デフォルトの名無しさん
04/10/26 23:54:04
>>133
そんなことないと思う。
C++ の危険な領域に入り込んでいない健全な姿だよ。

135:デフォルトの名無しさん
04/10/27 01:16:55
キャストなんて使わないで済ますのが一番。
dynamic_cast の出番は、時間さえあれば設計を見直すべきところがほとんど。

136:デフォルトの名無しさん
04/11/17 15:23:26
protected データメンバを宣言してはいけない
------------------------------------------------------------
ルールの理由:
private ではなくprotected としてデータメンバを宣言すると、
メンバ関数中にカプセル化できたはずのメンバが派生クラスから見えてしまいます。

例
//
// protected データメンバを宣言してはいけない
//
class A
{
　　protected:
　　int i; 　　// 違反
};

137:デフォルトの名無しさん
04/11/17 16:08:10
>>136
素人でつか？

138:デフォルトの名無しさん
04/11/17 16:21:57
>>136
「俺様ルールの違反」とちゃんと書け。

139:デフォルトの名無しさん
04/11/17 16:40:47
コンストラクタから直接グローバルデータにアクセスしてはいけない
--------------------------------------------------------------------------------

ルールの理由:
異なるコンパイル単位中の静的オブジェクトの初期化順序は、
C++ の言語定義では定義されていません。
そのため、コンストラクタからグローバルデータへのアクセスは、
未初期化オブジェクトからの読み取りになる場合があります。

例
//
//　コンストラクタから直接グローバルデータにアクセスしてはいけない
//

int a;
class A
{
public:
　　A();
private:
　　int b;
};
A::A()
{
　　b = a; // 違反
}

140:デフォルトの名無しさん
04/11/17 21:16:46
かわいく書く。

for(i=0; i<100; i++){　　// 100回がんばる

}

141:デフォルトの名無しさん
04/11/17 21:37:06
かわいくに反応して“がんばる”が…くそっ俺の脳みそがぁぁ

かわいいじゃねぇか

142:デフォルトの名無しさん
04/11/17 22:25:44
>>129
const void *p;
const_cast<int *>(static_cast<const int *>(p));
こんなんだったらCスタイルキャストの方が読みやすいかもしれない

143:デフォルトの名無しさん
04/11/17 22:31:40
>>129
画像演算とか。
一つの式中にキャストが10個くらい現れたりする。
C++キャストでは長すぎて意図が分からなくなってしまう。
const_castはさすがにCキャストで代用しようとは思わないが、
PODに対するreinterpret_castやstatic_castはCキャストのほうが分かりやすい時もある。

144:デフォルトの名無しさん
04/11/18 00:54:49
>>142-143
カッコ悪いプログラムがカッコ悪いソースになる。それがいいんじゃねぇか。

145:デフォルトの名無しさん
04/11/18 03:37:33
>>139
いずれにしても a の初期化し忘れ。

146:デフォルトの名無しさん
04/11/18 10:06:12
>>145
aは0で初期化される

147:デフォルトの名無しさん
04/11/19 23:20:36
コボラーと大してレベル変わらんなお前ら

148:デフォルトの名無しさん
04/11/19 23:52:23
int *a, *b; // ポインタ
int a, b;

これ最強

149:デフォルトの名無しさん
04/11/20 20:28:56
C++ の const Class & や Class* は必ず typedef してから使う。

typedef const Class & ClassRef;
typedef Class* ClassPtr;

150:デフォルトの名無しさん
04/11/21 06:52:22
>>149
ウザ

151:デフォルトの名無しさん
04/11/21 10:12:08
二重インクルードヘッダーは、
"__" + プロジェクト名＋ファイル名
にする。

【例】
HelloWorld プログラムの Hello.h ファイルは、
#ifndef __HELLOWORLD_HELLO_H
#define __HELLOWORLD_HELLO_H
...
#endif
とする。

152:デフォルトの名無しさん
04/11/21 10:33:02
何が言いたいんだ…？
文句を言いたいのか、上記のように統一しろと主張しようとしてるのかわからんぞ

153:デフォルトの名無しさん
04/11/21 10:46:19
>>151
ISO/ANSI規格では識別子の初めに _ が2つ続く物はコンパイラ・ライブラリ関数のために予約されているので駄目だ。

154:デフォルトの名無しさん
04/11/21 11:27:42
>>153
"_" がふたつだけじゃなくて、ひとつでも予約されてるんじゃなかったっけ？
(つまり "_" で始まる名前はすべて標準ライブラリ用に予約されてる)

155:デフォルトの名無しさん
04/11/21 11:51:19
漏れのインクルードガードは、ファイル名 (ピリオドを '_' に
変換したもの) + '_' だな。大文字/小文字はそのまんまだ。

　#ifndef MotherHacker_h_
　#define MotherHacker_h_

ここで気になるのが #endif なんだけど

　a. #endif // !MotherHacker_h_　( '!' あり )
　b. #endif // MotherHacker_h_　( '!' なし )
　c. #endif　　( なんもなし )

てめーらはどれ派？
漏れは昔は c.，以前は b. だった。でも今は a. 派。

156:デフォルトの名無しさん
04/11/21 12:10:00
漏れは
#ifndef MOTHER_HACKER_H__
#define MOTHER_HACKER_H__

#endif// MOTHER_HACKER_H__

最後の_が２つなのがミソ

157:デフォルトの名無しさん
04/11/21 12:38:30
>>154
本当だ。
今まで'_'の次に英大文字か'_'の場合だけが予約かと思っていた

158:158=157=153
04/11/21 12:41:55
>>156
インクルードガードのときだけ例外的にb派。
#ifdef HOGEに対しては#endif // defined HOGEとしている。

159:デフォルトの名無しさん
04/11/22 00:07:48
漏れは
#endif // !defined( _suffix_hoge_h_included_ )

160:デフォルトの名無しさん
04/11/22 02:18:33
漏れは//にスペース入れない
　　#ifndef MotherHacker_h_
　　#define MotherHacker_h_
　　#endif//MotherHacker_h_
なぜって識別子の位置が揃うから

161:デフォルトの名無しさん
04/11/22 03:21:50
>>160
> なぜって識別子の位置が揃うから
うーん、気持はわからなくはないけど。
#elseや#endifに条件式をコメントとして入れとくのは、そもそも#ifの位置が
遠く離れてて把握できなくても条件式をすぐに理解できるようにするためでしょ？
そんな状況なら桁の位置が揃ってるかどうかなんて、どうでもいいと思うんだけど。
桁揃えが気になるような距離なら、そもそも条件式をコメントに書かなくてもいいし。

162:デフォルトの名無しさん
04/11/22 10:14:40

163:デフォルトの名無しさん
04/11/23 17:04:27
>>156
残念だがそのミソは予約されている。

164:デフォルトの名無しさん
04/11/23 20:52:14
【規約】
プリプロセッサ命令は #if や #ifdef の中ではインデントさせる。
ただし # は必ず行頭に配置せよ。

例：
#ifdef HOGE
# include <hoge.h>
# ifdef FOO
#　　#include <foo.h>
#endif
#endif

165:デフォルトの名無しさん
04/11/23 20:56:26
>>164 なんで？なんかいいことあるの？

166:デフォルトの名無しさん
04/11/23 20:57:35
入れ子が複雑になっても、読みやすい、修正しやすい。
入れ子をベタで書くのはよくない作法だろ。

167:デフォルトの名無しさん
04/11/23 21:07:49
>>164
↓こんなんも、#だけ行頭に動かすの？
{
　while(...)
　{
　　if(...)
　　{
　　#if HOGE
　　　...;
　　#endif
　　　...;
　　}
　}
}

168:デフォルトの名無しさん
04/11/23 23:12:29
1カラム目以外に'#'があるとディレクティブと見做さないコンパイラがあったなぁ。

169:デフォルトの名無しさん
04/11/24 19:40:17
基本的に if 文は>>5のスタイルで書いているがキモいのか・・・？
>>7や>>14も嫌いではない。

170:デフォルトの名無しさん
04/11/24 20:01:33
俺は14の方がキモいと思う。
同じく普段は5を使っているが、行数制限があるときは7スタイルも使う。

171:デフォルトの名無しさん
04/11/24 20:04:22
このあたりはもう好みの問題でしょ。
個人的には>>14で書いてる。
>>5は、if の次に { だけの行がくるのがスカスカな感じでちょっといや。

172:デフォルトの名無しさん
04/11/24 22:49:23
>>5 のスタイルの方がネストしたときの括弧の対応がわかりやすいと思うけどなぁ・・・

Windows 2000 のコードとか、FFFTP なんかは、 >>5 のスタイルで書かれてるね

まぁ、>>14 の書き方でも絶対に間違わないって言う地震があるのならいいんじゃないの

好みの問題

173:デフォルトの名無しさん
04/11/24 22:51:59
私は>>7だな。

174:デフォルトの名無しさん
04/11/25 13:50:53
つまり>>5のやつが言葉を間違えたんだろ。キモイは言いすぎ。好みの問題でしかない。
俺は>>14だが。

175:デフォルトの名無しさん
04/11/25 20:13:12
>>14はなんだか中途半端な気がして、気持ち悪い。
なんか、切れそうで切れない生首のような、ほとんど首無しニックのような、気持ち悪さ。

176:デフォルトの名無しさん
04/11/26 14:38:36
>>5使ってるよ。

177:デフォルトの名無しさん
04/11/26 14:52:04
>5も好きじゃないんだが、
if (...)
　{
　　...;
　}
else
　{
　　...;
　}
って書かれるとどうもね。
#2段も下げるなって感じ?

178:デフォルトの名無しさん
04/11/26 14:59:41
>>177
GNUスタイルですな。慣れればいいのかもしれないが、

俺は>>7でタブは8カラム。以前までタブでなくスペース派
だったんだが、今はまあいいかなと思えるようになった。
タブを行頭にしか使わなければ環境依存も(ある程度)
許容できるし。

179:デフォルトの名無しさん
04/11/26 17:58:51
TABを使ったソースを別の環境で見たときに見た目が違うということがあっても
別に大した問題ではないだろう。
TABをスペースに置き換えるなんてエディタの機能で一発だったりするでしょ。
手間は大したこと無いから全然気にしないで、自分の環境で一番やりやすいやりかた
ですれば良いと思うよ。

180:デフォルトの名無しさん
04/11/29 23:35:29
CodeWizard とかの静的解析ツール使えばいいんじゃないの

181:デフォルトの名無しさん
04/11/30 01:45:33
流儀違うとCVSに落としたりするとき困るよな
全部2TAB→スペース変換してコミット

182:デフォルトの名無しさん
04/12/02 00:19:30
>>45 は

*(int *)&a

じゃないのか？

183:デフォルトの名無しさん
04/12/02 08:39:54
>>182
それじゃ a と同じになっちゃうだろ。

184:デフォルトの名無しさん
04/12/02 18:12:23
長いprintfのカンマは左側に書く。

printf(
"compless : %s\n"
"code : %xh\n"
"codesize : %xh\n"
"entry offset : %xh\n"
"begin offset : %xh\n"
"end offset : %xh\n"
,isompless?"true":"false"
,code
,codesize
,main_entry
,begin_entry
,end_entry
);

185:デフォルトの名無しさん
04/12/02 18:56:09
printfに限らず俺はインデントした上で右側にカンマ付けるけどな。
こうしている人の方が多いと思っているし。

186:デフォルトの名無しさん
04/12/03 18:44:42
継続行はCodeCompleteに倣って演算子を右に書く。

全体はApacheスタイルに近い。
タブは4カラムで、スペースじゃないけど。

187:デフォルトの名無しさん
04/12/08 09:12:31
ここは重複スレです

Cのマナーいろいろ
ｽﾚﾘﾝｸ(tech板)

188:デフォルトの名無しさん
04/12/08 09:17:24
>>187
仕切り厨ウザイ

189:デフォルトの名無しさん
04/12/08 09:31:06
こいつぼけ

190:デフォルトの名無しさん
04/12/08 10:21:59
>>189
おまえがな。

191:デフォルトの名無しさん
04/12/13 04:22:13
voidで返す関数はreturn書く？

192:デフォルトの名無しさん
04/12/13 04:35:34
voidで返す?

193:デフォルトの名無しさん
04/12/13 04:49:17
C++ならreturn void;

194:デフォルトの名無しさん
04/12/13 04:50:45
返り値がvoidならreturnは省略した方がコードが短くなって読みやすくなると思うんだけど。

195:デフォルトの名無しさん
04/12/13 05:17:00
そもそも値を返さないのがvoid

196:デフォルトの名無しさん
04/12/13 22:29:28
>>191
条件 return の場合以外書かない。

197:デフォルトの名無しさん
04/12/16 23:24:30
>>191
関数であると明確にするために、書いておく。

198:デフォルトの名無しさん
04/12/16 23:25:42
関数以外のものがあるわけじゃないのに…

199:デフォルトの名無しさん
04/12/16 23:47:17
pascalの癖が抜けないんだろう

200:197
04/12/17 03:16:35
>>199
悪いが、Pascalなんぞやったことないんだが。

201:デフォルトの名無しさん
04/12/17 03:24:20
>>200
無学を自慢するな

202:デフォルトの名無しさん
04/12/17 03:25:12
じゃ、VBか。

203:デフォルトの名無しさん
04/12/17 03:26:55
そもそも返り値がvoidの関数を作る事自体が間違えなんじゃないの？
処理は全部副作用だけなんて…

204:197
04/12/17 03:33:40
>>201
どこがどう自慢だったんだね？
むしろ謝っているとしか言えないが。

205:デフォルトの名無しさん
04/12/17 03:38:25
>>204
石黒級の馬鹿だな。まず日本語をなんとかしろよ。

206:デフォルトの名無しさん
04/12/17 03:46:05
>>205
何か日本語の使い方でおかしいところなんてあったか？
お前こそなんとかして反論しようとして
無理やり絞り出したようにしか見えんな。

207:デフォルトの名無しさん
04/12/17 03:57:40
もまいらもちつけ

208:デフォルトの名無しさん
04/12/17 04:03:40
低級な言い合いは止めてくれ

209:デフォルトの名無しさん
04/12/17 04:16:36
アセンブリはやっておくべきだよ

210:デフォルトの名無しさん
04/12/17 04:21:58
>>209
うまい

211:デフォルトの名無しさん
04/12/17 05:33:41
mov ax, 4c00h
int 21h

212:デフォルトの名無しさん
04/12/17 05:42:25
>>206
それ本気で言ってる？
もう必死すぎだなｗ

213:デフォルトの名無しさん
04/12/17 07:24:00
>>212
あまり強く言いすぎると、釣りってことにして逃げちゃって興醒めだよ。
真綿で首を絞めるみたいにイジらないと。

214:デフォルトの名無しさん
04/12/17 09:20:59
>>213
多分それ以前に>>212が釣りなんでは

215:デフォルトの名無しさん
04/12/17 09:21:21
そういうことは真綿で首を絞めてから言ってくれ。

216:デフォルトの名無しさん
04/12/17 09:38:18
日本語って言うならおれは>>203が気になるな。他でも見るが
「間違い」だろ？

217:デフォルトの名無しさん
04/12/17 12:06:40
>>216
本人だが同意

218:デフォルトの名無しさん
04/12/17 12:22:36
>>217
単純にtypo?

219:デフォルトの名無しさん
04/12/17 19:49:43
「Pascal やったことないと無学」ってことにしたい >>201 が
キチガイだったということで。

220:!=201
04/12/17 22:41:14
そりゃ無学だろ

221:デフォルトの名無しさん
04/12/17 23:06:33
URLﾘﾝｸ(www.page.sannet.ne.jp)
たまたま見つけた最悪なコードの見本。

222:デフォルトの名無しさん
04/12/17 23:09:32
アセンブラやったことないよ
パスカルやったことないよ
スクイークやったことないよ
シーシャープやったことないよ
セックルやったことないよ

一番ダメなプログラマーはどれ？

223:& ◆QWv3R1XL8M
04/12/17 23:11:52
１５日C++とSTLとテンプレ使えるようになる苦行教えてくれ。
耐えて、使えるようになりたい。

224:デフォルトの名無しさん
04/12/17 23:12:25
>>223
AC++というつまらない本を熟読する

225:デフォルトの名無しさん
04/12/17 23:24:40
>>222
パスカルやったことないよ

226:デフォルトの名無しさん
04/12/17 23:38:50
Ruby知らないというのは致命的・

227:デフォルトの名無しさん
04/12/17 23:43:08
>>224
MC++ はどう？

228:デフォルトの名無しさん
04/12/18 01:10:52
pascalが何の単位か分からない奴は無学

229:デフォルトの名無しさん
04/12/18 01:32:21
ヘクトパスカル？

230:デフォルトの名無しさん
04/12/18 01:35:44
>>229
メガバイトって言っているのと同じだよ

231:874
04/12/18 15:54:20
>#define unint unsigned int /* 型名の別名を定義します。 */
>#define unlong unsigned long

ﾜﾛﾀ

232:デフォルトの名無しさん
04/12/18 16:16:00
>>221、>>231のサイトって、中学生に教えている積もりなのか?
余りに痛々しいんだが。

233:デフォルトの名無しさん
04/12/21 00:22:46
ｋ

234:デフォルトの名無しさん
04/12/21 00:47:17
switch～caseのインデントってどうしてる？
俺は

switch(n){
case 0:
　　cout << "0" << endl;
　　break;
default:
　　break;
}

caseとswitchのインデントレベルは同じにしてるけど。

235:デフォルトの名無しさん
04/12/21 02:55:19
>>234
タブを４として、スペース２個を入れる。

236:デフォルトの名無しさん
04/12/21 04:57:49
>>235
K&Rと同じにしてる。
つまり同じレベル。

237:デフォルトの名無しさん
04/12/21 06:01:18
同じにしてる。
基本的にインデントが一気に2段下がることが無いように頑張っている

238:デフォルトの名無しさん
04/12/22 00:36:28
俺は>>235と同じだな。

239:デフォルトの名無しさん
04/12/24 15:14:41
switch(n)
{
case 0:
　　cout << "0" << endl;
break;
default:
break;
}

240:デフォルトの名無しさん
04/12/24 17:47:57
俺はこう。
switch (n) {
case FOO:
　　foo();
　　break;

case BAR: {
　　int x = bar(n);
　　baz(x);
　　break;
}

default:
　　/* NEVER REACH HERE */
　　abort();
}

241:デフォルトの名無しさん
04/12/24 18:45:23
switch (n)
{
case FOO:
　　foo();
　　break;

case BAR
　　{
　　　　int x = bar(n);
　　　　baz(x);
　　　　break;
　　}
}
俺のスタイル。

242:デフォルトの名無しさん
04/12/25 13:37:04
switch (n)
{
case FOO:
　　foo();
　　break;

case BAR
　　{int x = bar(n);
　　baz(x);
　　break;
　　}
}
俺のスタイル。

243:241
04/12/25 18:46:13
そう言えばswitchとclassのインデントの付け方は同じになっている。

244:デフォルトの名無しさん
04/12/25 23:17:43
>>243
それがpublic、protected、privateのことなら俺も同じ。

245:デフォルトの名無しさん
05/01/30 14:52:51
b

246:デフォルトの名無しさん
05/02/03 22:24:32
switch (...) {
　case 1 : {
　　foo();
　} break;
　case 2 :
　case 3 :
　case 4 : {
　　foo();
　} break;
　case 5 :
　　foo();
　　// Fall Through
　default : {
　　foo();
　} break;
}
俺のスタイル。
switchは滅多に使わんがなー

247:デフォルトの名無しさん
05/02/04 20:26:43
↑馬鹿発見

248:デフォルトの名無しさん
05/02/04 20:31:31
>>246
そうかそうか、それは素晴らしい書き方だな。よーくわかったぞ。

249:デフォルトの名無しさん
05/02/27 15:11:54
>>247-248
必死だなｗｗｗｗ

250:デフォルトの名無しさん
05/03/02 12:56:35
switch (n)
{
case FOO:
　　foo();
　　break;
case BAR
{
　　int x = bar(n);
　　baz(x);
}
　　break;
}

251:デフォルトの名無しさん
05/03/05 03:57:03
>>250
おお、なんと感動的な書き方なんだ。正直、俺は感動した。

252:デフォルトの名無しさん
05/03/05 19:25:32
俺スタイルは>241に酷似。

switch (n)
{
case FOO:
　　foo();
　　break;

case BAR:
　　// baz(int&) の引数のために実体となる変数が必要 ← みたいに、なんかコメントしとく
　　{
　　　　int x = bar(n);
　　　　baz(x);
　　}
　　break;
}

253:デフォルトの名無しさん
05/03/06 00:00:51
漏れは>>250に似てるけどこうかな
switch(n)
{
case FOO:
{
　　foo();
　　break;
}
case BAR:
{
　　int x = bar(n);
　　baz(x);
　　break;
}
　　
}

254:デフォルトの名無しさん
05/03/06 03:32:58
禿は禿本で
case FOO:
　　　　foo();
　　　　break;
case BAR: {
　　　　int x;
　　　　bar();
　　　　break;
}
こう書いてたっけ？
個人的には{で改行しない方が若干見やすいかなぁ

255:デフォルトの名無しさん
05/03/08 00:16:03
いまやC++は(boostの)シリアライズを持っているので
メンバ変数にhoge_と尻尾に_を付けるのではなく
一時変数に_を付ける
spiritのサンプルにあった。
メンバに堂々と何もつけないのはなかなか気持ちがよいな

256:デフォルトの名無しさん
05/03/08 00:45:46
>>255
> 一時変数に_を付ける

激しく受け入れ難い。

257:デフォルトの名無しさん
05/03/08 19:00:08
てかメンバもローカルも_無しでよくね？

258:デフォルトの名無しさん
05/03/08 20:56:40
↑禿同
this->が付いてたらメンバ。

259:デフォルトの名無しさん
05/03/09 06:37:01
>>258
技術的なメリット、デメリットでは this-> が最強なんだよな。
・クラステンプレートのコードでは付けないと恐ろしい罠に嵌りかねない。
・bool Is～() な関数を自分で呼ぶときも this->Is～() が読みやすい。
・無節操にメンバに触りまくって最適化を台無しにする糞コードが減る。

問題は、一般性が皆無なことだな。

this-> と等価な . （単項ドット演算子）を作って、
省略不可にすれば、・・・どうなっていただろう？

次ページ