コーディングスタイルにこだわるスレ
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2007/10/28(日) 15:59:01 コーディングスタイルについて熱く語れ
2007/10/28(日) 17:27:51
http://www.google.co.jp/search?q=%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B9%E3%82%BF%E3%82%A4%E3%83%AB&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_jaJP229JP231
コーディングスタイルに意味があるとしたらそれはプロジェクト内で統一することのみで
どう決めるかはまったく問題ではない。
もちろん一定以上の知的水準と経験を持った人間が決めればの話だが。
コーディングスタイルに意味があるとしたらそれはプロジェクト内で統一することのみで
どう決めるかはまったく問題ではない。
もちろん一定以上の知的水準と経験を持った人間が決めればの話だが。
2007/10/28(日) 17:33:54
goto奨励
2007/10/28(日) 18:00:20
>>17
> コーディングスタイルに意味があるとしたらそれはプロジェクト内で統一することのみで
誤読してるかもしれないが、コーディングスタイルの意義として、プロジェクト内でのスタイルの統一しかない
ということであれば、それに全く同意できない。
まず、可読性ありき。
> コーディングスタイルに意味があるとしたらそれはプロジェクト内で統一することのみで
誤読してるかもしれないが、コーディングスタイルの意義として、プロジェクト内でのスタイルの統一しかない
ということであれば、それに全く同意できない。
まず、可読性ありき。
2007/10/28(日) 18:44:05
もしコーディングスタイルを決める意義が「統一することのみ」だったら、
「一定以上の知的水準と経験を持った人間」が決める必要さえないしな。
「一定以上の知的水準と経験を持った人間」が決める必要さえないしな。
2007/10/28(日) 18:53:14
それじゃあ、変数名いってみようか。
ハンガリアン記法はクソ。
変数定義の箇所に型情報は記述されており、
適切に実装されたスコープ内では充分に目に付く。
型情報をたどれないほどに変数定義から離れた変数は、
同時に関数などのクソ設計を匂わせており、クソ。
ハンガリアン記法はクソ。
変数定義の箇所に型情報は記述されており、
適切に実装されたスコープ内では充分に目に付く。
型情報をたどれないほどに変数定義から離れた変数は、
同時に関数などのクソ設計を匂わせており、クソ。
2007/10/28(日) 18:57:04
>>21
ttp://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B
ttp://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B
2007/10/28(日) 19:04:11
> アプリケーションハンガリアン
> システムハンガリアン
シモニイすまんかった(´;ω;`)
> システムハンガリアン
シモニイすまんかった(´;ω;`)
2007/10/28(日) 19:20:22
>>22
またMSがいらんことを・・・
またMSがいらんことを・・・
25デフォルトの名無しさん
2007/10/28(日) 19:27:55 1、2、ハンガリアン!
2、2、ハンガリアン!
2、2、ハンガリアン!
2007/10/28(日) 19:31:21
>>22
それ読んだとき、めっちゃバグりそうな書き方だとおもったな。
内部で処理するときは、HTMLエンコードしないで処理して、表示のときに一括して、エンコーディングしたほうが
いいと思ったよ。
unsafeとsafeを混在させて処理してたら、いくらネーミングで工夫してもミスるだろって。
それ読んだとき、めっちゃバグりそうな書き方だとおもったな。
内部で処理するときは、HTMLエンコードしないで処理して、表示のときに一括して、エンコーディングしたほうが
いいと思ったよ。
unsafeとsafeを混在させて処理してたら、いくらネーミングで工夫してもミスるだろって。
2007/10/28(日) 19:33:32
>>25 どぅわ〜
2007/10/28(日) 20:22:40
joelなんか糞派登場
2007/10/29(月) 02:29:59
関数名、変数名は6文字以内。
2007/10/29(月) 13:10:06
//char a, *b, *const c, const *d;
char a, *b, *const c;char const *d;
char const *dを続けて宣言できないのが悔しい。
char a, *b, *const c;char const *d;
char const *dを続けて宣言できないのが悔しい。
2007/10/29(月) 19:49:30
考えるときはマンダム
立った時はジョジョ立ち
立った時はジョジョ立ち
2007/10/29(月) 20:24:41
牛乳は瓶の奴しか飲んではいけない。
飲むときは腰に手を当てること。
飲むときは腰に手を当てること。
2007/10/29(月) 21:59:31
2007/10/29(月) 22:11:03
最初の文字がi, j, k, l, m, n の変数は整数型。他は実数。
2007/10/29(月) 22:51:24
36sage
2007/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)
:
hsqscusName (html-safe, sql-safe, command-line-unsafe)
hsquscsName (html-safe, sql-unsafe, command-line-safe)
:
3736
2007/10/30(火) 00:37:04 orz
2007/10/30(火) 00:41:26
2007/10/30(火) 00:43:46
>>38
コードサーチでオプソをググったら腐るほどいた
コードサーチでオプソをググったら腐るほどいた
2007/10/30(火) 03:27:07
ヘアースタイルは7:3厳守。
2007/10/30(火) 05:24:12
エラーコードを解析する時は三白眼、効果音は
┣” ┣” ┣” ┣” ┣” ┣”
┣” ┣” ┣” ┣” ┣” ┣”
2007/10/30(火) 09:17:13
>>38
999:1くらいだと思う。もちろん1の方。
999:1くらいだと思う。もちろん1の方。
2007/10/30(火) 21:37:51
>>38
俺はデキる奴だぜー、と思い込んでるけど実際はそうでもない人が使いそう
俺はデキる奴だぜー、と思い込んでるけど実際はそうでもない人が使いそう
2007/10/31(水) 01:39:14
< とか > とかの向きを揃える目的なら使っちゃだめか?
2007/10/31(水) 02:55:54
定数を左に置くのは、次の場合だけだな。
if (0 < x && x < 100)
本当はif (0 < x < 100)と書きたいけど、書けないのでその代用としてだ。
if (0 < x && x < 100)
本当はif (0 < x < 100)と書きたいけど、書けないのでその代用としてだ。
46デフォルトの名無しさん
2007/10/31(水) 23:03:42 returnやsizeofの後をカッコでくくるかどうかって話はもう出た?
2007/10/31(水) 23:06:40
return の後の括弧は無し
sizeof の後の括弧は有り
sizeof の後の括弧は有り
return はくくらないのにsizeofはくくりたくなるんだよな。。
2007/10/31(水) 23:08:24
習慣っつーか慣用句みたいな感じ
2007/10/31(水) 23:09:44
括弧つけるべきか否か迷う時間が勿体無いので、
なんでも括弧つけることにしてる。
なんでも括弧つけることにしてる。
2007/10/31(水) 23:45:58
return 0; ならいいとしても、return i * 2; みたいになると、括弧で括りたくなる。
2007/10/31(水) 23:52:18
昔、会社のコーディング規約決める時に、returnの後の括弧は無しじゃね?
って言っても、みんな、returnの後は括弧付けるって言って引かないから、
もう、どっちでも良い事にしちゃった。
って言っても、みんな、returnの後は括弧付けるって言って引かないから、
もう、どっちでも良い事にしちゃった。
2007/11/01(木) 00:30:32
実際どっちでもいいし
2007/11/01(木) 00:33:31
>52
燃料投下。
ttp://www.st.rim.or.jp/~phinloda/cqa/cqa6.html#q20
燃料投下。
ttp://www.st.rim.or.jp/~phinloda/cqa/cqa6.html#q20
2007/11/01(木) 07:23:14
やっぱりキチガイは一人だけだったか。
奴が来ないとこんなに静か。
奴が来ないとこんなに静か。
2007/11/01(木) 08:35:41
交差点で100円ひろおったーよー
2007/11/01(木) 21:05:04
ちびまるこちゃんだな。
2007/12/20(木) 03:21:44
なんでもかんでもみんな マスゲームを踊ってるよ
ピョンヤンの丘にはボカッと 巨大な銅像献上
いつだって 忘れない 金日成偉い人 そんなの常識
パッパパラリラ
ピーヒャラピーヒャラ おなかが減ったよー
ピョンヤンの丘にはボカッと 巨大な銅像献上
いつだって 忘れない 金日成偉い人 そんなの常識
パッパパラリラ
ピーヒャラピーヒャラ おなかが減ったよー
2008/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を探さなきゃならんし。
それとも俺がそういうコミニティで育ったからか?
>見てから理解するのに時間がかかる
今更だが、
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を探さなきゃならんし。
それとも俺がそういうコミニティで育ったからか?
2008/01/21(月) 03:46:07
私は三つとも上のほうが読みやすいと感じる。
数字の 0 よりも、フラグとか関数呼び出しのが「大事なこと」だと思う。
コミュニティ次第なんだろうね。
ただ私なら、 3 は
for (;;) {
c = fgetc(stdin);
if ( c == EOF ) break;
...
}
みたいに書く。
数字の 0 よりも、フラグとか関数呼び出しのが「大事なこと」だと思う。
コミュニティ次第なんだろうね。
ただ私なら、 3 は
for (;;) {
c = fgetc(stdin);
if ( c == EOF ) break;
...
}
みたいに書く。
2008/01/21(月) 04:45:23
出力(条件比較や返値)より入力(関数呼出や引数)が「大事なこと」だと思えば上のほう、
if ( hogeHoge( parameter_list ) 〜
入力(関数呼出や引数)より出力(条件比較や返値)が「大事なこと」だと思えば下のほう、
if ( 0 < hogeHoge( 〜
ってところではないかな。
定数と一時変数を使えば
err = hogeHoge( parameter_list );
if ( err == SUCCESS )
2 は 1 の問題に出来るな。
ただし 3 はイディオムなので、私でも>>60のように分解はしないな。
if ( hogeHoge( parameter_list ) 〜
入力(関数呼出や引数)より出力(条件比較や返値)が「大事なこと」だと思えば下のほう、
if ( 0 < hogeHoge( 〜
ってところではないかな。
定数と一時変数を使えば
err = hogeHoge( parameter_list );
if ( err == SUCCESS )
2 は 1 の問題に出来るな。
ただし 3 はイディオムなので、私でも>>60のように分解はしないな。
2008/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( ...
になるね。
"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( ...
になるね。
2008/01/21(月) 08:38:08
定数左に置く人はfor文でもやっぱり左に置くの?
for (i = 0; N > i; ++i) みたいな感じに
for (i = 0; N > i; ++i) みたいな感じに
2008/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 ) って書くん?
気持ち悪くね?
そりゃ不等号の向きによるんでね。if文でも同じやろ。
for( i = 0; i < N; ++i )
for( i = N; 0 < i; --i )
定数右に書く人は"N より大きい"を if ( i > N ) って書くん?
気持ち悪くね?
2008/01/21(月) 10:11:40
それもそうだ。
2008/01/21(月) 10:38:05
>>64
不等号の向きが数直線だと思い込む方がどうかしている。
つまり0より大きいと0より小さいがならぶときに、
if (var > 0) ...;
if (var < 0) ...;
と書くか
if (0 < var) ...;
if (var < 0) ...;
と書くかの違いなわけだが。
例えば、このvarが関数呼び出しになっても後者のように書くということなのだろ?
それが気持ち悪いと思えないなら、私とは相容れない種類の人間だと言うことだ。
不等号の向きが数直線だと思い込む方がどうかしている。
つまり0より大きいと0より小さいがならぶときに、
if (var > 0) ...;
if (var < 0) ...;
と書くか
if (0 < var) ...;
if (var < 0) ...;
と書くかの違いなわけだが。
例えば、このvarが関数呼び出しになっても後者のように書くということなのだろ?
それが気持ち悪いと思えないなら、私とは相容れない種類の人間だと言うことだ。
2008/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 より小さい」。
私はそれぞれ
for ( i = 0; i < N; i++ )
for ( i = N; i > 0; i-- )
if ( i > N )
って書く。
逆は気持ち悪いって感じる。
「 i が N より大きい」をそのまま書いたら i > N でしょ。
N < i は「 N が i より小さい」。
2008/01/21(月) 10:56:56
私は基本的には定数右派だが、不等号については後者かな。
やはり var < 0 ってのは直感的ではないし見ていて気持ちが悪いって感じる。
やはり var < 0 ってのは直感的ではないし見ていて気持ちが悪いって感じる。
2008/01/21(月) 10:59:26
2008/01/21(月) 10:59:59
2008/01/21(月) 11:04:38
私は < だろうが > だろうが関数呼び出し相手なら
if (0 <= func(
if (0 == func(
if (0 >= func(
だなぁ。
if (0 <= func(
if (0 == func(
if (0 >= func(
だなぁ。
2008/01/21(月) 11:07:39
2008/01/21(月) 11:10:36
よし纏めよう。
・定数右派
基本的に、常に定数が右。不等号の向きなんて関係ねぇ。
・定数左派
基本的に、常に定数が左。不等号の向きなんて関係ねぇ。
・不等号は数直線派
基本的に、不等号は常に左を小さく。定数の位置なんて関係ねぇ。
ダメだ、>71も恐らく例外があるのだろうし分類しきれない……
・定数右派
基本的に、常に定数が右。不等号の向きなんて関係ねぇ。
・定数左派
基本的に、常に定数が左。不等号の向きなんて関係ねぇ。
・不等号は数直線派
基本的に、不等号は常に左を小さく。定数の位置なんて関係ねぇ。
ダメだ、>71も恐らく例外があるのだろうし分類しきれない……
7463
2008/01/21(月) 11:22:37 >>64-72
回答ありがとう
なるほどねー
1. 数直線に合わせる派
2.1. 評価対象を常に左に置く派
2.2. 評価対象を常に右に置く派
がいるみたいだね
…これ、どっかのMLの過去ログにもありそうだな
回答ありがとう
なるほどねー
1. 数直線に合わせる派
2.1. 評価対象を常に左に置く派
2.2. 評価対象を常に右に置く派
がいるみたいだね
…これ、どっかのMLの過去ログにもありそうだな
2008/01/21(月) 11:42:38
基本的に短い物が左。
そして変数同士の不等号は数直線派。
変数か定数かなんて関係ねぇ。
な俺は結果的に
即値 < 変数・定数 < 式 < 関数
な順番になるな。
定数左ってよりは即値左か?
画面が狭かった頃の規約の名残だな。
そして変数同士の不等号は数直線派。
変数か定数かなんて関係ねぇ。
な俺は結果的に
即値 < 変数・定数 < 式 < 関数
な順番になるな。
定数左ってよりは即値左か?
画面が狭かった頃の規約の名残だな。
2008/01/21(月) 13:24:24
こんなものは理屈じゃなくて、数学の記法では普通 0=x でなく x=0 と書くというのが一番大きい気がするけどな
不等号は3項関係なら数直線だが2項関係ならやはり変数を左辺に書くのが数学でも一般的だと思う
不等号は3項関係なら数直線だが2項関係ならやはり変数を左辺に書くのが数学でも一般的だと思う
2008/01/21(月) 13:59:49
その理屈だと関数が絡んだときにおかしくないか?
数学だとy=f(x)の方が一般的でないか?
数学だとy=f(x)の方が一般的でないか?
2008/01/21(月) 14:12:06
>数学だとy=f(x)の方が一般的でないか?
その記法は定数相手には使わないような。
確かに y については y = f( x ) 的な書き方をするけど、f(x) については f(x) = a * x + y 的な書き方もするはず。
だからまあプログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、それでも変数と定数に限れば 0=x ではなく x=0 だろう。
これはもう理屈とか抜きに。
その記法は定数相手には使わないような。
確かに y については y = f( x ) 的な書き方をするけど、f(x) については f(x) = a * x + y 的な書き方もするはず。
だからまあプログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、それでも変数と定数に限れば 0=x ではなく x=0 だろう。
これはもう理屈とか抜きに。
2008/01/21(月) 14:27:50
>>78
数学に限って言えば、
>0=x ではなく x=0 だろう
これは状況によりけりだな。まぁ、
>プログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、
は正しいと思うので、数学のルールは適用できないんだけどね。
数学に限って言えば、
>0=x ではなく x=0 だろう
これは状況によりけりだな。まぁ、
>プログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、
は正しいと思うので、数学のルールは適用できないんだけどね。
2008/01/21(月) 16:34:55
&&とか||が絡むなら不等号の向きをそろえるけど
それ以外なら気にしないな。
それ以外なら気にしないな。
81デフォルトの名無しさん
2008/01/21(月) 16:36:21 またこの話か。去年さんざん「祭り」したのに。
もう秋田。
もう秋田。
2008/01/21(月) 18:25:42
わざわざ来なくてもいいのに(笑)
2008/01/21(月) 18:34:21
基本的には数直線に合わせるけど、場合によっては変えるね。
言葉や数式で表現するとどうなるかを頭に置きながら
理解しやすい方を選択する。
言葉や数式で表現するとどうなるかを頭に置きながら
理解しやすい方を選択する。
84デフォルトの名無しさん
2008/01/21(月) 20:01:32 Cプログラマの為に、ポイントをまとめたドキュメントを販売しています。
プロのプログラマでもあまりにレベルが低い人が多すぎます。
そんな人に限って、自分のレベルの低さを自覚していない、、、
本人は構わないかもしれませんが、その下についた新人プログラマは
たまったものではありません。(私が経験しました。)
今になって分かりました。
彼らもまた、理解できていなかったのです。
プログラミング言語の一番の習得の近道はきちんと理解している人にアドバイスをもらうこと。です。
私のC言語に取り組んだ7年間をすべてぶつけたつもりでテキストを作りました。
私の会社の後輩からは、どんなテキストよりもわかりやすかった!や、
今まで教えてくれていた先輩や、テキストたちが、ちゃんと理解できていないことがわかりました。
と、嬉しいコメントをたくさんもらいました。
そしてなにより、彼らの社内での評価がとても高いということが、私の誇りです。
興味がある方はどうか、下のサイトをみてみてください。
http://mori.eco.to/
プロのプログラマでもあまりにレベルが低い人が多すぎます。
そんな人に限って、自分のレベルの低さを自覚していない、、、
本人は構わないかもしれませんが、その下についた新人プログラマは
たまったものではありません。(私が経験しました。)
今になって分かりました。
彼らもまた、理解できていなかったのです。
プログラミング言語の一番の習得の近道はきちんと理解している人にアドバイスをもらうこと。です。
私のC言語に取り組んだ7年間をすべてぶつけたつもりでテキストを作りました。
私の会社の後輩からは、どんなテキストよりもわかりやすかった!や、
今まで教えてくれていた先輩や、テキストたちが、ちゃんと理解できていないことがわかりました。
と、嬉しいコメントをたくさんもらいました。
そしてなにより、彼らの社内での評価がとても高いということが、私の誇りです。
興味がある方はどうか、下のサイトをみてみてください。
http://mori.eco.to/
2008/01/21(月) 20:04:01
ウゼェ
2008/01/21(月) 21:33:16
みるまでもなくネタだろ
2008/08/02(土) 01:43:31
最近、カプセル化は要らん子な気がしてきた。
真面目に適用したところで可読性や保守性は上がるどころか下がることの方が多いし、
getter/setterを書くより、コメントやドキュメントをしっかり書いた方が良い気がする。
真面目に適用したところで可読性や保守性は上がるどころか下がることの方が多いし、
getter/setterを書くより、コメントやドキュメントをしっかり書いた方が良い気がする。
2008/08/02(土) 02:58:06
getter/setter が無いと、ついつい直接書き換えして
後の挙動が掴めなくなってしまう俺みたいな屑も居るので書いてくれて良い
後の挙動が掴めなくなってしまう俺みたいな屑も居るので書いてくれて良い
2008/08/02(土) 09:35:09
つーか、そもそも下駄雪駄がある時点で間違いだろ。ちゃんと意味を考えたI/Fにするべきだ。
2008/09/28(日) 15:35:28
>>87
getter/setterがある時点でカプセル化に失敗してるよ
getter/setterがある時点でカプセル化に失敗してるよ
2008/09/28(日) 17:00:45
getter/setterだけでも、代入と取得のみに操作を限定できる利点がある。
メンバのアドレスを取られる心配がないだけでも幾らか安心感があると思うよ。
メンバのアドレスを取られる心配がないだけでも幾らか安心感があると思うよ。
2008/09/28(日) 20:03:24
ブレークポインタもかけやすいしな。
だけとgetter/setterが多くなるとカプセル化の意義が薄れてしまうのも忘れてはならないね
だけとgetter/setterが多くなるとカプセル化の意義が薄れてしまうのも忘れてはならないね
2008/09/29(月) 03:59:22
設計から導き出されるのが、いい getter/setter
実装から導き出されるのが、悪い getter/setter
悪い getter/setter でも、将来の変更に備えて、無いよりマシ。
実装から導き出されるのが、悪い getter/setter
悪い getter/setter でも、将来の変更に備えて、無いよりマシ。
2008/10/04(土) 02:42:58
基本的な値はコンストラクタで受け取るだけで、その後はgetterのみ。
どうしても後から値を変更する必要があるとか、設定値の種類が多すぎる場合のみsetterを使うかな。
どうしても後から値を変更する必要があるとか、設定値の種類が多すぎる場合のみsetterを使うかな。
2009/02/03(火) 14:10:18
無限ループは
while(true){
}
って書くのが一番美しいと思うんです
while(true){
}
って書くのが一番美しいと思うんです
2009/02/03(火) 14:28:30
for ("ever") {
}
}
2009/02/03(火) 19:29:38
2009/02/03(火) 21:00:25
誘導されてきました
int* a;
int *a;
どっちのほうが見やすいですか?
int* a;
int *a;
どっちのほうが見やすいですか?
2009/02/03(火) 21:32:24
int*型として考えるなら前者
変数自身がポインタと考えるなら後者
変数自身がポインタと考えるなら後者
100デフォルトの名無しさん
2009/02/03(火) 22:04:58 int* a, b;
とかやられるとヤヴァイから後者がいい
とかやられるとヤヴァイから後者がいい
101デフォルトの名無しさん
2009/02/03(火) 22:32:07 ポインタ型と普通の型をまとめて宣言しないでほしい
102デフォルトの名無しさん
2009/02/03(火) 22:37:07 resありです^^
103デフォルトの名無しさん
2009/02/03(火) 22:55:50 >100
こんなのコンパイルエラーで検出出来るだろJK
こんなのコンパイルエラーで検出出来るだろJK
104デフォルトの名無しさん
2009/02/03(火) 23:31:31 >>103
コンパイルに数分かかるプロジェクトを書いた事が無いのか
コンパイルに数分かかるプロジェクトを書いた事が無いのか
105デフォルトの名無しさん
2009/02/04(水) 00:31:53 >>100
変数宣言分けるからどうでもいい
変数宣言分けるからどうでもいい
106デフォルトの名無しさん
2009/02/04(水) 00:42:39 そもそも1行に2つも宣言しないよな
107デフォルトの名無しさん
2009/02/04(水) 10:03:18 テンプレートではint*で1つの型なのに、>>100の例があるから困る。
でも俺はint* a;派。
でも俺はint* a;派。
108デフォルトの名無しさん
2009/02/04(水) 10:55:18 結局、CもC++も書く私はint * a;で落ち着きましたとさ。
109デフォルトの名無しさん
2009/02/04(水) 12:23:17110デフォルトの名無しさん
2009/02/04(水) 13:04:35111デフォルトの名無しさん
2009/02/04(水) 21:26:38 ポインタを typedef した時の const の挙動がなあ・・・
112デフォルトの名無しさん
2009/02/05(木) 00:51:29 Code Complete には int *p にせよと書いてあったが、俺は >108 方式。
>>104
リンクまで込みでじゃなくて、一つのファイルをコンパイルするので?
そこ辞めてヨソ行った方がいいかも。
>>104
リンクまで込みでじゃなくて、一つのファイルをコンパイルするので?
そこ辞めてヨソ行った方がいいかも。
113デフォルトの名無しさん
2009/02/05(木) 01:00:05114デフォルトの名無しさん
2009/02/05(木) 09:44:40 なんでC/C++は宣言の時、int *a, *b;という構文にしたんだろう?
キャストやテンプレートではint*を使うことになるのに。
スレ違いか。
キャストやテンプレートではint*を使うことになるのに。
スレ違いか。
115デフォルトの名無しさん
2009/02/05(木) 17:16:21116デフォルトの名無しさん
2009/02/05(木) 19:33:24 >>114
constへのポインタとconstポインタを
はっきり書きわけられることはメリット。
ぱっと見はわかりにくい文法だけど、
関数へのポインタとかも含めていろいろ
わかってくると、全体としては悪くないと
納得せざるをえないと思う。
constへのポインタとconstポインタを
はっきり書きわけられることはメリット。
ぱっと見はわかりにくい文法だけど、
関数へのポインタとかも含めていろいろ
わかってくると、全体としては悪くないと
納得せざるをえないと思う。
117デフォルトの名無しさん
2009/02/05(木) 20:44:49 >>116
それがどうした
それがどうした
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- サナエノミクスについて力説 積極的な財政出動で「所得増える 消費マインド上がる 税収増える」片山さつき財務大臣 ★3 [少考さん★]
- 中国軍機のレーダー照射1週間 駆け引き続く 中国、米のレッドライン模索 日本、米以外の同志国とも連携探る 米は対立から距離置く★2 [ぐれ★]
- 鈴木農相「おこめ券はお米しか買えないわけではない。例えば卵、味噌、しょうゆ、こうした購入に利用可能」 ★4 [Hitzeschleier★]
- 【芸能】粗品、日本テレビに苦言 客のレベルが「かなり低い。あいつら分かってない」「拍手したいだけやねん」 [冬月記者★]
- 橋下徹氏「総理なら岡田さんに何を聴かれても耐えてほしかった」 高市首相の台湾有事めぐる答弁に# [jinjin★]
- 「ヒートテックに寿命があります」ユニクロが明かした“3年劣化”の理由 暖かさが落ちる意外な原因とは [ぐれ★]
- お前らもちろんマモンキングやってるよな?
- 助けて!!地元でテレビ番組の超絶美人のアナウンサーさんが退社した。゚(゚´Д`゚)゚。
- (´・ω・`)VIPにおける現在確認している不具合について
- 俺の口癖が「いや言うけど!(笑)」なんだが
- 吉田死ね
- ( ´・ω・` )起きたよ
