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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
2009/02/08(日) 12:50:57
インスタンスが２つあれば、その切り替えに使えるかもしれないが、
ま、そこまでするなら型名付けた方がいいと思う。
2009/02/08(日) 13:07:35
typedef struct ｛
｝ t, *p;
こんなのなら見るけど
2009/02/09(月) 21:09:40
>>99
C言語のこの仕様はポインタの理解をさまたげてくれたなあ・・・
Delphiは前者が前提なんだが、C挫折してDelphiやってはじめてポインタの概念がわかったよ俺は
ポインタって「なんとかのポインタ」で1つの型なんだ、と気づくまでにやたら時間がかかた。
2009/02/10(火) 12:22:29
ポインタ宣言に使う記号がアスタリスクなのもややこしいよね。
ポインタ絡みで間接演算子使うだけに。
2009/02/10(火) 12:28:56
if(flag){
}
if(flag == true){
}
どっちを選べばよいか･･･
2009/02/10(火) 12:34:02
>>128 構造体の typedef 禁止
2009/02/10(火) 13:29:14
>>131
前者に決まってる。論理定数との比較は無意味。
http://www.kouno.jp/home/c_faq/c9.html#2
2009/02/10(火) 15:04:14
if(flag){
この間にいくつスペースを挟めばいいのかわからない
2009/02/10(火) 16:26:13
入れなくてもいいし、入れるのならif (flag) {がお勧め。
2009/02/10(火) 17:11:33
"if"の後に一個、
"("の後に一個、
")"の後に一個スペースを入れないと、
かつ、二個以上入れた場合、コンパイルできない

とかいう仕様だったらいいのに。
俺は末期か・・・
2009/02/10(火) 20:49:28
if の後に空白を入れるスタイルだと、
条件が二行以上に渡る場合に４タブで綺麗に揃う
2009/02/10(火) 20:52:17
>>136
MS信者？
2009/02/10(火) 20:53:07
if ( hoge) {

こうか？
バランス悪すぎ
2009/02/10(火) 23:27:25
>137
漏れはこう
if( 条件1
|| 条件2 )
2009/02/11(水) 00:28:58
既存のコードにあとから手を付ける場合は、出来るだけ合わせて書いてるな
2009/02/11(水) 01:38:12
最近はワイドモニタだから、右に長くなりがちだなぁ。

基本は>>140と一緒だが。
2009/02/11(水) 01:57:32
じじいに言わせると80桁を越すと犯罪らしいぜ
2009/02/11(水) 02:00:18
コーディング規約でも規定されない限り、横の長さはそれほど神経質に考えないな
ある程度は工夫するけど
2009/02/11(水) 03:22:49
モニタが大きくなるとかえって80桁とかに縛りたくなる。
横にいくつもウィンドウを並べてみるのに都合がいい。
2009/02/11(水) 06:14:45
端末エミュレータを三つ並べても100桁表示できるご時世だから、気にしてもねぇ。
そんな私はどちらかと言えばこっち。
if (条件1 ||
   条件2) {
2009/02/11(水) 15:00:02
デバッガでトレースしやすいように１行で書いてる。
if (条件1 || 条件2 || 条件3 || 条件4 || 条件5 || 条件6 || 条件7 || 条件8 || 条件9 || 条件10) {
2009/02/11(水) 15:06:14
ソースコード関係ないけど、未だにWindowsのデスクトップの縦のアイコン数は、1024ｘ768時代の数だなｗ
でも最近Windows7使ってると、その傾向はなくなってきた（Vistaは常用したことない）

エディタは、文字数による改行なしで設定するのが俺のジャスティスだな
2009/02/11(水) 22:19:15
>>133
別に後者がいいとはまったく思わないが
trueとTRUEは違う
よってそのリンク先は根拠にならない
2009/02/11(水) 22:25:43
>>149
true でも TRUE でも以下の話は同じ。
> もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか

論理定数との比較自体が無意味。
2009/02/11(水) 22:26:58
((a == b) == TRUE)
↑これ何の冗談？ｗ
2009/02/11(水) 22:30:57
>>151
つまりそういう皮肉
2009/02/11(水) 23:00:51
>>150
それ、主題じゃないし
さらにその例はFAQそのものが不適切だ

論理定数との比較云々じゃなくて（そこは同意する）
そのFAQが違うだろって話ね
2009/02/11(水) 23:16:29
>>153
うるせぇなぁ。少しは応用しろよ。

>131 へのレスで挙げてるんだらこういうことだろ。
もし if(flag == true) が if(flag) より良いと思うのなら、なぜそこで止めるのか。
なぜ if(flag == true == true) を使わないのか。
2009/02/12(木) 01:10:46
処理上は無意味でも
if ( flag )より
if ( flag == true )のが
わかりやすくないか？
2009/02/12(木) 01:13:50
それじゃflagが２だったらとおらねぇだろ
2009/02/12(木) 01:16:11
それでいいじゃんｗ
2が入ること自体がおかしい
2009/02/12(木) 01:27:37
>>155
処理上は無意味でも
if ( flag == true )より
if ( flag == true == true )のが
わかりやすくないか？
2009/02/12(木) 01:41:46
trueはfalse以外が仕様だからそれじゃダメだっての。

if ( flag )
if ( flag != false )

これ以外は許されない
2009/02/12(木) 01:47:26
>>159
flag の型がちゃんと bool ならどっちでもいっしょ。

それよりも if ( flag != false != false ) のが（以下略
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 すると文句言われる事がある。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況