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

1 名前：デフォルトの名無しさん [2007/10/28(日) 15:59:01 ] コーディングスタイルについて熱く語れ 60 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 03:46:07 ] 私は三つとも上のほうが読みやすいと感じる。 数字の 0 よりも、フラグとか関数呼び出しのが「大事なこと」だと思う。 コミュニティ次第なんだろうね。 ただ私なら、 3 は for (;;) { c = fgetc(stdin); if ( c == EOF ) break; ... } みたいに書く。 61 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 04:45:23 ] 出力（条件比較や返値）より入力（関数呼出や引数）が「大事なこと」だと思えば上のほう、 if ( hogeHoge( parameter_list ) 〜 入力（関数呼出や引数）より出力（条件比較や返値）が「大事なこと」だと思えば下のほう、 if ( 0 < hogeHoge( 〜 ってところではないかな。 定数と一時変数を使えば err = hogeHoge( parameter_list ); if ( err == SUCCESS ) 2 は 1 の問題に出来るな。 ただし 3 はイディオムなので、私でも>>60のように分解はしないな。 62 名前：デフォルトの名無しさん mailto:sage [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( ... になるね。 63 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 08:38:08 ] 定数左に置く人はfor文でもやっぱり左に置くの？ for (i = 0; N > i; ++i) みたいな感じに 64 名前：デフォルトの名無しさん mailto:sage [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 ) って書くん？ 気持ち悪くね？ 65 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 10:11:40 ] それもそうだ。 66 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 10:38:05 ] >>64 不等号の向きが数直線だと思い込む方がどうかしている。 つまり0より大きいと0より小さいがならぶときに、 if (var > 0) ...; if (var < 0) ...; と書くか if (0 < var) ...; if (var < 0) ...; と書くかの違いなわけだが。 例えば、このvarが関数呼び出しになっても後者のように書くということなのだろ? それが気持ち悪いと思えないなら、私とは相容れない種類の人間だと言うことだ。 67 名前：デフォルトの名無しさん mailto:sage [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 より小さい」。 68 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 10:56:56 ] 私は基本的には定数右派だが、不等号については後者かな。 やはり var < 0 ってのは直感的ではないし見ていて気持ちが悪いって感じる。 69 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 10:59:26 ] >>68 おお、これは新しい意見だ。 ついに、var < 0 が否定されたぞ。 70 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 10:59:59 ] >>68訂正 × var < 0 ○ var > 0 71 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 11:04:38 ] 私は < だろうが > だろうが関数呼び出し相手なら if (0 <= func( if (0 == func( if (0 >= func( だなぁ。 72 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 11:07:39 ] >>70 だろうな。 さすがに var < 0 を 0 > var って書く人はいないか。 いないよな？ 73 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 11:10:36 ] よし纏めよう。 ・定数右派 基本的に、常に定数が右。不等号の向きなんて関係ねぇ。 ・定数左派 基本的に、常に定数が左。不等号の向きなんて関係ねぇ。 ・不等号は数直線派 基本的に、不等号は常に左を小さく。定数の位置なんて関係ねぇ。 ダメだ、>71も恐らく例外があるのだろうし分類しきれない…… 74 名前：63 mailto:sage [2008/01/21(月) 11:22:37 ] >>64-72 回答ありがとう なるほどねー 1. 数直線に合わせる派 2.1. 評価対象を常に左に置く派 2.2. 評価対象を常に右に置く派 がいるみたいだね …これ、どっかのMLの過去ログにもありそうだな 75 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 11:42:38 ] 基本的に短い物が左。 そして変数同士の不等号は数直線派。 変数か定数かなんて関係ねぇ。 な俺は結果的に 即値 < 変数・定数 < 式 < 関数 な順番になるな。 定数左ってよりは即値左か？ 画面が狭かった頃の規約の名残だな。 76 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 13:24:24 ] こんなものは理屈じゃなくて、数学の記法では普通 0=x でなく x=0 と書くというのが一番大きい気がするけどな 不等号は3項関係なら数直線だが2項関係ならやはり変数を左辺に書くのが数学でも一般的だと思う 77 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 13:59:49 ] その理屈だと関数が絡んだときにおかしくないか？ 数学だとy=f(x)の方が一般的でないか？ 78 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 14:12:06 ] >数学だとy=f(x)の方が一般的でないか？ その記法は定数相手には使わないような。 確かに y については y = f( x ) 的な書き方をするけど、f(x) については f(x) = a * x + y 的な書き方もするはず。 だからまあプログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、それでも変数と定数に限れば 0=x ではなく x=0 だろう。 これはもう理屈とか抜きに。 79 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 14:27:50 ] >>78 数学に限って言えば、 ＞0=x ではなく x=0 だろう これは状況によりけりだな。まぁ、 ＞プログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、 は正しいと思うので、数学のルールは適用できないんだけどね。 80 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 16:34:55 ] &&とか||が絡むなら不等号の向きをそろえるけど それ以外なら気にしないな。 81 名前：デフォルトの名無しさん [2008/01/21(月) 16:36:21 ] またこの話か。去年さんざん「祭り」したのに。 もう秋田。 82 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 18:25:42 ] わざわざ来なくてもいいのに（笑） 83 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 18:34:21 ] 基本的には数直線に合わせるけど、場合によっては変えるね。 言葉や数式で表現するとどうなるかを頭に置きながら 理解しやすい方を選択する。 84 名前：デフォルトの名無しさん [2008/01/21(月) 20:01:32 ] Cプログラマの為に、ポイントをまとめたドキュメントを販売しています。 プロのプログラマでもあまりにレベルが低い人が多すぎます。 そんな人に限って、自分のレベルの低さを自覚していない、、、 　本人は構わないかもしれませんが、その下についた新人プログラマは たまったものではありません。（私が経験しました。） 　今になって分かりました。 彼らもまた、理解できていなかったのです。 　プログラミング言語の一番の習得の近道はきちんと理解している人にアドバイスをもらうこと。です。 私のC言語に取り組んだ7年間をすべてぶつけたつもりでテキストを作りました。 　私の会社の後輩からは、どんなテキストよりもわかりやすかった！や、 今まで教えてくれていた先輩や、テキストたちが、ちゃんと理解できていないことがわかりました。 と、嬉しいコメントをたくさんもらいました。 そしてなにより、彼らの社内での評価がとても高いということが、私の誇りです。 　興味がある方はどうか、下のサイトをみてみてください。 mori.eco.to/ 85 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 20:04:01 ] ｳｾﾞｪ 86 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 21:33:16 ] みるまでもなくネタだろ 87 名前：デフォルトの名無しさん mailto:sage [2008/08/02(土) 01:43:31 ] 最近、カプセル化は要らん子な気がしてきた。 真面目に適用したところで可読性や保守性は上がるどころか下がることの方が多いし、 getter/setterを書くより、コメントやドキュメントをしっかり書いた方が良い気がする。 88 名前：デフォルトの名無しさん mailto:sage [2008/08/02(土) 02:58:06 ] getter/setter が無いと、ついつい直接書き換えして 後の挙動が掴めなくなってしまう俺みたいな屑も居るので書いてくれて良い 89 名前：デフォルトの名無しさん mailto:sage [2008/08/02(土) 09:35:09 ] つーか、そもそも下駄雪駄がある時点で間違いだろ。ちゃんと意味を考えたI/Fにするべきだ。 90 名前：デフォルトの名無しさん mailto:sage [2008/09/28(日) 15:35:28 ] >>87 getter/setterがある時点でカプセル化に失敗してるよ 91 名前：デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:00:45 ] getter/setterだけでも、代入と取得のみに操作を限定できる利点がある。 メンバのアドレスを取られる心配がないだけでも幾らか安心感があると思うよ。 92 名前：デフォルトの名無しさん mailto:sage [2008/09/28(日) 20:03:24 ] ブレークポインタもかけやすいしな。 だけとgetter/setterが多くなるとカプセル化の意義が薄れてしまうのも忘れてはならないね 93 名前：デフォルトの名無しさん mailto:sage [2008/09/29(月) 03:59:22 ] 設計から導き出されるのが、いい getter/setter 実装から導き出されるのが、悪い getter/setter 悪い getter/setter でも、将来の変更に備えて、無いよりマシ。 94 名前：デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:42:58 ] 基本的な値はコンストラクタで受け取るだけで、その後はgetterのみ。 どうしても後から値を変更する必要があるとか、設定値の種類が多すぎる場合のみsetterを使うかな。 95 名前：デフォルトの名無しさん mailto:sage [2009/02/03(火) 14:10:18 ] 無限ループは while(true){ } って書くのが一番美しいと思うんです 96 名前：デフォルトの名無しさん mailto:sage [2009/02/03(火) 14:28:30 ] for ("ever") { } 97 名前：デフォルトの名無しさん mailto:sage [2009/02/03(火) 19:29:38 ] >>95 それは意図しているのかそれともミスなのかが判断できない。 for(;;) { } このほうが意図が明確 98 名前：デフォルトの名無しさん mailto:sage [2009/02/03(火) 21:00:25 ] 誘導されてきました int* a; int *a; どっちのほうが見やすいですか？ 99 名前：デフォルトの名無しさん mailto:sage [2009/02/03(火) 21:32:24 ] int*型として考えるなら前者 変数自身がポインタと考えるなら後者 100 名前：デフォルトの名無しさん mailto:sage [2009/02/03(火) 22:04:58 ] int* a, b; とかやられるとヤヴァイから後者がいい 101 名前：デフォルトの名無しさん mailto:sage [2009/02/03(火) 22:32:07 ] ポインタ型と普通の型をまとめて宣言しないでほしい 102 名前：デフォルトの名無しさん mailto:sage [2009/02/03(火) 22:37:07 ] resありです＾＾ 103 名前：デフォルトの名無しさん mailto:sage [2009/02/03(火) 22:55:50 ] >100 こんなのコンパイルエラーで検出出来るだろJK 104 名前：デフォルトの名無しさん mailto:sage [2009/02/03(火) 23:31:31 ] >>103 コンパイルに数分かかるプロジェクトを書いた事が無いのか 105 名前：デフォルトの名無しさん mailto:sage [2009/02/04(水) 00:31:53 ] >>100 変数宣言分けるからどうでもいい 106 名前：デフォルトの名無しさん mailto:sage [2009/02/04(水) 00:42:39 ] そもそも1行に2つも宣言しないよな 107 名前：デフォルトの名無しさん mailto:sage [2009/02/04(水) 10:03:18 ] テンプレートではint*で１つの型なのに、>>100の例があるから困る。 でも俺はint* a;派。 108 名前：デフォルトの名無しさん mailto:sage [2009/02/04(水) 10:55:18 ] 結局、CもC++も書く私はint * a;で落ち着きましたとさ。 109 名前：デフォルトの名無しさん mailto:sage [2009/02/04(水) 12:23:17 ] >>107 俺もint* a派。型を意識したりテンプレート使うとそうなるよね。 複数宣言はしない。行を分けてコメントを書く。だから>>100は無いものとしてC/C++で書いてる。 110 名前：デフォルトの名無しさん mailto:sage [2009/02/04(水) 13:04:35 ] >>100 絶対賛成！ 型がどうこういってるやつは、 typedef int *intpとかするがいい。 111 名前：デフォルトの名無しさん mailto:sage [2009/02/04(水) 21:26:38 ] ポインタを typedef した時の const の挙動がなあ・・・ 112 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 00:51:29 ] Code Complete には int *p にせよと書いてあったが、俺は >108 方式。 >>104 リンクまで込みでじゃなくて、一つのファイルをコンパイルするので？ そこ辞めてヨソ行った方がいいかも。 113 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 01:00:05 ] >>112 趣味で書いたやつでテンプレートをひどく使ってそういう事態になったことはあるが、 仕事なら絶対にできないな。 114 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 09:44:40 ] なんでC/C++は宣言の時、int *a, *b;という構文にしたんだろう？ キャストやテンプレートではint*を使うことになるのに。 スレ違いか。 115 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 17:16:21 ] >>114 *aがint型と読めるという話はよく聞く。 関数・配列が複雑に絡み合ったのも、そうやって解読していくし。 C++はCとの互換のため。 116 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 19:33:24 ] >>114 constへのポインタとconstポインタを はっきり書きわけられることはメリット。 ぱっと見はわかりにくい文法だけど、 関数へのポインタとかも含めていろいろ わかってくると、全体としては悪くないと 納得せざるをえないと思う。 117 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 20:44:49 ] >>116 それがどうした 118 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 21:24:38 ] >>116 const int* a, b;// aもbもconstへのポインタ int* const c, d;// cもdもconstポインタ こういう文法にして欲しかった。 関数へのポインタの宣言はかなり気持ち悪く感じる(typedefの挙動なんか特に)。 こっちもなんとかして欲しかった。 119 名前：デフォルトの名無しさん mailto:sage [2009/02/05(木) 21:28:31 ] でも、ポインタを戻り値とする関数と区別するためにはやむを得ないんだよな・・・ 120 名前：デフォルトの名無しさん mailto:sage [2009/02/07(土) 04:21:07 ] >116 単純に記述量を減らすためかと。 例： int a = 1, *p = &a; 121 名前：デフォルトの名無しさん mailto:sage [2009/02/07(土) 10:03:22 ] >>120 別の型を1行で宣言したいと思わない。 むしろint *a,*bがint* a,bで宣言できたら、1行で宣言する変数が１つ増える毎に1文字タイプ量が減ってありがたい。 122 名前：デフォルトの名無しさん mailto:sage [2009/02/07(土) 10:16:16 ] >>119 関数へのポインタの宣言は例えばboost::function風に void F(int); function_ptr<void, int> a = &F; これなら見やすい。 123 名前：デフォルトの名無しさん [2009/02/07(土) 17:22:52 ] 今でも、C++でBoost使えば、functionっぽく書ける。実際に使うかどうかは別として。 void f(int, double); boost::mpl::identity<void (int, double)>::type* pfn = f; //void (*pfn)(int, double) = f;と同じ まあ素直にtypedefすべきだな。 124 名前：120 mailto:sage [2009/02/08(日) 00:38:56 ] 無名の構造体て書けなかったっけ? そのポインタを宣言するのに必要な気がする。 struct ｛ ｝ obj, *p; 125 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 00:41:41 ] それって、コンパイラが勝手に適当な名前を付けるやつだっけ 126 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 10:25:49 ] >>124 そのp使い道なくない？ 型名が無名だから関数の引数に渡せるわけじゃないし、ヒープから確保することもできない。 127 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 12:50:57 ] インスタンスが２つあれば、その切り替えに使えるかもしれないが、 ま、そこまでするなら型名付けた方がいいと思う。 128 名前：デフォルトの名無しさん mailto:sage [2009/02/08(日) 13:07:35 ] typedef struct ｛ ｝ t, *p; こんなのなら見るけど 129 名前：デフォルトの名無しさん mailto:sage [2009/02/09(月) 21:09:40 ] >>99 C言語のこの仕様はポインタの理解をさまたげてくれたなあ・・・ Delphiは前者が前提なんだが、C挫折してDelphiやってはじめてポインタの概念がわかったよ俺は ポインタって「なんとかのポインタ」で1つの型なんだ、と気づくまでにやたら時間がかかた。 130 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 12:22:29 ] ポインタ宣言に使う記号がアスタリスクなのもややこしいよね。 ポインタ絡みで間接演算子使うだけに。 131 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 12:28:56 ] if(flag){ } if(flag == true){ } どっちを選べばよいか･･･ 132 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 12:34:02 ] >>128 構造体の typedef 禁止 133 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 13:29:14 ] >>131 前者に決まってる。論理定数との比較は無意味。 www.kouno.jp/home/c_faq/c9.html#2 134 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 15:04:14 ] if(flag){ この間にいくつスペースを挟めばいいのかわからない 135 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 16:26:13 ] 入れなくてもいいし、入れるのならif (flag) {がお勧め。 136 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 17:11:33 ] "if"の後に一個、 "("の後に一個、 ")"の後に一個スペースを入れないと、 かつ、二個以上入れた場合、コンパイルできない とかいう仕様だったらいいのに。 俺は末期か・・・ 137 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 20:49:28 ] if の後に空白を入れるスタイルだと、 条件が二行以上に渡る場合に４タブで綺麗に揃う 138 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 20:52:17 ] >>136 MS信者？ 139 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 20:53:07 ] if ( hoge) { こうか？ バランス悪すぎ 140 名前：デフォルトの名無しさん mailto:sage [2009/02/10(火) 23:27:25 ] >137 漏れはこう if( 条件1 || 条件2 ) 141 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 00:28:58 ] 既存のコードにあとから手を付ける場合は、出来るだけ合わせて書いてるな 142 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 01:38:12 ] 最近はワイドモニタだから、右に長くなりがちだなぁ。 基本は>>140と一緒だが。 143 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 01:57:32 ] じじいに言わせると80桁を越すと犯罪らしいぜ 144 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 02:00:18 ] コーディング規約でも規定されない限り、横の長さはそれほど神経質に考えないな ある程度は工夫するけど 145 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 03:22:49 ] モニタが大きくなるとかえって80桁とかに縛りたくなる。 横にいくつもウィンドウを並べてみるのに都合がいい。 146 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 06:14:45 ] 端末エミュレータを三つ並べても100桁表示できるご時世だから、気にしてもねぇ。 そんな私はどちらかと言えばこっち。 if (条件1 ||    条件2) { 147 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 15:00:02 ] デバッガでトレースしやすいように１行で書いてる。 if (条件1 || 条件2 || 条件3 || 条件4 || 条件5 || 条件6 || 条件7 || 条件8 || 条件9 || 条件10) { 148 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 15:06:14 ] ソースコード関係ないけど、未だにWindowsのデスクトップの縦のアイコン数は、1024ｘ768時代の数だなｗ でも最近Windows7使ってると、その傾向はなくなってきた（Vistaは常用したことない） エディタは、文字数による改行なしで設定するのが俺のジャスティスだな 149 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 22:19:15 ] >>133 別に後者がいいとはまったく思わないが trueとTRUEは違う よってそのリンク先は根拠にならない 150 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 22:25:43 ] >>149 true でも TRUE でも以下の話は同じ。 > もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか 論理定数との比較自体が無意味。 151 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 22:26:58 ] ((a == b) == TRUE) ↑これ何の冗談？ｗ 152 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 22:30:57 ] >>151 つまりそういう皮肉 153 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:00:51 ] >>150 それ、主題じゃないし さらにその例はFAQそのものが不適切だ 論理定数との比較云々じゃなくて（そこは同意する） そのFAQが違うだろって話ね 154 名前：デフォルトの名無しさん mailto:sage [2009/02/11(水) 23:16:29 ] >>153 うるせぇなぁ。少しは応用しろよ。 >131 へのレスで挙げてるんだらこういうことだろ。 もし if(flag == true) が if(flag) より良いと思うのなら、なぜそこで止めるのか。 なぜ if(flag == true == true) を使わないのか。 155 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 01:10:46 ] 処理上は無意味でも if ( flag )より if ( flag == true )のが わかりやすくないか？ 156 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 01:13:50 ] それじゃflagが２だったらとおらねぇだろ 157 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 01:16:11 ] それでいいじゃんｗ 2が入ること自体がおかしい 158 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 01:27:37 ] >>155 処理上は無意味でも if ( flag == true )より if ( flag == true == true )のが わかりやすくないか？ 159 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 01:41:46 ] trueはfalse以外が仕様だからそれじゃダメだっての。 if ( flag ) if ( flag != false ) これ以外は許されない 160 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 01:47:26 ] >>159 flag の型がちゃんと bool ならどっちでもいっしょ。 それよりも if ( flag != false != false ) のが（以下略 161 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 02:12:25 ] >>160 C言語だとダメなやつもあるから、0と0以外にしとくのが安全なスタイルってもんだよ。 比較演算の結果でてくる論理を比較するのもありだけどね。 assert( (p == NULL) != false ); 162 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 02:15:40 ] >>161 わざわざ「flag の型がちゃんと bool なら」って書いてあるのに何言ってんの？ > assert( (p == NULL) != false ); ねーよ 163 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 02:33:29 ] いやいや、そこはこうでしょ assert( (p == NULL) != false != false);ってのが(ry 164 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 02:47:00 ] だからさ、FAQの > もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか これがそもそもおかしい おそらく原作者はジョークのつもりだったろうが、真に受けてるアホがいるからな・・・ 165 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 02:58:25 ] Cの(ユーザー定義の)TRUEとC++の(言語の)trueの違いがわかってない奴がいるな Cでif(flag==TRUE)は間違いだが、C++でif(flag==true)は書き方の問題だ 書き方の問題＝好みだよ ここでif((flag==true)==true)を持ち出す奴はジョークが理解できないってことだ 166 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 03:50:19 ] >>164 で、何がいいたいの？論理定数との比較を擁護するつもりなの？ 167 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 04:00:02 ] >>165 はなから技術的な正しさとか間違いとかを問題としてるんじゃない。 論理定数との比較に意味が無く、混乱の元でしかないから書くべきではないという話だ。 (... == true) も (... != false) も同じくらいに意味が無い。 168 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 04:43:58 ] 意味あるじゃん ある特定の人間にとっては見やすいという意味が 169 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 05:01:14 ] カスみたいな意味だな。 170 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 10:58:38 ] 一番ダメなのは is〜, has〜, can〜 などの自然に読み下せるように工夫した命名規則を 台無しにしてしまうこと。 if (x.isReady()) で済むところを if (x.isReady() == true) だの if (x.isReady() != false) だの わざわざノイズを混ぜるのが許せない。 171 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 11:49:41 ] 俺はif(flag)派だが、if(flag==true)なソースを見てもいちいち噛み付かないな TRUEは明らかに不味いがtrueは見た目の問題、見易いかどうかは主観だからな それをノイズと感じるのも自由だし、そんなのは人に押し付けなければどっちでもいい それよりTRUEとtrueを混同して大昔のFAQを持ち出したり、 技術と好みの違いが分からない奴の方がスキル低いだろ 172 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 13:42:38 ] TRUEとの比較には問題があるなんて>>133なども当然理解しているだろ。 それは誰もが理解しているという前提で、本筋からそれるのでスルーしただけにしか思えない。 173 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:31:56 ] 初見のソースでif( hoge == true ) と書かれていると、hogeがboolになっているか、 そうでなければtrue/falseの2値しか取り得ないのかチェックする手間が生じる。 初見じゃなくてもどうなってるかいずれ忘れるかもしれない。 （そんなの気にしないとかってのは論外過ぎる） if( hoge != false ) も、万人がつっかえず読めるソースであるとは言い切れない。 174 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 00:20:00 ] もしかしてflagが２でも==trueなら通るのか？ 175 名前：デフォルトの名無しさん [2009/02/13(金) 00:35:12 ] flagに2が入っている時点で不具合だとしか思わない bool型ならな 176 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 01:02:25 ] 素直に!=falseにしとけよ。 177 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 04:07:26 ] >>172 理解してたらtrueに対してFAQ(TRUE)を持ち出さないだろ 178 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 10:51:29 ] ヘンなケースだけど if (flag) 形式は うっかり bool の配列を渡してハマりそうになったことあるなぁ bool array[2]; if (array) みたいな 179 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:13:43 ] >>173 初見のソースでif(hoge==1)と書かれていると、hogeがintになっているか、 チェックするのか？しないだろ？ ただのいいがかりじゃねえか、おまえの頭が論外だよｗ 180 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:19:19 ] 読み違えてるよ 181 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:23:58 ] hoge == 1 は何とも思わないが、 hoge == true を見つけたら bool 値に対する理解が 不十分な可能性を疑わざるを得ないだろうね。バグを探してるときならなおさら。 signed/unsigned が混在してたり、可変長引数にキャスト無しの NULL を渡してたり、 ループ変数に char が使ってあったりするのと同じ。言語仕様の不十分な理解から出る バグのにおいがする。 182 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:37:11 ] hoge==true見つけただけで言語使用を理解してない可能性を疑うってどんだけレベルの低い環境なんだ ところで181の挙げた例に細かいミスがあるんだが、普段の俺ならスルーしてあげる だが181の論理によれば、俺からみたら181は言語使用を理解してないと疑わざるを得ない 183 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:38:48 ] 言語使用→言語仕様 184 名前：181 mailto:sage [2009/02/13(金) 14:43:46 ] 何かミスがあるというなら言語仕様を理解していないと疑われるのはしかたがないと思うけど、 できればはっきりと指摘してほしいところだね。 185 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:46:01 ] どうせハッタリだろ。 186 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 15:08:25 ] なんか話ずれてるけど 173はif(hoge==true)ならhogeがboolかチェックするんでしょ？ もうその時点でありえないんだけど、そんな底辺レベルの職場なら if(hoge==1)でもhogeがintかチェックする必要がある、チェックしないのはダブスタじゃん って意味だよね、違う？ 普通の職場なら同僚やらオープンソースで if(hoge==true)見つけても、「あらあら、このひとはtrueと比較しちゃうんだ」って思って終わりだよ どんだけ病んだ職場で働いてるんだ、転職したほうがいいよ 187 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 15:25:30 ] >>186 hoge == true （あるいは hoge != false ） を書くような人は bool 型や if 文になどついての理解が あやふやな可能性が高いので、同様に理解の不足から int == true などという間違いを犯している 可能性があることを推測できる。 hoge == 1 を見ただけではそのような推測はできない。 関連箇所でのバグを探してるんじゃなければスルーすることも多いだろう。それが普通だというのも 妥当な話だ。しかし、スレタイを読む限りここでそれを主張するのは無意味だろう。 188 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 20:14:16 ] あのさ, if (is_true_this(x) || is_true_that(x)) { } ってコーディングを許してくれないのはなぜ? 仕様的に副作用がない事を要求されている関数使って、なんで this_is_true = is_true_this(x); that_is_true = is_true_that(x); if (this_is_true || that_is_true) .... って、かかんとあかんわけ? 189 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 20:15:31 ] 関数が何返したのか分かりにくい 190 名前：173 mailto:sage [2009/02/13(金) 22:09:36 ] >179,182 if( hoge == TRUE )のケースを考えてみてよ。 hogeは本当にTRUEかFALSEしか取り得ないのか不安にならない? 漏れが指摘したいのはむしろこっちの方なんだよ。 if( hoge == true )の場合は気にし過ぎってのは素直に認める。 （コンパイルすりゃすぐ分かるというのはEnter押してから気付いた） でもバグ発生時には疑うべき記述だと思う。 191 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 23:40:30 ] if ((!!flag == true) != false) { 　　flag = true; 　　flag = true; // 念のためもう一度 } これくらいやっとけば安心 192 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 00:48:46 ] 実際、trueやfalseと比較し捲くっているコードを整理したら、若干ではあるけど 所要時間に有意差が認められたからなぁ。 193 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 01:01:22 ] (1) if( hoge == TRUE ) (2) if( !!hoge == true ) (3) if( hoge == true ) (4) if( hoge ) 最悪のケースを想定した場合、読み手が考え込む時間が一番短いのは(4)でしょ。 ifの動き、hogeの値、コーディングスタイル、ネーミング位しか悩める要素が無いんだから。 他は最悪、型とか脳内演算とかで、余計な思考時間を生んでしまう恐れがある。 194 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 01:35:45 ] true との比較では所要時間に差は出るだろうが false との比較で差が出るのは最適化レベルがおかしいんじゃないのか 195 名前：192 mailto:sage [2009/02/14(土) 01:41:23 ] >>194 trueもfalseも纏めて整理したから、falseの有無で差があるかは確認していない。 196 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 01:42:04 ] あえて(2)を混ぜて誤魔化してないか？ｗ 197 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 11:27:41 ] trueと比較しない場合 >>178みたいなのでハマるくらい? 198 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 11:52:14 ] 逆にboolをtrueと比較して困るケースの具体例、つか経験談ってある？ 199 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 11:58:59 ] >>198 1以外の値が入ってるときとか。 200 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 11:59:12 ] >>198 >194 201 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 16:47:04 ] ちょっと違う話かも知れんが、 if (式) { 　return true; } else { 　return false; } なんてプログラムを見ることがたまにある。 最初からreturn 式;にしろよ、って思う。 202 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 16:48:03 ] 変更になりそうな箇所がおおいならそう書くこともある。 203 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 19:46:26 ] 漏れはこうだなあ。 if (式) { 　return true; } return false; 204 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 19:54:47 ] そういうのを書く時は最終的にtrueを返すようにしてるな 205 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 19:55:23 ] return (式) ? true : false; 206 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 21:41:18 ] >>205 これはないな。 207 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 21:58:37 ] 式が関数でtrue/falseの意味が取り違える可能性があるような名前ならアリかもな。 208 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 16:12:23 ] >>205 俺もこれだけはやっちゃダメだろとは思う マクロならそうなるけど 自分のことしか考えてないタイプ 209 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:18:59 ] static _Boolean checkLevel( double value, double level, _Boolean reverse ) {   if ( reverse == _False ) {     if ( level <= value ) {       return _True;     }   } else {     if ( value < level ) {       return _True;     }   }   return _False; } -- これ見たときはどうしてくれようかと思った。 210 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:55:06 ] 設計書にそういう「ロジック」を書いてるんだろうなあ。。。 1. 引数は値、レベル、反転フラグとする。 2. 反転フラグが _False であれば、以下を行う。 　　1) ・・・ 3. 上記以外の場合、以下を行う。 　　1) ・・・ 日本人プログラマが10人いれば、8人は何も考えずにコーディングを行う。 1人は、「反転フラグて。。。呼び出し側で結果を反転させりゃいいのに。。。」とか思いながらコーディングを行う。 残りの1人だけが「なんで設計書にロジック書いてんだｗｗｗこの現場やべえｗｗｗ」と笑い、辞める。 211 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 18:11:22 ] >>210 設計書を書いた奴と相談するっていう選択肢が無いのが悲しいな。 212 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 20:05:55 ] _Booleanはどういう定義なんだよソレｗ 213 名前：209 mailto:sage [2009/02/15(日) 20:14:34 ] >>212 おっと、書き忘れてた。 ＞typedef enum { _False = 0, _True = 1 } _Boolean; だとさ。ちなみに、Sun-OSのcc(標準ではc99としてコンパイルする)を使っているのに c99禁止と言う不思議なコーディング規約(と言っても明文化されていない)だし。 >>210 >209のコードに関しては、設計者=コーダーの可能性大。 214 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 05:43:24 ] "<="や">="を書くことが幼稚な気がして今まで避けてきたんだが "<"や">"は小数を扱うのが正しい使い方で、 整数を扱う場合はイコールをつけたほうが直感的な気がする for(int i=0; i<10; i++) ってのが一般的で10回カウントするってのが直感的にわかるけど なんというか、行って帰ってきて結果的にはあってるって感じで、 for(int i=0; i<=9; i++) のが1から9まで1ずつカウントするって意味で 正しい使い方な気がする 215 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 05:47:32 ] １からじゃなくて０からでした 216 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 06:00:51 ] >>205が何でだめなのか、プログラミング初級者の俺に教えてくれ 無駄がなくてわかりやすいと思うんだが 217 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 07:21:32 ] 1. 返り値がニ値しか取りえないなら、isHoge関数にすべき 2. 構文糖衣はあくまで糖衣 3. 流し読みする時に目に入り辛い (最後の行だからいい？一カ所使われていると、 複数箇所使われている可能性が高いから、結局同じこと) 218 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 07:39:52 ] >>214 ＞１からじゃなくて０からでした こういう馬鹿が居るから直感的じゃないんだよ。 219 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 09:29:50 ] >>216 「? true : false」の部分が丸々冗長。 単純にこれを消しても同じ意味だよ。 220 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:36:57 ] 式が bool 型ならそうだろうが そうじゃなけりゃえらい違いだよ。 bool 型へのキャストは警告出すコンパイラがあるんで、 やむを得ず ? true : false としないといけない。 マクロ化したいけど、作ってもみんな使ってくれないし・・・。 221 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:44:33 ] 強制的に bool にしたいなら !!(式) でいいだろ。 222 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:56:47 ] Cだったら、0か0以外にしとけばいいんだよ。 223 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:59:57 ] >>220 条件演算子なんか使わなくても、比較式入れとけばいいじゃん。 224 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:10:01 ] 真偽値を比較するなんてとんでもない！ 225 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:26:09 ] >>224 真偽値だったら、そのままreturnすればいいんじゃね? #define true 0 #define false -1 ↑みたいな変態的な定義でもされてたら、条件演算子もやむなしって気がするけど。 226 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:44:02 ] 自分だったら!!よりは? true : false選ぶなあ。 227 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:48:27 ] >>225 bool hoge(int ch) { 　return isupper(ch); } isupper の戻り値は真偽値（int 型の非0/0）だが bool ではない。 コンパイラによってはそのまま return すると文句言われる事がある。 228 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:58:38 ] >>227 いや、だから、真偽値以外だったら、比較にすればいいんじゃね?って話。 　return isupper(ch) != 0; 229 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:58:49 ] >>225 それが標準だったらどんなに良かったかと常々思ってる。 230 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:03:33 ] >>229 trueやfalseが標準で定義されていて、 n > 0 みたいな比較式の結果と違う値になってたらよかったってこと? 231 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:15:34 ] >>228 真偽値を比較するなんてとんでもない！ ぶっちゃけ読み辛くてしゃーない。 232 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:23:21 ] >>231 ああ、それはそうだな。 Cライクな真偽値と、C++のboolを併用するときはしかなないのかね。 static_cast<bool> とかするとどうなるんだろう。 233 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:25:08 ] VC++はboolへのあらゆる直接的な変換は警告出した気がする 234 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:25:56 ] g++はノーキャストでも完全スルーなんだが 235 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:52:23 ] >>220 式が bool じゃなくて return するのに問題があるというのなら、 ? の左に書くのだって同じ問題があるはずじゃないか。 やっぱり、? 以降は単純に冗長だよ。 236 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:58:25 ] だーかーらー、五月蝿い警告が出るコンパイラへの対策なだけだと言うとるに。 どのコンパイラでも警告でないならそのまま返したいさ、そりゃ。 237 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 01:36:14 ] >>236 うるさいっていうかアホだろ。 return での bool への変換は警告するのに ? 演算子の前に置いたときの bool への変換は出ないとか、 意味がわからん。 そもそも警告を黙らせるためのコードなんか書いちゃいけない。 警告によって指摘された問題に対策しないといけない。 238 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 04:04:58 ] そりゃそうだ。C/C++に、?の左側に置いた式はbool型に変換されるなんて規則はないから そこでbool型への変換だなんて警告が出るわけない。 239 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 04:33:49 ] >>238 何を根拠にそんなこと言うの？ C++ の ? は bool に変換して評価するよ。 5.16 Conditional operator p1 > The first expression is contextually converted to bool (Clause 4). 240 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 05:14:14 ] そうだったのか。 C99だけ見ていたが、こっちは、0と比較して云々となっていて、 _Boolへ変換するとは書かれていなかった。 C++もそんな調子だと思っていたよ、すまない。 241 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 13:47:17 ] C99 なら _Bool f(int x) { return x == 1; } でも比較演算自体は int だから警告が出るというのか？ それもアホだな。 242 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 14:45:41 ] そんなこと言ったら C99 では true も false も int 型なわけで。 結局のところ "? true : false" がまったく冗長なだけの記述には違いないね。 243 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 19:22:44 ] ECMAScriptなら冗長でないよ 244 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 21:31:42 ] どでもいいけど、システムハンガリアンって呼ばれてる 変数のタイプをプリフィックス/ポストフィックスとして つける命名規則だけは絶対裂けるべきだ 一部に改訂が入って、使ってる型の定義が変わった場合の メンテナンスはとんでもないことになる 245 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 00:03:28 ] 下手に否定するより、よりベターな手法を教えてそっちに誘導した方が良い。 チーム全体に徹底させるだけの権限と統治力を持ってない場合は特に。 人は力強く押さないとあらぬ方向に進むが、引っ張れば割とすんなり思った方向へ進む。 246 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 12:32:31 ] >>244 WIN16→WIN32→WIN64の悲劇ですね。 247 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 21:33:35 ] WORD型やDWORD型なら、typedefを書き換えればいい たぶん・・・ 248 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:15:01 ] スタイルスレで聞きたいと思ったことが１つあるんだ。 C++のcppの方にソースを見やすくするために関数を小分けにしたものを staticで記述して使ってるんだが、private関数にするべきかね？ 249 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:28:51 ] >>248 privateにしなくてもいいんじゃね? C++のprivateって、そもそもが美しくないし。 250 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:47:33 ] どっちかっていうと、外部にも派生クラスにも公開する気がない関数はクラスに含めるべきじゃないと思う。 クラスのインターフェイスとは関係ない、実装側だけの問題なら、実装側で完結してるほうが美しい。 static 関数なら、いくら変更しても外部には影響しないし。 251 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:02:01 ] 継承したときにvirtualつけて使いたいけど、クラス外からは使われたくないものに だけつけときゃいいのか。 252 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:02:30 ] static関数化できるものなら、Utilityクラスとかにして 外に出しちゃうのも良い鴨 253 名前：249 mailto:sage [2009/02/20(金) 00:05:44 ] staticって、クラスのメンバとしてか。。。 勘違いしてた。 254 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:16:57 ] メンバのstaticではなく実装用の小規模な補助関数ってことで。 255 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 01:12:07 ] >>248 .cpp ローカルな関数は static じゃなくて無名名前空間を使う。 private にすべきかどうかはクラスのメンバであるべきかどうかで区別する。 何も考えずに書くと private 関数の宣言をヘッダに書くことになるんで何かおかしな 感覚になるけど、 pimpl とかインターフェース継承とか使って隠せば問題ない。 256 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 01:22:53 ] なるほどね。いわゆるCのstatic関数ってのは推奨されてないのかな。 そこまで意識して気をつけようとも思わないけど、気が付くと疑問に思う。 257 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 01:25:22 ] >>256 関数や変数だけならいいんだけど、 C と違って .cpp ローカルな struct や enum も グローバルに置いてると定義がかぶってアウトだから、なるべく無名名前空間を使う 癖をつけておいたほうがいいよ。 258 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 12:56:17 ] >>257 それだけなら別にアウトじゃない。 規格としてはダメかもしれんが。 ただ、メンバ関数はリンケージをファイル スコープにできないから、無名名前空間が 絶対必須。 259 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 17:20:06 ] addとappendや、eraseとremoveの使い分けってどうしてる？ 260 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 17:28:41 ] addは追加、appendは付加。 eraseは消去、removeは除去。ついでに言えばdeleteは削除。 まぁ、それでも巧く決まらないときは既存ライブラリの命名に倣ったりするが。 261 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 17:48:20 ] ロングマンで一通り調べてみた appendは追記みたいな 順序付きリストの末尾に付け加えるということなのか add⊇append 議論領域をUとすると remove A from Bの操作の後はA B∧A∈Uだけど erase A from Bの場合はA B∧A Uとまぁそんな感じ？ delteはcomputer上での操作を強調してあったけど メモリから消えるって事だからプログラミングっていう議論領域だとeraseに近いのかな？ 262 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 21:03:27 ] erase(A) はAによって識別される何かを削除する delete(A) はAを削除する remove(A) はAを取り除くが削除されるかどうかは仕様次第 263 名前：デフォルトの名無しさん mailto:sage [2009/02/22(日) 13:37:57 ] append は後ろに追加するような意味だから 例えば map や set には使えない でも add なら使えると思う 264 名前：デフォルトの名無しさん mailto:sage [2009/02/22(日) 17:56:13 ] 使われ方みると前 insert,後 appendで対って感じだな 265 名前：デフォルトの名無しさん mailto:sage [2009/02/23(月) 13:48:14 ] ちなみに、先頭に加えるのは prepend っていう。 266 名前：デフォルトの名無しさん mailto:sage [2009/02/23(月) 14:29:25 ] 難しく考えないでAddFirst/AddLastでいいと思う javaや.NETのコレクションではそうなってる 267 名前：デフォルトの名無しさん mailto:sage [2009/02/23(月) 16:32:13 ] 似た言葉をニュアンスの違いで使い分けたりするのはやめるべき 268 名前：デフォルトの名無しさん mailto:sage [2009/03/21(土) 10:44:11 ] ははは 269 名前：デフォルトの名無しさん mailto:sage [2009/04/17(金) 16:59:50 ] 突然このスレにたどりついた俺は if(hoge(var) == 0) じゃなくて、絶対 if (0== hoge(var)) 派だ なぜなら左辺が変数のときに if(var == 0) じゃなくて、絶対 if (var = 0) と書いてバグらせてしまう 奴がプロジェクトに出るからだ（中々見つけにくいんだな、このバグ） 後、関数の出口の return が必ず末尾の一つだけってプロジェクトに 参加したことがあるけど、処理の条件が変わっても、メモリリークが 出にくい構造になるのは良いと思った 270 名前：デフォルトの名無しさん mailto:sage [2009/04/17(金) 17:10:55 ] > 後、関数の出口の return が必ず末尾の一つだけってプロジェクトに > 参加したことがあるけど、処理の条件が変わっても、メモリリークが > 出にくい構造になるのは良いと思った これは結局ケースバイケースで、関数的（副作用がない）なコードが主か、 副作用とかバリバリか、で変わってくるよね。 あと、例外的な場合の処理にgotoを許すか、とか。 271 名前：デフォルトの名無しさん mailto:sage [2009/04/17(金) 17:44:38 ] >中々見つけにくいんだな、このバグ 最近のコンパイラなら確実にwarning出すんでそうでも無い 272 名前：デフォルトの名無しさん mailto:sage [2009/04/17(金) 22:26:29 ] ついでに言えば、比較対象が0ではなくて変数だったらやっぱり検出できないから殆ど意味がない。 273 名前：デフォルトの名無しさん mailto:sage [2009/04/18(土) 01:02:21 ] RAII 使え、 const 付けとけ、って話でもあるな。 274 名前：デフォルトの名無しさん mailto:sage [2009/08/21(金) 17:39:24 ] まぁOOPが不可能なプロジェクトなら、そういうリーク対策にも意味はあるかもしれんね OOPが可能なら、RAII（厳密にはデストラクタによる資源解放）の徹底も可能だよな 275 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 12:09:43 ] >>269 C/C++で、zeroとの比較をするのであれば、 if (hoge(var) == 0)とぜすに、if (!hoge(var))の方が目的がはっきりする 比較する数値がたまたまzeroであるのなら、数字で比較すべきではない 定数化された変数を用いるか、#defineマクロで名付けられた定数を用いるべきだ よって条件式に、数字が書き込まれている時点で何かおかしなコードであると思われる 276 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 12:32:58 ] >>275 しかしstrcmpの時ははゼロを扱っていいと思う。 277 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 12:38:20 ] おばかのきわみ > #define ZERO 0 278 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 12:55:27 ] >>276 その場合、BASE_CMPとか名付けて比較したほうが分りやすい予感 279 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 13:11:50 ] >>278 少なくとも俺は今、BASE_CMPナニソレ？(´･ω･`)　ってなってるが。 280 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 13:12:58 ] >>278 CMP_OBJCTじゃね? 281 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 13:15:20 ] >>275 あほか。 「ゼロと比較する」という処理ならコードにそのまま書いたほうがいいだろｊｋ 282 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 13:22:58 ] #define STREQ(a, b) !strcmp((a), (b)) みたいなマクロに 283 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 13:28:21 ] >>282 それなら辛うじて許せるような気もするが、 strcmpくらいそのまま使えよ、ってのが正直なところ。 strcmp(a, b) < 0 // a < b strcmp(a, b) > 0 // a > b strcmp(a, b) == 0 // a == b という、並べて書いた上での法則がせっかくあるのに。 284 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 18:55:48 ] >>278 わかりやすくねーよ。 イディオムはそのままにするべき。 285 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 19:01:39 ] strcmpの場合 比較対象と同等か、大きい、もしくは、小さいだから >>282よりはマシだろ 286 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 19:04:58 ] >>285 意味不明(´･ω･`) 287 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 19:25:05 ] >>275 > if (hoge(var) == 0)とぜすに、if (!hoge(var))の方が目的がはっきりする そんなバナナ 0との比較なら素直に==0、真偽値としての比較ならそのまま、ってのが普通の感覚だと 思うけどなぁ。まぁ最後は主観だからあれだけど。 0をマクロに入れるなんてのは論外。 288 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 19:51:24 ] NULLの分らんアホばっかだな 289 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 20:10:03 ] >>287 0との比較の「0」とは何かという話じゃないの？ 290 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 20:14:06 ] >>288-289 お前ら二人は一体なにをいってるんだ？ 291 名前：デフォルトの名無しさん mailto:sage [2009/08/31(月) 21:11:58 ] NULL自体が要らないマクロ 292 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 23:12:56 ] 初心者なんですが、if (cond == false)って書き方と if (!cond)ってどちらにすべきですか？ ずっと後者だと思っていたのですが、前者もたまに見かけるので わからなくなってしまいました。 293 名前：デフォルトの名無しさん mailto:sage [2009/09/05(土) 23:50:59 ] >>292 論理定数との比較はそもそもナンセンスなので、前者は論理値に対する理解が あやしい感じがする。 たいした理由じゃないんだけど、どちらかというと後者にしといたほうがいいと思うよ。 294 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 00:27:29 ] >>293 ありがとうございます。このまま後者の書き方を続けていきます。 295 名前：デフォルトの名無しさん mailto:sage [2009/09/06(日) 10:41:39 ] その cond の名前が ablable とか enabled なら ! allowed のような書き方が良いだろう。 availability とか visibility とかだと、「可視性ですか？」 じゃ頭弱いみたいだから 「可視性は偽ですか」の方が分かりやすいと思う。 専用に enum 作れという話だけど。 296 名前：デフォルトの名無しさん mailto:sage [2009/09/11(金) 19:06:43 ] //これはだめ hoge(foo,bar); //これはおｋ hoge(foo, bar); 297 名前：デフォルトの名無しさん mailto:sage [2009/09/11(金) 20:49:45 ] www.eetimes.jp/content/3107 1TBS って初めて聞いた。 298 名前：デフォルトの名無しさん mailto:sage [2009/09/11(金) 21:31:02 ] >297 これ思ったけど、1TBSの方が図2のような間違いは簡単に検出できるような。 （単純に /;\s*{/ で検出できる。オールマンスタイルの場合、ツールによってはマッチしない） でも個人的にはオールマンスタイルのが好きだけどな。 299 名前：デフォルトの名無しさん mailto:sage [2009/09/12(土) 07:31:42 ] 俺は1TBSくらいの黒っぽさが好みだな もちろん黒すぎるのは辛いけど、オールマンだとちょっと白っぽく感じる まぁこれはさすがに完全に好みの問題だろうと思うな… 300 名前：デフォルトの名無しさん mailto:sage [2009/09/13(日) 02:47:08 ] そもそも筆者のコメントを打つ位置が気に入らない。 //行末に書くな 301 名前：デフォルトの名無しさん mailto:sage [2009/09/13(日) 03:18:16 ] 俺は//の後にスペースがないのが気に入らない 302 名前：デフォルトの名無しさん mailto:sage [2009/09/13(日) 11:47:43 ] 一番のツッコミどころは比較式の左辺に定数だろ。 303 名前：デフォルトの名無しさん [2009/09/25(金) 00:36:47 ] そもそも if(!x) とか if(!(z=x-N)) とかやることが多いから==使わないな。 304 名前：デフォルトの名無しさん mailto:sage [2009/09/25(金) 07:48:41 ] 条件式に関数呼び出しを書くなってルールもあったな 305 名前：デフォルトの名無しさん mailto:sage [2009/09/25(金) 09:26:21 ] へぇ。どういう理屈でそんなルールが認められるのかさっぱりわからんな。 306 名前：デフォルトの名無しさん mailto:sage [2009/09/25(金) 10:21:31 ] >>305 && や || のショートカットと関数の副作用の関係 f0() || f1() || … f0 が成立すると f1 以降が評価されないってのを知らないやつがいるそうだ なので、こう書かなきゃいけない。とてもうざい。 v0 = f0(); v1 = f1(); … if (v0 || v1 || …) 307 名前：デフォルトの名無しさん mailto:sage [2009/09/25(金) 10:25:40 ] >>306 それ、 (s && strlen(s) > MIN) とかいう時はどうすればいいの？ 308 名前：デフォルトの名無しさん mailto:sage [2009/09/25(金) 10:59:33 ] int len = -1; if (!s) { len = strlen(s); if (MIN < len) { ... } } 309 名前：デフォルトの名無しさん mailto:sage [2009/09/25(金) 11:00:20 ] !sじゃなくてsなｗ　素で間違えた。 310 名前：デフォルトの名無しさん mailto:sage [2009/09/25(金) 11:26:08 ] そんなルールおとなしく守ってるプログラマなんてほんとにいるの？ 何なの？ばかなの？しぬの？ 311 名前：デフォルトの名無しさん mailto:sage [2009/09/25(金) 12:08:10 ] >>310 元請けにコードの監査部隊がいて意地でも書き直させる方法を取っていた うざくってしょうがなかった 312 名前：デフォルトの名無しさん mailto:sage [2009/09/25(金) 12:10:14 ] その監査部隊を短絡評価の講習要員にすればいいのに。 313 名前：デフォルトの名無しさん mailto:sage [2009/09/26(土) 21:43:06 ] 308の書き方だと、正しく読めない/書けない奴が居るから仕方が無い。 一方、漏れらに308の書き方を強制しても、せいぜい能率が落ちるだけ。 実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。 平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは 冷徹ではあるが正しい方策。 314 名前：デフォルトの名無しさん mailto:sage [2009/09/26(土) 23:32:37 ] へぼいコーディングルールの話になると、その理論がよくでてくるけど、実際はコーディングルールを 決めてるやつがヘボいだけだろうな。ほとんどの場合。 それに「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論が、本当に正しいかすごい疑問だし。 315 名前：デフォルトの名無しさん mailto:sage [2009/09/26(土) 23:42:03 ] まぁ俺の持論とは真逆だな ウンココーダの頭数揃えても、精鋭一人にも劣る 316 名前：デフォルトの名無しさん mailto:sage [2009/09/27(日) 09:34:49 ] > 実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。 > 平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは > 冷徹ではあるが正しい方策。 「人月の神話」に燦然と挑戦しているな。 まぁそのような開発分野もあるんだろう。多分。 317 名前：デフォルトの名無しさん mailto:sage [2009/09/28(月) 09:09:58 ] 「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論は確かに疑問だが、 十分な精鋭を確保できるプロジェクトなんてほとんど無いんだから、大量のヘボが存在 するのは前提だと思う。 加えて上司も無能だと、そのヘボが逐次投入されてチームは恐竜に、プロジェクトは タールの沼に。 318 名前：デフォルトの名無しさん mailto:sage [2009/09/29(火) 21:53:42 ] >316 そうでもないと思うが。 1つのプロジェクトに投入する人員については、「人月の神話」の理論で良いけど、 複数のプロジェクトに人員を配置する場合は、>313の理論の方が適している。 308みないなルールは大規模なプロジェクトほど多く、小規模なプロジェクトほど比較的フリーだろ? （逆な例もある事は承知している） 319 名前：デフォルトの名無しさん mailto:sage [2009/09/29(火) 21:57:10 ] 短絡評価が分からないだけならまだしも、「教えても理解できない」という人員なんか さすがに切り捨てても困らないと思うけどな 320 名前：デフォルトの名無しさん mailto:sage [2009/09/29(火) 22:31:14 ] 簡単なコードを量産するような人海戦術プロジェクトでも、上位の2,3割だけ使って、 のこりはじゃまにならないように遊ばせておいても、あんがい生産性あがるんじゃないかって気もする。 321 名前：デフォルトの名無しさん mailto:sage [2009/09/29(火) 23:13:59 ] >>318 人月の神話、読んでないか忘れてるだろ。 >>319 短絡評価に限って言えばその通りだけど、教えられても理解できない部分は人によって違うから。 >>320 論文報告を楽しみに待ってる。 322 名前：デフォルトの名無しさん mailto:sage [2009/09/30(水) 00:10:59 ] どうでもいいけどstrlen()が返すのはintじゃなくてsize_tだよ 323 名前：デフォルトの名無しさん mailto:sage [2009/10/01(木) 20:40:57 ] ストレンツォ容赦せん！ 324 名前：デフォルトの名無しさん mailto:sage [2009/10/11(日) 14:52:50 ] >>318 つまり、たとえば優秀なプログラマなら3ヶ月で終わる仕事を一年かけて （原則同じくらいの人数で）やるけど、 同時に抱えられるプロジェクト数を増やして会社としてのスケールメリットを得るって話？ 要するに節約できるのは総務だの人事だのの管理コストの話であって プロジェクトそのものの効率は上がってないと思うが… 325 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 02:57:19 ] >324 プロジェクトの効率は上がらなくても、利益は上げられる罠。 場合にもよるが。 下手すりゃ投入人員と期間を増やせばその分儲かる。 糞ルールがまかり通ってる現場って、大体は上がこんな思想で動いてる希ガス。 326 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 03:57:31 ] まぁ、その思想を最高だと思って布教しようとしたりしなきゃどうでもいいけどな 327 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 11:55:45 ] javaで public void XXX() throws YYY, ZZZ { } のthrows以下が長くなると80桁超えますけど見やすい折り返し方ないですか？ eclipseのデフォルトで整形すると public void XXX() throws YYY, 　　　　ZZZ { } とやってくれましたけど見づらいな。 328 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 12:44:58 ] >>325 思想とか計算づくで、レベル低いんじゃなくて、ただレベル低いだけなんじゃないの? 効率が利益に結びつかないから、淘汰されないだけで。 329 名前：デフォルトの名無しさん mailto:sage [2009/10/18(日) 21:42:59 ] >>324 保守要員みたいなところにエース級は投入せんだろ。 むしろ OJT で勉強させるために新人を。。。 330 名前：デフォルトの名無しさん mailto:sage [2009/10/20(火) 11:51:05 ] >>327 行が長くなるときどう折り返すか ttp://java-house.jp/ml/archive/j-h-b/009166.html#body 331 名前：デフォルトの名無しさん mailto:sage [2009/10/20(火) 12:09:53 ] C++ 使っててカンマとか演算子の「前」で折り返して、演算子の類が行頭にくるように してたんだけど、 Python 使い出したらそうもいかなくなって、今は微妙な気持ちです。 332 名前：デフォルトの名無しさん mailto:sage [2009/10/20(火) 12:20:08 ] >>331 英語では普通、カンマやセミコロンなどは単語の後ろに空白なしにつける。当然、改行はその後。 演算子もそれに準じる。 333 名前：デフォルトの名無しさん mailto:sage [2009/10/20(火) 13:57:32 ] >>331 （ ・∀・）人（・∀・ ）ﾅｶｰﾏ .append(foo) .append(bar) .toString(); + fooooooooooooooooooooooo - (baaaaaaaaaar % baaaaaaaaz); = { 11111111111 , 2222222222 , 3333333333 } if ( (cooooooooooooooond) || (baaaaaaaar && bazzzzzzzz) ) 文末を見るより、文頭を見るほうが目の動きが少ない。 334 名前：デフォルトの名無しさん mailto:sage [2009/10/20(火) 14:05:42 ] . を先頭にもってくるのは許せるが、 , を先頭にもってくるのが許せないのはなぜだろう。 335 名前：デフォルトの名無しさん mailto:sage [2009/10/24(土) 22:25:29 ] if 〜 else if 〜 else の各節にコメントをつけたいとき、俺はこのように書いているんです。 // こういう場合はこう if (...) { } // こういう場合はこう else { } ところが、節を分断するのはよくないと言う人がいるんですね。それはそれで一理あります。 その人はこう書いている。 if (...) // こういう場合はこう { } else // こういう場合はこう { } このやり方だと、条件式が長くなったり複数行にわたると、ちっと面倒なことになる。 みなさん、if文のコメントはどのように書いていますか？ 336 名前：デフォルトの名無しさん mailto:sage [2009/10/24(土) 22:35:25 ] >>335 if にコメント付いてれば else へのコメントは冗長だろ？考えるだけ無駄。 337 名前：デフォルトの名無しさん mailto:sage [2009/10/24(土) 23:21:52 ] 冗長なんて言ったらコメントなんて書けなくなる。 それに複数のelse ifがある場合はコメントがあった方がいい。 338 名前：デフォルトの名無しさん mailto:sage [2009/10/25(日) 00:16:58 ] >>337 お前はなんのためにコメントが書きたいの？ コメントを書くことが目的なの？ 339 名前：デフォルトの名無しさん mailto:sage [2009/10/25(日) 01:41:21 ] // コメント if(...) { } else { // コメント } 340 名前：デフォルトの名無しさん mailto:sage [2009/10/25(日) 02:39:09 ] >>339 俺もそれだ。 341 名前：デフォルトの名無しさん mailto:sage [2009/10/25(日) 02:43:33 ] 俺はこうだわ。space efficiant!! if(...) { // コメント   foo(); } else if(...) { // コメント   bar(); } else {   foobar(); } 342 名前：デフォルトの名無しさん mailto:sage [2009/10/25(日) 07:39:57 ] 漏れは内容に応じて使い分けた方が良いと思うけど。 // 分岐全体について。 if( ... ){　　　// 式について。 　// ブロック内の処理&実行条件の概要 } else { 　// ブロック内の処理&実行条件の概要 } （例） // 〜と〜を切り分ける if( … 　　// 〜をチェック && … ) { // 〜をチェック 　// 〜の場合、〜する } else { 　// 〜の場合、〜する } 343 名前：デフォルトの名無しさん mailto:sage [2009/10/25(日) 14:06:52 ] こうしてる if(...) { 　// ...なら〜 } else { 　// 〜(条件についての記述は無し) }

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef