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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
2009/02/12(木) 02:12:25
>>160
C言語だとダメなやつもあるから、0と0以外にしとくのが安全なスタイルってもんだよ。

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

assert( (p == NULL) != false );
2009/02/12(木) 02:15:40
>>161
わざわざ「flag の型がちゃんと bool なら」って書いてあるのに何言ってんの？

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

ねーよ
2009/02/12(木) 02:33:29
いやいや、そこはこうでしょ
assert( (p == NULL) != false != false);ってのが(ry
2009/02/12(木) 02:47:00
だからさ、FAQの
> もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか
これがそもそもおかしい
おそらく原作者はジョークのつもりだったろうが、真に受けてるアホがいるからな・・・
2009/02/12(木) 02:58:25
Cの(ユーザー定義の)TRUEとC++の(言語の)trueの違いがわかってない奴がいるな
Cでif(flag==TRUE)は間違いだが、C++でif(flag==true)は書き方の問題だ
書き方の問題＝好みだよ

ここでif((flag==true)==true)を持ち出す奴はジョークが理解できないってことだ
2009/02/12(木) 03:50:19
>>164
で、何がいいたいの？論理定数との比較を擁護するつもりなの？
2009/02/12(木) 04:00:02
>>165
はなから技術的な正しさとか間違いとかを問題としてるんじゃない。
論理定数との比較に意味が無く、混乱の元でしかないから書くべきではないという話だ。
(... == true) も (... != false) も同じくらいに意味が無い。
2009/02/12(木) 04:43:58
意味あるじゃん
ある特定の人間にとっては見やすいという意味が
2009/02/12(木) 05:01:14
カスみたいな意味だな。
2009/02/12(木) 10:58:38
一番ダメなのは is〜, has〜, can〜 などの自然に読み下せるように工夫した命名規則を
台無しにしてしまうこと。

if (x.isReady()) で済むところを
if (x.isReady() == true) だの
if (x.isReady() != false) だの
わざわざノイズを混ぜるのが許せない。
2009/02/12(木) 11:49:41
俺はif(flag)派だが、if(flag==true)なソースを見てもいちいち噛み付かないな
TRUEは明らかに不味いがtrueは見た目の問題、見易いかどうかは主観だからな
それをノイズと感じるのも自由だし、そんなのは人に押し付けなければどっちでもいい

それよりTRUEとtrueを混同して大昔のFAQを持ち出したり、
技術と好みの違いが分からない奴の方がスキル低いだろ
2009/02/12(木) 13:42:38
TRUEとの比較には問題があるなんて>>133なども当然理解しているだろ。
それは誰もが理解しているという前提で、本筋からそれるのでスルーしただけにしか思えない。
2009/02/12(木) 22:31:56
初見のソースでif( hoge == true ) と書かれていると、hogeがboolになっているか、
そうでなければtrue/falseの2値しか取り得ないのかチェックする手間が生じる。
初見じゃなくてもどうなってるかいずれ忘れるかもしれない。
（そんなの気にしないとかってのは論外過ぎる）

if( hoge != false ) も、万人がつっかえず読めるソースであるとは言い切れない。
2009/02/13(金) 00:20:00
もしかしてflagが２でも==trueなら通るのか？
175デフォルトの名無しさん
垢版 |
2009/02/13(金) 00:35:12
flagに2が入っている時点で不具合だとしか思わない
bool型ならな
2009/02/13(金) 01:02:25
素直に!=falseにしとけよ。
2009/02/13(金) 04:07:26
>>172
理解してたらtrueに対してFAQ(TRUE)を持ち出さないだろ
2009/02/13(金) 10:51:29
ヘンなケースだけど if (flag) 形式は
うっかり bool の配列を渡してハマりそうになったことあるなぁ
bool array[2];
if (array)
みたいな
2009/02/13(金) 14:13:43
>>173
初見のソースでif(hoge==1)と書かれていると、hogeがintになっているか、
チェックするのか？しないだろ？
ただのいいがかりじゃねえか、おまえの頭が論外だよｗ
2009/02/13(金) 14:19:19
読み違えてるよ
2009/02/13(金) 14:23:58
hoge == 1 は何とも思わないが、 hoge == true を見つけたら bool 値に対する理解が
不十分な可能性を疑わざるを得ないだろうね。バグを探してるときならなおさら。

signed/unsigned が混在してたり、可変長引数にキャスト無しの NULL を渡してたり、
ループ変数に char が使ってあったりするのと同じ。言語仕様の不十分な理解から出る
バグのにおいがする。
2009/02/13(金) 14:37:11
hoge==true見つけただけで言語使用を理解してない可能性を疑うってどんだけレベルの低い環境なんだ
ところで181の挙げた例に細かいミスがあるんだが、普段の俺ならスルーしてあげる
だが181の論理によれば、俺からみたら181は言語使用を理解してないと疑わざるを得ない
2009/02/13(金) 14:38:48
言語使用→言語仕様
184181
垢版 |
2009/02/13(金) 14:43:46
何かミスがあるというなら言語仕様を理解していないと疑われるのはしかたがないと思うけど、
できればはっきりと指摘してほしいところだね。
2009/02/13(金) 14:46:01
どうせハッタリだろ。
2009/02/13(金) 15:08:25
なんか話ずれてるけど
173はif(hoge==true)ならhogeがboolかチェックするんでしょ？
もうその時点でありえないんだけど、そんな底辺レベルの職場なら
if(hoge==1)でもhogeがintかチェックする必要がある、チェックしないのはダブスタじゃん
って意味だよね、違う？

普通の職場なら同僚やらオープンソースで
if(hoge==true)見つけても、「あらあら、このひとはtrueと比較しちゃうんだ」って思って終わりだよ
どんだけ病んだ職場で働いてるんだ、転職したほうがいいよ
2009/02/13(金) 15:25:30
>>186
hoge == true （あるいは hoge != false ） を書くような人は bool 型や if 文になどついての理解が
あやふやな可能性が高いので、同様に理解の不足から int == true などという間違いを犯している
可能性があることを推測できる。

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

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

って、かかんとあかんわけ?
2009/02/13(金) 20:15:31
関数が何返したのか分かりにくい
190173
垢版 |
2009/02/13(金) 22:09:36
>179,182
if( hoge == TRUE )のケースを考えてみてよ。
hogeは本当にTRUEかFALSEしか取り得ないのか不安にならない?
漏れが指摘したいのはむしろこっちの方なんだよ。

if( hoge == true )の場合は気にし過ぎってのは素直に認める。
（コンパイルすりゃすぐ分かるというのはEnter押してから気付いた）
でもバグ発生時には疑うべき記述だと思う。
2009/02/13(金) 23:40:30
if ((!!flag == true) != false) {
　　flag = true;
　　flag = true; // 念のためもう一度
}
これくらいやっとけば安心
2009/02/14(土) 00:48:46
実際、trueやfalseと比較し捲くっているコードを整理したら、若干ではあるけど
所要時間に有意差が認められたからなぁ。
2009/02/14(土) 01:01:22
(1) if( hoge == TRUE )
(2) if( !!hoge == true )
(3) if( hoge == true )
(4) if( hoge )

最悪のケースを想定した場合、読み手が考え込む時間が一番短いのは(4)でしょ。
ifの動き、hogeの値、コーディングスタイル、ネーミング位しか悩める要素が無いんだから。
他は最悪、型とか脳内演算とかで、余計な思考時間を生んでしまう恐れがある。
2009/02/14(土) 01:35:45
true との比較では所要時間に差は出るだろうが
false との比較で差が出るのは最適化レベルがおかしいんじゃないのか
195192
垢版 |
2009/02/14(土) 01:41:23
>>194
trueもfalseも纏めて整理したから、falseの有無で差があるかは確認していない。
2009/02/14(土) 01:42:04
あえて(2)を混ぜて誤魔化してないか？ｗ
2009/02/14(土) 11:27:41
trueと比較しない場合
>>178みたいなのでハマるくらい?
2009/02/14(土) 11:52:14
逆にboolをtrueと比較して困るケースの具体例、つか経験談ってある？
2009/02/14(土) 11:58:59
>>198
1以外の値が入ってるときとか。
2009/02/14(土) 11:59:12
>>198
>194
2009/02/14(土) 16:47:04
ちょっと違う話かも知れんが、

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

なんてプログラムを見ることがたまにある。
最初からreturn 式;にしろよ、って思う。
2009/02/14(土) 16:48:03
変更になりそうな箇所がおおいならそう書くこともある。
2009/02/14(土) 19:46:26
漏れはこうだなあ。

if (式) {
　return true;
}
return false;
2009/02/14(土) 19:54:47
そういうのを書く時は最終的にtrueを返すようにしてるな
2009/02/14(土) 19:55:23
return (式) ? true : false;
2009/02/14(土) 21:41:18
>>205
これはないな。
2009/02/14(土) 21:58:37
式が関数でtrue/falseの意味が取り違える可能性があるような名前ならアリかもな。
2009/02/15(日) 16:12:23
>>205
俺もこれだけはやっちゃダメだろとは思う
マクロならそうなるけど

自分のことしか考えてないタイプ
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;
}
--
これ見たときはどうしてくれようかと思った。
2009/02/15(日) 17:55:06
設計書にそういう「ロジック」を書いてるんだろうなあ。。。

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

日本人プログラマが10人いれば、8人は何も考えずにコーディングを行う。
1人は、「反転フラグて。。。呼び出し側で結果を反転させりゃいいのに。。。」とか思いながらコーディングを行う。
残りの1人だけが「なんで設計書にロジック書いてんだｗｗｗこの現場やべえｗｗｗ」と笑い、辞める。
2009/02/15(日) 18:11:22
>>210
設計書を書いた奴と相談するっていう選択肢が無いのが悲しいな。
2009/02/15(日) 20:05:55
_Booleanはどういう定義なんだよソレｗ
213209
垢版 |
2009/02/15(日) 20:14:34
>>212
おっと、書き忘れてた。
＞typedef enum { _False = 0, _True = 1 } _Boolean;
だとさ。ちなみに、Sun-OSのcc(標準ではc99としてコンパイルする)を使っているのに
c99禁止と言う不思議なコーディング規約(と言っても明文化されていない)だし。

>>210
>209のコードに関しては、設計者=コーダーの可能性大。
2009/02/16(月) 05:43:24
"<="や">="を書くことが幼稚な気がして今まで避けてきたんだが
"<"や">"は小数を扱うのが正しい使い方で、
整数を扱う場合はイコールをつけたほうが直感的な気がする
for(int i=0; i<10; i++)
ってのが一般的で10回カウントするってのが直感的にわかるけど
なんというか、行って帰ってきて結果的にはあってるって感じで、
for(int i=0; i<=9; i++)
のが1から9まで1ずつカウントするって意味で
正しい使い方な気がする
2009/02/16(月) 05:47:32
１からじゃなくて０からでした
2009/02/16(月) 06:00:51
>>205が何でだめなのか、プログラミング初級者の俺に教えてくれ
無駄がなくてわかりやすいと思うんだが
2009/02/16(月) 07:21:32
1. 返り値がニ値しか取りえないなら、isHoge関数にすべき
2. 構文糖衣はあくまで糖衣
3. 流し読みする時に目に入り辛い
(最後の行だからいい？一カ所使われていると、
複数箇所使われている可能性が高いから、結局同じこと)
2009/02/16(月) 07:39:52
>>214
＞１からじゃなくて０からでした
こういう馬鹿が居るから直感的じゃないんだよ。
2009/02/16(月) 09:29:50
>>216
「? true : false」の部分が丸々冗長。
単純にこれを消しても同じ意味だよ。
2009/02/16(月) 22:36:57
式が bool 型ならそうだろうが
そうじゃなけりゃえらい違いだよ。
bool 型へのキャストは警告出すコンパイラがあるんで、
やむを得ず ? true : false としないといけない。
マクロ化したいけど、作ってもみんな使ってくれないし・・・。
2009/02/16(月) 22:44:33
強制的に bool にしたいなら !!(式) でいいだろ。
2009/02/16(月) 22:56:47
Cだったら、0か0以外にしとけばいいんだよ。
2009/02/16(月) 22:59:57
>>220
条件演算子なんか使わなくても、比較式入れとけばいいじゃん。
2009/02/16(月) 23:10:01
真偽値を比較するなんてとんでもない！
2009/02/16(月) 23:26:09
>>224
真偽値だったら、そのままreturnすればいいんじゃね?

#define true 0
#define false -1
↑みたいな変態的な定義でもされてたら、条件演算子もやむなしって気がするけど。
2009/02/16(月) 23:44:02
自分だったら!!よりは? true : false選ぶなあ。
2009/02/16(月) 23:48:27
>>225
bool hoge(int ch) {
　return isupper(ch);
}

isupper の戻り値は真偽値（int 型の非0/0）だが bool ではない。
コンパイラによってはそのまま return すると文句言われる事がある。
2009/02/16(月) 23:58:38
>>227
いや、だから、真偽値以外だったら、比較にすればいいんじゃね?って話。

　return isupper(ch) != 0;


2009/02/16(月) 23:58:49
>>225
それが標準だったらどんなに良かったかと常々思ってる。
2009/02/17(火) 00:03:33
>>229
trueやfalseが標準で定義されていて、
n > 0 みたいな比較式の結果と違う値になってたらよかったってこと?
2009/02/17(火) 00:15:34
>>228
真偽値を比較するなんてとんでもない！
ぶっちゃけ読み辛くてしゃーない。
2009/02/17(火) 00:23:21
>>231
ああ、それはそうだな。
Cライクな真偽値と、C++のboolを併用するときはしかなないのかね。
static_cast<bool> とかするとどうなるんだろう。
2009/02/17(火) 00:25:08
VC++はboolへのあらゆる直接的な変換は警告出した気がする
2009/02/17(火) 00:25:56
g++はノーキャストでも完全スルーなんだが
2009/02/17(火) 00:52:23
>>220
式が bool じゃなくて return するのに問題があるというのなら、
? の左に書くのだって同じ問題があるはずじゃないか。
やっぱり、? 以降は単純に冗長だよ。
2009/02/17(火) 22:58:25
だーかーらー、五月蝿い警告が出るコンパイラへの対策なだけだと言うとるに。
どのコンパイラでも警告でないならそのまま返したいさ、そりゃ。
2009/02/18(水) 01:36:14
>>236
うるさいっていうかアホだろ。

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

そもそも警告を黙らせるためのコードなんか書いちゃいけない。
警告によって指摘された問題に対策しないといけない。
2009/02/18(水) 04:04:58
そりゃそうだ。C/C++に、?の左側に置いた式はbool型に変換されるなんて規則はないから
そこでbool型への変換だなんて警告が出るわけない。
2009/02/18(水) 04:33:49
>>238
何を根拠にそんなこと言うの？
C++ の ? は bool に変換して評価するよ。
5.16 Conditional operator p1
> The first expression is contextually converted to bool (Clause 4).
2009/02/18(水) 05:14:14
そうだったのか。
C99だけ見ていたが、こっちは、0と比較して云々となっていて、
_Boolへ変換するとは書かれていなかった。
C++もそんな調子だと思っていたよ、すまない。
2009/02/18(水) 13:47:17
C99 なら _Bool f(int x) { return x == 1; } でも比較演算自体は int だから警告が出るというのか？
それもアホだな。
2009/02/18(水) 14:45:41
そんなこと言ったら C99 では true も false も int 型なわけで。

結局のところ "? true : false" がまったく冗長なだけの記述には違いないね。
2009/02/18(水) 19:22:44
ECMAScriptなら冗長でないよ
2009/02/18(水) 21:31:42
どでもいいけど、システムハンガリアンって呼ばれてる
変数のタイプをプリフィックス/ポストフィックスとして
つける命名規則だけは絶対裂けるべきだ

一部に改訂が入って、使ってる型の定義が変わった場合の
メンテナンスはとんでもないことになる
2009/02/19(木) 00:03:28
下手に否定するより、よりベターな手法を教えてそっちに誘導した方が良い。
チーム全体に徹底させるだけの権限と統治力を持ってない場合は特に。

人は力強く押さないとあらぬ方向に進むが、引っ張れば割とすんなり思った方向へ進む。
2009/02/19(木) 12:32:31
>>244
WIN16→WIN32→WIN64の悲劇ですね。
2009/02/19(木) 21:33:35
WORD型やDWORD型なら、typedefを書き換えればいい
たぶん・・・
2009/02/19(木) 23:15:01
スタイルスレで聞きたいと思ったことが１つあるんだ。

C++のcppの方にソースを見やすくするために関数を小分けにしたものを
staticで記述して使ってるんだが、private関数にするべきかね？
2009/02/19(木) 23:28:51
>>248
privateにしなくてもいいんじゃね?
C++のprivateって、そもそもが美しくないし。
2009/02/19(木) 23:47:33
どっちかっていうと、外部にも派生クラスにも公開する気がない関数はクラスに含めるべきじゃないと思う。
クラスのインターフェイスとは関係ない、実装側だけの問題なら、実装側で完結してるほうが美しい。
static 関数なら、いくら変更しても外部には影響しないし。
2009/02/20(金) 00:02:01
継承したときにvirtualつけて使いたいけど、クラス外からは使われたくないものに
だけつけときゃいいのか。
2009/02/20(金) 00:02:30
static関数化できるものなら、Utilityクラスとかにして
外に出しちゃうのも良い鴨
253249
垢版 |
2009/02/20(金) 00:05:44
staticって、クラスのメンバとしてか。。。
勘違いしてた。
2009/02/20(金) 00:16:57
メンバのstaticではなく実装用の小規模な補助関数ってことで。
2009/02/20(金) 01:12:07
>>248
.cpp ローカルな関数は static じゃなくて無名名前空間を使う。
private にすべきかどうかはクラスのメンバであるべきかどうかで区別する。

何も考えずに書くと private 関数の宣言をヘッダに書くことになるんで何かおかしな
感覚になるけど、 pimpl とかインターフェース継承とか使って隠せば問題ない。
2009/02/20(金) 01:22:53
なるほどね。いわゆるCのstatic関数ってのは推奨されてないのかな。
そこまで意識して気をつけようとも思わないけど、気が付くと疑問に思う。
2009/02/20(金) 01:25:22
>>256
関数や変数だけならいいんだけど、 C と違って .cpp ローカルな struct や enum も
グローバルに置いてると定義がかぶってアウトだから、なるべく無名名前空間を使う
癖をつけておいたほうがいいよ。
2009/02/20(金) 12:56:17
>>257
それだけなら別にアウトじゃない。
規格としてはダメかもしれんが。

ただ、メンバ関数はリンケージをファイル
スコープにできないから、無名名前空間が
絶対必須。
2009/02/21(土) 17:20:06
addとappendや、eraseとremoveの使い分けってどうしてる？
2009/02/21(土) 17:28:41
addは追加、appendは付加。
eraseは消去、removeは除去。ついでに言えばdeleteは削除。

まぁ、それでも巧く決まらないときは既存ライブラリの命名に倣ったりするが。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況