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

コーディングスタイルについて熱く語れ

余裕の2get

インデント禁止

改行禁止

()禁止

if文の比較では定数は左に置くよな、常識的に考えて。

if(0==a){
　 処理
}

みたいに

if文なんて使ってるやつはばかです

include禁止

>>6
スペース入れろよ。

>>6
詳細は
http://pc11.2ch.net/test/read.cgi/tech/1193250955/l50
こっちを参照で。

必死だなｗ

>>9
スペース禁止

ｶﾞｯ禁止


ぬるぽ

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;
}
と書くのはどうでしょうか？
コード内部で参照するパラメータ名は使用する側が自由に決めることができます

define禁止

NULL禁止

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

コーディングスタイルに意味があるとしたらそれはプロジェクト内で統一することのみで
どう決めるかはまったく問題ではない。
もちろん一定以上の知的水準と経験を持った人間が決めればの話だが。

goto奨励

>>17
> コーディングスタイルに意味があるとしたらそれはプロジェクト内で統一することのみで

誤読してるかもしれないが、コーディングスタイルの意義として、プロジェクト内でのスタイルの統一しかない
ということであれば、それに全く同意できない。

まず、可読性ありき。

もしコーディングスタイルを決める意義が「統一することのみ」だったら、
「一定以上の知的水準と経験を持った人間」が決める必要さえないしな。

それじゃあ、変数名いってみようか。

ハンガリアン記法はクソ。

変数定義の箇所に型情報は記述されており、
適切に実装されたスコープ内では充分に目に付く。
型情報をたどれないほどに変数定義から離れた変数は、
同時に関数などのクソ設計を匂わせており、クソ。

>>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

> アプリケーションハンガリアン
> システムハンガリアン

シモニイすまんかった（´；ω；｀）

>>22
またMSがいらんことを・・・

１、２、ハンガリアン！
２、２、ハンガリアン！

>>22
それ読んだとき、めっちゃバグりそうな書き方だとおもったな。
内部で処理するときは、HTMLエンコードしないで処理して、表示のときに一括して、エンコーディングしたほうが
いいと思ったよ。
unsafeとsafeを混在させて処理してたら、いくらネーミングで工夫してもミスるだろって。

>>25 どぅわ〜

joelなんか糞派登場

関数名、変数名は6文字以内。

//char a, *b, *const c, const *d;
char a, *b, *const c;char const *d;

char const *dを続けて宣言できないのが悔しい。

考えるときはマンダム
立った時はジョジョ立ち

牛乳は瓶の奴しか飲んではいけない。
飲むときは腰に手を当てること。

>>29
俺が就職したばかりの頃は、
リンカの制限で関数名は4文字までだった。
プリプロセッサは16文字まで対応してたから、
マクロ使ったりして工夫してたなぁ。

今考えると冗談みたいな話だ。

最初の文字がi, j, k, l, m, n の変数は整数型。他は実数。

>>34
文字列、真偽値は…？
つーかクラスオブジェクトは…？

hsqscsName (html-safe, sql-safe, command-line-safe)
hsqscusName (html-safe, sql-safe, command-line-unsafe)
hsquscsName (html-safe, sql-unsafe, command-line-safe)
:

orz

今さらだけど>>6はどうかと思うな
見てから理解するのに時間がかかる

実際にあの方式使ってる人どのくらいいる？

>>38
コードサーチでオプソをググったら腐るほどいた

ヘアースタイルは7:3厳守。

エラーコードを解析する時は三白眼、効果音は
　┣” ┣” ┣” ┣” ┣” ┣”

>>38
999:1くらいだと思う。もちろん1の方。

>>38
俺はデキる奴だぜー、と思い込んでるけど実際はそうでもない人が使いそう

< とか > とかの向きを揃える目的なら使っちゃだめか？

定数を左に置くのは、次の場合だけだな。
if (0 < x && x < 100)
本当はif (0 < x < 100)と書きたいけど、書けないのでその代用としてだ。

returnやsizeofの後をカッコでくくるかどうかって話はもう出た？

return の後の括弧は無し
sizeof の後の括弧は有り

return はくくらないのにsizeofはくくりたくなるんだよな。。

習慣っつーか慣用句みたいな感じ

括弧つけるべきか否か迷う時間が勿体無いので、
なんでも括弧つけることにしてる。

return 0; ならいいとしても、return i * 2; みたいになると、括弧で括りたくなる。

昔、会社のコーディング規約決める時に、returnの後の括弧は無しじゃね？
って言っても、みんな、returnの後は括弧付けるって言って引かないから、
もう、どっちでも良い事にしちゃった。

実際どっちでもいいし

>52
燃料投下。
ttp://www.st.rim.or.jp/~phinloda/cqa/cqa6.html#q20

やっぱりキチガイは一人だけだったか。
奴が来ないとこんなに静か。

交差点で１００円ひろおったーよー

ちびまるこちゃんだな。

なんでもかんでもみんな マスゲームを踊ってるよ
ピョンヤンの丘にはボカッと 巨大な銅像献上
いつだって 忘れない 金日成偉い人 そんなの常識
パッパパラリラ
ピーヒャラピーヒャラ おなかが減ったよー

>今さらだけど>>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を探さなきゃならんし。
それとも俺がそういうコミニティで育ったからか？

私は三つとも上のほうが読みやすいと感じる。
数字の 0 よりも、フラグとか関数呼び出しのが「大事なこと」だと思う。
コミュニティ次第なんだろうね。

ただ私なら、 3 は

for (;;) {
c = fgetc(stdin);
if ( c == EOF ) break;
...
}

みたいに書く。

出力（条件比較や返値）より入力（関数呼出や引数）が「大事なこと」だと思えば上のほう、
if ( hogeHoge( parameter_list ) 〜
入力（関数呼出や引数）より出力（条件比較や返値）が「大事なこと」だと思えば下のほう、
if ( 0 < hogeHoge( 〜
ってところではないかな。

定数と一時変数を使えば
err = hogeHoge( parameter_list );
if ( err == SUCCESS )
2 は 1 の問題に出来るな。

ただし 3 はイディオムなので、私でも>>60のように分解はしないな。

ん、制御とデータで分けた方が適切なのかな。

"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( ...

になるね。

定数左に置く人はfor文でもやっぱり左に置くの？
for (i = 0; N > i; ++i) みたいな感じに

>for (i = 0; N > i; ++i) みたいな感じに
そりゃ不等号の向きによるんでね。if文でも同じやろ。
for( i = 0; i < N; ++i )
for( i = N; 0 < i; --i )

定数右に書く人は"N より大きい"を if ( i > N ) って書くん？
気持ち悪くね？

それもそうだ。

>>64
不等号の向きが数直線だと思い込む方がどうかしている。
つまり0より大きいと0より小さいがならぶときに、
if (var > 0) ...;
if (var < 0) ...;
と書くか
if (0 < var) ...;
if (var < 0) ...;
と書くかの違いなわけだが。

例えば、このvarが関数呼び出しになっても後者のように書くということなのだろ?
それが気持ち悪いと思えないなら、私とは相容れない種類の人間だと言うことだ。

>>64
私はそれぞれ

for ( i = 0; i < N; i++ )
for ( i = N; i > 0; i-- )
if ( i > N )

って書く。
逆は気持ち悪いって感じる。

「 i が N より大きい」をそのまま書いたら i > N でしょ。
N < i は「 N が i より小さい」。

私は基本的には定数右派だが、不等号については後者かな。
やはり var < 0 ってのは直感的ではないし見ていて気持ちが悪いって感じる。

>>68
おお、これは新しい意見だ。
ついに、var < 0 が否定されたぞ。

>>68訂正
× var < 0
○ var > 0

私は < だろうが > だろうが関数呼び出し相手なら
if (0 <= func(
if (0 == func(
if (0 >= func(
だなぁ。

>>70
だろうな。
さすがに var < 0 を 0 > var って書く人はいないか。
いないよな？

よし纏めよう。
・定数右派
基本的に、常に定数が右。不等号の向きなんて関係ねぇ。
・定数左派
基本的に、常に定数が左。不等号の向きなんて関係ねぇ。
・不等号は数直線派
基本的に、不等号は常に左を小さく。定数の位置なんて関係ねぇ。

ダメだ、>71も恐らく例外があるのだろうし分類しきれない……

>>64-72
回答ありがとう

なるほどねー
1. 数直線に合わせる派
2.1. 評価対象を常に左に置く派
2.2. 評価対象を常に右に置く派
がいるみたいだね

…これ、どっかのMLの過去ログにもありそうだな

基本的に短い物が左。
そして変数同士の不等号は数直線派。
変数か定数かなんて関係ねぇ。

な俺は結果的に
即値 < 変数・定数 < 式 < 関数
な順番になるな。

定数左ってよりは即値左か？
画面が狭かった頃の規約の名残だな。

こんなものは理屈じゃなくて、数学の記法では普通 0=x でなく x=0 と書くというのが一番大きい気がするけどな
不等号は3項関係なら数直線だが2項関係ならやはり変数を左辺に書くのが数学でも一般的だと思う

その理屈だと関数が絡んだときにおかしくないか？
数学だとy=f(x)の方が一般的でないか？

>数学だとy=f(x)の方が一般的でないか？

その記法は定数相手には使わないような。
確かに y については y = f( x ) 的な書き方をするけど、f(x) については f(x) = a * x + y 的な書き方もするはず。
だからまあプログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、それでも変数と定数に限れば 0=x ではなく x=0 だろう。
これはもう理屈とか抜きに。

>>78
数学に限って言えば、
＞0=x ではなく x=0 だろう
これは状況によりけりだな。まぁ、
＞プログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、
は正しいと思うので、数学のルールは適用できないんだけどね。

&&とか||が絡むなら不等号の向きをそろえるけど
それ以外なら気にしないな。

またこの話か。去年さんざん「祭り」したのに。

もう秋田。

わざわざ来なくてもいいのに（笑）

基本的には数直線に合わせるけど、場合によっては変えるね。
言葉や数式で表現するとどうなるかを頭に置きながら
理解しやすい方を選択する。

Cプログラマの為に、ポイントをまとめたドキュメントを販売しています。
プロのプログラマでもあまりにレベルが低い人が多すぎます。
そんな人に限って、自分のレベルの低さを自覚していない、、、
　本人は構わないかもしれませんが、その下についた新人プログラマは
たまったものではありません。（私が経験しました。）
　今になって分かりました。
彼らもまた、理解できていなかったのです。
　プログラミング言語の一番の習得の近道はきちんと理解している人にアドバイスをもらうこと。です。
私のC言語に取り組んだ7年間をすべてぶつけたつもりでテキストを作りました。
　私の会社の後輩からは、どんなテキストよりもわかりやすかった！や、
今まで教えてくれていた先輩や、テキストたちが、ちゃんと理解できていないことがわかりました。
と、嬉しいコメントをたくさんもらいました。
そしてなにより、彼らの社内での評価がとても高いということが、私の誇りです。
　興味がある方はどうか、下のサイトをみてみてください。
http://mori.eco.to/

ｳｾﾞｪ

みるまでもなくネタだろ

最近、カプセル化は要らん子な気がしてきた。
真面目に適用したところで可読性や保守性は上がるどころか下がることの方が多いし、
getter/setterを書くより、コメントやドキュメントをしっかり書いた方が良い気がする。

getter/setter が無いと、ついつい直接書き換えして
後の挙動が掴めなくなってしまう俺みたいな屑も居るので書いてくれて良い

つーか、そもそも下駄雪駄がある時点で間違いだろ。ちゃんと意味を考えたI/Fにするべきだ。

>>87
getter/setterがある時点でカプセル化に失敗してるよ

getter/setterだけでも、代入と取得のみに操作を限定できる利点がある。
メンバのアドレスを取られる心配がないだけでも幾らか安心感があると思うよ。

ブレークポインタもかけやすいしな。
だけとgetter/setterが多くなるとカプセル化の意義が薄れてしまうのも忘れてはならないね

設計から導き出されるのが、いい getter/setter
実装から導き出されるのが、悪い getter/setter

悪い getter/setter でも、将来の変更に備えて、無いよりマシ。

基本的な値はコンストラクタで受け取るだけで、その後はgetterのみ。
どうしても後から値を変更する必要があるとか、設定値の種類が多すぎる場合のみsetterを使うかな。

無限ループは
while(true){
}
って書くのが一番美しいと思うんです

for ("ever") {
}

>>95
それは意図しているのかそれともミスなのかが判断できない。

for(;;)
{
}

このほうが意図が明確

誘導されてきました

int* a;
int *a;

どっちのほうが見やすいですか？

int*型として考えるなら前者
変数自身がポインタと考えるなら後者

int* a, b;
とかやられるとヤヴァイから後者がいい

ポインタ型と普通の型をまとめて宣言しないでほしい

resありです＾＾

>100
こんなのコンパイルエラーで検出出来るだろJK

>>103
コンパイルに数分かかるプロジェクトを書いた事が無いのか

>>100
変数宣言分けるからどうでもいい

そもそも1行に2つも宣言しないよな

テンプレートではint*で１つの型なのに、>>100の例があるから困る。
でも俺はint* a;派。

結局、CもC++も書く私はint * a;で落ち着きましたとさ。

>>107
俺もint* a派。型を意識したりテンプレート使うとそうなるよね。
複数宣言はしない。行を分けてコメントを書く。だから>>100は無いものとしてC/C++で書いてる。

>>100
絶対賛成！

型がどうこういってるやつは、
typedef int *intpとかするがいい。

ポインタを typedef した時の const の挙動がなあ・・・

Code Complete には int *p にせよと書いてあったが、俺は >108 方式。

>>104
リンクまで込みでじゃなくて、一つのファイルをコンパイルするので？
そこ辞めてヨソ行った方がいいかも。

>>112
趣味で書いたやつでテンプレートをひどく使ってそういう事態になったことはあるが、
仕事なら絶対にできないな。

なんでC/C++は宣言の時、int *a, *b;という構文にしたんだろう？
キャストやテンプレートではint*を使うことになるのに。

スレ違いか。

>>114
*aがint型と読めるという話はよく聞く。
関数・配列が複雑に絡み合ったのも、そうやって解読していくし。

C++はCとの互換のため。

>>114
constへのポインタとconstポインタを
はっきり書きわけられることはメリット。

ぱっと見はわかりにくい文法だけど、
関数へのポインタとかも含めていろいろ
わかってくると、全体としては悪くないと
納得せざるをえないと思う。

>>116
それがどうした

>>116
const int* a, b;// aもbもconstへのポインタ
int* const c, d;// cもdもconstポインタ
こういう文法にして欲しかった。

関数へのポインタの宣言はかなり気持ち悪く感じる(typedefの挙動なんか特に)。
こっちもなんとかして欲しかった。

でも、ポインタを戻り値とする関数と区別するためにはやむを得ないんだよな・・・

>116
単純に記述量を減らすためかと。

例： int a = 1, *p = &a;

>>120
別の型を1行で宣言したいと思わない。
むしろint *a,*bがint* a,bで宣言できたら、1行で宣言する変数が１つ増える毎に1文字タイプ量が減ってありがたい。

>>119
関数へのポインタの宣言は例えばboost::function風に
void F(int);
function_ptr<void, int> a = &F;
これなら見やすい。

今でも、C++でBoost使えば、functionっぽく書ける。実際に使うかどうかは別として。
void f(int, double);
boost::mpl::identity<void (int, double)>::type* pfn = f; //void (*pfn)(int, double) = f;と同じ
まあ素直にtypedefすべきだな。

無名の構造体て書けなかったっけ?
そのポインタを宣言するのに必要な気がする。

struct ｛
｝ obj, *p;

それって、コンパイラが勝手に適当な名前を付けるやつだっけ

>>124
そのp使い道なくない？
型名が無名だから関数の引数に渡せるわけじゃないし、ヒープから確保することもできない。

インスタンスが２つあれば、その切り替えに使えるかもしれないが、
ま、そこまでするなら型名付けた方がいいと思う。

typedef struct ｛
｝ t, *p;
こんなのなら見るけど

>>99
C言語のこの仕様はポインタの理解をさまたげてくれたなあ・・・
Delphiは前者が前提なんだが、C挫折してDelphiやってはじめてポインタの概念がわかったよ俺は
ポインタって「なんとかのポインタ」で1つの型なんだ、と気づくまでにやたら時間がかかた。

ポインタ宣言に使う記号がアスタリスクなのもややこしいよね。
ポインタ絡みで間接演算子使うだけに。

if(flag){
}
if(flag == true){
}
どっちを選べばよいか･･･

>>128 構造体の typedef 禁止

>>131
前者に決まってる。論理定数との比較は無意味。
http://www.kouno.jp/home/c_faq/c9.html#2

if(flag){
この間にいくつスペースを挟めばいいのかわからない

入れなくてもいいし、入れるのならif (flag) {がお勧め。

"if"の後に一個、
"("の後に一個、
")"の後に一個スペースを入れないと、
かつ、二個以上入れた場合、コンパイルできない

とかいう仕様だったらいいのに。
俺は末期か・・・

if の後に空白を入れるスタイルだと、
条件が二行以上に渡る場合に４タブで綺麗に揃う

>>136
MS信者？

if ( hoge) {

こうか？
バランス悪すぎ

>137
漏れはこう
if( 条件1
|| 条件2 )

既存のコードにあとから手を付ける場合は、出来るだけ合わせて書いてるな

最近はワイドモニタだから、右に長くなりがちだなぁ。

基本は>>140と一緒だが。

じじいに言わせると80桁を越すと犯罪らしいぜ

コーディング規約でも規定されない限り、横の長さはそれほど神経質に考えないな
ある程度は工夫するけど

モニタが大きくなるとかえって80桁とかに縛りたくなる。
横にいくつもウィンドウを並べてみるのに都合がいい。

端末エミュレータを三つ並べても100桁表示できるご時世だから、気にしてもねぇ。
そんな私はどちらかと言えばこっち。
if (条件1 ||
   条件2) {

デバッガでトレースしやすいように１行で書いてる。
if (条件1 || 条件2 || 条件3 || 条件4 || 条件5 || 条件6 || 条件7 || 条件8 || 条件9 || 条件10) {

ソースコード関係ないけど、未だにWindowsのデスクトップの縦のアイコン数は、1024ｘ768時代の数だなｗ
でも最近Windows7使ってると、その傾向はなくなってきた（Vistaは常用したことない）

エディタは、文字数による改行なしで設定するのが俺のジャスティスだな

>>133
別に後者がいいとはまったく思わないが
trueとTRUEは違う
よってそのリンク先は根拠にならない

>>149
true でも TRUE でも以下の話は同じ。
> もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか

論理定数との比較自体が無意味。

((a == b) == TRUE)
↑これ何の冗談？ｗ

>>151
つまりそういう皮肉

>>150
それ、主題じゃないし
さらにその例はFAQそのものが不適切だ

論理定数との比較云々じゃなくて（そこは同意する）
そのFAQが違うだろって話ね

>>153
うるせぇなぁ。少しは応用しろよ。

>131 へのレスで挙げてるんだらこういうことだろ。
もし if(flag == true) が if(flag) より良いと思うのなら、なぜそこで止めるのか。
なぜ if(flag == true == true) を使わないのか。

処理上は無意味でも
if ( flag )より
if ( flag == true )のが
わかりやすくないか？

それじゃflagが２だったらとおらねぇだろ

それでいいじゃんｗ
2が入ること自体がおかしい

>>155
処理上は無意味でも
if ( flag == true )より
if ( flag == true == true )のが
わかりやすくないか？

trueはfalse以外が仕様だからそれじゃダメだっての。

if ( flag )
if ( flag != false )

これ以外は許されない

>>159
flag の型がちゃんと bool ならどっちでもいっしょ。

それよりも if ( flag != false != false ) のが（以下略

>>160
C言語だとダメなやつもあるから、0と0以外にしとくのが安全なスタイルってもんだよ。

比較演算の結果でてくる論理を比較するのもありだけどね。

assert( (p == NULL) != false );

>>161
わざわざ「flag の型がちゃんと bool なら」って書いてあるのに何言ってんの？

> assert( (p == NULL) != false );

ねーよ

いやいや、そこはこうでしょ
assert( (p == NULL) != false != false);ってのが(ry

だからさ、FAQの
> もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか
これがそもそもおかしい
おそらく原作者はジョークのつもりだったろうが、真に受けてるアホがいるからな・・・

Cの(ユーザー定義の)TRUEとC++の(言語の)trueの違いがわかってない奴がいるな
Cでif(flag==TRUE)は間違いだが、C++でif(flag==true)は書き方の問題だ
書き方の問題＝好みだよ

ここでif((flag==true)==true)を持ち出す奴はジョークが理解できないってことだ

>>164
で、何がいいたいの？論理定数との比較を擁護するつもりなの？

>>165
はなから技術的な正しさとか間違いとかを問題としてるんじゃない。
論理定数との比較に意味が無く、混乱の元でしかないから書くべきではないという話だ。
(... == true) も (... != false) も同じくらいに意味が無い。

意味あるじゃん
ある特定の人間にとっては見やすいという意味が

カスみたいな意味だな。

一番ダメなのは is〜, has〜, can〜 などの自然に読み下せるように工夫した命名規則を
台無しにしてしまうこと。

if (x.isReady()) で済むところを
if (x.isReady() == true) だの
if (x.isReady() != false) だの
わざわざノイズを混ぜるのが許せない。

俺はif(flag)派だが、if(flag==true)なソースを見てもいちいち噛み付かないな
TRUEは明らかに不味いがtrueは見た目の問題、見易いかどうかは主観だからな
それをノイズと感じるのも自由だし、そんなのは人に押し付けなければどっちでもいい

それよりTRUEとtrueを混同して大昔のFAQを持ち出したり、
技術と好みの違いが分からない奴の方がスキル低いだろ

TRUEとの比較には問題があるなんて>>133なども当然理解しているだろ。
それは誰もが理解しているという前提で、本筋からそれるのでスルーしただけにしか思えない。

初見のソースでif( hoge == true ) と書かれていると、hogeがboolになっているか、
そうでなければtrue/falseの2値しか取り得ないのかチェックする手間が生じる。
初見じゃなくてもどうなってるかいずれ忘れるかもしれない。
（そんなの気にしないとかってのは論外過ぎる）

if( hoge != false ) も、万人がつっかえず読めるソースであるとは言い切れない。

もしかしてflagが２でも==trueなら通るのか？

flagに2が入っている時点で不具合だとしか思わない
bool型ならな

素直に!=falseにしとけよ。

>>172
理解してたらtrueに対してFAQ(TRUE)を持ち出さないだろ

ヘンなケースだけど if (flag) 形式は
うっかり bool の配列を渡してハマりそうになったことあるなぁ
bool array[2];
if (array)
みたいな

>>173
初見のソースでif(hoge==1)と書かれていると、hogeがintになっているか、
チェックするのか？しないだろ？
ただのいいがかりじゃねえか、おまえの頭が論外だよｗ

読み違えてるよ

hoge == 1 は何とも思わないが、 hoge == true を見つけたら bool 値に対する理解が
不十分な可能性を疑わざるを得ないだろうね。バグを探してるときならなおさら。

signed/unsigned が混在してたり、可変長引数にキャスト無しの NULL を渡してたり、
ループ変数に char が使ってあったりするのと同じ。言語仕様の不十分な理解から出る
バグのにおいがする。

hoge==true見つけただけで言語使用を理解してない可能性を疑うってどんだけレベルの低い環境なんだ
ところで181の挙げた例に細かいミスがあるんだが、普段の俺ならスルーしてあげる
だが181の論理によれば、俺からみたら181は言語使用を理解してないと疑わざるを得ない

言語使用→言語仕様

何かミスがあるというなら言語仕様を理解していないと疑われるのはしかたがないと思うけど、
できればはっきりと指摘してほしいところだね。

どうせハッタリだろ。

なんか話ずれてるけど
173はif(hoge==true)ならhogeがboolかチェックするんでしょ？
もうその時点でありえないんだけど、そんな底辺レベルの職場なら
if(hoge==1)でもhogeがintかチェックする必要がある、チェックしないのはダブスタじゃん
って意味だよね、違う？

普通の職場なら同僚やらオープンソースで
if(hoge==true)見つけても、「あらあら、このひとはtrueと比較しちゃうんだ」って思って終わりだよ
どんだけ病んだ職場で働いてるんだ、転職したほうがいいよ

>>186
hoge == true （あるいは hoge != false ） を書くような人は bool 型や if 文になどついての理解が
あやふやな可能性が高いので、同様に理解の不足から int == true などという間違いを犯している
可能性があることを推測できる。

hoge == 1 を見ただけではそのような推測はできない。

関連箇所でのバグを探してるんじゃなければスルーすることも多いだろう。それが普通だというのも
妥当な話だ。しかし、スレタイを読む限りここでそれを主張するのは無意味だろう。

あのさ,
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) ....

って、かかんとあかんわけ?

関数が何返したのか分かりにくい

>179,182
if( hoge == TRUE )のケースを考えてみてよ。
hogeは本当にTRUEかFALSEしか取り得ないのか不安にならない?
漏れが指摘したいのはむしろこっちの方なんだよ。

if( hoge == true )の場合は気にし過ぎってのは素直に認める。
（コンパイルすりゃすぐ分かるというのはEnter押してから気付いた）
でもバグ発生時には疑うべき記述だと思う。

if ((!!flag == true) != false) {
　　flag = true;
　　flag = true; // 念のためもう一度
}
これくらいやっとけば安心

実際、trueやfalseと比較し捲くっているコードを整理したら、若干ではあるけど
所要時間に有意差が認められたからなぁ。

(1) if( hoge == TRUE )
(2) if( !!hoge == true )
(3) if( hoge == true )
(4) if( hoge )

最悪のケースを想定した場合、読み手が考え込む時間が一番短いのは(4)でしょ。
ifの動き、hogeの値、コーディングスタイル、ネーミング位しか悩める要素が無いんだから。
他は最悪、型とか脳内演算とかで、余計な思考時間を生んでしまう恐れがある。

true との比較では所要時間に差は出るだろうが
false との比較で差が出るのは最適化レベルがおかしいんじゃないのか

>>194
trueもfalseも纏めて整理したから、falseの有無で差があるかは確認していない。

あえて(2)を混ぜて誤魔化してないか？ｗ

trueと比較しない場合
>>178みたいなのでハマるくらい?

逆にboolをtrueと比較して困るケースの具体例、つか経験談ってある？

>>198
1以外の値が入ってるときとか。

>>198
>194

ちょっと違う話かも知れんが、

if (式) {
　return true;
} else {
　return false;
}

なんてプログラムを見ることがたまにある。
最初からreturn 式;にしろよ、って思う。

変更になりそうな箇所がおおいならそう書くこともある。

漏れはこうだなあ。

if (式) {
　return true;
}
return false;

そういうのを書く時は最終的にtrueを返すようにしてるな

return (式) ? true : false;

>>205
これはないな。

式が関数でtrue/falseの意味が取り違える可能性があるような名前ならアリかもな。

>>205
俺もこれだけはやっちゃダメだろとは思う
マクロならそうなるけど

自分のことしか考えてないタイプ

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;
}
--
これ見たときはどうしてくれようかと思った。

設計書にそういう「ロジック」を書いてるんだろうなあ。。。

1. 引数は値、レベル、反転フラグとする。
2. 反転フラグが _False であれば、以下を行う。
　　1) ・・・
3. 上記以外の場合、以下を行う。
　　1) ・・・

日本人プログラマが10人いれば、8人は何も考えずにコーディングを行う。
1人は、「反転フラグて。。。呼び出し側で結果を反転させりゃいいのに。。。」とか思いながらコーディングを行う。
残りの1人だけが「なんで設計書にロジック書いてんだｗｗｗこの現場やべえｗｗｗ」と笑い、辞める。

>>210
設計書を書いた奴と相談するっていう選択肢が無いのが悲しいな。

_Booleanはどういう定義なんだよソレｗ

>>212
おっと、書き忘れてた。
＞typedef enum { _False = 0, _True = 1 } _Boolean;
だとさ。ちなみに、Sun-OSのcc(標準ではc99としてコンパイルする)を使っているのに
c99禁止と言う不思議なコーディング規約(と言っても明文化されていない)だし。

>>210
>209のコードに関しては、設計者=コーダーの可能性大。

"<="や">="を書くことが幼稚な気がして今まで避けてきたんだが
"<"や">"は小数を扱うのが正しい使い方で、
整数を扱う場合はイコールをつけたほうが直感的な気がする
for(int i=0; i<10; i++)
ってのが一般的で10回カウントするってのが直感的にわかるけど
なんというか、行って帰ってきて結果的にはあってるって感じで、
for(int i=0; i<=9; i++)
のが1から9まで1ずつカウントするって意味で
正しい使い方な気がする

１からじゃなくて０からでした

>>205が何でだめなのか、プログラミング初級者の俺に教えてくれ
無駄がなくてわかりやすいと思うんだが

1. 返り値がニ値しか取りえないなら、isHoge関数にすべき
2. 構文糖衣はあくまで糖衣
3. 流し読みする時に目に入り辛い
(最後の行だからいい？一カ所使われていると、
複数箇所使われている可能性が高いから、結局同じこと)

>>214
＞１からじゃなくて０からでした
こういう馬鹿が居るから直感的じゃないんだよ。

>>216
「? true : false」の部分が丸々冗長。
単純にこれを消しても同じ意味だよ。

式が bool 型ならそうだろうが
そうじゃなけりゃえらい違いだよ。
bool 型へのキャストは警告出すコンパイラがあるんで、
やむを得ず ? true : false としないといけない。
マクロ化したいけど、作ってもみんな使ってくれないし・・・。

強制的に bool にしたいなら !!(式) でいいだろ。

Cだったら、0か0以外にしとけばいいんだよ。

>>220
条件演算子なんか使わなくても、比較式入れとけばいいじゃん。

真偽値を比較するなんてとんでもない！

>>224
真偽値だったら、そのままreturnすればいいんじゃね?

#define true 0
#define false -1
↑みたいな変態的な定義でもされてたら、条件演算子もやむなしって気がするけど。

自分だったら!!よりは? true : false選ぶなあ。

>>225
bool hoge(int ch) {
　return isupper(ch);
}

isupper の戻り値は真偽値（int 型の非0/0）だが bool ではない。
コンパイラによってはそのまま return すると文句言われる事がある。

>>227
いや、だから、真偽値以外だったら、比較にすればいいんじゃね?って話。

　return isupper(ch) != 0;

>>225
それが標準だったらどんなに良かったかと常々思ってる。

>>229
trueやfalseが標準で定義されていて、
n > 0 みたいな比較式の結果と違う値になってたらよかったってこと?

>>228
真偽値を比較するなんてとんでもない！
ぶっちゃけ読み辛くてしゃーない。

>>231
ああ、それはそうだな。
Cライクな真偽値と、C++のboolを併用するときはしかなないのかね。
static_cast<bool> とかするとどうなるんだろう。

VC++はboolへのあらゆる直接的な変換は警告出した気がする

g++はノーキャストでも完全スルーなんだが

>>220
式が bool じゃなくて return するのに問題があるというのなら、
? の左に書くのだって同じ問題があるはずじゃないか。
やっぱり、? 以降は単純に冗長だよ。

だーかーらー、五月蝿い警告が出るコンパイラへの対策なだけだと言うとるに。
どのコンパイラでも警告でないならそのまま返したいさ、そりゃ。

>>236
うるさいっていうかアホだろ。

return での bool への変換は警告するのに
? 演算子の前に置いたときの bool への変換は出ないとか、
意味がわからん。

そもそも警告を黙らせるためのコードなんか書いちゃいけない。
警告によって指摘された問題に対策しないといけない。

そりゃそうだ。C/C++に、?の左側に置いた式はbool型に変換されるなんて規則はないから
そこでbool型への変換だなんて警告が出るわけない。

>>238
何を根拠にそんなこと言うの？
C++ の ? は bool に変換して評価するよ。
5.16 Conditional operator p1
> The first expression is contextually converted to bool (Clause 4).

そうだったのか。
C99だけ見ていたが、こっちは、0と比較して云々となっていて、
_Boolへ変換するとは書かれていなかった。
C++もそんな調子だと思っていたよ、すまない。

C99 なら _Bool f(int x) { return x == 1; } でも比較演算自体は int だから警告が出るというのか？
それもアホだな。

そんなこと言ったら C99 では true も false も int 型なわけで。

結局のところ "? true : false" がまったく冗長なだけの記述には違いないね。

ECMAScriptなら冗長でないよ

どでもいいけど、システムハンガリアンって呼ばれてる
変数のタイプをプリフィックス/ポストフィックスとして
つける命名規則だけは絶対裂けるべきだ

一部に改訂が入って、使ってる型の定義が変わった場合の
メンテナンスはとんでもないことになる

下手に否定するより、よりベターな手法を教えてそっちに誘導した方が良い。
チーム全体に徹底させるだけの権限と統治力を持ってない場合は特に。

人は力強く押さないとあらぬ方向に進むが、引っ張れば割とすんなり思った方向へ進む。

>>244
WIN16→WIN32→WIN64の悲劇ですね。

WORD型やDWORD型なら、typedefを書き換えればいい
たぶん・・・

スタイルスレで聞きたいと思ったことが１つあるんだ。

C++のcppの方にソースを見やすくするために関数を小分けにしたものを
staticで記述して使ってるんだが、private関数にするべきかね？

>>248
privateにしなくてもいいんじゃね?
C++のprivateって、そもそもが美しくないし。

どっちかっていうと、外部にも派生クラスにも公開する気がない関数はクラスに含めるべきじゃないと思う。
クラスのインターフェイスとは関係ない、実装側だけの問題なら、実装側で完結してるほうが美しい。
static 関数なら、いくら変更しても外部には影響しないし。

継承したときにvirtualつけて使いたいけど、クラス外からは使われたくないものに
だけつけときゃいいのか。

static関数化できるものなら、Utilityクラスとかにして
外に出しちゃうのも良い鴨

staticって、クラスのメンバとしてか。。。
勘違いしてた。

メンバのstaticではなく実装用の小規模な補助関数ってことで。

>>248
.cpp ローカルな関数は static じゃなくて無名名前空間を使う。
private にすべきかどうかはクラスのメンバであるべきかどうかで区別する。

何も考えずに書くと private 関数の宣言をヘッダに書くことになるんで何かおかしな
感覚になるけど、 pimpl とかインターフェース継承とか使って隠せば問題ない。

なるほどね。いわゆるCのstatic関数ってのは推奨されてないのかな。
そこまで意識して気をつけようとも思わないけど、気が付くと疑問に思う。

>>256
関数や変数だけならいいんだけど、 C と違って .cpp ローカルな struct や enum も
グローバルに置いてると定義がかぶってアウトだから、なるべく無名名前空間を使う
癖をつけておいたほうがいいよ。

>>257
それだけなら別にアウトじゃない。
規格としてはダメかもしれんが。

ただ、メンバ関数はリンケージをファイル
スコープにできないから、無名名前空間が
絶対必須。

addとappendや、eraseとremoveの使い分けってどうしてる？

addは追加、appendは付加。
eraseは消去、removeは除去。ついでに言えばdeleteは削除。

まぁ、それでも巧く決まらないときは既存ライブラリの命名に倣ったりするが。

ロングマンで一通り調べてみた

appendは追記みたいな
順序付きリストの末尾に付け加えるということなのか
add⊇append

議論領域をUとすると
remove A from Bの操作の後はA B∧A∈Uだけど
erase A from Bの場合はA B∧A Uとまぁそんな感じ？
delteはcomputer上での操作を強調してあったけど
メモリから消えるって事だからプログラミングっていう議論領域だとeraseに近いのかな？

erase(A) はAによって識別される何かを削除する
delete(A) はAを削除する
remove(A) はAを取り除くが削除されるかどうかは仕様次第

append は後ろに追加するような意味だから
例えば map や set には使えない
でも add なら使えると思う

使われ方みると前 insert,後 appendで対って感じだな

ちなみに、先頭に加えるのは prepend っていう。

難しく考えないでAddFirst/AddLastでいいと思う
javaや.NETのコレクションではそうなってる

似た言葉をニュアンスの違いで使い分けたりするのはやめるべき

ははは

突然このスレにたどりついた俺は

if(hoge(var) == 0) じゃなくて、絶対 if (0== hoge(var)) 派だ

なぜなら左辺が変数のときに

if(var == 0) じゃなくて、絶対 if (var = 0) と書いてバグらせてしまう
奴がプロジェクトに出るからだ（中々見つけにくいんだな、このバグ）

後、関数の出口の return が必ず末尾の一つだけってプロジェクトに
参加したことがあるけど、処理の条件が変わっても、メモリリークが
出にくい構造になるのは良いと思った

> 後、関数の出口の return が必ず末尾の一つだけってプロジェクトに
> 参加したことがあるけど、処理の条件が変わっても、メモリリークが
> 出にくい構造になるのは良いと思った

これは結局ケースバイケースで、関数的（副作用がない）なコードが主か、
副作用とかバリバリか、で変わってくるよね。
あと、例外的な場合の処理にgotoを許すか、とか。

>中々見つけにくいんだな、このバグ
最近のコンパイラなら確実にwarning出すんでそうでも無い

ついでに言えば、比較対象が0ではなくて変数だったらやっぱり検出できないから殆ど意味がない。

RAII 使え、 const 付けとけ、って話でもあるな。

まぁOOPが不可能なプロジェクトなら、そういうリーク対策にも意味はあるかもしれんね
OOPが可能なら、RAII（厳密にはデストラクタによる資源解放）の徹底も可能だよな

>>269
C/C++で、zeroとの比較をするのであれば、
if (hoge(var) == 0)とぜすに、if (!hoge(var))の方が目的がはっきりする

比較する数値がたまたまzeroであるのなら、数字で比較すべきではない
定数化された変数を用いるか、#defineマクロで名付けられた定数を用いるべきだ

よって条件式に、数字が書き込まれている時点で何かおかしなコードであると思われる

>>275
しかしstrcmpの時ははゼロを扱っていいと思う。

おばかのきわみ > #define ZERO 0

>>276
その場合、BASE_CMPとか名付けて比較したほうが分りやすい予感

>>278
少なくとも俺は今、BASE_CMPナニソレ？(´･ω･`)　ってなってるが。

>>278
CMP_OBJCTじゃね?

>>275
あほか。
「ゼロと比較する」という処理ならコードにそのまま書いたほうがいいだろｊｋ

#define STREQ(a, b) !strcmp((a), (b)) みたいなマクロに

>>282
それなら辛うじて許せるような気もするが、
strcmpくらいそのまま使えよ、ってのが正直なところ。

strcmp(a, b) < 0 // a < b
strcmp(a, b) > 0 // a > b
strcmp(a, b) == 0 // a == b

という、並べて書いた上での法則がせっかくあるのに。

>>278
わかりやすくねーよ。
イディオムはそのままにするべき。

strcmpの場合
比較対象と同等か、大きい、もしくは、小さいだから
>>282よりはマシだろ

>>285
意味不明(´･ω･`)

>>275
> if (hoge(var) == 0)とぜすに、if (!hoge(var))の方が目的がはっきりする

そんなバナナ

0との比較なら素直に==0、真偽値としての比較ならそのまま、ってのが普通の感覚だと
思うけどなぁ。まぁ最後は主観だからあれだけど。
0をマクロに入れるなんてのは論外。

NULLの分らんアホばっかだな

>>287
0との比較の「0」とは何かという話じゃないの？

>>288-289
お前ら二人は一体なにをいってるんだ？

NULL自体が要らないマクロ

初心者なんですが、if (cond == false)って書き方と
if (!cond)ってどちらにすべきですか？
ずっと後者だと思っていたのですが、前者もたまに見かけるので
わからなくなってしまいました。

>>292
論理定数との比較はそもそもナンセンスなので、前者は論理値に対する理解が
あやしい感じがする。

たいした理由じゃないんだけど、どちらかというと後者にしといたほうがいいと思うよ。

>>293
ありがとうございます。このまま後者の書き方を続けていきます。

その cond の名前が ablable とか enabled なら ! allowed のような書き方が良いだろう。
availability とか visibility とかだと、「可視性ですか？」 じゃ頭弱いみたいだから 「可視性は偽ですか」の方が分かりやすいと思う。
専用に enum 作れという話だけど。

//これはだめ
hoge(foo,bar);

//これはおｋ
hoge(foo, bar);

http://www.eetimes.jp/content/3107

1TBS って初めて聞いた。

>297
これ思ったけど、1TBSの方が図2のような間違いは簡単に検出できるような。
（単純に /;\s*{/ で検出できる。オールマンスタイルの場合、ツールによってはマッチしない）

でも個人的にはオールマンスタイルのが好きだけどな。

俺は1TBSくらいの黒っぽさが好みだな
もちろん黒すぎるのは辛いけど、オールマンだとちょっと白っぽく感じる

まぁこれはさすがに完全に好みの問題だろうと思うな…

そもそも筆者のコメントを打つ位置が気に入らない。 //行末に書くな

俺は//の後にスペースがないのが気に入らない

一番のツッコミどころは比較式の左辺に定数だろ。

そもそも
if(!x)
とか
if(!(z=x-N))
とかやることが多いから==使わないな。

条件式に関数呼び出しを書くなってルールもあったな

へぇ。どういう理屈でそんなルールが認められるのかさっぱりわからんな。

>>305
&& や || のショートカットと関数の副作用の関係
f0() || f1() || …
f0 が成立すると f1 以降が評価されないってのを知らないやつがいるそうだ
なので、こう書かなきゃいけない。とてもうざい。
v0 = f0(); v1 = f1(); …
if (v0 || v1 || …)

>>306
それ、 (s && strlen(s) > MIN) とかいう時はどうすればいいの？

int len = -1;
if (!s) {
len = strlen(s);
if (MIN < len) {
...
}
}

!sじゃなくてsなｗ　素で間違えた。

そんなルールおとなしく守ってるプログラマなんてほんとにいるの？
何なの？ばかなの？しぬの？

>>310
元請けにコードの監査部隊がいて意地でも書き直させる方法を取っていた
うざくってしょうがなかった

その監査部隊を短絡評価の講習要員にすればいいのに。

308の書き方だと、正しく読めない/書けない奴が居るから仕方が無い。
一方、漏れらに308の書き方を強制しても、せいぜい能率が落ちるだけ。

実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。
平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは
冷徹ではあるが正しい方策。

へぼいコーディングルールの話になると、その理論がよくでてくるけど、実際はコーディングルールを
決めてるやつがヘボいだけだろうな。ほとんどの場合。

それに「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論が、本当に正しいかすごい疑問だし。

まぁ俺の持論とは真逆だな
ウンココーダの頭数揃えても、精鋭一人にも劣る

> 実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。
> 平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは
> 冷徹ではあるが正しい方策。

「人月の神話」に燦然と挑戦しているな。
まぁそのような開発分野もあるんだろう。多分。

「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論は確かに疑問だが、
十分な精鋭を確保できるプロジェクトなんてほとんど無いんだから、大量のヘボが存在
するのは前提だと思う。
加えて上司も無能だと、そのヘボが逐次投入されてチームは恐竜に、プロジェクトは
タールの沼に。

>316
そうでもないと思うが。
1つのプロジェクトに投入する人員については、「人月の神話」の理論で良いけど、
複数のプロジェクトに人員を配置する場合は、>313の理論の方が適している。

308みないなルールは大規模なプロジェクトほど多く、小規模なプロジェクトほど比較的フリーだろ?
（逆な例もある事は承知している）

短絡評価が分からないだけならまだしも、「教えても理解できない」という人員なんか
さすがに切り捨てても困らないと思うけどな

簡単なコードを量産するような人海戦術プロジェクトでも、上位の2,3割だけ使って、
のこりはじゃまにならないように遊ばせておいても、あんがい生産性あがるんじゃないかって気もする。

>>318
人月の神話、読んでないか忘れてるだろ。

>>319
短絡評価に限って言えばその通りだけど、教えられても理解できない部分は人によって違うから。

>>320
論文報告を楽しみに待ってる。

どうでもいいけどstrlen()が返すのはintじゃなくてsize_tだよ

ストレンツォ容赦せん！

>>318
つまり、たとえば優秀なプログラマなら3ヶ月で終わる仕事を一年かけて
（原則同じくらいの人数で）やるけど、
同時に抱えられるプロジェクト数を増やして会社としてのスケールメリットを得るって話？
要するに節約できるのは総務だの人事だのの管理コストの話であって
プロジェクトそのものの効率は上がってないと思うが…

>324
プロジェクトの効率は上がらなくても、利益は上げられる罠。
場合にもよるが。
下手すりゃ投入人員と期間を増やせばその分儲かる。

糞ルールがまかり通ってる現場って、大体は上がこんな思想で動いてる希ガス。

まぁ、その思想を最高だと思って布教しようとしたりしなきゃどうでもいいけどな

javaで

public void XXX() throws YYY, ZZZ {
}

のthrows以下が長くなると80桁超えますけど見やすい折り返し方ないですか？
eclipseのデフォルトで整形すると

public void XXX() throws YYY,
　　　　ZZZ {
}

とやってくれましたけど見づらいな。

>>325
思想とか計算づくで、レベル低いんじゃなくて、ただレベル低いだけなんじゃないの?
効率が利益に結びつかないから、淘汰されないだけで。

>>324
保守要員みたいなところにエース級は投入せんだろ。

むしろ OJT で勉強させるために新人を。。。

>>327
行が長くなるときどう折り返すか
ttp://java-house.jp/ml/archive/j-h-b/009166.html#body

C++ 使っててカンマとか演算子の「前」で折り返して、演算子の類が行頭にくるように
してたんだけど、 Python 使い出したらそうもいかなくなって、今は微妙な気持ちです。

>>331
英語では普通、カンマやセミコロンなどは単語の後ろに空白なしにつける。当然、改行はその後。
演算子もそれに準じる。

>>331
（ ・∀・）人（・∀・ ）ﾅｶｰﾏ

.append(foo)
.append(bar)
.toString();

+ fooooooooooooooooooooooo
- (baaaaaaaaaar % baaaaaaaaz);

= {
11111111111
, 2222222222
, 3333333333
}

if (
(cooooooooooooooond)
|| (baaaaaaaar && bazzzzzzzz)
)

文末を見るより、文頭を見るほうが目の動きが少ない。

. を先頭にもってくるのは許せるが、 , を先頭にもってくるのが許せないのはなぜだろう。

if 〜 else if 〜 else の各節にコメントをつけたいとき、俺はこのように書いているんです。
// こういう場合はこう
if (...)
{
}
// こういう場合はこう
else
{
}

ところが、節を分断するのはよくないと言う人がいるんですね。それはそれで一理あります。
その人はこう書いている。
if (...) // こういう場合はこう
{
}
else // こういう場合はこう
{
}

このやり方だと、条件式が長くなったり複数行にわたると、ちっと面倒なことになる。
みなさん、if文のコメントはどのように書いていますか？

>>335
if にコメント付いてれば else へのコメントは冗長だろ？考えるだけ無駄。

冗長なんて言ったらコメントなんて書けなくなる。
それに複数のelse ifがある場合はコメントがあった方がいい。

>>337
お前はなんのためにコメントが書きたいの？
コメントを書くことが目的なの？

// コメント
if(...) {
}
else {
// コメント
}

>>339
俺もそれだ。

俺はこうだわ。space efficiant!!

if(...) { // コメント
  foo();
} else if(...) { // コメント
  bar();
} else {
  foobar();
}

漏れは内容に応じて使い分けた方が良いと思うけど。

// 分岐全体について。
if( ... ){　　　// 式について。
　// ブロック内の処理&実行条件の概要
}
else {
　// ブロック内の処理&実行条件の概要
}


（例）
// 〜と〜を切り分ける
if( … 　　// 〜をチェック
&& … ) { // 〜をチェック
　// 〜の場合、〜する
}
else {
　// 〜の場合、〜する
}

こうしてる
if(...) {
　// ...なら〜
} else {
　// 〜(条件についての記述は無し)
}

お前ら、そんな面倒なコメントつけるくらいなら
is_こういう場合() っていう関数作ってif に入れとけよ。

どうしてもコメント書きたかったら
is_こういう場合() のところに書けばすっきりしていいだろ。

>344
それだと is〜() が何をチェックしてるのか知りたくなったら、一々中身を見なきゃ分からないし、
is〜() の条件を変えたくなったら、使ってる場所を全部チェックした上で変更するか、
「使われない関数」が生じるのを覚悟で別な関数を追加しなきゃならん。
（まぁ静的リンクのみなら、コンパイルすれば何処で使ってるかは分かるけど）

is〜()の名称自体は「何を」チェックするかに留めて、「何故」チェックするかとか
条件式全体が何を意味するかとかは、コメントに書く方がよっぽど面倒が無い。

>>345
> それだと is〜() が何をチェックしてるのか知りたくなったら、一々中身を見なきゃ分からないし、
ちゃんと名前付けて、関数宣言部分にコメント書けば、そんなことにはならないよ。
中身見るのはバグを疑うときぐらい。

> is〜()の名称自体は「何を」チェックするかに留めて、「何故」チェックするかとか
> 条件式全体が何を意味するかとかは、コメントに書く方がよっぽど面倒が無い。
コメントに書いて良いのは「何故」だけだな。

仕方なくわかりづらいコード書くときしか関数の中にコメントは書かないな
外側に書いたドキュメントだけでいい

>>345の思考様式だと関数を細かく分けることは悪になりそうだなｗ
適切な名前の関数を作ってどんどん分けるのは常識レベルだと思ってたが

漏れは>344の言葉をそのまま鵜呑みにすると

　// Hogeの場合
　if ( isFoo() && isBar() )

のようなコードも、コメント付けるより

　if( isHoge() ）

とした方が良いって事になるのを否定しただけです。
ちょっと言葉足らずで意図不明瞭だったのは申し訳ない。
↓以外は>346-348全てに同意。


>346
>コメントに書いて良いのは「何故」だけだな。

この言葉を鵜呑みにすると、「何時呼び出す」とか書けない。
これは「5W1Hが単純に読み取れない場合だけ」のがより適切だと思う。


>348
>適切な名前の関数を作ってどんどん分けるのは常識レベルだと思ってたが

これは「どんどん」「分ける」の間に「適切な粒度になるよう」が抜けてる。

適切に分けてりゃ、関数名は「何を」チェックするかだけ示せば十分>>344のように
運用できるだろ

>>349
>>コメントに書いて良いのは「何故」だけだな。
>
> この言葉を鵜呑みにすると、「何時呼び出す」とか書けない。

コードに呼び出しタイミングは書いてあるのに、なんでそんなことを
コメントに書きたいの？

それとも、関数を作った側がどんなときに呼び出すべきか想定してる
ってこと？
それなら関数の側にコメント書くから、やっぱり if にコメント書くことには
ならないよ。

ってゆーか、さ、
if ((flag & F_OPT1) && (flag & F_ERROR_ABORT)) // デバッグが有効で abort する場合
{ ... }
else
{ ... }

みたいに謎の条件判断とコメント両方つけるぐらいなら

if (is_abort_on_debug(flag))
{ ... }
else
{ ... }
って書くだろ？

ついでに言っとくと、>>342 みたいに
細切れでコメントつけるのはあんまり好きじゃない。

if (is_debug() && // デバッグモードをチェック
　　is_error_abort() ) { // エラーで abortするかチェック
　　// デバッグ時エラーならアボートする
　　... // 必要な処理をする
} else {
　　// デバッグモードでないか、エラーでも abort しない場合
　　nr_error++; // エラーカウンタを更新
　　... // 必要な処理をする
}

みたいに、C言語の日本語直訳を書くだけになりやすい。


それなら
/*****************************
* この関数は○○の時は△△します。
* 詳細は http://＜社内サイトの仕様書置き場＞
* の □□ のフローを参照してください。
* データフォーマットは grep -r Hoge_data ./sub1/include で探してしてください。
*****************************/
とでも書いてあったほうがわかるよ。

オレだよ、オレオレ

>350
「AかつB ⇒ Cである」の「Cである」が、一言で言えるなら>344で十分だけど、
常にそうであるとは限らんでしょ。
「Aである」「Bである」とか、一言で言える「Cである」は
>344の方針で良いと思うけど。


>351
すまん、if文へのコメント限定ではなく、コメント全般で考えてた。
if文へのコメント限定だったら、「何時真になる」とか。


>352
その例、漏れなら下のいずれかにする。
1,2の場合はコメント無し。3は政治的理由等で1,2が採択できない場合の最後の手段。

(1) if ( (flag & F_OPT_DEBUG) && (flag & F_ERROR_ABORT) )
(2) if ( isDebug(flag) && isAbort(flag) )
(3)　if ( (flag & F_OPT1)　　　　　　　　　//デバッグON
　　　　&&(flag & F_ERROR_ABORT) )


>353
352も漏れだけど、そーいう実況的コメントを書けという意図ではない。
コメントを書くなら、対象が明示的になる位置に書くべきでないの?
という趣旨で書いてる。

>355=>345≠>354
orz

>>352のコードは二つのことを一つの関数で表してるから微妙だな。
>>353や>>355のコードの方が良い。

だが、>>345で言ってることはどうにも奇妙に感じられる。
要は、コードで語り合った方がいいタイプってことだな。

中身が1行のif文やfor文について

// 1
if (...)
　　...;
{}省略してバグ混入したら嫌。

// 2
if (...) { ...; }
デバッグの時にブレークポイントが置きにくい。1行が長くなりそうなのも×。

// 3
if (...)
{
　　...;
}
行数取りすぎて画面内に表示されるコードが減ってしまう。if (...) {にすれば1行減るけど普段使ってないから一貫して使いたくない。

// 4
if (...)
{ ...; }
インデントがないのが見にくそう。かと言って{がインデントされているのも気持ち悪い。

それぞれデメリットがあって悩ましいです。
皆さんはどう書いていますか？

「{}省略してバグ混入」とはちょくちょく聞く意見だが、
生まれてこの方十数万行書いてきたが、
一回もソレになったことがない。

中括弧書き忘れたからといってバグるやつも、
バグるから書いておけばいいと考えるやつも、
死んでしまえと思う。

その程度の注意力と読解力、記述力しかないのなら、
人間やめてしまえと思う。

>359
確かに中括弧省略によるバグ混入のリスクがどの程度あるのか疑問ですね。
しかし、その反論も中括弧を省略するメリットがなければ意味がなくないですか？
中括弧を書く僅かな手間で、少しでも注意力のいらないコードが書けるのなら理にかなっていると思いますが。

>>360
ifに一行くっついてて、それにもう一行加えるんだろ？　すぐ下とかに。
それを書くときに中括弧が必要か否かに注意を払えないやつ、
書き忘れ、などと捕らえてしまうやつは死んだほうがいい。
変更を加えるとき、いつだってその挿入行の前後への注意は必要だ。

その注意力すら欠いておいてプログラミングをしようとするのは怖い。

> 中括弧を書く僅かな手間で、少しでも注意力のいらないコードが書けるのなら理にかなっていると思いますが。

それは否定していない。ただ、効果は有るが、全体にとって微少だと思ってる。
ただ、そんなヤワなサポートに頼ってしまう時点で、既に色々ダメだ。

個人的にはこうしてる。

if (cond) return; // continue, breakなども

if (cond) {
 abababa;
} else {
 abababa;
}

これは、注意力軽減への配慮でもなんでもなく、
見た目を統一したいがためにそうしてる。
ネストを避けるための式は右側に書いちゃう。
それ以外で中括弧はいつもつける。elseがなくてもつける。

> 中括弧を省略するメリット

メリットなんざ特に思いつかない。あえて言うなら見た目。

中括弧省略によるバグは実際会社で２例ほど見た
自分だけがいじるコードならいいだろうけど
後々他の馬の骨がいじる可能性も考えると
{ } 省略はやめた方がいい

ちなみに、俺は開始 { は if と同じ行に書く派
そして { } 内が短くても { の次は改行を入れ、} は単独行にする
昔は { を if の次の行に書いてたけど間延びするのでやめた
でも、行が長いと間が詰まりすぎると感じる事もあるので微妙な所

最初は一行でも後で書き足すことも多いので大抵は常に括弧付ける。
括弧あった方が見やすいし。

>>361
> それは否定していない。ただ、効果は有るが、全体にとって微少だと思ってる。
コーディングスタイルで重要なのは統一する事ですよね。
どっちでもいいような事でも、できるだけ合理的な方を選びたいです。

> ネストを避けるための式は右側に書いちゃう。
> それ以外で中括弧はいつもつける。elseがなくてもつける。
参考になります。
確かにreturnなどは1行が長くなる事が少ないですし、if文の右側でもいいですね。

>>362,363
やはり中括弧は省略しない方がいいんですね。

お前らLinux KernelとGNUのコーディング規約調べてみｗ

Linuxカーネルは、単文を中括弧で囲むのを基本的に禁止してるね。
if文の分岐の片方が単文な時だけ、特例として中括弧で囲うルールだったはず。

後から追加して複文になったときの問題だけじゃなくて、
if-else のネストで意図したものと異なる方に
else がくっつくことがあるって問題もあるんだぜ

それでもLinuxは無駄な中括弧を排除してるし、それであの巨大プロジェクトが一応は
問題なくやれてる訳だよな
ぶっちゃけ、こだわるほどのことではないんだろ

Linuxいじるような人は概ねレベルが高いだろうから問題ないんだろうな
というイメージだが、実際の所どうなんだろう

しっかり統一できてればいいんじゃね

VC使っててもミスる人いるのに
vimやemacsで大丈夫なの？

ミスとか以前に、他の複数行のif文と見た感じが統一されなくて気持ち悪いのは俺だけ？

統一性は別に気にならないな
単一文 if は単一文 if で統一されていれば

ぶっちゃけ、if-breakやif-returnまで中括弧入れてると冗長感はかなりあったから、
俺はLinux方式の方が好みかな
Perlなんかは逆に中括弧の強制が言語的に決まってたりするし、それはそれでいい
と思うけど（つーかPerlはreturn ifとかand returnとか好き放題に書けるしな）

rubyみたいなif修飾子があれば最高なんだよな。
next if condとかってスカッとする。

Perlのstatement modifierをそのままパクった奴だな
さらにそのパクリ元はBASIC/PLUSらしいが、どういう言語かシラネ

else if () は中括弧なしの単文だよな。


>>368
Linux はコードのチェックインの前に基本的に
Kernel ML へのパッチ提出でレビューを経るから
抜けはそこで指摘できる。

一人でコーディングするなら後任のことも
考えて {} つけといたほうがいい。

そんなのミスる奴は、悪いけど擁護しきれないレベルだと思うんだが
まともかつ慣れた奴でそんなミスをやる奴っているの？

都市伝説だと思うよｗ

>>378
新人をいきなり投入ってあるよ。
ま、一人に投げっぱなしじゃないけど、
char *foo(void)
{
　　char buff[128];
　　。。。
　　return buff;
}
みたいなコード書くヤツでも平気で
投入されてくるから要注意だｗ


そういえば、
for (...);
{
/* 何かの処理 */
}
で、ループの中が一度しか実行されない病
にはまった事はあるｗ

人いないのかよ。

ぬるぽ！

>>381 ガッ

対応する中括弧のインデントの階層を同じにしろといつも思ってる
なんでみんな階層変えて書くの？死ぬの？

>>383 が言いたいのは

if (...) {
}

スタイルは嫌いだ、ってこと？

一つのクラス内やファイル内に記述する関数やメソッドの順番ってどうしてる？
たとえばCで f1()からf2()とf3()が呼ばれて、f3()からf4()が呼ばれる場合、自分は
void f2() { ... }
void f4() { ... }
void f3() { f4(); ... }
void f1() { f2(); ... f3(); ... }
のように、呼び出される関数を上の方に書いてるんだけど、
呼び出される関数を下の方に書くスタイルもあるよね。
こういう理由でこういうスタイルにしているというのがあれば教えて。

トップダウンで実装してる時はトップダウンで。
ボトムアップで実装してる時はボトムアップで。

# コーディング規則があるときや、既存のプロジェクトでは他に合わせて。

>>385
eclipseにメンバをソートする機能があるから、それでアルファベット順にソート。

>>385
プロトタイプ宣言はつけてるのでどんな順番でもいいのだが、
追加・変更した関数を上に持ってくる。 だいたい
いじる関数は決まってるからな。

自然と、下に行くほど枯れた関数ということになる。
機能単位でまとめられるようであれば別ファイルに
くくり出すときに雑魚は下の方でソートしてる。


起動時間などの最適化をかけるために順序を
変えることもある。 起動時に使うものをなるべく
一箇所に集めて上に持ってくるとか。

宣言を繰り返すのが面倒だから、呼ばれる側が上。
自然とファイルローカルな関数が上に来て、外部関数は下に来る。
ヘッダで宣言してる外部関数は、ヘッダでの宣言順にあわせる。

他人のソースをいくつか読んでみて、
見やすいのと見難いので比較してみれば？

わしは前フリ長いの嫌いなんで、上位の関数を
上に書いて欲しい。 わからないところだけ下を見る。


つか、クラスで最初に private もって来る奴とかいないだろ？
それと同じことじゃね？

>>390
ふつーにいるだろ? privateを最初に書くの。

if(hoge)
if (hoge)
if( hoge )

どう書く？
カッコが入れ子になった場合に一番見やすいのは最後だと思うが野暮ったい

if (hoge)

関数やマクロの場合は hoge(...) と、カッコの前を空けない。
if (...), for (...), while (...) などは空ける。

>>392
2番目がふつー。

if ( hoge )
だな。

for, while も同様。

カッコの内側に空白を入れるのは、マイクロソフトのサンプルとかが
そのスタイルだよね。

MSはC++では1番目，C#は2番目

訂正C++は3番目

今MSDNのサンプルで確認したら統一されてないな。
あったりなかったり。
カッコの内側のスペース。

VS2008のオートフォーマットは、デフォルトでは、C#はカッコの
内側にスペース入れない設定。
C++は、設定項目がなかった。

一番大切な事は、それを書いて自分が何を感じるかだ

>>401
もちろんコスモを感じる

ブランクを感じる。

ごめん、書いてみたかっただけw

なるほど、色々参考になった。
自分の場合、ソースの流れを追うときに、呼び出される関数が上にあるか下にあるかが
あらかじめ分かってた方がスムーズに追えるかなと思うんだが、順番を気にしない人が
けっこう多いんだね。

>>404
というより、関数の間に依存関係がありすぎるのはキモイ。
>>385の例で言うとf1->f3->f4ていうのが深い。

俺ならpublicなインタフェースに対し、その実装から、
privateなメソッドを一回呼び出したりする程度。
だから順番としては、（基本、互いに呼び出しあったりしない）publicなものを上にババーと書いて、
下のほうにprivateなメソッドをコソコソと書く。_fなどとprefixをつけて名前を汚して書く。

>>405
関数の深さ制限って、何のため？深くて何が悪いの？
「そろそろ関数分けるか・・・あ、もう３段目だ。やめとこ。」とか言っちゃうの？

名前を汚すって、何のために？
private なりファイルローカルなり、もっとマシな仕組みが言語側にあるでしょ？

どっちも意味わかんない。

> 「そろそろ関数分けるか・・・あ、もう３段目だ。やめとこ。」とか言っちゃうの？

言わない。「そろそろ関数分け」たりしない。
適切に設けられた関数は既に簡潔に表現されてる。
結果、そんなに呼び出しが深くなったりはしない。

> 名前を汚すって、何のために？

すまない、完全にこれは蛇足。
privateでかつ、仮状態のメソッドを区別するためにそうしてるだけ。
汚い名前をつけとくと、落ち着かないでしょ？
キレイな名前がつくときは、整理されて明確な役割を担ったとき。
ま、この話題はどうでもいいな。

f1(){ f2(); f3()}
f2(){ f3(); f4()}
f3(){ f4(); }

のようにスパゲティに依存してるのはちょっと気持ち悪いが、
単に深くなるのは気にしないな。

ていうか関数が2層しかない、って相当単純なものしか書いてないんじゃないの？

>>407
関数の表記が簡素であることと呼び出しの深さがどう関係するの？

…あ、もしかして「適切にファイル分割された状態であれば、ひとつの
ファイル内でそんなに深くなることはないはず」ってこと？

> 言わない。「そろそろ関数分け」たりしない。
> 適切に設けられた関数は既に簡潔に表現されてる。

事後の関数分けをしないでもいいって、どんな神プログラマだよｗ

> ていうか関数が2層しかない、って相当単純なものしか書いてないんじゃないの？

しらんがなｗ

それと、二層どころか、ほとんどは一層だよ。
publicなメソッドから、同じクラスのほかのpublicメソッドを呼び出したりはしない。
メソッドのオーバーロードの場合は除いて、ね。
publicメソッドからたまーに、privateなメソッドを呼び出したりするだけ。

だから、publicなメソッド同士の記述の順番なんぞどうでもいい。
なぜなら、そこに呼び出しあうような関係は無いから。
privateメソッドがそれらの間にあると読みにくいと思うから、
上のほうか、下のほうにまとめておく。邪魔だから。

> 事後の関数分けをしないでもいいって、どんな神プログラマだよｗ

残念、俺は糞プログラマだよｗ

底辺はリファクタリングを知らない。

>>412
なんだ。そうか。納得した。

自覚があるなら >405 みたいなミスリーディングな主張は控えていただきたい。

コーディング規約の大半は普通のプログラマのためではなく、
あなたの隣に座っているプログラマのような何かが生産し続ける、
見ただけで死ぬような目潰しコードを多少は見られるようにするという
崇高な試みのために存在する。

むしろコーディングに主義主張を持つ俺らみたいのが二人以上いると
宗教戦争を起こすので「めんどくせえからこーしとけ」的なルールな気もｗ

>>411
なるほど。たしかにメソッドの記述の順番が気になる箇所は、
関数をどんどん深く呼び出してる箇所とほぼ一致してるなあ。
そういう箇所はコードが読みにくいというよりも、そもそも
クラス構造に問題がありそう。
そういった、クラスの構造や粒度などについて書かれてる
書籍でおすすめのものがあれば教えてくれるとうれしい。

ソースを上から順に読むとか、飛び先を目で探すとかってことは
めったにないんで、べつに順番はどうでもいい。
気になるんだったら、アルファベット順にでも並べとけばいい。

>>417
まず大前提としてはKISS(Keep it simple, stupid)があって、
これはいつまでたっても我々にとって有効な指針になると思う…。

「Cプログラミング診断室　藤原 博文」
　構造化のテクを磨くことも大事。楽しい読み物。
　余計なことやヘンなことはしない、ということの大事さが分かる。

「リファクタリング　マーチン ファウラー」
　目新しさは無いかもしれないが、押さえておいていいかも。

「オブジェクト指向における再利用のためのデザインパターン　GoF」
「オブジェクト指向入門 第2版 原則・コンセプト　バートランド・メイヤー」
　自力で独学でOOP能力を高めていくのも大事だけど、
　OOPとは何ぞや、優れた設計とは何ぞや、を本から学びたければ。
　個人的に、デザパタ本は手垢で黒くなってきてるほど読んでる。

> クラスの構造や粒度などについて書かれてる書籍

で、肝心のコレはちょっと思いつかないｗ

ただ、図書館行って片っ端から技術書立ち読みしたら、
それっぽい本にきっと出合えると思う。
アジャイルなんたらっていう赤い本も面白かった気が。
技術系MLアーカイブを追っかけたり
（ttp://java-house.jp/ml/topics/topics.html#style）
するのもいいかも。なんかいい本あったら教えてｗ

Ｃプログラミング診断室
ttp://www.pro.or.jp/~fuji/mybooks/cdiag/index.html

これならお手軽に読める。内容はちょっと古いかもしれないし、
内容のすべてに同意できるとは限らないけど、
ある程度の距離を保って読めば、やっぱ今でも面白いかと。

カーニハンの「プログラミング作法」ぐらい読んどけよ。

診断室で一番共感したのは、糞グラマを無理に使うくらいなら切り捨てた方がマシ、
ってとこだな

>>419,420
ありがとう。「Cプログラミング診断室」読んでみる。

関数を分割するべきか否かを、関数の行数や
if等のネストの深さで、機械的に判断するのは間違い。
…などと書いてみるテスト。

一連の処理の固まりを、「処理内容が大体想像できる一文」で
置換する（記述を要約する）のが正しい関数化の手法であって、
行数等を判断基準に関数化するというのは、
ぶつ切りしてるに過ぎないと思う。

でもってこの「〜する」の一文を見つけたり、まとめられるように
フローをアレンジする能力ってのが、プログラムのセンスって奴だと思う。

バカを統制するのには機械的な基準はある程度有効

「こういうコーディングスタイル、ダサいよな」みたいな話題で、
わざわざ「俺はバカどもを使ってるから仕方なくやってんだよ」って
反論してくるやつって、実は本人がそのダサいスタイルなんじゃないかって
気がしてならない。

無能プロジェクトリーダの決める規準より言語設計者の決めるものの方がまし、
という意味で、言語がこと細かにスタイルを規定して欲しい。

Pythonのことか

>425
関数名（+引数等） = 処理内容の要約となるよう設計（分割）すべき、
ってルールはさほど難しく無いと思うんだ。

…と思ったけど要約できん奴は、ダラダラ書くんだろうな…
ダラダラ書かせない為に機械的制限は有効だと思うけど、
えてして基本が忘れ去られてる、と思うんだ漏れは。

そして void add_A_and_B(void) みたいな
関数を書く奴が出てくるんだな。

そんなレベルならどんな規則で縛ろうと無意味

>430
そーいうのを良しとするとは書いてなかろう。
そーいうのばかり抑制する事に気を取られて、
基本的な部分がおざなりになってるということ。

enum { SpecialID1, SpecialID2 }; でそれぞれに値を
記憶する場所があってそれを設定する場合に

1) Set_SpecialID1or2(SpecialID1, int value)
2) Set_SpecialID1(int value), Set_SpecialID2(int value)
3) Set(SpecialID1, int value)
4) Set_Special(flag, val1, ...) //flag： １のみ、２のみもしくは両方を指定可能

どれが好き？

わしは 3) でこっそり実装して 2) の
マクロを提供って感じなんだがオススメとかある？

>>433
マクロはよくない。

だって、シンボル数が増えると
起動時間遅くなるから。。。

>>433
口頭で動作を説明する場合の表現に近いコードを選ぶべし。

じゃ、SVOC だな。

>433
漏れならこう書く。

　bool SetHoge( int key, int value )
　bool GetHoge( int key, int& value )
　int GetHoge( int key, int error_value = 0 )　　//手抜き版

エラーハンドリングが不要なケースではもっと端折るけど。

なんかこういうのってデザインパターンにないんだっけ？

ない

>>433
本当に、単純に値を出し入れするだけなら
3)かなあ。これSpecialIDの設定はintじゃないよね？

ところで、C#をやるようになってから
C++でこの手の値入出力系のメンバにGet,Setをつけなくなった。
こんな感じ。

class tes
{
private:
　int m_data;
public:
　int Data() const { return this->m_data; }
　void Data(int data) { this->m_data = data; }
};

実装していて今の所問題ない。俺の場合は。
これって、どんな問題が考えられる？

>>441
x.Data(0);
↑一見して何してんのか読み取れない。

>>442
分かるじゃん。
Dataは何らかのオブジェクトのコレクション (Datumの複数形だからね) を表していて
その0番目の要素を参照しようとしてるんだよ。


・・あれ？ 違う・・だと・・？

rubyとかだとね、x.data = 0と書けるね。

コーディングルールとして完全に縛ってれば別に問題は無いんじゃね。初期化子とかに
似ているといえば似ている気もしなくもないし。
ただ、暗黙の変換に似た気持ち悪さは感じるが。

関数をオーバーロードにするか、別名の関数にするかの判断基準ってどうしてます？

漏れは機能が似てるならオーバーロードするね

そういうのはクラスを使う人のための配慮だから実装がどうだからオーバーロード使うとかいう
基準を設けるのは間違ってるだろ

メリットが何もないからオーバーロードはしない

メリットのある場合もある
無い時はしない方がいい

暗黙の型変換とかと同じで、しないと大変なことになるんじゃなければ、しない方がいい

>>447-450
どうもです。
利用者が引数に渡す型が違う事を意識するものは、オーバーロードを使わない方針にします。

関数で、自分では操作しないけど戻り値は自己責任で自由に使ってねって言う場合、

std::vector<int> &GetVector() const { return const_cast<std::vector<int> &>(this->m_vector); }

こんな感じで書いてるんだけど、まずいかな。
const関数なんで使う側はコピーを返してると勘違いするとか。
なんか、自分ではいじらない、ただ渡したものは自由に使っていいよ
っていうものの正しい書き方が見えない。orz

const_castが必要になる状況は不自然。無理を通している。
constのvectorってのも不可解。何に使うつもり？

constメソッドにするとvs2008ではメンバが
const定義扱いでコンパイルされるらしい。
this->m_vectorはconstじゃないけど、GetVector() const;で内からそのまま返すと

error C2440: 'return' : 'const std::vector<_Ty>' から 'std::vector<_Ty> &' に変換できません。

とエラーが出る。

>>454が何を言っているのかわからない

>>452
＞なんか、自分ではいじらない、ただ渡したものは自由に使っていいよ
＞っていうものの正しい書き方が見えない。orz
非constメンバ関数にするべき。

const 版と非 const 版を作る。
const オブジェクトに対しても使えるようにするなら、メンバを mutable 修飾する。

スタイル的には、そんな設計がおかしい。
変更する必要のある側が保持して、使う側はその時点のものを借りる関係であるべきだ。
452 のは、ヨソの家の無線LANにただのりするような構造だ。
仕方の無いときはあるが、そんな時は別のスレがふさわしい。

>>455
ああごめん。vs2008だとこれが通らないよって話。
class tes
{
private:
std::vector<int> m_vector;
public:
std::vector<int> &GetVector() const { return this->m_vector; }
};

>>456
そういうもんかー。
内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で
constつけといた方が喜ばれるかと思ったけど、取っておくか。�dクス。

>>452
> 関数で、自分では操作しないけど戻り値は自己責任で自由に使ってねって言う場合、

それ、メンバに持ってるのがおかしいだろ。

>>458
通るわけねえだろ const なめんな。
通るコンパイラを見せてみろ。
スタイルの問題じゃなくて知識の問題だってんだ。

>>459
そういうもんかー。
内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で
constつけといた方が喜ばれるかと思ったけど、取っておくか。�dクス。

>>460
>>452〜>>455の流れで>>458に続く。
知識じゃなくて日本語の問題だなぁおいｗ

>>461
なんで >459 へのレスが >456 へのレスと同じになるの？

>>460
> const なめんな。

なんかカッコイイ発言だなｗ

コンパイルエラーが出るからconst外しをするとか
コーディングスタイル以前の問題

> 内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で

メンバ変数、しかもベクタ丸ごと外に晒そうなんて考える奴が言う台詞か？ｗ

>>465
なるほど。サンプルが悪いと。
んでは誰か聞かせて欲しいんだけど

中で余計な事しないよ的な意味でのconst

ってあり？なし？もしくは、これを実現する場合は
>>457のconst 版と非 const 版を作る。が最良？

>>466
それって普通の「内部状態変更しないよ的な意味でのconst」と何が違うの？

上の例だと、渡す時は内部状態を操作しないけど、戻り値は自己責任で自由に使ってね
それによって内部状態が変更されるよって言う場合。
std::vector<int> &GetVector() const;

>>468
外部で自由に設定していいものを「内部状態」とは言わんだろうし、
それを反映してコードでもメンバ変数にするべきじゃないでしょ。
ってすでに >457 も >459 も言ってるんだけど、それについてはどう
なのさ？

>>466
const tes ctes;
があったとき、ctes が変更されそうな操作をコンパイラがエラーにしてくれるのは素晴らしいことだ。
非 const メンバ関数を呼んだり、非 const ポインタ（や参照）への変換はもちろんエラーだ。
他に、オブジェクト内部の変数のアドレスを返すことについても、コンパイラは追跡してくれる。
非 const のアドレスを返すと、外から内部状態を変更されてしまうかも知れないから、わざわざチェック
してエラーにしてくれる。

458 のエラーは、C++ の規格でそうなっている。
とても有難い機能で、コンパイラベンダのみなさんがこの機能を頑張って実装してくれたお陰で、僕らは
constness の追跡について機械任せでいられる。
これにより、 const メンバ関数だけを呼ぶ限り、const オブジェクトについて、関数を呼んだ時も呼んだ
後も内部状態が変化していないことを想定していいことになる。お行儀のいいコードならだけど。
だから、const の意味を二つに分ける必要なんて無い。

アリナシの話は、それどころか原則 const であるべきで、観念的に副作用がある場合のみ非 const
であるべき。

そして const 版と非 const 版の両方が必要なら実装すればいい。

C++のクラスでメンバ変数が多いとき、コンストラクタ初期化子を
改行して書くと思うんだけどどう書く？
セミコロンとカンマをどこに持ってくるのかが知りたい
1)
hoge::hoge()
　　: foo(),
　　bar(),
　　baz()
2) googleスタイル？
hoge::hoge()
　　: foo(),
　　　bar(),
　　　baz()
3)
hoge::hoge()
　　: foo()
　　, bar()
　　, baz()
4)
hoge::hoge() :
　　foo(),
　　bar(),
　　baz()

セミコロンじゃなくてコロンだった

// インラインなら
hoge(): foo(apple), bar(banana),
　　yaw(orange), baz(strawberry)
{ ... }

// ソースに書くならこう
hoge::hoge():
foo(apple), bar(banana), yaw(orange),
baz(strawberry)
{
...
}

やっぱコロン、カンマは後ろに持ってきたほうが見た目がいいよね
回答ありがとう

俺は真逆で、コロンが前に来てないと落ち着かない
というより、前置か二項っぽい意味合いのものは、行頭に来るように置くのが普通
だと思うけどなぁ

自分を中心に地球が回ってると考えるタイプの方ですね

つーか、ある程度まともなコーディング基準で、>>475に反するものは見たことが無い
>>473に反するものは良く見る

もちろん、どこかには反対の例もあるかもしれんけど

普通かどうかで言えば、コンマが後ろにくるのが普通だと思われているからこそ
enum 宣言や配列初期化子に余分なコンマがあっても許されるようになったのだろう。

俺は後ろ派だが、手前派には
・行単位の追加削除移動の時に手当ての必要が少ない
・縦に並べた時に筆算のようになるし、自然言語と親和する
というようなメリットがあるので理解できる。

後ろ派はメリットよりは慣習的なものだと思う。
改行の持つ意味合いが強かった頃の名残りではなかろうか。

コロンに関しては、元の英語での使い方が一対一や一対多の左側を明示するもの
なのだから、makefile やラベルのように後ろに付けるのが普通だろう。

コロンは前、カンマは後ろ派

訂正

ラベルのコロンは当然後ろ
クラス初期化子のとこのコロンは前

つか、色々ソース見ても、>>471の1か2が普通じゃね？

漏れ、改行しないんだけど

hoge::hoge(): foo(), bar(), baz()

短いのはそれでいいんじゃね

>>480
根拠を書かずに普通っていうと、476が出るぞ。

>>483
いろんなソースをそれなりに見てる人なら大体同じように感じると思うけどな
統計でも取らなきゃ文句言われるってんなら知らん

>>484
君の経験上普通なのは疑ってない。
君の経験を普通だとする根拠を求めている。

例えば、Win32, *nix, 汎用機、マイコン、クライアントサイド、サーバサイド、
官公庁調達、金融系、業務系、Web 系、オープン系、データベース、
パッケージソフト、ガジェット、デーモン、デバドラ、分散、超並列、
大手、下請け、大学/研究所、他にも色んな分類の仕方があると思うが、
さまざまなカルチャーがある。

分類の抽象度は任せるが、いくつかを挙げて、
　「こういった分野では普通だ」
　「経験したこれとこれとこれの全ての分野で普通だ」
とするなら、ずっと説得力があるのではないだろうか。

俺なら>>471の3。
この流儀に俺が行き着いたのは、SQLでクエリを書くようになってから。
文字列を*に置き換えて全体の形を表すと、

*******
***********
*****
********
******************

のように右側がデコボコし、そこにandやらorやら,やらが来ると、読むとき目がウネウネする。
区切り、中身（？）、の二種類で、文字のサイズが固定なものを左に持ってきたほうが、
読みやすさが増すと思う。上記の例を使ってカンタンに表すと、区切りを@として、

*******@
***********@
*****@
********@
******************

より、

*******
@***********
@*****
@********
@******************

がマシだという理屈。

>>485
平たく言うと、普通○○なんじゃね、はこのスレでは絶対禁止ってことだな

>>486
ちょっとわかる。
SQLで長いWHERE節を書いてると、
普通の言語以上になんかくどく感じる。

ただ、AND/ORは行頭にまとめた
ほうがいいのでは、と思いつつ、今は
まだ行末に書くようにしてる。

漏れも3)派。
でも区切り記号ではなく演算子の場合は行末の方が優れている部分もあると思う。
例えば一次的に演算子を置き換えてみたい場合、↓みたいに書ける。

　***** + //-
　*****

でもやっぱ3)が好き。

ttp://codepad.org/nYNt4bQw

>>487
学問カテと技術系板では、無限定の「普通」を使うべきではないと思う。
別に「普通」であることの証明を求めているわけじゃなくて、根拠を求めてるだけなんだけどね。

>>491
俺は、技術系板では無限定の「普通」を使うべきではない、とは思わないな。
学問と技術なんざ別物だ。

技術系の板で根拠の無い発言を当然とするのは残念だ。

技術系じゃ完全な根拠を要求するのは不可能だろ

ぶっちゃけ心理学とか社会学とかもかなり根拠曖昧なままやってるしな

お前ら携帯か？ 流れ読めよ。

>>494
何で「完全な根拠」なんていう、文脈から外れたものを持ってくるんだ。
経験が根拠ならどういう経験なのかを、実験が根拠ならどういう実験かを述べよというだけのことだ。

>>495
実験なりモデルなり、根拠は論文に提示してあるだろう。
おかしなものは否定したらよい。
具体的に何か一つでも挙げてみろ。


ハイゼンベルクの不確定性原理やらゲーデルの不完全性定理やらが定着した現在、そんな完全な証明なんて求めるわけが無い。
だがしかし、何かを主張する時に口からでまかせ言っていいことにはならないし、そうでないと説得すべく努力すべきだ。

> 何かを主張する時に口からでまかせ言っていいことにはならないし

ならなくはないだろうｗ　好き勝手言えばいいし、それを止めるすべは無い。
ただ、それなりの根拠がないと相手にすらされないだけでｗ

ちと聞きたいんだけど、
privateなメンバ変数、関数の頭にアンダースコアつけるマーチンファウラー式って、protectedなメンバ変数や関数にもアンダースコアつけるもの？

自分がよく見るJavaだと、privateに付けてるコードの中でもprotectedになるとバラバラな感じだけど、どっちが主流or論理的根拠があるのかな

つかファウラーたんはなんて言ってるんだろう？

それをマーチンファウラー式と呼ぶのは知らなかったｗ

名前をアンスコで始めるのはやめたほうがいいんじゃね？
厳密に言うと _MyFunc とか C++言語の規定違反だったと思うけど。

ま、つけるなら public 以外全部だな。

>>499
ファウラーたんが発祥らしい

>>500
なるほど、public以外ぜんぶが主流か
自分はJavaが多いんで他あんまり知らないんだけど、C++は規約違反なのかあ
C#とかは末尾にアンスコつけるらしいね

> C#とかは末尾にアンスコつけるらしいね
　　　　　　　　　 　　　＿＿＿_
　　　　　　　　　　　／　　 　 　＼
　　　　　　　　 　／　─　 　 ─　＼
　　　　　　　　／ 　 （●） 　（●）　 ＼　　　
　　　　　　　　|　 　 　 （__人__）　 　　 |
　 　　　　　　 ＼　 　　 ｀ ⌒´ 　　 ,／
　r､　　　 　r､／　　　　　　　　　　ヘ
　ヽヾ　三　|:l1　　　　　　　　 　　　　ヽ
　　＼>ヽ/ |｀ ｝　　　　　　　　　 　　|　|
　　　ﾍ　lノ `'ｿ 　　　　　　　 　　　　|　|
　　　　/´　 /　　　　　　　　　　　　 |.　|
　　　　＼. ｨ 　　　　　　 　 　 　 　　|　 |
　　　 　 　 |　　　　　　　 　 　 　 　 | 　|

あ、ごめん
末尾にアンスコもC++か

「末尾 アンダースコア」でぐぐったらC++の話が出てくるから、さっきの規約違反回避のためにそうやるのかな？

つけておくとコードみたらすぐわかるし、thisとかいらなくなるし、コード内で名前重複しづらくなるし、メソッドでも付けるぐらい気にいってるけど、最近は付けない風潮なのかなあ

アンスコってアンダースコートの事かと思った

>>500
_[A-Z].* と __[A-Z].* が処理系予約って話だろ?
処理系の解釈も OS 込みとか, 言語処理系単体とかあるみたいだな

>>503
スコープを知りたくなること自体が、設計か実装が悪臭を放っている可能性を
示唆していると考える人は否定的になる。
プラグマチックに考えるなら、そのルールが有益になるチームはいくらでも
あるだろうと思う。

だからといって敢えて削除するメリットがあるとも思えないし
混乱を深めるだけだと思う

そうそう
付けないメリットより、付けるメリットの方が多い気がするんだよね

IDEが発達していらなくなるという主張も聞いた事あるけど、IDEだからこそ、一文字目からアンダースコアの有無による補完リストのフィルタリングとかできて便利だと思うんだが

一文字目アンスコはC/C++で規格違反になると何度言えば（ry
見苦しかろうが m_ とかにすれ

アンスコってアンインストールの事かと思った

>>507
削除しろなんて言って無いし。

>>509
規格で予約されているのは、先頭のアンダースコアに続く大文字と、
出現位置を問わず二連続のアンダースコア。
先頭のアンダースコアに続いて小文字が現れるのは規格適合。

正確には何らかのネームスペース内ではだな
グローバルネームスペースでは不適合

メンバでは結局適合だけどね
ただ混乱を避けるために一律禁止した方が良い
よく知らない人が書いちゃうし

こいつらはgotoで書いて良いかどうかって議論をあまり聞かないが、どうだろうか

　for (i = 0; i < n; i++) {
　REDO:
　　...
　　if (...) goto REDO;
　　...
　}

REWIND:
　for (i = 0; i < n; i++) {
　　...
　　if (...) goto REWIND;
　　...
　}

どちらもgoto使うのが一番簡潔かつ分かりやすいと思うのだが、
必要になるケースが少ないからか、議題に上る事すらない気がする
でもたまーに必要になることがあるのよね
その時いつもgoto使いたくなるけど我慢して別の方法を使ってるが、
やっぱりgoto使うのが一番エレガントだと思うのだがどうよ

REWINDは時々使う
REDOはほとんどcontinueで代用できる

でも、i-- して continue; とか
i++ を最後に書いて continue; とか
何かキモくね？

まぁ、continue や break も字面が違うだけで goto だからな。

else の ない if 文は goto 書いてあってもなくても
実質 goto だし、goto はよく使うよ。


ループの中で goto 使うときは while() で書いたほうが
気持ちの上では抵抗が少ないかな。

>>514
REDO のほうは do ... while(...); のほうがよくないか？
REWIND はループを関数化して戻り値で分岐するかなぁ。

for の再初期化式以外でループ変数を触るような場合は、
while か do で書くかな。
その goto REWIND はありだと思うけど。

>>518
１カ所なら do-while でいいと思うけど
２カ所以上あったら面倒くさいと思う
redo のある言語もあるくらいだし、
その redo の代わりに goto 使うのはありじゃないかな

for( int i=0,step=1; i < n; i+=step,step=1 ) {
　...
　if( ... ) {
　　step=0;　　//REWND時は　step=-i
　　continue;
　}
　...
}

きったねえソースだな

if (n == 0) goto end;
start1:
i = 0;
start2:
...
if (!...) goto start3;
goto start1;
start3:
...
i++;
if (i >= n) goto end;
goto start2;
end:

あんまり面白くなかった。。。

for文のトコとかフラグを使う辺りが醜いのは認めますが…だめっすかね。>522

●>521のメリット
・ネストが無駄に深くならない。
・通常のfor文同様、ループ処理の肝となる処理が1行に集約されてる。

・カウンタの更新タイミングが明確。
　例えばカウンタを直接操作する方法でやってしまいがちな、↓のようなミスを防げる。
　　　if( i == x )　i = 0; //カウンタリセット(処理は継続)　← この行を追加
　　　...
　　　++data[i];　// data[x] にincrementされない。

・フローの制御方法が（比較的）単純明快。↓
　　for( int i=0,step=1; i < n; i+=step,step=1 ) {
　　　if( ... ) step = 0;　// もう1回
　　　if( ... ) step = -i;　// 最初から
　　　if( ... ) step = -n;　// n個戻る
　　　if( ... ) step += n;　// n個スキップ
　　}

>>524
毎回そのコメント書くんならいいんじゃない？
ただ、step=1 がレギュラーケースじゃない場合を考えて、step=1/*次へ*/ もループ中に書いたほうがいいと思うけど。
記述意図を明確にする意味なら、data や i を構造体にラップしてそれを操作する関数群を用意した方が良いだろう。

>>524
＞・ネストが無駄に深くならない。
goto 使った時とネストの深さに変化は無いし、
goto を使った方が if がすっきりする

＞・通常のfor文同様、ループ処理の肝となる処理が1行に集約されてる。
一行にたくさんの処理を詰め込んだだけで、分かり辛くなるだけ
goto だと単純な上に、ラベルにより意味も明解

＞・カウンタの更新タイミングが明確。
goto を使った方が分かりやすい
i+=step,step=1 なんて頭を使ってどういうコードか理解しないと分からない

＞・フローの制御方法が（比較的）単純明快。
step が途中で変わるのはとても分かり辛い
普通、そういう場合は for でカウンタを操作するのをやめて、
常に { } 内で直接カウンタを操作するようにする

そもそも、REDO や REWIND が必要なケースは稀であり、
そんな稀なケースに、より単純で明解な実装法があるにも関わらず、
複雑な技巧を凝らしたコードを仕込むのは得策ではない

goto が最も危険なのは、変数宣言を下に飛び越えたり、ブロック内に飛び込んだりする時だが、
REDO や REWIND はこの使い方には相当しない
飛ぶ位置はループ頭やループ前という極めて安全な位置のみであり、
かつ、どんな処理を行いたいのかが極めて分かりやすく、
goto を使う事に問題は無いと言える

>>524
そこまで制御書くなら for じゃなくて while 使うなあ

>525
関数とかでラップしちゃうとカウンタの変化するタイミングとかが却ってわかり辛いと思うんですが。
例えば↓
　　for( Counter<int> i = 0; i < n; i.increment() ) {
　　　if( ... ) i.retry();　//← retry実行後、i の値はどうなる?
　　　std::cout << i <<std::endl;　// retry実行時、何が出力される?
　　}
これだと i を直接操作する方がよっぽど素直かと。
（わざわざ「step」を使うのは、直接操作した場合生じる問題を回避するため）

>526
素直にgoto使う方がよりシンプルなのは否定しません。
ただ524は「gotoを使わない」という前提ありきで書いてます。
「公開しないコード書く時」あるいは「明示的に許可されてる」のでない限り
gotoは使うべきじゃ無いと思うので。

>527
その辺は適当に読み変えて下さい。
個人的な趣味&行数を抑える目的&etcで for1行にしました。

> 「公開しないコード書く時」あるいは「明示的に許可されてる」のでない限り
> gotoは使うべきじゃ無いと思うので。
ダイクストラも罪作りなことをしたもんだ。

教条的にGOTOを排除しようとするのは80年代に蔓延したおかしな傾向だろ。
ダイクストラが言ったのは60年代末。

>>528
goto 使わない場合は次のように実装できる

REDO:
for (int i = 0; i < size; ++i) {
　bool redo;
　do {
　　redo = false;
　　if (...) { redo = true; continue; }
　} while (redo);
}

REWIND:
bool rewind;
do {
　rewind = false;
　for (int i = 0; i < size; ++i) {
　　if (...) { rewind = true; break; }
　}
} while (rewind);

カウンタに一切手を加えない分、step を使うよりは分かりやすい
もちろん、goto の方が分かりやすいが

REDOを多重ループにすると今度はbreakでループを抜けられない…
とか思ったけど、そんなレアケース考えてもしょうがないか

複雑なら関数化も視野に入れていいんじゃない

じゃC++0xのラムダ関数で

>>528
もっと説明的なコードを書こうよ、って話。
Counter<int> i なんて名前じゃ曖昧になって当然。
CodeIterator currentCode(data, CodeIterator::Head);
if (...) currentCode.rewindToHead();
とかにしようよ。
先頭に巻き戻した後に、何が出力されるかどうかもないでしょ。先頭のだよ。

その構造は、中間言語処理や書式化文字列処理など、様々な場面で登場する。
その時々に相応しい構造と命名をしたら良い。

>531
漏れはその書き方が一番無難だと思う。
goto使う方法はgotoの使用が許されるなら最善手だとは思うけど、
叩かれるのを覚悟して使うほどのメリットは無いと思う。
（叩かれるのを覚悟して>521を書いた奴が言う台詞じゃ無いけど）

>535
そこまで書くよりは、普通に↓と書く方が良いと思うけど。
　for( int i=0; i<n; ++i ) {
　　if( ... ) i =-1;　//最初から
　}
ただこの例を見ても分かるように、カウンタを直接弄る方法は
「最初から」が何故-1なのか直感的に分かり辛い。
（>535みたいな書き方しても同様の問題が出てくる。）
だから>521。でもって↑も521も、下手に関数化するよりは
手の内を全て見せてしまった方が分かり易いと思われる。

まぁそこまでやるなら素直に>531のが良いとは思いますが。

追記。
ただ>531のredoは
　for (int i = 0; i < size; ++i) {
　　do {
　　　// 繰り返す処理
　　} while ( ... );
　}
と書くべきかと。フラグ要らんでしょ。

本当は if は途中に出てきてるのだよ

>538
>531
>if (...) { redo = true; continue; }
continueしとるで。

こういうことだよ

for (int i = 0; i < size; ++i) {
　bool redo;
　do {
　　redo = false;
　　...
　　if (...) { redo = true; continue; }
　　...
　} while (redo);
}

>>514の一つ目をdo while文で書いたときのフラグなしバージョン
for (...) {
　do {
　　...
　　if (...) continue;
　　...
　　break;
　} while(true);
}
まあ、redoはできても通常のcontinue、breakができなくなるけどね

通常の意味でのcontinueはdo while文の中でbreakすればいいか
ややこしい…

お前らおかしいぞ
普通に goto 使え

飛び先を制御するためだけに
ループしない while を用意するのは邪悪

普段gotoを使わないから>>514のようなケースのとき
gotoを使うってとこまで頭が働かないな

無限ループは for (;;) {} で、ループしないループは do {} while (0) で、
というのはイディオム。

do {} while (0); は continue しようが何しようが必ず抜けるから
continue した時はループする >>541 とは全く別の話だな

>>514のコードを書き換えるという前提では、結局gotoを使うのが一番簡潔に
なるんだろうけど、実際のコーディングではケースバイケースで全然違う書き方を
すると思う。
いったん普通にループを抜けてからREWINDやREDOに相当する処理を別にするとか。

最近言語に関係なくインデントにスペース2つを使うプロジェクトを
よく見る気がするんですが、これって元々どの辺の文化で使われていたんでしょうか？

スクリプト言語じゃないかね

GNU?

ぐにゅ？

>>549-552
2桁インデントはGNUスタイルだろ。
indentがインストールされている環境なら、indent -gnu <ソースファイル> でGNUスタイルに整形される。

GNU indent 2.2.3で試してみた。
::::::::::::::foo.c // オリジナル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0) printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.kr.c // K&Rスタイル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0)
printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.gnu.c // GNUスタイル
#include <stdio.h>
int
main ()
{
for (int ic = 0; ic < 10; ++ic)
{
if (ic % 2 == 0)
printf ("%d\n", ic);
}
return 0;
}

>>554
navi2chとかchalice使いでないと違いわからんだろ、これ

>554を変換してみた
::::::::::::::foo.c // オリジナル
#include <stdio.h>
int main()
{
    for (int ic = 0; ic < 10; ++ic) {
        if (ic % 2 == 0) printf("%d\n", ic);
    }
    return 0;
}
::::::::::::::foo.kr.c // K&Rスタイル
#include <stdio.h>
int main()
{
    for (int ic = 0; ic < 10; ++ic) {
        if (ic % 2 == 0)
            printf("%d\n", ic);
    }
    return 0;
}
::::::::::::::foo.gnu.c // GNUスタイル
#include <stdio.h>
int
main ()
{
  for (int ic = 0; ic < 10; ++ic)
    {
      if (ic % 2 == 0)
        printf ("%d\n", ic);
    }
  return 0;
}

>>555
ニョロカッコの位置と改行位置で分かるだろ?

以下のような理由をあげて、 「構造体の typedef 禁止！！！」つったのに
平気で typedef srruct foo { ... } foo_t; をやってくるおまえらは
なにものですか > 今度使ってる害虫
Avoid using typedefs for structure types. Typedefs are problematic
because they do not properly hide their underlying type; for example you
need to know if the typedef is the structure itself or a pointer to the
structure. In addition they must be declared exactly once, whereas an
incomplete structure type can be mentioned as many times as necessary.
Typedefs are difficult to use in stand-alone header files: the header
that defines the typedef must be included before the header that uses it,
or by the header that uses it (which causes namespace pollution), or
there must be a back-door mechanism for obtaining the typedef.

>>558
それを挙げて禁止とか言ったんなら、英語の読めない中途半端な経験者だったんだろう。
一般的な解説と、具体的なデメリットとを繋いで説明できればよかったのにね。

キャッチボールで相手のレベルに合わせて投げるのと同じように、
コミュニケーションでも相手のレベルに合わせて伝えるべき。
子供相手に変化球投げたりしないだろ?

と、昔上司から言われた台詞を貴方にも。

>>559, 560
そのほかに指示したのは、「名前の長さは長くても20文字程度に押さえてね」だけで、
こっちは守られてるのに、「構造体の typedef 禁止」は無視するってのはおかしくないか？

一部の地域には構造体を typedef しなきゃいけない宗教的理由でもあるのか？

>>561
少なくとも、妄信的にtypedefする奴はいる。

>>561
http://www.google.co.jp/search?q=%E5%85%A5%E9%96%80+typedef+struct

名前20文字以内が守れてるってのは、普通にやってればなかなかそこまで
長くならないってだけかもしれない。

妄信的に単語を短縮する奴もいる。
酷いのだと何でもかんでもアルファベット3文字とか。
特にCOBOLer上がり。

H8環境でC++使ってないとtypedefだらけになる。

>>558
そういうトラブルは typedef を禁止したところで
なくならないし未然防止にもならない。

そもそも言語に対するスキルというか
リテラシーが低いことが問題。

名前の長さも同じこと。 不思議な省略単語濫用で
20文字以内になっても意味がない。

>>566
んなことは分かてる、なんでルールを無視するんだ？ と言ってる
実際にあった話だが、顧客指定でLaTeXでドキュメント寄越せと言われたらどうするよ

タグ名と typedef 名が同一ならよいのだから、そのくらいはヴァリデータツールを書いて、通らなければコミットできないようにしてしまえばよいのではないか。

>>568
同一ならいいってわけじゃないだろう。 >>558 は読んだか？

まぁ、下請けになめられてるんだろうな。

>>569
読んだ上で問題ないと判断したんだが、具体的にどういう場合に不具合があるんだ？
そこにある三つの問題全てクリアになると思うよ。

>>571
"they must be declared exactly once"
"the header that defines the typedef must be included before the header that uses it"

A.h で struct A だけが宣言されていて、使う側で毎度 struct A と書く場合、
使う側で A.h をインクルードせずに struct A の前方宣言で済ませることができる。

A.h で struct A の宣言に加えて typedef struct A A があり、関連する関数の宣言に
struct A* ではなく A* が現れる場合、 A* を使うためには必ず A.h のインクルードが
必要になる。

問題が３つだとしたら２つは残ってるように見える。
何か誤解されてるんじゃなかろうか？

>>572
コーディング規約にすることで未然に防ぎたい不具合の具体的な例をお願い。

> A.h で struct A の宣言に加えて typedef struct A A があり、関連する関数の宣言に
> struct A* ではなく A* が現れる場合、 A* を使うためには必ず A.h のインクルードが
> 必要になる。

根拠が分からない。
手元の三つのコンパイラでコンパイルでき、警告さえ出さない。
俺が失念している規格があるのかもしれないから、具体的に示してもらえるとありがたい。

> A.h で struct A だけが宣言されていて、使う側で毎度 struct A と書く場合、
> 使う側で A.h をインクルードせずに struct A の前方宣言で済ませることができる。

というわけで、こちらも前方宣言で済ませることができる。
ただし typedef struct A A; の一行が余分に必要になる。
ちなみに C++ なら余分の typedef も不要。


と、ここまで書いてようやく気づいたが、同じ typedef 名の typedef がいけないということか。
typedef struct A A;
typedef struct A { int a; } A;
とあると、後者でエラーになるということか。

ちなみにこれは gcc ではエラーだが、cl と bcc32 ではスルーだった。
もちろん C++ ならどれも ok。

その理由で禁止なら、支持できるが、本当にこんなことを言ってたの？

>>573
> 手元の三つのコンパイラでコンパイルでき、警告さえ出さない。

どんなコードでテストしてるの？

> というわけで、こちらも前方宣言で済ませることができる。
> ただし typedef struct A A; の一行が余分に必要になる。
...
> typedef struct A A;
> typedef struct A { int a; } A;
> とあると、後者でエラーになるということか。

前方宣言のつもりで複数のヘッダに typedef struct A A; と書いたとしたら、
それらのヘッダをひとつの翻訳単位にインクルードすればやっぱりエラーになるだろ。

C禁止にしてC++に統合しようぜ。

そんな事したらリーナスおじさんが黙っていない

俺もOOPは大好きだが、
OOPLとしてのC++にも感謝してるが、
どっちか無くせといわれたら、C++がイランなｗ
Cは必要だな。

>>573
> もちろん C++ ならどれも ok。

C++ でも微妙だったりする。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#407

揚げ足取りならC++ならC的な書き方もできるがね。

とはいえ組み込み系だと環境構築してる間に開発期間がなくなる勢いだから
トップダウンでCを減らして欲しい。ボトムアップじゃムリポ。

>>579
組み込み系だとC++が使えない程度に貧弱なハードの場合も多々あるんだが
つか、テンプレートとか使うとC++ってコードサイズが見積もれなくないか？

逆に、constなんかはCよりC++の仕様のほうが組込にも向いているように思う。

自分の知り合いは、テンプレートは使う（もちろんコードサイズ増加は織り込み済み）が、
それよりも動的メモリ確保(malloc/new等)禁止のほうを気にかけている感じだった。
これももちろん分野によるのだろうけど。

if文の中に長い関数式を書くのはあまり好みではないので分けて書くことが多いけどどうよ
何をあほな書き方してんだと思うかいな。

if (MessageBox("保存しますか?", "内容が変更されています", MB_YESNO | MB_ICONQUESTION) == IDYES)
文;
----------------------------------------------------
const char * const pc1 = "保存しますか?";
const char * const pc2 = "内容が変更されています";
int num1 = MessageBox(pc1, pc2, utype);
// もしくは
// const LPCTSTR lpctstr1 = "保存しますか?";
// const LPCTSTR lpctstr2 = "内容が変更されています";
// uint utype = MB_YESNO | MB_ICONQUESTION;
// int num1 = MessageBox(lpctstr1, lpctstr2, utype);
int num2 = num1 == IDYES;
if (num2)
文;

え？　折角変数使うのにnum2みたいな糞名前？

そんなんつけるくらいなら
int ret = MessageBox(pc1, pc2, utype);
if (ret == IDYES)

こうするほうがまだマシでは？
else if (ret == IDCANCEL)などと続けられることも考えて。

>>580
ハード性能の貧弱さで C++ が使えなくなるなんてことはないよ。

例外、 RTTI 、テンプレートとか、機能や具体的な使い方に応じて
費用対効果が見合わないことはあるだろうけどね。
でもそれは組み込みにかかわらずあたりまえの話。

マイナーすぎてコンパイラが無いっていう方向の貧弱さを言ってるんだったら別。

>>584 主記憶64kでやってみろよ

>>585 別に問題ありませんが何か？

>>585
むしろその環境に対して C++ の何が問題を起こすと思っているのか聞きたい。

C++ が問題というよりは、組み込みでテンプレとか
ガンガン使っておいて ROM/RAM 足りませんみたいな
こと言ってくる奴が多すぎて困る。

バグったらバグったで自分じゃ解析できないから
ヘルプミーだと。 C++禁止にしようぜ。

テンプレ禁止しろよ

テンプレってリソース喰うん？

>>590 いいえ

リソースを食うコードを書いてしまいやすいと言うべきかな

なにこのほほえましいスレ。

>>588
禁止というか免許制にすればいいのにとは思う

http://sky.geocities.jp/tcshacina/hash.c
これは？

Javaで使い終わった変数にnullセットとか意味あんの？
ゴスリングも、今のGCは賢いからそんなことせんでええと言っているし、
そもそもスタイルとして美しくないので嫌いなんだが。
あと、宣言時のnullセットも同じく。
ここの先輩諸氏はどう思われますか。

宣言時のnullセットは意味が無いな

インスタンス変数で、null代入しないとオブジェクトリークになる、
というのでもない限りいらんだろ。

GC目的のつもりの代入に限って言えば、
それを強いるなど狂気の沙汰だ。

生存時間の長いローカル変数に対して、時間がかかる処理の前にnull代入するのは意味がないこともないよ
GCの世代昇格を防いだり

>そもそもスタイルとして美しくないので嫌いなんだが。

なぜそう思う？

>>596
VB出身者が必要だと思ってるんだろ。それ。

使い終わった変数にnullを入れると安全になるって思い込んでるヤツは
よくみるな。
それで安全になるようなコードの書き方をしてるなら、そっちを見直すべき
なんだけど。

C++なら新人に多重deleteされないようにdeleteし終わったらNULL入れておくかな。
C++はNULLのdeleteは「何もしない」のが仕様として決まっているから。
無条件deleteでも問題ない話になる。

コーディングルールの話をしてて、それはダメだってことになると、
「これはヘタクソには有効だ」って反論がでてくるけど、ヘタクソ向けの
コーディングルールなんていらないよな。
だいたいヘタクソに対しても別に有効じゃねえだろって感じだし。

よう俺。
デメリットを指摘しても「でも僕はこっちの方がいいです。慣れですよ」とか言われるし。

個人でプログラムしてるのなら、
周りの人間がそいつのコーディングスタイルをどうのこうの言っても意味が無い
好みの問題に他人が口出しするものではない

が、チームを組んでプログラムしてたり、
そいつのソースを将来別の誰かがメンテしたりするのなら、
コーディングスタイルを合わせるよう「命令」しないといけない

デメリットやメリットは無意味で、問答無用で「命令」だ

もしかして:スレ違い

ヘタクソにコーディングルールを強いると、生産性が落ちてバグが増えそうで怖い。
なのでヘタクソのコーディングルールに合わせるのです。

>>609
> 生産性が落ちてバグが増えそうで怖い

見えないものを怖がるな

どのようなヘタクソに、どのようなコーディングルールを強いた場合、
生産性がどれくらい落ちて、バグがどれくらい増えるのか、ちゃんと検証すればいい

検証の結果、本当は逆に生産性が上がってバグが減るのかも知れない

>>604
スマートポインタ、最低でも auto_ptr で自分で delete 書かないほうがいいだろ。
確実だし、デストラクタでヌル詰めるとか無駄だし。

>611
>最低でもauto_ptr
そしてコンテナでハマると。

>609,610
バカをフォローする手間を省くためだと思う。
ルールを決めるに当たって
・バカでも憶えやすい・理解しやすい
・特定の条件下では最も無難
・機械的にチェックしやすい
に傾きがちなのもきっとそのせい。

昔は馬鹿を育てたんだけどな
俺も育てられたし

ポインタをnullクリアより、変数のスコープを小さくしましょうとか、
使い回しをやめろとか教えたほうがいいだろ。

ポインタをnullクリアって、バグがおきないとかバグを発見しやすくする
工夫じゃなくて、バグってもなんとなく動いちゃう工夫だし。

あと上から目線で馬鹿向けって言ってるけど、使い終わったポインタを
NULLクリアするって言ってるやつって、馬鹿向けじゃなくて本気でそれ
がいいって思ってるっぽいし。

スタイルというより教育だな。

ある程度熟達すればコーディングスタイルにほとんどばらつきが出ない Lisp 系は、
コーディングスタイルという点ではけっこういい言語かも知れない

馬鹿の度合いにもよるけどな。
とにかくいじらせるコード量を減らすこと。
今はそれで対処できるのでそうしてる。
教育できそうな馬鹿っていいよね。
うらやましいよ。
こっちの馬鹿は英単語すら読めねえんだぜ。
だから当然エラーメッセージもw

>>616
ループを回すのに、dolist や loop を使うか、map 系を使うかというのでちょっ
と悩む。

>>614
> 本気でそれがいいって思ってるっぽい
一概にそうとは言いきれない

無限ループ
入力 -> フィルター -> 出力 ==> 別プロセス

をやると, 世代別 GC しか持ってない言語だと, フィルターの出力段近くで使っ
てる変数とか出力バッファがらみの動的オブジェクトは明示的に null 代入し
ないとメモリー足りなくなる

deleteしたポインタにnull入れても無意味だし、GCある言語でも
スコープはずれたり使いまわししてる変数にnull入れても無意味。

GC目的以外ならnullは有効だろう。
シングルトンパターンでの生成を遅延させたりするとき、
bool isinitedみたいなよけいないもんを使うより単に、
Foo foo = null;
getInstance() {
if (foo == null) foo = new FooBig();
return foo;
}
とすれば満足では。

あと、Foo::delete(Foo **foo)みたいにして
中でdelete *foo; *foo = null;とかさせておいて、
呼び出し元で、それ以降の望まないfoo->bar()を失敗させるのもやった。
当時はこれでうまくいったと思ってたが、今見るとなんかアホっぽいけど。

ポインタのnullクリアは、GC関連なら特殊なパターン以外は意味ないし、
バグを防ぐって意味なら、変数のスコープを狭くしなさいとか、使いまわしは
やめなさいとかってルールのほうがいいよね。

不正アクセス防止になるじゃねーの？　JAVAなんか使わないから知らんけど。

いやならないんじゃないの?

ぬるぽが出るんじゃないの？

nullクリアが真価を発揮するのは、デバッガでソース追う時。
スパゲティなソースでも、きちんとnullクリアしてるかどうかで
デバッグのしやすさが格段に違う。

「追いやすいコード」を目指すなら、多少手間でもnullクリアをしとくべき。
読みやすさを心がけてるなら、追いやすさも当然心がけるよな?

free(p);
#if DEBUG
p = NULL;
#endif

ですねわかります

>>626
null クリアでトレースしやすくなる理由がわかりません。

>627
そしてリリース版/デバッグ版の挙動の違いに悩まされる訳ですね。分かります。

>628
一部のデバッガが、未初期化・delete後の領域に
0xccとか埋める理由を考えてみると良いかと。

とか書くとnullクリアしなくても、その機能だけでも十分とか言い出すんだろうな。

>>629
0xcc とか埋めるのはデバッガじゃないよ。
VC++ でデバッグビルドの時のデフォルト動作だったはず。

で、その機能はトレースのしやすさとは関係ないと思うんだけど、どういうこと？

うっかり破棄後のポインタを触る可能性を考えるなら、スマートポインタを
使っておけばスコープアウトで解放するんだからほぼ根絶できるし、
スコープアウト前に解放する場合はスマートポインタが null クリア相当の
ことはするし。

手間をかけてでも null クリアしとけというのはやっぱりわからん。

Javaの話じゃなかったのか

Java で 0xcc 埋めとか、無いよな。

そんなもん入ってたら大変なことになるだろうな

>>633
なんで？

プログラマやデバッガが Java の意味として解釈できるアクセス対象は、
せいぜいバイトコードまでで、そりよりしたのレベルはランタイムに依るから、
実際のところ 0xcc で埋められていようといまいと、何も起こらないと思うんだが
（正確にはインターフェースのこちら側にとっては何も起こってないように見える）

>>634
その 0xcc 埋めは Java では実装できないだろ。
JVM の実装として話すんなら C++ 以下の話だろう。

>>635
> その 0xcc 埋めは Java では実装できないだろ

だから、プログラマやデバッガの立場では 0xcc 埋めできないんだから、
実際に 0xcc が入っていても大変なことになんてなるわけないと思うんだが

>>636
そういうことか。
「Java の話ではない」って流れについて言ってるのかと思った。ごめん。

>630
>うっかり破棄後のポインタを触る可能性を考えるなら、スマートポインタを
>使っておけばスコープアウトで解放するんだからほぼ根絶できるし

それはメモリ管理が楽になるだけであって、トレースしやすさとは別の話だと思うけど。
トレースし易いってのは、nullとか0xCCとか埋められれば、特定のアドレスの値を
見れば状態が分かるとかいう事だと思うが。

0xccが無効なオブジェクト扱いになるんかいな。NULLは処理系として例外扱いだろ？

>>638
0xcc の話なら確かに「特定のアドレスの値を見れば状態が分かる」けど、
破棄後のポインタにヌルを入れてもそんなことにはならないよ。

>640
ポインタの値を見れば、そのポインタの状態は一目瞭然ですよね。

>>641
スコープアウトさせてしまえば見るまでも無く状態は明白ですよね。

>642
「デバッガでポインタをウォッチしているケース」は想定してます?

>>643
してません。何のためにそんなことしてるのかな？

例えば
　Hoge *p = new Hoge()
　if( … ) {
　　// 何かの処理
　}
　moge( p );
のようなソースで、一々ソース追わずに moge() まで飛ばしてから p を見るとか。

>>645
だから、たとえば何のために p を見るの？それで何が知りたいの？

デバッガを使わないとコーディングもデバッグもできない人が世の中にはいるようで。

>646
>たとえば何のために p を見るの？それで何が知りたいの？
仕様通りの結果が得られたかを 知るため/知りたい。
null 埋めルールが徹底されてりゃ、途中で p が delete されたかどうかも
pを見るだけで容易に分かる。
p の先を見たり、大袈裟なツールに頼る必要も無い。
「トレースしやすい」とはそーいうことです。

>647
古文書の解析にはデバッガ必須。

>>648
> null 埋めルールが徹底されてりゃ、途中で p が delete されたかどうかも
> pを見るだけで容易に分かる。

その null 埋めルールを徹底するためにもスマートポインタ使ったほうがいい（ >>630 ）
ってのはわかってて言ってるの？

>>645
いまどき生ポインタ使って自分で delete するやつなんていねーだろ。

>649
分かってて言ってます。
（勿論スマートポインタを使う方が賢いと言うことも。）

>で、その機能はトレースのしやすさとは関係ないと思うんだけど、どういうこと？
とか言ってるから、null埋めそのものがトレースにどう有益かを述べてるだけですが何か。

つまり、「おいらの頭はスカスカだから、NULL埋めしてデバッガで追わないとどうしようもないスパゲッティコーディングしかできないよ」ってことですね。判ります。

或いは、「適切にコーディングされた工芸品のようなコードでもデバッガで追わないと理解できないくらい頭がゆるゆるなんです」とか。

>>651
あぁそうなの。てっきり >>626 の「多少手間でもnullクリア」に賛同してる人なのかと思ってた。

明示的にコードを書くかどうかを別にした「null埋めそのものがトレースにどう有益か」に
異論は無いよ。ありがとう。

>652
貴方のような物分りの悪い方に「このポインタは用済み」ってのを明示するためです。

nullを埋めないと明示できないのか。

スマートポインタを使えない状況も考慮すると、NULL埋めを徹底させた方がいい気もするなぁ

実際の大規模プロジェクトの現場では、スマートポインタで統一させるのと
初期化/使用後にNULL埋めを徹底させるのと、どっちが多いんだろうか？

Cに縛られているロートルが多いと言うことを鑑みると、後者が多いと思われ。
なんせ未だにカラム制限のあるコーディング規約もあるくらいだ。

>>657
> スマートポインタを使えない状況も考慮すると、NULL埋めを徹底させた方がいい気もするなぁ

どんな状況だ？
最低でも std::auto_ptr は使えるだろ。

馬鹿なプログラマがスマポ使えないんだお。

スマポが必要になったことが無い。俺が馬鹿だからだろうか。

>>661 そのとおりか、あるいは経験不足か、あるいは経験過多です。

つまり、明日は晴天だけど時々曇りで場合によっては雨ということですね

>>659
組み込み系やデバイスドライバ開発だと
スマポが使えない/使わないケースがよくあるよ
場合によってはC++ NGでCだけでの開発を求められたりとか

>>664
それ、技術的な制約でそうなるの？（だとしたらどんな制約？）
それとも決定権のある人が無理解なだけなの？

>>665
OSが提供する安全なユーザ空間の上でしかプログラムを組んだ事の無い
アプリ屋さんだと、ちょっと想像しにくいと世界だと思う
そういうもんなんだよとしか言えないし面倒なんで詳しい説明はしない
OSの構造や設計法あるいはリアルタイムOSの解説など
ネットで調べるなり本を読むなり該当スレへ質問するなり自分で考えてくれ

>>666
いや、俺は組み込み屋なんだが。
幸いにして関わったプロジェクトでは C++ コンパイラが使えたんで、
何の問題も無く使えている（ような気がする？）。
もちろん OS のある環境とまったく同じというわけにはいかないけど、
少なくともスマートポインタを使わない理由は無い。現に使えている。

なんだろうな？
まぁもうちょっと調べてみるよ。

スマートポインタは何を解決してくるの？
deleteの書き忘れ？
deleteを書き忘れちゃうようなコードを書く人のためのもの？

しょぼい組み込みだとコンパイラがないとか
コンパイラの信頼性とか、そういう世界なのかな。

>>668
マーフィーの法則によるとdeleteを書き忘れない人は存在しない

()や{}を書く時セットで両方記入しておいて、
カーソル移動して中身を後から書いてる。
同様に、new書いたらdeleteを直後に書く。

直後じゃなかったとしても、生成と破棄はセットで設計してるから大丈夫。
対になるものはいつも対応を取りながら進めていく。

>>667
ちなみにターゲットマシンのCPUは何でございましたでしょうか？

>>671
だからそれを人力でやってるのが駄目なんだっつーの。
そりゃ普通そう書くよ。

>671
変なフレームワークや仕様を強要されてる場合、newとdeleteを
別々のクラス/関数/スレッド/etcで実行せざるを得なかったりして
必ずしも1対1にできるとは限らないと思う。

>>671
そのやりかただと return や例外やその他いろいろ破綻する可能性が残る。

>>668 スマートポインタはこういった問題を防ぐためにある。

>>672
ARM7,9,11 と PowerPC 系が少し。

> newとdeleteを別々のクラス/関数/スレッド/etcで実行せざるを得なかったりして

そういうときはまず設計を改めたいものだ。
生成期間の管理があやふやになってスマポに頼るような時、
すでに半分棺桶に体突っ込んでるようなもの。どの道破綻する。

>>676
ゲーム? のはずないか。
そのあたりは c++ いけるしな。

>>677
> そういうときはまず設計を改めたいものだ。
メッセージ作って他のスレッドに投げてそのスレッドがさらにまた…
ってな事はしないのか？

スマポが嫌われるのは、多分
・どれを weak_ptr にするかでどうせ後々面倒が起こって、それじゃ delete 忘れ修正の手間と大差ない
・余分なメモリアロケーションが発生するのが嫌だ
のどちらかが大きいのではなかろうか。

参照カウンタではなくリンクリストで実装された侵入型ならどちらも回避できる。
が、リンクリストでの実装は参照カウンタに比べて遅いのだとか。


スマポが delete 忘れを解決するというが、たとえばコンストラクタで new したものを
delete する程度なら、調査追跡も楽だから、スワポなんて無くていい。

スワポがあると助かるのは、例えば、寿命の管理が面倒な場合など。
例えば、何らかのキューにオブジェクトを突っ込む必要があるような場合、突っ込んだ
側にとってはもう不要だが、キューから取り出す側はまだ delete されると困る、という
ような場合。

他には例えば、 Factory メソッドで生成するとか、new するオブジェクトと delete する
オブジェクトが違う場合などは、delete 忘れの追跡が面倒になることもあるから、スワポ
が便利。

スワポが必要になる状況が無いとか、ハンドルとかのスワポ以外の対策があるなら、
別に無理に使う必要は無い。


>>679
俺はスマポ反対ではないが、そういうときにリソースをやりとりして
誰の持ち物か分からなくなるようなのは行儀悪すぎるだろう。

>>680
> ・どれを weak_ptr にするかでどうせ後々面倒が起こって、それじゃ delete 忘れ修正の手間と大差ない
> ・余分なメモリアロケーションが発生するのが嫌だ

なら std::auto_ptr や boost::scoped_ptr を使わない理由は無いな。

> スマポが delete 忘れを解決するというが、たとえばコンストラクタで new したものを
> delete する程度なら、調査追跡も楽だから、スワポなんて無くていい。

そのやりかただと代入やコピーコンストラクタや例外やその他いろいろ破綻する可能性が残る。

> スワポがあると助かるのは、例えば、寿命の管理が面倒な場合など。

スワポってなぁに？

> 俺はスマポ反対ではないが、そういうときにリソースをやりとりして
> 誰の持ち物か分からなくなるようなのは行儀悪すぎるだろう。

boost::scoped_ptr なら移動不可能な単一所有権。
std::auto_ptr (std::uniqe_ptr) なら移動可能な単一所有権。
boost::shared_ptr なら共有される所有権。

単一所有権なら誰の持ち物かは明白。
共有される所有権が誰の持ち物か分からなくなるのは、まぁ当然だよね。

s/std::uniqe_ptr/std::unique_ptr/

> 他には例えば、 Factory メソッドで生成するとか

createみたいなメソッドはもう格上げして、
使う側からしたら　(new, create) <--> delete
という扱いにすればその心配はないかも。

deleteの追跡とやらは、createを呼び出した側での話しになる。

>>658
> なんせ未だにカラム制限のあるコーディング規約もあるくらいだ。
Linux カーネルとか *BSD とか Solaris とかのの話か?

>>681
> なら std::auto_ptr や boost::scoped_ptr を使わない理由は無いな。
scoped_ptr の類まで嫌う人たちがいるのかな？

> スワポってなぁに？
市況2板を見た後だったので FX 脳になってた。

>>684
んにゃ、某大手家電メーカーの特定部署。1行80カラム以内で
コメントは(行単位でないなら)41カラムだかどこだかより前に出現してはいけない。
インデントも確か特殊だった記憶がある。

あー、そういう環境じゃしょうがないよね。

>>686
富士通みたいな所だな。

某fj2で、携帯作ってるトコなんかだと
自動的にテスト仕様書を生成するために

//:　unkがmoreそうな場合はleaveする
　if (iUnk < iMore) {
　　User::Leave(EGodBlessYou);
　}

みたいに、「//:」を0カラム目にしてコメントを書け
という規定があるね

プリプロセスの#includeとかが行頭にないとコンパイラがスルーしたことならあったな。
もう直ったのかshc

20年くらい前かな
関数名のプリフィックスを2文字、機能単位で3文字、ユニークな部分を3文字に制限された
チームがあった

うっせーバカ！現在進行形だ！

今まさに、boostが使えない（or入れるのに手間がかかる）プロジェクトに居るんだが、
std::auto_ptrのみで、このスレで紹介されたような状況を対応する方法はあるのだろうか？

>>693
コピーしたときの妙な特性さえ把握してれば普通に使える奴だよ std::auto_ptr は。
何が心配なの？

>>694
すまん、書き方が悪かった。
一番聞きたかったのは、boost::sheard_ptrでないと解決できないような問題は存在する（多いのか）？
大抵の問題はstd::auto_ptrを駆使すれば問題を解決できるのか。

boost::sheard_ptrはboostが使える環境でないと使えない。（あたりまえだけど）
で、組込み系だと使えるライブラリが制限されていることは多いんで、
boostがあれば解決、だと、現実解にならない場面が多いのよ。

仮に boostがあれば解決だったとして、
boostが使えない環境で boost::sheard_ptr 相当の、
あるいは必要な部分だけの機能を自作することは現実的ではないの？

>>695
そんなもん、「作るものによる」としか言えないに決まってるじゃねーか。
心配している「状況」を挙げないと。

>>695
スレ違い。
本を読んで自分で考えろ。その後まだ質問があれば、適切なスレで質問するといい。

std::auto_ptr はコンテナ（vectorとか）との相性が悪い。

横に長いソースはやめてください
フルHDのモニタでエディタ全画面表示にしてもラップするって酷いお

フォントがでかすぎるんじゃねぇの?

>>701
お前に俺の気持ちは分からない

しらんがな

２０１１年、Ruby,Perl,PHP,Pythonって並べたときにさ
ここで、Ruby以外を選ぶ奴ってマジでなんなんだろうな


本当にバカだな

巣に帰れ

C++のコンストラクタ初期化子のインデントについて

CHoge() : hoge1(0), hoge2(0), hoge3(0), ...

この初期化子を1行1メンバで並べるときインデントはどうしてますか？
VS2008だと半角スペースが2つ入るんだけどMSはそういうスタイルなのかしら

VS って自動で埋め込まれるインデントの
量（空白３つ分とか）をユーザーが設定することはできないの？

どうなの？

>>700
同意だわ。読みづらい。
最近は異常に識別名が長すぎるんだよな。

場合によって、敢えて横長にする人もいるから何とも。
右側は別に文脈を読む上では重要じゃないときとか、似たようなことを連続で書く時とか。

test

スペースやインデントは
コーディングスタイルに含めるべきではない。

これらはコードの文字の長さによって
変わるもので、決まったルールなんか作れない。
短ければ改行入れないが、
ながければ改行入れるでしょう？

スペース・タブ混在インデントは絶滅して欲しい。
一々ソース書いた奴のタブ幅設定の推測しなきゃならんとか腐りすぎだ。
スペースインデントは表示が崩れないだけまだマシだが、
2文字インデントとか2・3・3文字インデントとか変なルールで読むことを強要するあたりやっぱ腐ってる。
って訳でインデントはタブ文字にして、インデント幅はタブ幅設定で好きに設定してくれ。
桁揃えはインデント分をタブ文字、桁揃え分をスペースだと崩れにくい。

整形ツール使えば気にならなくなるし

今作ってるツールの設定ファイルで空白・タブ混在させてるのを思い出した
よく考えたら絶対文句言われるな作りだなｗ

if文が深くなるの避けるために否定にして抜けるのってあり？

if A:
____spam()
____if B:
________egg()
を
if not A:
____continue

if not B:
____continue
spam()
egg()
にするの
if A and Bはなしとして

A=true,B=falseの時の動作が違うことないかそれ

>>716
そうやって間違う元だから、無闇と否定するのはよくない。
真理値表でも作れば間違えないだろうけれど、読む方が間違う元だ。
だからと言って、一々コメントに真理値表を書くのも間抜けだしね。

たまにどや顔でドモルガンの定理を使って書き換える奴いるけど、
そういう奴もしばしば書き換えに失敗しているよ。

>>716
その if が、エラーチェックみたいなやつなら、普通にそうしてる。

>>713
俺がこのスレを開いたときに考えたことと
丸っきり同じ事が書いてあってびっくりした
願わくば今のソース全部再フォーマットしたいわ

ネストしたfor文を意図的に抜けたい時、for文の繰り返し条件のところに脱出フラグも書くのってアカン？
for (初期値; 繰り返し条件 && 脱出フラグ; インクリメント) {
}

>>721
いったん「インクリメント」のところまで戻らせないといけないから、break 脱出い比べてイマイチ感

>>722
for文ネストしててもbreakがいいの？
…
if(脱出条件) {
boolean 脱出フラグ = true;
break;
}
}
if(脱出フラグ) break;
}
if(脱出フラグ) break;
}

俺的には↑これ読みにくいと思ってるんだけど

あ、すまん >>723これスコープが変だわ
boolean宣言はループ入る前にfalse入れとく

その例なら goto で脱出するのが最善だと思う。

C も C++ もなぜか多重ループからの脱出を実装しないね

多重ループを関数やメソッドにつっこみreturnで脱出する方法がある

>>727
やるだけなら goto でいいだろ

> 多重ループを関数やメソッドにつっこみreturnで脱出する方法がある

脱出するためだけにそんなことしたら分かりにくくなるだけ

>>728
C++でもいずれ、foreachとlambdaで
ループを書くのが自然になるかも。
そうなればループ中断はreturnに
なるな。

なんの脈絡もないおれおれ予想乙

gotoで抜けたらスコープどうなんの？
メモリ確保されまままじゃね？
gotoにしろreturnにしろ、スコープからすっこ抜けるルーチンは好きじゃない

スコープがわかってるなら…
Cの場合、
スコープからでたとき（関数からでたとき）、スタックにあるやつは、なくなる（なくなったも同然になる）

「開発者はほとんどの場合gotoの使用を適切に制限しており、
Dijkstra氏が懸念したような無制限な使用は行われていないことが判明した。
これらのことから、実際にはgotoは有害でない」

C言語の開発者によるgoto文の使い方を対象とした実証研究の結果、「goto文は無害だと考えられる」
| スラッシュドット・ジャパン デベロッパー
http://developers.slashdot.jp/story/15/02/14/2017207/
2015年02月15日 13時04分