探検
コーディングスタイルにこだわるスレ
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2007/10/28(日) 15:59:01 コーディングスタイルについて熱く語れ
421デフォルトの名無しさん
2009/12/10(木) 00:01:11 カーニハンの「プログラミング作法」ぐらい読んどけよ。
422デフォルトの名無しさん
2009/12/10(木) 00:09:02 診断室で一番共感したのは、糞グラマを無理に使うくらいなら切り捨てた方がマシ、
ってとこだな
ってとこだな
424デフォルトの名無しさん
2009/12/12(土) 02:46:17 関数を分割するべきか否かを、関数の行数や
if等のネストの深さで、機械的に判断するのは間違い。
…などと書いてみるテスト。
一連の処理の固まりを、「処理内容が大体想像できる一文」で
置換する(記述を要約する)のが正しい関数化の手法であって、
行数等を判断基準に関数化するというのは、
ぶつ切りしてるに過ぎないと思う。
でもってこの「〜する」の一文を見つけたり、まとめられるように
フローをアレンジする能力ってのが、プログラムのセンスって奴だと思う。
if等のネストの深さで、機械的に判断するのは間違い。
…などと書いてみるテスト。
一連の処理の固まりを、「処理内容が大体想像できる一文」で
置換する(記述を要約する)のが正しい関数化の手法であって、
行数等を判断基準に関数化するというのは、
ぶつ切りしてるに過ぎないと思う。
でもってこの「〜する」の一文を見つけたり、まとめられるように
フローをアレンジする能力ってのが、プログラムのセンスって奴だと思う。
425デフォルトの名無しさん
2009/12/13(日) 00:14:47 バカを統制するのには機械的な基準はある程度有効
426デフォルトの名無しさん
2009/12/13(日) 00:28:09 「こういうコーディングスタイル、ダサいよな」みたいな話題で、
わざわざ「俺はバカどもを使ってるから仕方なくやってんだよ」って
反論してくるやつって、実は本人がそのダサいスタイルなんじゃないかって
気がしてならない。
わざわざ「俺はバカどもを使ってるから仕方なくやってんだよ」って
反論してくるやつって、実は本人がそのダサいスタイルなんじゃないかって
気がしてならない。
427デフォルトの名無しさん
2009/12/13(日) 18:32:43 無能プロジェクトリーダの決める規準より言語設計者の決めるものの方がまし、
という意味で、言語がこと細かにスタイルを規定して欲しい。
という意味で、言語がこと細かにスタイルを規定して欲しい。
428デフォルトの名無しさん
2009/12/13(日) 19:15:24 Pythonのことか
429デフォルトの名無しさん
2009/12/13(日) 20:28:37 >425
関数名(+引数等) = 処理内容の要約となるよう設計(分割)すべき、
ってルールはさほど難しく無いと思うんだ。
…と思ったけど要約できん奴は、ダラダラ書くんだろうな…
ダラダラ書かせない為に機械的制限は有効だと思うけど、
えてして基本が忘れ去られてる、と思うんだ漏れは。
関数名(+引数等) = 処理内容の要約となるよう設計(分割)すべき、
ってルールはさほど難しく無いと思うんだ。
…と思ったけど要約できん奴は、ダラダラ書くんだろうな…
ダラダラ書かせない為に機械的制限は有効だと思うけど、
えてして基本が忘れ去られてる、と思うんだ漏れは。
430デフォルトの名無しさん
2009/12/14(月) 23:31:25 そして void add_A_and_B(void) みたいな
関数を書く奴が出てくるんだな。
関数を書く奴が出てくるんだな。
431デフォルトの名無しさん
2009/12/14(月) 23:36:42 そんなレベルならどんな規則で縛ろうと無意味
432デフォルトの名無しさん
2009/12/15(火) 02:07:21 >430
そーいうのを良しとするとは書いてなかろう。
そーいうのばかり抑制する事に気を取られて、
基本的な部分がおざなりになってるということ。
そーいうのを良しとするとは書いてなかろう。
そーいうのばかり抑制する事に気を取られて、
基本的な部分がおざなりになってるということ。
433デフォルトの名無しさん
2009/12/22(火) 15:01:18 enum { SpecialID1, SpecialID2 }; でそれぞれに値を
記憶する場所があってそれを設定する場合に
1) Set_SpecialID1or2(SpecialID1, int value)
2) Set_SpecialID1(int value), Set_SpecialID2(int value)
3) Set(SpecialID1, int value)
4) Set_Special(flag, val1, ...) //flag: 1のみ、2のみもしくは両方を指定可能
どれが好き?
わしは 3) でこっそり実装して 2) の
マクロを提供って感じなんだがオススメとかある?
記憶する場所があってそれを設定する場合に
1) Set_SpecialID1or2(SpecialID1, int value)
2) Set_SpecialID1(int value), Set_SpecialID2(int value)
3) Set(SpecialID1, int value)
4) Set_Special(flag, val1, ...) //flag: 1のみ、2のみもしくは両方を指定可能
どれが好き?
わしは 3) でこっそり実装して 2) の
マクロを提供って感じなんだがオススメとかある?
434デフォルトの名無しさん
2009/12/22(火) 18:47:11435デフォルトの名無しさん
2009/12/22(火) 23:01:42 だって、シンボル数が増えると
起動時間遅くなるから。。。
起動時間遅くなるから。。。
436デフォルトの名無しさん
2009/12/23(水) 01:22:14 >>433
口頭で動作を説明する場合の表現に近いコードを選ぶべし。
口頭で動作を説明する場合の表現に近いコードを選ぶべし。
437デフォルトの名無しさん
2009/12/23(水) 19:35:57 じゃ、SVOC だな。
438デフォルトの名無しさん
2009/12/24(木) 03:10:27 >433
漏れならこう書く。
bool SetHoge( int key, int value )
bool GetHoge( int key, int& value )
int GetHoge( int key, int error_value = 0 ) //手抜き版
エラーハンドリングが不要なケースではもっと端折るけど。
漏れならこう書く。
bool SetHoge( int key, int value )
bool GetHoge( int key, int& value )
int GetHoge( int key, int error_value = 0 ) //手抜き版
エラーハンドリングが不要なケースではもっと端折るけど。
439デフォルトの名無しさん
2009/12/24(木) 21:47:18 なんかこういうのってデザインパターンにないんだっけ?
440デフォルトの名無しさん
2009/12/24(木) 22:07:50 ない
441デフォルトの名無しさん
2010/01/27(水) 12:43:02 >>433
本当に、単純に値を出し入れするだけなら
3)かなあ。これSpecialIDの設定はintじゃないよね?
ところで、C#をやるようになってから
C++でこの手の値入出力系のメンバにGet,Setをつけなくなった。
こんな感じ。
class tes
{
private:
int m_data;
public:
int Data() const { return this->m_data; }
void Data(int data) { this->m_data = data; }
};
実装していて今の所問題ない。俺の場合は。
これって、どんな問題が考えられる?
本当に、単純に値を出し入れするだけなら
3)かなあ。これSpecialIDの設定はintじゃないよね?
ところで、C#をやるようになってから
C++でこの手の値入出力系のメンバにGet,Setをつけなくなった。
こんな感じ。
class tes
{
private:
int m_data;
public:
int Data() const { return this->m_data; }
void Data(int data) { this->m_data = data; }
};
実装していて今の所問題ない。俺の場合は。
これって、どんな問題が考えられる?
442デフォルトの名無しさん
2010/01/28(木) 00:36:10443デフォルトの名無しさん
2010/02/20(土) 16:25:28444デフォルトの名無しさん
2010/02/20(土) 16:28:26 rubyとかだとね、x.data = 0と書けるね。
445デフォルトの名無しさん
2010/02/21(日) 09:56:48 コーディングルールとして完全に縛ってれば別に問題は無いんじゃね。初期化子とかに
似ているといえば似ている気もしなくもないし。
ただ、暗黙の変換に似た気持ち悪さは感じるが。
似ているといえば似ている気もしなくもないし。
ただ、暗黙の変換に似た気持ち悪さは感じるが。
446デフォルトの名無しさん
2010/02/21(日) 17:38:20 関数をオーバーロードにするか、別名の関数にするかの判断基準ってどうしてます?
447デフォルトの名無しさん
2010/02/21(日) 23:09:19 漏れは機能が似てるならオーバーロードするね
448デフォルトの名無しさん
2010/02/21(日) 23:14:09 そういうのはクラスを使う人のための配慮だから実装がどうだからオーバーロード使うとかいう
基準を設けるのは間違ってるだろ
基準を設けるのは間違ってるだろ
449デフォルトの名無しさん
2010/02/22(月) 00:08:58 メリットが何もないからオーバーロードはしない
450デフォルトの名無しさん
2010/02/22(月) 02:43:29 メリットのある場合もある
無い時はしない方がいい
暗黙の型変換とかと同じで、しないと大変なことになるんじゃなければ、しない方がいい
無い時はしない方がいい
暗黙の型変換とかと同じで、しないと大変なことになるんじゃなければ、しない方がいい
451デフォルトの名無しさん
2010/02/22(月) 08:31:37452デフォルトの名無しさん
2010/03/05(金) 16:33:59 関数で、自分では操作しないけど戻り値は自己責任で自由に使ってねって言う場合、
std::vector<int> &GetVector() const { return const_cast<std::vector<int> &>(this->m_vector); }
こんな感じで書いてるんだけど、まずいかな。
const関数なんで使う側はコピーを返してると勘違いするとか。
なんか、自分ではいじらない、ただ渡したものは自由に使っていいよ
っていうものの正しい書き方が見えない。orz
std::vector<int> &GetVector() const { return const_cast<std::vector<int> &>(this->m_vector); }
こんな感じで書いてるんだけど、まずいかな。
const関数なんで使う側はコピーを返してると勘違いするとか。
なんか、自分ではいじらない、ただ渡したものは自由に使っていいよ
っていうものの正しい書き方が見えない。orz
453デフォルトの名無しさん
2010/03/05(金) 17:00:54 const_castが必要になる状況は不自然。無理を通している。
constのvectorってのも不可解。何に使うつもり?
constのvectorってのも不可解。何に使うつもり?
454デフォルトの名無しさん
2010/03/05(金) 17:09:19 constメソッドにするとvs2008ではメンバが
const定義扱いでコンパイルされるらしい。
this->m_vectorはconstじゃないけど、GetVector() const;で内からそのまま返すと
error C2440: 'return' : 'const std::vector<_Ty>' から 'std::vector<_Ty> &' に変換できません。
とエラーが出る。
const定義扱いでコンパイルされるらしい。
this->m_vectorはconstじゃないけど、GetVector() const;で内からそのまま返すと
error C2440: 'return' : 'const std::vector<_Ty>' から 'std::vector<_Ty> &' に変換できません。
とエラーが出る。
455デフォルトの名無しさん
2010/03/05(金) 19:14:42 >>454が何を言っているのかわからない
456デフォルトの名無しさん
2010/03/05(金) 19:34:56457デフォルトの名無しさん
2010/03/05(金) 19:57:36 const 版と非 const 版を作る。
const オブジェクトに対しても使えるようにするなら、メンバを mutable 修飾する。
スタイル的には、そんな設計がおかしい。
変更する必要のある側が保持して、使う側はその時点のものを借りる関係であるべきだ。
452 のは、ヨソの家の無線LANにただのりするような構造だ。
仕方の無いときはあるが、そんな時は別のスレがふさわしい。
const オブジェクトに対しても使えるようにするなら、メンバを mutable 修飾する。
スタイル的には、そんな設計がおかしい。
変更する必要のある側が保持して、使う側はその時点のものを借りる関係であるべきだ。
452 のは、ヨソの家の無線LANにただのりするような構造だ。
仕方の無いときはあるが、そんな時は別のスレがふさわしい。
458デフォルトの名無しさん
2010/03/05(金) 20:55:11459デフォルトの名無しさん
2010/03/06(土) 01:04:58460デフォルトの名無しさん
2010/03/06(土) 02:23:03461デフォルトの名無しさん
2010/03/06(土) 03:11:30462デフォルトの名無しさん
2010/03/06(土) 03:20:03 >>461
なんで >459 へのレスが >456 へのレスと同じになるの?
なんで >459 へのレスが >456 へのレスと同じになるの?
463デフォルトの名無しさん
2010/03/06(土) 13:45:49464デフォルトの名無しさん
2010/03/06(土) 13:53:10 コンパイルエラーが出るからconst外しをするとか
コーディングスタイル以前の問題
コーディングスタイル以前の問題
465デフォルトの名無しさん
2010/03/06(土) 13:59:57 > 内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で
メンバ変数、しかもベクタ丸ごと外に晒そうなんて考える奴が言う台詞か?w
メンバ変数、しかもベクタ丸ごと外に晒そうなんて考える奴が言う台詞か?w
466デフォルトの名無しさん
2010/03/06(土) 17:28:15467デフォルトの名無しさん
2010/03/06(土) 17:33:42 >>466
それって普通の「内部状態変更しないよ的な意味でのconst」と何が違うの?
それって普通の「内部状態変更しないよ的な意味でのconst」と何が違うの?
468デフォルトの名無しさん
2010/03/06(土) 17:44:49 上の例だと、渡す時は内部状態を操作しないけど、戻り値は自己責任で自由に使ってね
それによって内部状態が変更されるよって言う場合。
std::vector<int> &GetVector() const;
それによって内部状態が変更されるよって言う場合。
std::vector<int> &GetVector() const;
469デフォルトの名無しさん
2010/03/06(土) 18:00:30 >>468
外部で自由に設定していいものを「内部状態」とは言わんだろうし、
それを反映してコードでもメンバ変数にするべきじゃないでしょ。
ってすでに >457 も >459 も言ってるんだけど、それについてはどう
なのさ?
外部で自由に設定していいものを「内部状態」とは言わんだろうし、
それを反映してコードでもメンバ変数にするべきじゃないでしょ。
ってすでに >457 も >459 も言ってるんだけど、それについてはどう
なのさ?
470デフォルトの名無しさん
2010/03/07(日) 00:54:36 >>466
const tes ctes;
があったとき、ctes が変更されそうな操作をコンパイラがエラーにしてくれるのは素晴らしいことだ。
非 const メンバ関数を呼んだり、非 const ポインタ(や参照)への変換はもちろんエラーだ。
他に、オブジェクト内部の変数のアドレスを返すことについても、コンパイラは追跡してくれる。
非 const のアドレスを返すと、外から内部状態を変更されてしまうかも知れないから、わざわざチェック
してエラーにしてくれる。
458 のエラーは、C++ の規格でそうなっている。
とても有難い機能で、コンパイラベンダのみなさんがこの機能を頑張って実装してくれたお陰で、僕らは
constness の追跡について機械任せでいられる。
これにより、 const メンバ関数だけを呼ぶ限り、const オブジェクトについて、関数を呼んだ時も呼んだ
後も内部状態が変化していないことを想定していいことになる。お行儀のいいコードならだけど。
だから、const の意味を二つに分ける必要なんて無い。
アリナシの話は、それどころか原則 const であるべきで、観念的に副作用がある場合のみ非 const
であるべき。
そして const 版と非 const 版の両方が必要なら実装すればいい。
const tes ctes;
があったとき、ctes が変更されそうな操作をコンパイラがエラーにしてくれるのは素晴らしいことだ。
非 const メンバ関数を呼んだり、非 const ポインタ(や参照)への変換はもちろんエラーだ。
他に、オブジェクト内部の変数のアドレスを返すことについても、コンパイラは追跡してくれる。
非 const のアドレスを返すと、外から内部状態を変更されてしまうかも知れないから、わざわざチェック
してエラーにしてくれる。
458 のエラーは、C++ の規格でそうなっている。
とても有難い機能で、コンパイラベンダのみなさんがこの機能を頑張って実装してくれたお陰で、僕らは
constness の追跡について機械任せでいられる。
これにより、 const メンバ関数だけを呼ぶ限り、const オブジェクトについて、関数を呼んだ時も呼んだ
後も内部状態が変化していないことを想定していいことになる。お行儀のいいコードならだけど。
だから、const の意味を二つに分ける必要なんて無い。
アリナシの話は、それどころか原則 const であるべきで、観念的に副作用がある場合のみ非 const
であるべき。
そして const 版と非 const 版の両方が必要なら実装すればいい。
471デフォルトの名無しさん
2010/03/14(日) 17:06:10 C++のクラスでメンバ変数が多いとき、コンストラクタ初期化子を
改行して書くと思うんだけどどう書く?
セミコロンとカンマをどこに持ってくるのかが知りたい
1)
hoge::hoge()
: foo(),
bar(),
baz()
2) googleスタイル?
hoge::hoge()
: foo(),
bar(),
baz()
3)
hoge::hoge()
: foo()
, bar()
, baz()
4)
hoge::hoge() :
foo(),
bar(),
baz()
改行して書くと思うんだけどどう書く?
セミコロンとカンマをどこに持ってくるのかが知りたい
1)
hoge::hoge()
: foo(),
bar(),
baz()
2) googleスタイル?
hoge::hoge()
: foo(),
bar(),
baz()
3)
hoge::hoge()
: foo()
, bar()
, baz()
4)
hoge::hoge() :
foo(),
bar(),
baz()
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;
}
...
}
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【サッカー】Jリーグ観客動員が歴代最多を更新 初の「1300万人超え」達成…平均入場者数も史上最高に [尺アジ★]
- サナエノミクスについて力説 積極的な財政出動で「所得増える 消費マインド上がる 税収増える」片山さつき財務大臣 ★3 [少考さん★]
- 日中対立「着地点」見えず 中国、他国にも圧力の過去―関係悪化から1カ月 [蚤の市★]
- 日本の英語力96位から動かず AI評価で可視化された「読めるが話せない」の正体 (EF EPI 2025) ★2 [少考さん★]
- 【芸能】粗品、日本テレビに苦言 客のレベルが「かなり低い。あいつら分かってない」「拍手したいだけやねん」 [冬月記者★]
- 【静岡】伊東市長選、前市議の杉本氏初当選 学歴詐称疑惑の田久保氏は及ばず 市長選3700万円、市議選6300万円の計1億円費やされる [ぐれ★]
- なんでネトウヨが勃起してるの? [377482965]
- 【朗報】イーロン・マスク「AIとロボットで誰も働かなくて良くなる。全員ニートで金銭も税金もないパラダイスみてぇな国を作りてえ」 [347751896]
- 駄目な社会不適合者を1人思い浮かべてからこのスレを開いて下さい
- 【悲報】米山隆一と室井佑月、ガチで離婚しそうwwwwwwwwwwwwwwwwwwww [802034645]
- 伊東市の元市長、高市が激励メッセージを送り自民党県連が全面支援したのに敗北 [931948549]
- 【画像】兵庫県民「立花さんの動画を見て真実を知った。斎藤さん頑張れ!」→立花、デマと正式に認定され逮捕 [732289945]
