探検
コーディングスタイルにこだわるスレ
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2007/10/28(日) 15:59:01 コーディングスタイルについて熱く語れ
472デフォルトの名無しさん
2010/03/14(日) 17:08:09 セミコロンじゃなくてコロンだった
473デフォルトの名無しさん
2010/03/14(日) 17:18:54 // インラインなら
hoge(): foo(apple), bar(banana),
yaw(orange), baz(strawberry)
{ ... }
// ソースに書くならこう
hoge::hoge():
foo(apple), bar(banana), yaw(orange),
baz(strawberry)
{
...
}
hoge(): foo(apple), bar(banana),
yaw(orange), baz(strawberry)
{ ... }
// ソースに書くならこう
hoge::hoge():
foo(apple), bar(banana), yaw(orange),
baz(strawberry)
{
...
}
474デフォルトの名無しさん
2010/03/14(日) 18:31:09 やっぱコロン、カンマは後ろに持ってきたほうが見た目がいいよね
回答ありがとう
回答ありがとう
475デフォルトの名無しさん
2010/03/15(月) 08:29:36 俺は真逆で、コロンが前に来てないと落ち着かない
というより、前置か二項っぽい意味合いのものは、行頭に来るように置くのが普通
だと思うけどなぁ
というより、前置か二項っぽい意味合いのものは、行頭に来るように置くのが普通
だと思うけどなぁ
476デフォルトの名無しさん
2010/03/15(月) 09:18:03 自分を中心に地球が回ってると考えるタイプの方ですね
477デフォルトの名無しさん
2010/03/15(月) 09:59:37478デフォルトの名無しさん
2010/03/15(月) 10:19:09 普通かどうかで言えば、コンマが後ろにくるのが普通だと思われているからこそ
enum 宣言や配列初期化子に余分なコンマがあっても許されるようになったのだろう。
俺は後ろ派だが、手前派には
・行単位の追加削除移動の時に手当ての必要が少ない
・縦に並べた時に筆算のようになるし、自然言語と親和する
というようなメリットがあるので理解できる。
後ろ派はメリットよりは慣習的なものだと思う。
改行の持つ意味合いが強かった頃の名残りではなかろうか。
コロンに関しては、元の英語での使い方が一対一や一対多の左側を明示するもの
なのだから、makefile やラベルのように後ろに付けるのが普通だろう。
enum 宣言や配列初期化子に余分なコンマがあっても許されるようになったのだろう。
俺は後ろ派だが、手前派には
・行単位の追加削除移動の時に手当ての必要が少ない
・縦に並べた時に筆算のようになるし、自然言語と親和する
というようなメリットがあるので理解できる。
後ろ派はメリットよりは慣習的なものだと思う。
改行の持つ意味合いが強かった頃の名残りではなかろうか。
コロンに関しては、元の英語での使い方が一対一や一対多の左側を明示するもの
なのだから、makefile やラベルのように後ろに付けるのが普通だろう。
479デフォルトの名無しさん
2010/03/15(月) 10:27:34 コロンは前、カンマは後ろ派
480デフォルトの名無しさん
2010/03/15(月) 10:29:51481デフォルトの名無しさん
2010/03/15(月) 10:33:48 漏れ、改行しないんだけど
hoge::hoge(): foo(), bar(), baz()
hoge::hoge(): foo(), bar(), baz()
482デフォルトの名無しさん
2010/03/15(月) 10:54:36 短いのはそれでいいんじゃね
483デフォルトの名無しさん
2010/03/15(月) 19:44:16 >>480
根拠を書かずに普通っていうと、476が出るぞ。
根拠を書かずに普通っていうと、476が出るぞ。
484デフォルトの名無しさん
2010/03/15(月) 22:10:50485デフォルトの名無しさん
2010/03/16(火) 14:42:09 >>484
君の経験上普通なのは疑ってない。
君の経験を普通だとする根拠を求めている。
例えば、Win32, *nix, 汎用機、マイコン、クライアントサイド、サーバサイド、
官公庁調達、金融系、業務系、Web 系、オープン系、データベース、
パッケージソフト、ガジェット、デーモン、デバドラ、分散、超並列、
大手、下請け、大学/研究所、他にも色んな分類の仕方があると思うが、
さまざまなカルチャーがある。
分類の抽象度は任せるが、いくつかを挙げて、
「こういった分野では普通だ」
「経験したこれとこれとこれの全ての分野で普通だ」
とするなら、ずっと説得力があるのではないだろうか。
君の経験上普通なのは疑ってない。
君の経験を普通だとする根拠を求めている。
例えば、Win32, *nix, 汎用機、マイコン、クライアントサイド、サーバサイド、
官公庁調達、金融系、業務系、Web 系、オープン系、データベース、
パッケージソフト、ガジェット、デーモン、デバドラ、分散、超並列、
大手、下請け、大学/研究所、他にも色んな分類の仕方があると思うが、
さまざまなカルチャーがある。
分類の抽象度は任せるが、いくつかを挙げて、
「こういった分野では普通だ」
「経験したこれとこれとこれの全ての分野で普通だ」
とするなら、ずっと説得力があるのではないだろうか。
486デフォルトの名無しさん
2010/03/16(火) 15:40:54 俺なら>>471の3。
この流儀に俺が行き着いたのは、SQLでクエリを書くようになってから。
文字列を*に置き換えて全体の形を表すと、
*******
***********
*****
********
******************
のように右側がデコボコし、そこにandやらorやら,やらが来ると、読むとき目がウネウネする。
区切り、中身(?)、の二種類で、文字のサイズが固定なものを左に持ってきたほうが、
読みやすさが増すと思う。上記の例を使ってカンタンに表すと、区切りを@として、
*******@
***********@
*****@
********@
******************
より、
*******
@***********
@*****
@********
@******************
がマシだという理屈。
この流儀に俺が行き着いたのは、SQLでクエリを書くようになってから。
文字列を*に置き換えて全体の形を表すと、
*******
***********
*****
********
******************
のように右側がデコボコし、そこにandやらorやら,やらが来ると、読むとき目がウネウネする。
区切り、中身(?)、の二種類で、文字のサイズが固定なものを左に持ってきたほうが、
読みやすさが増すと思う。上記の例を使ってカンタンに表すと、区切りを@として、
*******@
***********@
*****@
********@
******************
より、
*******
@***********
@*****
@********
@******************
がマシだという理屈。
487デフォルトの名無しさん
2010/03/16(火) 20:15:54 >>485
平たく言うと、普通○○なんじゃね、はこのスレでは絶対禁止ってことだな
平たく言うと、普通○○なんじゃね、はこのスレでは絶対禁止ってことだな
488デフォルトの名無しさん
2010/03/16(火) 20:29:02 >>486
ちょっとわかる。
SQLで長いWHERE節を書いてると、
普通の言語以上になんかくどく感じる。
ただ、AND/ORは行頭にまとめた
ほうがいいのでは、と思いつつ、今は
まだ行末に書くようにしてる。
ちょっとわかる。
SQLで長いWHERE節を書いてると、
普通の言語以上になんかくどく感じる。
ただ、AND/ORは行頭にまとめた
ほうがいいのでは、と思いつつ、今は
まだ行末に書くようにしてる。
489デフォルトの名無しさん
2010/03/17(水) 00:10:58 漏れも3)派。
でも区切り記号ではなく演算子の場合は行末の方が優れている部分もあると思う。
例えば一次的に演算子を置き換えてみたい場合、↓みたいに書ける。
***** + //-
*****
でもやっぱ3)が好き。
でも区切り記号ではなく演算子の場合は行末の方が優れている部分もあると思う。
例えば一次的に演算子を置き換えてみたい場合、↓みたいに書ける。
***** + //-
*****
でもやっぱ3)が好き。
490デフォルトの名無しさん
2010/03/17(水) 00:40:35 ttp://codepad.org/nYNt4bQw
491デフォルトの名無しさん
2010/03/17(水) 20:09:46492デフォルトの名無しさん
2010/03/17(水) 23:51:51493デフォルトの名無しさん
2010/03/19(金) 16:10:52 技術系の板で根拠の無い発言を当然とするのは残念だ。
494デフォルトの名無しさん
2010/03/19(金) 21:52:08 技術系じゃ完全な根拠を要求するのは不可能だろ
495デフォルトの名無しさん
2010/03/19(金) 22:07:52 ぶっちゃけ心理学とか社会学とかもかなり根拠曖昧なままやってるしな
496デフォルトの名無しさん
2010/03/21(日) 00:10:13497デフォルトの名無しさん
2010/03/21(日) 13:55:32 > 何かを主張する時に口からでまかせ言っていいことにはならないし
ならなくはないだろうw 好き勝手言えばいいし、それを止めるすべは無い。
ただ、それなりの根拠がないと相手にすらされないだけでw
ならなくはないだろうw 好き勝手言えばいいし、それを止めるすべは無い。
ただ、それなりの根拠がないと相手にすらされないだけでw
498デフォルトの名無しさん
2010/04/03(土) 01:47:17ちと聞きたいんだけど、
privateなメンバ変数、関数の頭にアンダースコアつけるマーチンファウラー式って、protectedなメンバ変数や関数にもアンダースコアつけるもの?
自分がよく見るJavaだと、privateに付けてるコードの中でもprotectedになるとバラバラな感じだけど、どっちが主流or論理的根拠があるのかな
つかファウラーたんはなんて言ってるんだろう?
499デフォルトの名無しさん
2010/04/03(土) 11:20:33 それをマーチンファウラー式と呼ぶのは知らなかったw
500デフォルトの名無しさん
2010/04/03(土) 15:40:03 名前をアンスコで始めるのはやめたほうがいいんじゃね?
厳密に言うと _MyFunc とか C++言語の規定違反だったと思うけど。
ま、つけるなら public 以外全部だな。
厳密に言うと _MyFunc とか C++言語の規定違反だったと思うけど。
ま、つけるなら public 以外全部だな。
501498
2010/04/04(日) 11:44:39502デフォルトの名無しさん
2010/04/04(日) 13:48:42 > C#とかは末尾にアンスコつけるらしいね
____
/ \
/ ─ ─ \
/ (●) (●) \
| (__人__) |
\ ` ⌒´ ,/
r、 r、/ ヘ
ヽヾ 三 |:l1 ヽ
\>ヽ/ |` } | |
ヘ lノ `'ソ | |
/´ / |. |
\. ィ | |
| | |
____
/ \
/ ─ ─ \
/ (●) (●) \
| (__人__) |
\ ` ⌒´ ,/
r、 r、/ ヘ
ヽヾ 三 |:l1 ヽ
\>ヽ/ |` } | |
ヘ lノ `'ソ | |
/´ / |. |
\. ィ | |
| | |
503デフォルトの名無しさん
2010/04/04(日) 14:50:07 あ、ごめん
末尾にアンスコもC++か
「末尾 アンダースコア」でぐぐったらC++の話が出てくるから、さっきの規約違反回避のためにそうやるのかな?
つけておくとコードみたらすぐわかるし、thisとかいらなくなるし、コード内で名前重複しづらくなるし、メソッドでも付けるぐらい気にいってるけど、最近は付けない風潮なのかなあ
末尾にアンスコもC++か
「末尾 アンダースコア」でぐぐったらC++の話が出てくるから、さっきの規約違反回避のためにそうやるのかな?
つけておくとコードみたらすぐわかるし、thisとかいらなくなるし、コード内で名前重複しづらくなるし、メソッドでも付けるぐらい気にいってるけど、最近は付けない風潮なのかなあ
504デフォルトの名無しさん
2010/04/04(日) 14:52:20 アンスコってアンダースコートの事かと思った
505デフォルトの名無しさん
2010/04/05(月) 00:18:23506デフォルトの名無しさん
2010/04/05(月) 21:55:39 >>503
スコープを知りたくなること自体が、設計か実装が悪臭を放っている可能性を
示唆していると考える人は否定的になる。
プラグマチックに考えるなら、そのルールが有益になるチームはいくらでも
あるだろうと思う。
スコープを知りたくなること自体が、設計か実装が悪臭を放っている可能性を
示唆していると考える人は否定的になる。
プラグマチックに考えるなら、そのルールが有益になるチームはいくらでも
あるだろうと思う。
507デフォルトの名無しさん
2010/04/05(月) 22:27:28 だからといって敢えて削除するメリットがあるとも思えないし
混乱を深めるだけだと思う
混乱を深めるだけだと思う
508デフォルトの名無しさん
2010/04/05(月) 23:22:03 そうそう
付けないメリットより、付けるメリットの方が多い気がするんだよね
IDEが発達していらなくなるという主張も聞いた事あるけど、IDEだからこそ、一文字目からアンダースコアの有無による補完リストのフィルタリングとかできて便利だと思うんだが
付けないメリットより、付けるメリットの方が多い気がするんだよね
IDEが発達していらなくなるという主張も聞いた事あるけど、IDEだからこそ、一文字目からアンダースコアの有無による補完リストのフィルタリングとかできて便利だと思うんだが
509デフォルトの名無しさん
2010/04/05(月) 23:59:24 一文字目アンスコはC/C++で規格違反になると何度言えば(ry
見苦しかろうが m_ とかにすれ
見苦しかろうが m_ とかにすれ
510デフォルトの名無しさん
2010/04/06(火) 00:47:59 アンスコってアンインストールの事かと思った
511506
2010/04/06(火) 14:53:28512デフォルトの名無しさん
2010/04/06(火) 21:13:10 正確には何らかのネームスペース内ではだな
グローバルネームスペースでは不適合
グローバルネームスペースでは不適合
513デフォルトの名無しさん
2010/04/06(火) 21:14:49 メンバでは結局適合だけどね
ただ混乱を避けるために一律禁止した方が良い
よく知らない人が書いちゃうし
ただ混乱を避けるために一律禁止した方が良い
よく知らない人が書いちゃうし
514デフォルトの名無しさん
2010/04/06(火) 21:22:11 こいつらはgotoで書いて良いかどうかって議論をあまり聞かないが、どうだろうか
for (i = 0; i < n; i++) {
REDO:
...
if (...) goto REDO;
...
}
REWIND:
for (i = 0; i < n; i++) {
...
if (...) goto REWIND;
...
}
どちらもgoto使うのが一番簡潔かつ分かりやすいと思うのだが、
必要になるケースが少ないからか、議題に上る事すらない気がする
でもたまーに必要になることがあるのよね
その時いつもgoto使いたくなるけど我慢して別の方法を使ってるが、
やっぱりgoto使うのが一番エレガントだと思うのだがどうよ
for (i = 0; i < n; i++) {
REDO:
...
if (...) goto REDO;
...
}
REWIND:
for (i = 0; i < n; i++) {
...
if (...) goto REWIND;
...
}
どちらもgoto使うのが一番簡潔かつ分かりやすいと思うのだが、
必要になるケースが少ないからか、議題に上る事すらない気がする
でもたまーに必要になることがあるのよね
その時いつもgoto使いたくなるけど我慢して別の方法を使ってるが、
やっぱりgoto使うのが一番エレガントだと思うのだがどうよ
515デフォルトの名無しさん
2010/04/06(火) 23:05:32 REWINDは時々使う
REDOはほとんどcontinueで代用できる
REDOはほとんどcontinueで代用できる
516デフォルトの名無しさん
2010/04/06(火) 23:16:28 でも、i-- して continue; とか
i++ を最後に書いて continue; とか
何かキモくね?
i++ を最後に書いて continue; とか
何かキモくね?
517デフォルトの名無しさん
2010/04/07(水) 00:44:07 まぁ、continue や break も字面が違うだけで goto だからな。
else の ない if 文は goto 書いてあってもなくても
実質 goto だし、goto はよく使うよ。
ループの中で goto 使うときは while() で書いたほうが
気持ちの上では抵抗が少ないかな。
else の ない if 文は goto 書いてあってもなくても
実質 goto だし、goto はよく使うよ。
ループの中で goto 使うときは while() で書いたほうが
気持ちの上では抵抗が少ないかな。
518デフォルトの名無しさん
2010/04/07(水) 01:06:20519デフォルトの名無しさん
2010/04/07(水) 08:16:11 for の再初期化式以外でループ変数を触るような場合は、
while か do で書くかな。
その goto REWIND はありだと思うけど。
while か do で書くかな。
その goto REWIND はありだと思うけど。
520デフォルトの名無しさん
2010/04/07(水) 18:52:37521デフォルトの名無しさん
2010/04/09(金) 22:57:22 for( int i=0,step=1; i < n; i+=step,step=1 ) {
...
if( ... ) {
step=0; //REWND時は step=-i
continue;
}
...
}
...
if( ... ) {
step=0; //REWND時は step=-i
continue;
}
...
}
522デフォルトの名無しさん
2010/04/10(土) 08:15:27 きったねえソースだな
523デフォルトの名無しさん
2010/04/13(火) 02:32:01 if (n == 0) goto end;
start1:
i = 0;
start2:
...
if (!...) goto start3;
goto start1;
start3:
...
i++;
if (i >= n) goto end;
goto start2;
end:
あんまり面白くなかった。。。
start1:
i = 0;
start2:
...
if (!...) goto start3;
goto start1;
start3:
...
i++;
if (i >= n) goto end;
goto start2;
end:
あんまり面白くなかった。。。
524デフォルトの名無しさん
2010/04/15(木) 01:05:19 for文のトコとかフラグを使う辺りが醜いのは認めますが…だめっすかね。>522
●>521のメリット
・ネストが無駄に深くならない。
・通常のfor文同様、ループ処理の肝となる処理が1行に集約されてる。
・カウンタの更新タイミングが明確。
例えばカウンタを直接操作する方法でやってしまいがちな、↓のようなミスを防げる。
if( i == x ) i = 0; //カウンタリセット(処理は継続) ← この行を追加
...
++data[i]; // data[x] にincrementされない。
・フローの制御方法が(比較的)単純明快。↓
for( int i=0,step=1; i < n; i+=step,step=1 ) {
if( ... ) step = 0; // もう1回
if( ... ) step = -i; // 最初から
if( ... ) step = -n; // n個戻る
if( ... ) step += n; // n個スキップ
}
●>521のメリット
・ネストが無駄に深くならない。
・通常のfor文同様、ループ処理の肝となる処理が1行に集約されてる。
・カウンタの更新タイミングが明確。
例えばカウンタを直接操作する方法でやってしまいがちな、↓のようなミスを防げる。
if( i == x ) i = 0; //カウンタリセット(処理は継続) ← この行を追加
...
++data[i]; // data[x] にincrementされない。
・フローの制御方法が(比較的)単純明快。↓
for( int i=0,step=1; i < n; i+=step,step=1 ) {
if( ... ) step = 0; // もう1回
if( ... ) step = -i; // 最初から
if( ... ) step = -n; // n個戻る
if( ... ) step += n; // n個スキップ
}
525デフォルトの名無しさん
2010/04/15(木) 17:17:58 >>524
毎回そのコメント書くんならいいんじゃない?
ただ、step=1 がレギュラーケースじゃない場合を考えて、step=1/*次へ*/ もループ中に書いたほうがいいと思うけど。
記述意図を明確にする意味なら、data や i を構造体にラップしてそれを操作する関数群を用意した方が良いだろう。
毎回そのコメント書くんならいいんじゃない?
ただ、step=1 がレギュラーケースじゃない場合を考えて、step=1/*次へ*/ もループ中に書いたほうがいいと思うけど。
記述意図を明確にする意味なら、data や i を構造体にラップしてそれを操作する関数群を用意した方が良いだろう。
526デフォルトの名無しさん
2010/04/15(木) 20:40:40 >>524
>・ネストが無駄に深くならない。
goto 使った時とネストの深さに変化は無いし、
goto を使った方が if がすっきりする
>・通常のfor文同様、ループ処理の肝となる処理が1行に集約されてる。
一行にたくさんの処理を詰め込んだだけで、分かり辛くなるだけ
goto だと単純な上に、ラベルにより意味も明解
>・カウンタの更新タイミングが明確。
goto を使った方が分かりやすい
i+=step,step=1 なんて頭を使ってどういうコードか理解しないと分からない
>・フローの制御方法が(比較的)単純明快。
step が途中で変わるのはとても分かり辛い
普通、そういう場合は for でカウンタを操作するのをやめて、
常に { } 内で直接カウンタを操作するようにする
そもそも、REDO や REWIND が必要なケースは稀であり、
そんな稀なケースに、より単純で明解な実装法があるにも関わらず、
複雑な技巧を凝らしたコードを仕込むのは得策ではない
goto が最も危険なのは、変数宣言を下に飛び越えたり、ブロック内に飛び込んだりする時だが、
REDO や REWIND はこの使い方には相当しない
飛ぶ位置はループ頭やループ前という極めて安全な位置のみであり、
かつ、どんな処理を行いたいのかが極めて分かりやすく、
goto を使う事に問題は無いと言える
>・ネストが無駄に深くならない。
goto 使った時とネストの深さに変化は無いし、
goto を使った方が if がすっきりする
>・通常のfor文同様、ループ処理の肝となる処理が1行に集約されてる。
一行にたくさんの処理を詰め込んだだけで、分かり辛くなるだけ
goto だと単純な上に、ラベルにより意味も明解
>・カウンタの更新タイミングが明確。
goto を使った方が分かりやすい
i+=step,step=1 なんて頭を使ってどういうコードか理解しないと分からない
>・フローの制御方法が(比較的)単純明快。
step が途中で変わるのはとても分かり辛い
普通、そういう場合は for でカウンタを操作するのをやめて、
常に { } 内で直接カウンタを操作するようにする
そもそも、REDO や REWIND が必要なケースは稀であり、
そんな稀なケースに、より単純で明解な実装法があるにも関わらず、
複雑な技巧を凝らしたコードを仕込むのは得策ではない
goto が最も危険なのは、変数宣言を下に飛び越えたり、ブロック内に飛び込んだりする時だが、
REDO や REWIND はこの使い方には相当しない
飛ぶ位置はループ頭やループ前という極めて安全な位置のみであり、
かつ、どんな処理を行いたいのかが極めて分かりやすく、
goto を使う事に問題は無いと言える
527デフォルトの名無しさん
2010/04/15(木) 22:20:30 >>524
そこまで制御書くなら for じゃなくて while 使うなあ
そこまで制御書くなら for じゃなくて while 使うなあ
528デフォルトの名無しさん
2010/04/16(金) 02:23:13 >525
関数とかでラップしちゃうとカウンタの変化するタイミングとかが却ってわかり辛いと思うんですが。
例えば↓
for( Counter<int> i = 0; i < n; i.increment() ) {
if( ... ) i.retry(); //← retry実行後、i の値はどうなる?
std::cout << i <<std::endl; // retry実行時、何が出力される?
}
これだと i を直接操作する方がよっぽど素直かと。
(わざわざ「step」を使うのは、直接操作した場合生じる問題を回避するため)
>526
素直にgoto使う方がよりシンプルなのは否定しません。
ただ524は「gotoを使わない」という前提ありきで書いてます。
「公開しないコード書く時」あるいは「明示的に許可されてる」のでない限り
gotoは使うべきじゃ無いと思うので。
>527
その辺は適当に読み変えて下さい。
個人的な趣味&行数を抑える目的&etcで for1行にしました。
関数とかでラップしちゃうとカウンタの変化するタイミングとかが却ってわかり辛いと思うんですが。
例えば↓
for( Counter<int> i = 0; i < n; i.increment() ) {
if( ... ) i.retry(); //← retry実行後、i の値はどうなる?
std::cout << i <<std::endl; // retry実行時、何が出力される?
}
これだと i を直接操作する方がよっぽど素直かと。
(わざわざ「step」を使うのは、直接操作した場合生じる問題を回避するため)
>526
素直にgoto使う方がよりシンプルなのは否定しません。
ただ524は「gotoを使わない」という前提ありきで書いてます。
「公開しないコード書く時」あるいは「明示的に許可されてる」のでない限り
gotoは使うべきじゃ無いと思うので。
>527
その辺は適当に読み変えて下さい。
個人的な趣味&行数を抑える目的&etcで for1行にしました。
529デフォルトの名無しさん
2010/04/16(金) 07:02:33 > 「公開しないコード書く時」あるいは「明示的に許可されてる」のでない限り
> gotoは使うべきじゃ無いと思うので。
ダイクストラも罪作りなことをしたもんだ。
> gotoは使うべきじゃ無いと思うので。
ダイクストラも罪作りなことをしたもんだ。
530デフォルトの名無しさん
2010/04/16(金) 09:23:16 教条的にGOTOを排除しようとするのは80年代に蔓延したおかしな傾向だろ。
ダイクストラが言ったのは60年代末。
ダイクストラが言ったのは60年代末。
531デフォルトの名無しさん
2010/04/16(金) 20:46:59 >>528
goto 使わない場合は次のように実装できる
REDO:
for (int i = 0; i < size; ++i) {
bool redo;
do {
redo = false;
if (...) { redo = true; continue; }
} while (redo);
}
REWIND:
bool rewind;
do {
rewind = false;
for (int i = 0; i < size; ++i) {
if (...) { rewind = true; break; }
}
} while (rewind);
カウンタに一切手を加えない分、step を使うよりは分かりやすい
もちろん、goto の方が分かりやすいが
goto 使わない場合は次のように実装できる
REDO:
for (int i = 0; i < size; ++i) {
bool redo;
do {
redo = false;
if (...) { redo = true; continue; }
} while (redo);
}
REWIND:
bool rewind;
do {
rewind = false;
for (int i = 0; i < size; ++i) {
if (...) { rewind = true; break; }
}
} while (rewind);
カウンタに一切手を加えない分、step を使うよりは分かりやすい
もちろん、goto の方が分かりやすいが
532デフォルトの名無しさん
2010/04/16(金) 21:39:42 REDOを多重ループにすると今度はbreakでループを抜けられない…
とか思ったけど、そんなレアケース考えてもしょうがないか
とか思ったけど、そんなレアケース考えてもしょうがないか
533デフォルトの名無しさん
2010/04/16(金) 21:46:21 複雑なら関数化も視野に入れていいんじゃない
534デフォルトの名無しさん
2010/04/16(金) 23:11:08 じゃC++0xのラムダ関数で
535525
2010/04/16(金) 23:44:09 >>528
もっと説明的なコードを書こうよ、って話。
Counter<int> i なんて名前じゃ曖昧になって当然。
CodeIterator currentCode(data, CodeIterator::Head);
if (...) currentCode.rewindToHead();
とかにしようよ。
先頭に巻き戻した後に、何が出力されるかどうかもないでしょ。先頭のだよ。
その構造は、中間言語処理や書式化文字列処理など、様々な場面で登場する。
その時々に相応しい構造と命名をしたら良い。
もっと説明的なコードを書こうよ、って話。
Counter<int> i なんて名前じゃ曖昧になって当然。
CodeIterator currentCode(data, CodeIterator::Head);
if (...) currentCode.rewindToHead();
とかにしようよ。
先頭に巻き戻した後に、何が出力されるかどうかもないでしょ。先頭のだよ。
その構造は、中間言語処理や書式化文字列処理など、様々な場面で登場する。
その時々に相応しい構造と命名をしたら良い。
536デフォルトの名無しさん
2010/04/18(日) 13:34:35 >531
漏れはその書き方が一番無難だと思う。
goto使う方法はgotoの使用が許されるなら最善手だとは思うけど、
叩かれるのを覚悟して使うほどのメリットは無いと思う。
(叩かれるのを覚悟して>521を書いた奴が言う台詞じゃ無いけど)
>535
そこまで書くよりは、普通に↓と書く方が良いと思うけど。
for( int i=0; i<n; ++i ) {
if( ... ) i =-1; //最初から
}
ただこの例を見ても分かるように、カウンタを直接弄る方法は
「最初から」が何故-1なのか直感的に分かり辛い。
(>535みたいな書き方しても同様の問題が出てくる。)
だから>521。でもって↑も521も、下手に関数化するよりは
手の内を全て見せてしまった方が分かり易いと思われる。
まぁそこまでやるなら素直に>531のが良いとは思いますが。
漏れはその書き方が一番無難だと思う。
goto使う方法はgotoの使用が許されるなら最善手だとは思うけど、
叩かれるのを覚悟して使うほどのメリットは無いと思う。
(叩かれるのを覚悟して>521を書いた奴が言う台詞じゃ無いけど)
>535
そこまで書くよりは、普通に↓と書く方が良いと思うけど。
for( int i=0; i<n; ++i ) {
if( ... ) i =-1; //最初から
}
ただこの例を見ても分かるように、カウンタを直接弄る方法は
「最初から」が何故-1なのか直感的に分かり辛い。
(>535みたいな書き方しても同様の問題が出てくる。)
だから>521。でもって↑も521も、下手に関数化するよりは
手の内を全て見せてしまった方が分かり易いと思われる。
まぁそこまでやるなら素直に>531のが良いとは思いますが。
537デフォルトの名無しさん
2010/04/18(日) 13:35:59 追記。
ただ>531のredoは
for (int i = 0; i < size; ++i) {
do {
// 繰り返す処理
} while ( ... );
}
と書くべきかと。フラグ要らんでしょ。
ただ>531のredoは
for (int i = 0; i < size; ++i) {
do {
// 繰り返す処理
} while ( ... );
}
と書くべきかと。フラグ要らんでしょ。
538デフォルトの名無しさん
2010/04/18(日) 13:57:59 本当は if は途中に出てきてるのだよ
539デフォルトの名無しさん
2010/04/18(日) 14:52:50 >538
>531
>if (...) { redo = true; continue; }
continueしとるで。
>531
>if (...) { redo = true; continue; }
continueしとるで。
540デフォルトの名無しさん
2010/04/18(日) 18:10:11 こういうことだよ
for (int i = 0; i < size; ++i) {
bool redo;
do {
redo = false;
...
if (...) { redo = true; continue; }
...
} while (redo);
}
for (int i = 0; i < size; ++i) {
bool redo;
do {
redo = false;
...
if (...) { redo = true; continue; }
...
} while (redo);
}
541デフォルトの名無しさん
2010/04/18(日) 18:12:11 >>514の一つ目をdo while文で書いたときのフラグなしバージョン
for (...) {
do {
...
if (...) continue;
...
break;
} while(true);
}
まあ、redoはできても通常のcontinue、breakができなくなるけどね
for (...) {
do {
...
if (...) continue;
...
break;
} while(true);
}
まあ、redoはできても通常のcontinue、breakができなくなるけどね
542デフォルトの名無しさん
2010/04/18(日) 18:17:17 通常の意味でのcontinueはdo while文の中でbreakすればいいか
ややこしい…
ややこしい…
543デフォルトの名無しさん
2010/04/18(日) 18:32:55 お前らおかしいぞ
普通に goto 使え
普通に goto 使え
544デフォルトの名無しさん
2010/04/18(日) 19:51:37 飛び先を制御するためだけに
ループしない while を用意するのは邪悪
ループしない while を用意するのは邪悪
545デフォルトの名無しさん
2010/04/18(日) 21:16:50 普段gotoを使わないから>>514のようなケースのとき
gotoを使うってとこまで頭が働かないな
gotoを使うってとこまで頭が働かないな
546デフォルトの名無しさん
2010/04/19(月) 08:13:33 無限ループは for (;;) {} で、ループしないループは do {} while (0) で、
というのはイディオム。
というのはイディオム。
547デフォルトの名無しさん
2010/04/19(月) 19:25:34 do {} while (0); は continue しようが何しようが必ず抜けるから
continue した時はループする >>541 とは全く別の話だな
continue した時はループする >>541 とは全く別の話だな
548デフォルトの名無しさん
2010/06/12(土) 22:46:29 >>514のコードを書き換えるという前提では、結局gotoを使うのが一番簡潔に
なるんだろうけど、実際のコーディングではケースバイケースで全然違う書き方を
すると思う。
いったん普通にループを抜けてからREWINDやREDOに相当する処理を別にするとか。
なるんだろうけど、実際のコーディングではケースバイケースで全然違う書き方を
すると思う。
いったん普通にループを抜けてからREWINDやREDOに相当する処理を別にするとか。
549デフォルトの名無しさん
2010/06/18(金) 01:39:17 最近言語に関係なくインデントにスペース2つを使うプロジェクトを
よく見る気がするんですが、これって元々どの辺の文化で使われていたんでしょうか?
よく見る気がするんですが、これって元々どの辺の文化で使われていたんでしょうか?
550デフォルトの名無しさん
2010/06/18(金) 19:27:50 スクリプト言語じゃないかね
551デフォルトの名無しさん
2010/06/18(金) 19:50:49 GNU?
552デフォルトの名無しさん
2010/06/18(金) 23:54:30 ぐにゅ?
553デフォルトの名無しさん
2010/06/28(月) 10:51:33554デフォルトの名無しさん
2010/06/28(月) 10:59:34 GNU indent 2.2.3で試してみた。
::::::::::::::foo.c // オリジナル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0) printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.kr.c // K&Rスタイル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0)
printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.gnu.c // GNUスタイル
#include <stdio.h>
int
main ()
{
for (int ic = 0; ic < 10; ++ic)
{
if (ic % 2 == 0)
printf ("%d\n", ic);
}
return 0;
}
::::::::::::::foo.c // オリジナル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0) printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.kr.c // K&Rスタイル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0)
printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.gnu.c // GNUスタイル
#include <stdio.h>
int
main ()
{
for (int ic = 0; ic < 10; ++ic)
{
if (ic % 2 == 0)
printf ("%d\n", ic);
}
return 0;
}
555デフォルトの名無しさん
2010/06/28(月) 15:41:41 >>554
navi2chとかchalice使いでないと違いわからんだろ、これ
navi2chとかchalice使いでないと違いわからんだろ、これ
556デフォルトの名無しさん
2010/06/28(月) 16:30:35 >554を変換してみた
::::::::::::::foo.c // オリジナル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0) printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.kr.c // K&Rスタイル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0)
printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.gnu.c // GNUスタイル
#include <stdio.h>
int
main ()
{
for (int ic = 0; ic < 10; ++ic)
{
if (ic % 2 == 0)
printf ("%d\n", ic);
}
return 0;
}
::::::::::::::foo.c // オリジナル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0) printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.kr.c // K&Rスタイル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0)
printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.gnu.c // GNUスタイル
#include <stdio.h>
int
main ()
{
for (int ic = 0; ic < 10; ++ic)
{
if (ic % 2 == 0)
printf ("%d\n", ic);
}
return 0;
}
557デフォルトの名無しさん
2010/06/29(火) 22:32:49558デフォルトの名無しさん
2010/12/12(日) 19:10:07 以下のような理由をあげて、 「構造体の typedef 禁止!!!」つったのに
平気で typedef srruct foo { ... } foo_t; をやってくるおまえらは
なにものですか > 今度使ってる害虫
Avoid using typedefs for structure types. Typedefs are problematic
because they do not properly hide their underlying type; for example you
need to know if the typedef is the structure itself or a pointer to the
structure. In addition they must be declared exactly once, whereas an
incomplete structure type can be mentioned as many times as necessary.
Typedefs are difficult to use in stand-alone header files: the header
that defines the typedef must be included before the header that uses it,
or by the header that uses it (which causes namespace pollution), or
there must be a back-door mechanism for obtaining the typedef.
平気で typedef srruct foo { ... } foo_t; をやってくるおまえらは
なにものですか > 今度使ってる害虫
Avoid using typedefs for structure types. Typedefs are problematic
because they do not properly hide their underlying type; for example you
need to know if the typedef is the structure itself or a pointer to the
structure. In addition they must be declared exactly once, whereas an
incomplete structure type can be mentioned as many times as necessary.
Typedefs are difficult to use in stand-alone header files: the header
that defines the typedef must be included before the header that uses it,
or by the header that uses it (which causes namespace pollution), or
there must be a back-door mechanism for obtaining the typedef.
559デフォルトの名無しさん
2010/12/12(日) 20:19:08560デフォルトの名無しさん
2010/12/13(月) 02:21:42 キャッチボールで相手のレベルに合わせて投げるのと同じように、
コミュニケーションでも相手のレベルに合わせて伝えるべき。
子供相手に変化球投げたりしないだろ?
と、昔上司から言われた台詞を貴方にも。
コミュニケーションでも相手のレベルに合わせて伝えるべき。
子供相手に変化球投げたりしないだろ?
と、昔上司から言われた台詞を貴方にも。
561デフォルトの名無しさん
2010/12/13(月) 03:09:28 >>559, 560
そのほかに指示したのは、「名前の長さは長くても20文字程度に押さえてね」だけで、
こっちは守られてるのに、「構造体の typedef 禁止」は無視するってのはおかしくないか?
一部の地域には構造体を typedef しなきゃいけない宗教的理由でもあるのか?
そのほかに指示したのは、「名前の長さは長くても20文字程度に押さえてね」だけで、
こっちは守られてるのに、「構造体の typedef 禁止」は無視するってのはおかしくないか?
一部の地域には構造体を typedef しなきゃいけない宗教的理由でもあるのか?
562デフォルトの名無しさん
2010/12/13(月) 03:53:23 >>561
少なくとも、妄信的にtypedefする奴はいる。
少なくとも、妄信的にtypedefする奴はいる。
563デフォルトの名無しさん
2010/12/13(月) 07:30:35 >>561
http://www.google.co.jp/search?q=%E5%85%A5%E9%96%80+typedef+struct
名前20文字以内が守れてるってのは、普通にやってればなかなかそこまで
長くならないってだけかもしれない。
http://www.google.co.jp/search?q=%E5%85%A5%E9%96%80+typedef+struct
名前20文字以内が守れてるってのは、普通にやってればなかなかそこまで
長くならないってだけかもしれない。
564デフォルトの名無しさん
2010/12/13(月) 22:03:37 妄信的に単語を短縮する奴もいる。
酷いのだと何でもかんでもアルファベット3文字とか。
特にCOBOLer上がり。
酷いのだと何でもかんでもアルファベット3文字とか。
特にCOBOLer上がり。
565デフォルトの名無しさん
2010/12/14(火) 00:18:34 H8環境でC++使ってないとtypedefだらけになる。
566デフォルトの名無しさん
2010/12/23(木) 22:21:26 >>558
そういうトラブルは typedef を禁止したところで
なくならないし未然防止にもならない。
そもそも言語に対するスキルというか
リテラシーが低いことが問題。
名前の長さも同じこと。 不思議な省略単語濫用で
20文字以内になっても意味がない。
そういうトラブルは typedef を禁止したところで
なくならないし未然防止にもならない。
そもそも言語に対するスキルというか
リテラシーが低いことが問題。
名前の長さも同じこと。 不思議な省略単語濫用で
20文字以内になっても意味がない。
567デフォルトの名無しさん
2010/12/23(木) 23:58:54568デフォルトの名無しさん
2010/12/24(金) 01:23:48 タグ名と typedef 名が同一ならよいのだから、そのくらいはヴァリデータツールを書いて、通らなければコミットできないようにしてしまえばよいのではないか。
569デフォルトの名無しさん
2010/12/24(金) 13:17:29570デフォルトの名無しさん
2010/12/26(日) 10:09:36 まぁ、下請けになめられてるんだろうな。
571デフォルトの名無しさん
2010/12/28(火) 19:29:32572デフォルトの名無しさん
2010/12/28(火) 22:13:38 >>571
"they must be declared exactly once"
"the header that defines the typedef must be included before the header that uses it"
A.h で struct A だけが宣言されていて、使う側で毎度 struct A と書く場合、
使う側で A.h をインクルードせずに struct A の前方宣言で済ませることができる。
A.h で struct A の宣言に加えて typedef struct A A があり、関連する関数の宣言に
struct A* ではなく A* が現れる場合、 A* を使うためには必ず A.h のインクルードが
必要になる。
問題が3つだとしたら2つは残ってるように見える。
何か誤解されてるんじゃなかろうか?
"they must be declared exactly once"
"the header that defines the typedef must be included before the header that uses it"
A.h で struct A だけが宣言されていて、使う側で毎度 struct A と書く場合、
使う側で A.h をインクルードせずに struct A の前方宣言で済ませることができる。
A.h で struct A の宣言に加えて typedef struct A A があり、関連する関数の宣言に
struct A* ではなく A* が現れる場合、 A* を使うためには必ず A.h のインクルードが
必要になる。
問題が3つだとしたら2つは残ってるように見える。
何か誤解されてるんじゃなかろうか?
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 「おこめ券は米以外の食品も買える。効果的な活用を」 地元で農水相 [山形県] [少考さん★]
- 【速報】「女芸人No.1決定戦 THE W」9代目女王にニッチェ! 7年ぶり3度目で悲願の優勝 [牛丼★]
- 【芸能】『女芸人No.1決定戦THE W』 粗品が最後にバッサリ「優勝賞金1000万円にしてはレベル低い大会」 [冬月記者★]
- 今年の流行語大賞 『働いて働いて働いてまいります』が受賞で不快感… 過労自殺の遺族らが会見「家族にむち打つような行為だ」 [冬月記者★]
- 【東京】「家族で話題にして」 “世田谷一家殺害から25年 警視庁が呼びかけ [煮卵★]
- 【広島】ペルー女性の国保加入を誤って認め、福山市が医療費484万円を肩代わりするミス…入院して手術を受ける [ぐれ★]
- 宅急便デス
- さっむ
- ッシャー
- ちはるのかちはらないのか
- クズ「勉強頑張らなかった奴は一生DQNと一緒に肉体労働しろ」☚勉強頑張れるのも環境と巡り合わせなんだが? [783475554]
- 失われた30年から脱却する方法
