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

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