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

1 名前：デフォルトの名無しさん [2007/10/28(日) 15:59:01 ] コーディングスタイルについて熱く語れ 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