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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
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信者？
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)」を 使わないのか
これがそもそもおかしい
おそらく原作者はジョークのつもりだったろうが、真に受けてるアホがいるからな・・・
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況