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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
2007/10/30(火) 00:43:46
>>38
コードサーチでオプソをググったら腐るほどいた
2007/10/30(火) 03:27:07
ヘアースタイルは7:3厳守。
2007/10/30(火) 05:24:12
エラーコードを解析する時は三白眼、効果音は
　┣” ┣” ┣” ┣” ┣” ┣”
2007/10/30(火) 09:17:13
>>38
999:1くらいだと思う。もちろん1の方。
2007/10/30(火) 21:37:51
>>38
俺はデキる奴だぜー、と思い込んでるけど実際はそうでもない人が使いそう
2007/10/31(水) 01:39:14
< とか > とかの向きを揃える目的なら使っちゃだめか？
2007/10/31(水) 02:55:54
定数を左に置くのは、次の場合だけだな。
if (0 < x && x < 100)
本当はif (0 < x < 100)と書きたいけど、書けないのでその代用としてだ。
46デフォルトの名無しさん
垢版 |
2007/10/31(水) 23:03:42
returnやsizeofの後をカッコでくくるかどうかって話はもう出た？
2007/10/31(水) 23:06:40
return の後の括弧は無し
sizeof の後の括弧は有り
NGNG?2BP(125)
return はくくらないのにsizeofはくくりたくなるんだよな。。
2007/10/31(水) 23:08:24
習慣っつーか慣用句みたいな感じ
2007/10/31(水) 23:09:44
括弧つけるべきか否か迷う時間が勿体無いので、
なんでも括弧つけることにしてる。
2007/10/31(水) 23:45:58
return 0; ならいいとしても、return i * 2; みたいになると、括弧で括りたくなる。
2007/10/31(水) 23:52:18
昔、会社のコーディング規約決める時に、returnの後の括弧は無しじゃね？
って言っても、みんな、returnの後は括弧付けるって言って引かないから、
もう、どっちでも良い事にしちゃった。

2007/11/01(木) 00:30:32
実際どっちでもいいし
2007/11/01(木) 00:33:31
>52
燃料投下。
ttp://www.st.rim.or.jp/~phinloda/cqa/cqa6.html#q20
2007/11/01(木) 07:23:14
やっぱりキチガイは一人だけだったか。
奴が来ないとこんなに静か。
2007/11/01(木) 08:35:41
交差点で１００円ひろおったーよー
2007/11/01(木) 21:05:04
ちびまるこちゃんだな。
2007/12/20(木) 03:21:44
なんでもかんでもみんな マスゲームを踊ってるよ
ピョンヤンの丘にはボカッと 巨大な銅像献上
いつだって 忘れない 金日成偉い人 そんなの常識
パッパパラリラ
ピーヒャラピーヒャラ おなかが減ったよー
2008/01/21(月) 02:38:32
>今さらだけど>>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を探さなきゃならんし。
それとも俺がそういうコミニティで育ったからか？
2008/01/21(月) 03:46:07
私は三つとも上のほうが読みやすいと感じる。
数字の 0 よりも、フラグとか関数呼び出しのが「大事なこと」だと思う。
コミュニティ次第なんだろうね。

ただ私なら、 3 は

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

みたいに書く。
2008/01/21(月) 04:45:23
出力（条件比較や返値）より入力（関数呼出や引数）が「大事なこと」だと思えば上のほう、
if ( hogeHoge( parameter_list ) 〜
入力（関数呼出や引数）より出力（条件比較や返値）が「大事なこと」だと思えば下のほう、
if ( 0 < hogeHoge( 〜
ってところではないかな。

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

ただし 3 はイディオムなので、私でも>>60のように分解はしないな。
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( ...

になるね。
2008/01/21(月) 08:38:08
定数左に置く人はfor文でもやっぱり左に置くの？
for (i = 0; N > i; ++i) みたいな感じに
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 ) って書くん？
気持ち悪くね？
2008/01/21(月) 10:11:40
それもそうだ。
2008/01/21(月) 10:38:05
>>64
不等号の向きが数直線だと思い込む方がどうかしている。
つまり0より大きいと0より小さいがならぶときに、
if (var > 0) ...;
if (var < 0) ...;
と書くか
if (0 < var) ...;
if (var < 0) ...;
と書くかの違いなわけだが。

例えば、このvarが関数呼び出しになっても後者のように書くということなのだろ?
それが気持ち悪いと思えないなら、私とは相容れない種類の人間だと言うことだ。
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 より小さい」。
2008/01/21(月) 10:56:56
私は基本的には定数右派だが、不等号については後者かな。
やはり var < 0 ってのは直感的ではないし見ていて気持ちが悪いって感じる。
2008/01/21(月) 10:59:26
>>68
おお、これは新しい意見だ。
ついに、var < 0 が否定されたぞ。
2008/01/21(月) 10:59:59
>>68訂正
× var < 0
○ var > 0
2008/01/21(月) 11:04:38
私は < だろうが > だろうが関数呼び出し相手なら
if (0 <= func(
if (0 == func(
if (0 >= func(
だなぁ。
2008/01/21(月) 11:07:39
>>70
だろうな。
さすがに var < 0 を 0 > var って書く人はいないか。
いないよな？
2008/01/21(月) 11:10:36
よし纏めよう。
・定数右派
基本的に、常に定数が右。不等号の向きなんて関係ねぇ。
・定数左派
基本的に、常に定数が左。不等号の向きなんて関係ねぇ。
・不等号は数直線派
基本的に、不等号は常に左を小さく。定数の位置なんて関係ねぇ。

ダメだ、>71も恐らく例外があるのだろうし分類しきれない……
7463
垢版 |
2008/01/21(月) 11:22:37
>>64-72
回答ありがとう

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

…これ、どっかのMLの過去ログにもありそうだな
2008/01/21(月) 11:42:38
基本的に短い物が左。
そして変数同士の不等号は数直線派。
変数か定数かなんて関係ねぇ。

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

定数左ってよりは即値左か？
画面が狭かった頃の規約の名残だな。
2008/01/21(月) 13:24:24
こんなものは理屈じゃなくて、数学の記法では普通 0=x でなく x=0 と書くというのが一番大きい気がするけどな
不等号は3項関係なら数直線だが2項関係ならやはり変数を左辺に書くのが数学でも一般的だと思う
2008/01/21(月) 13:59:49
その理屈だと関数が絡んだときにおかしくないか？
数学だとy=f(x)の方が一般的でないか？
2008/01/21(月) 14:12:06
>数学だとy=f(x)の方が一般的でないか？

その記法は定数相手には使わないような。
確かに y については y = f( x ) 的な書き方をするけど、f(x) については f(x) = a * x + y 的な書き方もするはず。
だからまあプログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、それでも変数と定数に限れば 0=x ではなく x=0 だろう。
これはもう理屈とか抜きに。
2008/01/21(月) 14:27:50
>>78
数学に限って言えば、
＞0=x ではなく x=0 だろう
これは状況によりけりだな。まぁ、
＞プログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、
は正しいと思うので、数学のルールは適用できないんだけどね。
2008/01/21(月) 16:34:55
&&とか||が絡むなら不等号の向きをそろえるけど
それ以外なら気にしないな。
81デフォルトの名無しさん
垢版 |
2008/01/21(月) 16:36:21
またこの話か。去年さんざん「祭り」したのに。

もう秋田。
2008/01/21(月) 18:25:42
わざわざ来なくてもいいのに（笑）
2008/01/21(月) 18:34:21
基本的には数直線に合わせるけど、場合によっては変えるね。
言葉や数式で表現するとどうなるかを頭に置きながら
理解しやすい方を選択する。
84デフォルトの名無しさん
垢版 |
2008/01/21(月) 20:01:32
Cプログラマの為に、ポイントをまとめたドキュメントを販売しています。
プロのプログラマでもあまりにレベルが低い人が多すぎます。
そんな人に限って、自分のレベルの低さを自覚していない、、、
　本人は構わないかもしれませんが、その下についた新人プログラマは
たまったものではありません。（私が経験しました。）
　今になって分かりました。
彼らもまた、理解できていなかったのです。
　プログラミング言語の一番の習得の近道はきちんと理解している人にアドバイスをもらうこと。です。
私のC言語に取り組んだ7年間をすべてぶつけたつもりでテキストを作りました。
　私の会社の後輩からは、どんなテキストよりもわかりやすかった！や、
今まで教えてくれていた先輩や、テキストたちが、ちゃんと理解できていないことがわかりました。
と、嬉しいコメントをたくさんもらいました。
そしてなにより、彼らの社内での評価がとても高いということが、私の誇りです。
　興味がある方はどうか、下のサイトをみてみてください。
http://mori.eco.to/
2008/01/21(月) 20:04:01
ｳｾﾞｪ
2008/01/21(月) 21:33:16
みるまでもなくネタだろ
2008/08/02(土) 01:43:31
最近、カプセル化は要らん子な気がしてきた。
真面目に適用したところで可読性や保守性は上がるどころか下がることの方が多いし、
getter/setterを書くより、コメントやドキュメントをしっかり書いた方が良い気がする。
2008/08/02(土) 02:58:06
getter/setter が無いと、ついつい直接書き換えして
後の挙動が掴めなくなってしまう俺みたいな屑も居るので書いてくれて良い
2008/08/02(土) 09:35:09
つーか、そもそも下駄雪駄がある時点で間違いだろ。ちゃんと意味を考えたI/Fにするべきだ。
2008/09/28(日) 15:35:28
>>87
getter/setterがある時点でカプセル化に失敗してるよ
2008/09/28(日) 17:00:45
getter/setterだけでも、代入と取得のみに操作を限定できる利点がある。
メンバのアドレスを取られる心配がないだけでも幾らか安心感があると思うよ。
2008/09/28(日) 20:03:24
ブレークポインタもかけやすいしな。
だけとgetter/setterが多くなるとカプセル化の意義が薄れてしまうのも忘れてはならないね
2008/09/29(月) 03:59:22
設計から導き出されるのが、いい getter/setter
実装から導き出されるのが、悪い getter/setter

悪い getter/setter でも、将来の変更に備えて、無いよりマシ。
2008/10/04(土) 02:42:58
基本的な値はコンストラクタで受け取るだけで、その後はgetterのみ。
どうしても後から値を変更する必要があるとか、設定値の種類が多すぎる場合のみsetterを使うかな。
2009/02/03(火) 14:10:18
無限ループは
while(true){
}
って書くのが一番美しいと思うんです
2009/02/03(火) 14:28:30
for ("ever") {
}
2009/02/03(火) 19:29:38
>>95
それは意図しているのかそれともミスなのかが判断できない。

for(;;)
{
}

このほうが意図が明確
2009/02/03(火) 21:00:25
誘導されてきました

int* a;
int *a;

どっちのほうが見やすいですか？
2009/02/03(火) 21:32:24
int*型として考えるなら前者
変数自身がポインタと考えるなら後者
2009/02/03(火) 22:04:58
int* a, b;
とかやられるとヤヴァイから後者がいい
2009/02/03(火) 22:32:07
ポインタ型と普通の型をまとめて宣言しないでほしい
2009/02/03(火) 22:37:07
resありです＾＾
2009/02/03(火) 22:55:50
>100
こんなのコンパイルエラーで検出出来るだろJK
2009/02/03(火) 23:31:31
>>103
コンパイルに数分かかるプロジェクトを書いた事が無いのか
2009/02/04(水) 00:31:53
>>100
変数宣言分けるからどうでもいい
2009/02/04(水) 00:42:39
そもそも1行に2つも宣言しないよな
2009/02/04(水) 10:03:18
テンプレートではint*で１つの型なのに、>>100の例があるから困る。
でも俺はint* a;派。
2009/02/04(水) 10:55:18
結局、CもC++も書く私はint * a;で落ち着きましたとさ。
2009/02/04(水) 12:23:17
>>107
俺もint* a派。型を意識したりテンプレート使うとそうなるよね。
複数宣言はしない。行を分けてコメントを書く。だから>>100は無いものとしてC/C++で書いてる。
2009/02/04(水) 13:04:35
>>100
絶対賛成！

型がどうこういってるやつは、
typedef int *intpとかするがいい。
2009/02/04(水) 21:26:38
ポインタを typedef した時の const の挙動がなあ・・・
2009/02/05(木) 00:51:29
Code Complete には int *p にせよと書いてあったが、俺は >108 方式。

>>104
リンクまで込みでじゃなくて、一つのファイルをコンパイルするので？
そこ辞めてヨソ行った方がいいかも。
2009/02/05(木) 01:00:05
>>112
趣味で書いたやつでテンプレートをひどく使ってそういう事態になったことはあるが、
仕事なら絶対にできないな。
2009/02/05(木) 09:44:40
なんでC/C++は宣言の時、int *a, *b;という構文にしたんだろう？
キャストやテンプレートではint*を使うことになるのに。

スレ違いか。
2009/02/05(木) 17:16:21
>>114
*aがint型と読めるという話はよく聞く。
関数・配列が複雑に絡み合ったのも、そうやって解読していくし。

C++はCとの互換のため。
2009/02/05(木) 19:33:24
>>114
constへのポインタとconstポインタを
はっきり書きわけられることはメリット。

ぱっと見はわかりにくい文法だけど、
関数へのポインタとかも含めていろいろ
わかってくると、全体としては悪くないと
納得せざるをえないと思う。
2009/02/05(木) 20:44:49
>>116
それがどうした
2009/02/05(木) 21:24:38
>>116
const int* a, b;// aもbもconstへのポインタ
int* const c, d;// cもdもconstポインタ
こういう文法にして欲しかった。

関数へのポインタの宣言はかなり気持ち悪く感じる(typedefの挙動なんか特に)。
こっちもなんとかして欲しかった。
2009/02/05(木) 21:28:31
でも、ポインタを戻り値とする関数と区別するためにはやむを得ないんだよな・・・
2009/02/07(土) 04:21:07
>116
単純に記述量を減らすためかと。

例： int a = 1, *p = &a;
2009/02/07(土) 10:03:22
>>120
別の型を1行で宣言したいと思わない。
むしろint *a,*bがint* a,bで宣言できたら、1行で宣言する変数が１つ増える毎に1文字タイプ量が減ってありがたい。
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すべきだな。
124120
垢版 |
2009/02/08(日) 00:38:56
無名の構造体て書けなかったっけ?
そのポインタを宣言するのに必要な気がする。

struct ｛
｝ obj, *p;
2009/02/08(日) 00:41:41
それって、コンパイラが勝手に適当な名前を付けるやつだっけ
2009/02/08(日) 10:25:49
>>124
そのp使い道なくない？
型名が無名だから関数の引数に渡せるわけじゃないし、ヒープから確保することもできない。
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信者？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況