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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
2009/12/08(火) 14:42:14
> 事後の関数分けをしないでもいいって、どんな神プログラマだよｗ

残念、俺は糞プログラマだよｗ
2009/12/08(火) 14:42:55
底辺はリファクタリングを知らない。
2009/12/08(火) 14:47:21
>>412
なんだ。そうか。納得した。

自覚があるなら >405 みたいなミスリーディングな主張は控えていただきたい。
2009/12/08(火) 15:38:25
コーディング規約の大半は普通のプログラマのためではなく、
あなたの隣に座っているプログラマのような何かが生産し続ける、
見ただけで死ぬような目潰しコードを多少は見られるようにするという
崇高な試みのために存在する。
2009/12/09(水) 00:16:00
むしろコーディングに主義主張を持つ俺らみたいのが二人以上いると
宗教戦争を起こすので「めんどくせえからこーしとけ」的なルールな気もｗ
417385
垢版 |
2009/12/09(水) 02:05:52
>>411
なるほど。たしかにメソッドの記述の順番が気になる箇所は、
関数をどんどん深く呼び出してる箇所とほぼ一致してるなあ。
そういう箇所はコードが読みにくいというよりも、そもそも
クラス構造に問題がありそう。
そういった、クラスの構造や粒度などについて書かれてる
書籍でおすすめのものがあれば教えてくれるとうれしい。
2009/12/09(水) 12:10:51
ソースを上から順に読むとか、飛び先を目で探すとかってことは
めったにないんで、べつに順番はどうでもいい。
気になるんだったら、アルファベット順にでも並べとけばいい。
419411
垢版 |
2009/12/09(水) 13:29:14
>>417
まず大前提としてはKISS(Keep it simple, stupid)があって、
これはいつまでたっても我々にとって有効な指針になると思う…。

「Cプログラミング診断室　藤原 博文」
　構造化のテクを磨くことも大事。楽しい読み物。
　余計なことやヘンなことはしない、ということの大事さが分かる。

「リファクタリング　マーチン ファウラー」
　目新しさは無いかもしれないが、押さえておいていいかも。

「オブジェクト指向における再利用のためのデザインパターン　GoF」
「オブジェクト指向入門 第2版 原則・コンセプト　バートランド・メイヤー」
　自力で独学でOOP能力を高めていくのも大事だけど、
　OOPとは何ぞや、優れた設計とは何ぞや、を本から学びたければ。
　個人的に、デザパタ本は手垢で黒くなってきてるほど読んでる。

> クラスの構造や粒度などについて書かれてる書籍

で、肝心のコレはちょっと思いつかないｗ

ただ、図書館行って片っ端から技術書立ち読みしたら、
それっぽい本にきっと出合えると思う。
アジャイルなんたらっていう赤い本も面白かった気が。
技術系MLアーカイブを追っかけたり
（ttp://java-house.jp/ml/topics/topics.html#style）
するのもいいかも。なんかいい本あったら教えてｗ
2009/12/09(水) 13:35:48
Ｃプログラミング診断室
ttp://www.pro.or.jp/~fuji/mybooks/cdiag/index.html

これならお手軽に読める。内容はちょっと古いかもしれないし、
内容のすべてに同意できるとは限らないけど、
ある程度の距離を保って読めば、やっぱ今でも面白いかと。
2009/12/10(木) 00:01:11
カーニハンの「プログラミング作法」ぐらい読んどけよ。
2009/12/10(木) 00:09:02
診断室で一番共感したのは、糞グラマを無理に使うくらいなら切り捨てた方がマシ、
ってとこだな
423385
垢版 |
2009/12/11(金) 01:01:26
>>419,420
ありがとう。「Cプログラミング診断室」読んでみる。
2009/12/12(土) 02:46:17
関数を分割するべきか否かを、関数の行数や
if等のネストの深さで、機械的に判断するのは間違い。
…などと書いてみるテスト。

一連の処理の固まりを、「処理内容が大体想像できる一文」で
置換する（記述を要約する）のが正しい関数化の手法であって、
行数等を判断基準に関数化するというのは、
ぶつ切りしてるに過ぎないと思う。

でもってこの「～する」の一文を見つけたり、まとめられるように
フローをアレンジする能力ってのが、プログラムのセンスって奴だと思う。
2009/12/13(日) 00:14:47
バカを統制するのには機械的な基準はある程度有効
2009/12/13(日) 00:28:09
「こういうコーディングスタイル、ダサいよな」みたいな話題で、
わざわざ「俺はバカどもを使ってるから仕方なくやってんだよ」って
反論してくるやつって、実は本人がそのダサいスタイルなんじゃないかって
気がしてならない。
2009/12/13(日) 18:32:43
無能プロジェクトリーダの決める規準より言語設計者の決めるものの方がまし、
という意味で、言語がこと細かにスタイルを規定して欲しい。
2009/12/13(日) 19:15:24
Pythonのことか
2009/12/13(日) 20:28:37
>425
関数名（+引数等） = 処理内容の要約となるよう設計（分割）すべき、
ってルールはさほど難しく無いと思うんだ。

…と思ったけど要約できん奴は、ダラダラ書くんだろうな…
ダラダラ書かせない為に機械的制限は有効だと思うけど、
えてして基本が忘れ去られてる、と思うんだ漏れは。
2009/12/14(月) 23:31:25
そして void add_A_and_B(void) みたいな
関数を書く奴が出てくるんだな。
2009/12/14(月) 23:36:42
そんなレベルならどんな規則で縛ろうと無意味
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： １のみ、２のみもしくは両方を指定可能

どれが好き？

わしは 3) でこっそり実装して 2) の
マクロを提供って感じなんだがオススメとかある？
2009/12/22(火) 18:47:11
>>433
マクロはよくない。
2009/12/22(火) 23:01:42
だって、シンボル数が増えると
起動時間遅くなるから。。。
2009/12/23(水) 01:22:14
>>433
口頭で動作を説明する場合の表現に近いコードを選ぶべし。
2009/12/23(水) 19:35:57
じゃ、SVOC だな。
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 )　　//手抜き版

エラーハンドリングが不要なケースではもっと端折るけど。
2009/12/24(木) 21:47:18
なんかこういうのってデザインパターンにないんだっけ？
2009/12/24(木) 22:07:50
ない
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; }
};

実装していて今の所問題ない。俺の場合は。
これって、どんな問題が考えられる？
2010/01/28(木) 00:36:10
>>441
x.Data(0);
↑一見して何してんのか読み取れない。
2010/02/20(土) 16:25:28
>>442
分かるじゃん。
Dataは何らかのオブジェクトのコレクション (Datumの複数形だからね) を表していて
その0番目の要素を参照しようとしてるんだよ。


・・あれ？ 違う・・だと・・？
2010/02/20(土) 16:28:26
rubyとかだとね、x.data = 0と書けるね。
2010/02/21(日) 09:56:48
コーディングルールとして完全に縛ってれば別に問題は無いんじゃね。初期化子とかに
似ているといえば似ている気もしなくもないし。
ただ、暗黙の変換に似た気持ち悪さは感じるが。
2010/02/21(日) 17:38:20
関数をオーバーロードにするか、別名の関数にするかの判断基準ってどうしてます？
2010/02/21(日) 23:09:19
漏れは機能が似てるならオーバーロードするね
2010/02/21(日) 23:14:09
そういうのはクラスを使う人のための配慮だから実装がどうだからオーバーロード使うとかいう
基準を設けるのは間違ってるだろ
2010/02/22(月) 00:08:58
メリットが何もないからオーバーロードはしない
2010/02/22(月) 02:43:29
メリットのある場合もある
無い時はしない方がいい

暗黙の型変換とかと同じで、しないと大変なことになるんじゃなければ、しない方がいい
2010/02/22(月) 08:31:37
>>447-450
どうもです。
利用者が引数に渡す型が違う事を意識するものは、オーバーロードを使わない方針にします。
2010/03/05(金) 16:33:59
関数で、自分では操作しないけど戻り値は自己責任で自由に使ってねって言う場合、

std::vector<int> &GetVector() const { return const_cast<std::vector<int> &>(this->m_vector); }

こんな感じで書いてるんだけど、まずいかな。
const関数なんで使う側はコピーを返してると勘違いするとか。
なんか、自分ではいじらない、ただ渡したものは自由に使っていいよ
っていうものの正しい書き方が見えない。orz
2010/03/05(金) 17:00:54
const_castが必要になる状況は不自然。無理を通している。
constのvectorってのも不可解。何に使うつもり？
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> &' に変換できません。

とエラーが出る。
2010/03/05(金) 19:14:42
>>454が何を言っているのかわからない
2010/03/05(金) 19:34:56
>>452
＞なんか、自分ではいじらない、ただ渡したものは自由に使っていいよ
＞っていうものの正しい書き方が見えない。orz
非constメンバ関数にするべき。
2010/03/05(金) 19:57:36
const 版と非 const 版を作る。
const オブジェクトに対しても使えるようにするなら、メンバを mutable 修飾する。

スタイル的には、そんな設計がおかしい。
変更する必要のある側が保持して、使う側はその時点のものを借りる関係であるべきだ。
452 のは、ヨソの家の無線LANにただのりするような構造だ。
仕方の無いときはあるが、そんな時は別のスレがふさわしい。
2010/03/05(金) 20:55:11
>>455
ああごめん。vs2008だとこれが通らないよって話。
class tes
{
private:
std::vector<int> m_vector;
public:
std::vector<int> &GetVector() const { return this->m_vector; }
};

>>456
そういうもんかー。
内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で
constつけといた方が喜ばれるかと思ったけど、取っておくか。㌧クス。
2010/03/06(土) 01:04:58
>>452
> 関数で、自分では操作しないけど戻り値は自己責任で自由に使ってねって言う場合、

それ、メンバに持ってるのがおかしいだろ。
2010/03/06(土) 02:23:03
>>458
通るわけねえだろ const なめんな。
通るコンパイラを見せてみろ。
スタイルの問題じゃなくて知識の問題だってんだ。
2010/03/06(土) 03:11:30
>>459
そういうもんかー。
内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で
constつけといた方が喜ばれるかと思ったけど、取っておくか。㌧クス。

>>460
>>452～>>455の流れで>>458に続く。
知識じゃなくて日本語の問題だなぁおいｗ
2010/03/06(土) 03:20:03
>>461
なんで >459 へのレスが >456 へのレスと同じになるの？
2010/03/06(土) 13:45:49
>>460
> const なめんな。

なんかカッコイイ発言だなｗ
2010/03/06(土) 13:53:10
コンパイルエラーが出るからconst外しをするとか
コーディングスタイル以前の問題
2010/03/06(土) 13:59:57
> 内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で

メンバ変数、しかもベクタ丸ごと外に晒そうなんて考える奴が言う台詞か？ｗ
2010/03/06(土) 17:28:15
>>465
なるほど。サンプルが悪いと。
んでは誰か聞かせて欲しいんだけど

中で余計な事しないよ的な意味でのconst

ってあり？なし？もしくは、これを実現する場合は
>>457のconst 版と非 const 版を作る。が最良？
2010/03/06(土) 17:33:42
>>466
それって普通の「内部状態変更しないよ的な意味でのconst」と何が違うの？
2010/03/06(土) 17:44:49
上の例だと、渡す時は内部状態を操作しないけど、戻り値は自己責任で自由に使ってね
それによって内部状態が変更されるよって言う場合。
std::vector<int> &GetVector() const;
2010/03/06(土) 18:00:30
>>468
外部で自由に設定していいものを「内部状態」とは言わんだろうし、
それを反映してコードでもメンバ変数にするべきじゃないでしょ。
ってすでに >457 も >459 も言ってるんだけど、それについてはどう
なのさ？
2010/03/07(日) 00:54:36
>>466
const tes ctes;
があったとき、ctes が変更されそうな操作をコンパイラがエラーにしてくれるのは素晴らしいことだ。
非 const メンバ関数を呼んだり、非 const ポインタ（や参照）への変換はもちろんエラーだ。
他に、オブジェクト内部の変数のアドレスを返すことについても、コンパイラは追跡してくれる。
非 const のアドレスを返すと、外から内部状態を変更されてしまうかも知れないから、わざわざチェック
してエラーにしてくれる。

458 のエラーは、C++ の規格でそうなっている。
とても有難い機能で、コンパイラベンダのみなさんがこの機能を頑張って実装してくれたお陰で、僕らは
constness の追跡について機械任せでいられる。
これにより、 const メンバ関数だけを呼ぶ限り、const オブジェクトについて、関数を呼んだ時も呼んだ
後も内部状態が変化していないことを想定していいことになる。お行儀のいいコードならだけど。
だから、const の意味を二つに分ける必要なんて無い。

アリナシの話は、それどころか原則 const であるべきで、観念的に副作用がある場合のみ非 const
であるべき。

そして const 版と非 const 版の両方が必要なら実装すればいい。
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()
2010/03/14(日) 17:08:09
セミコロンじゃなくてコロンだった
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)
{
...
}
2010/03/14(日) 18:31:09
やっぱコロン、カンマは後ろに持ってきたほうが見た目がいいよね
回答ありがとう
2010/03/15(月) 08:29:36
俺は真逆で、コロンが前に来てないと落ち着かない
というより、前置か二項っぽい意味合いのものは、行頭に来るように置くのが普通
だと思うけどなぁ
2010/03/15(月) 09:18:03
自分を中心に地球が回ってると考えるタイプの方ですね
2010/03/15(月) 09:59:37
つーか、ある程度まともなコーディング基準で、>>475に反するものは見たことが無い
>>473に反するものは良く見る

もちろん、どこかには反対の例もあるかもしれんけど
2010/03/15(月) 10:19:09
普通かどうかで言えば、コンマが後ろにくるのが普通だと思われているからこそ
enum 宣言や配列初期化子に余分なコンマがあっても許されるようになったのだろう。

俺は後ろ派だが、手前派には
・行単位の追加削除移動の時に手当ての必要が少ない
・縦に並べた時に筆算のようになるし、自然言語と親和する
というようなメリットがあるので理解できる。

後ろ派はメリットよりは慣習的なものだと思う。
改行の持つ意味合いが強かった頃の名残りではなかろうか。

コロンに関しては、元の英語での使い方が一対一や一対多の左側を明示するもの
なのだから、makefile やラベルのように後ろに付けるのが普通だろう。
2010/03/15(月) 10:27:34
コロンは前、カンマは後ろ派
2010/03/15(月) 10:29:51
訂正

ラベルのコロンは当然後ろ
クラス初期化子のとこのコロンは前

つか、色々ソース見ても、>>471の1か2が普通じゃね？
2010/03/15(月) 10:33:48
漏れ、改行しないんだけど

hoge::hoge(): foo(), bar(), baz()
2010/03/15(月) 10:54:36
短いのはそれでいいんじゃね
2010/03/15(月) 19:44:16
>>480
根拠を書かずに普通っていうと、476が出るぞ。
2010/03/15(月) 22:10:50
>>483
いろんなソースをそれなりに見てる人なら大体同じように感じると思うけどな
統計でも取らなきゃ文句言われるってんなら知らん
2010/03/16(火) 14:42:09
>>484
君の経験上普通なのは疑ってない。
君の経験を普通だとする根拠を求めている。

例えば、Win32, *nix, 汎用機、マイコン、クライアントサイド、サーバサイド、
官公庁調達、金融系、業務系、Web 系、オープン系、データベース、
パッケージソフト、ガジェット、デーモン、デバドラ、分散、超並列、
大手、下請け、大学/研究所、他にも色んな分類の仕方があると思うが、
さまざまなカルチャーがある。

分類の抽象度は任せるが、いくつかを挙げて、
　「こういった分野では普通だ」
　「経験したこれとこれとこれの全ての分野で普通だ」
とするなら、ずっと説得力があるのではないだろうか。
2010/03/16(火) 15:40:54
俺なら>>471の3。
この流儀に俺が行き着いたのは、SQLでクエリを書くようになってから。
文字列を*に置き換えて全体の形を表すと、

*******
***********
*****
********
******************

のように右側がデコボコし、そこにandやらorやら,やらが来ると、読むとき目がウネウネする。
区切り、中身（？）、の二種類で、文字のサイズが固定なものを左に持ってきたほうが、
読みやすさが増すと思う。上記の例を使ってカンタンに表すと、区切りを@として、

*******@
***********@
*****@
********@
******************

より、

*******
@***********
@*****
@********
@******************

がマシだという理屈。
2010/03/16(火) 20:15:54
>>485
平たく言うと、普通○○なんじゃね、はこのスレでは絶対禁止ってことだな
2010/03/16(火) 20:29:02
>>486
ちょっとわかる。
SQLで長いWHERE節を書いてると、
普通の言語以上になんかくどく感じる。

ただ、AND/ORは行頭にまとめた
ほうがいいのでは、と思いつつ、今は
まだ行末に書くようにしてる。
2010/03/17(水) 00:10:58
漏れも3)派。
でも区切り記号ではなく演算子の場合は行末の方が優れている部分もあると思う。
例えば一次的に演算子を置き換えてみたい場合、↓みたいに書ける。

　***** + //-
　*****

でもやっぱ3)が好き。
2010/03/17(水) 00:40:35
ttp://codepad.org/nYNt4bQw
2010/03/17(水) 20:09:46
>>487
学問カテと技術系板では、無限定の「普通」を使うべきではないと思う。
別に「普通」であることの証明を求めているわけじゃなくて、根拠を求めてるだけなんだけどね。
2010/03/17(水) 23:51:51
>>491
俺は、技術系板では無限定の「普通」を使うべきではない、とは思わないな。
学問と技術なんざ別物だ。
2010/03/19(金) 16:10:52
技術系の板で根拠の無い発言を当然とするのは残念だ。
2010/03/19(金) 21:52:08
技術系じゃ完全な根拠を要求するのは不可能だろ
2010/03/19(金) 22:07:52
ぶっちゃけ心理学とか社会学とかもかなり根拠曖昧なままやってるしな
2010/03/21(日) 00:10:13
お前ら携帯か？ 流れ読めよ。

>>494
何で「完全な根拠」なんていう、文脈から外れたものを持ってくるんだ。
経験が根拠ならどういう経験なのかを、実験が根拠ならどういう実験かを述べよというだけのことだ。

>>495
実験なりモデルなり、根拠は論文に提示してあるだろう。
おかしなものは否定したらよい。
具体的に何か一つでも挙げてみろ。


ハイゼンベルクの不確定性原理やらゲーデルの不完全性定理やらが定着した現在、そんな完全な証明なんて求めるわけが無い。
だがしかし、何かを主張する時に口からでまかせ言っていいことにはならないし、そうでないと説得すべく努力すべきだ。
2010/03/21(日) 13:55:32
> 何かを主張する時に口からでまかせ言っていいことにはならないし

ならなくはないだろうｗ　好き勝手言えばいいし、それを止めるすべは無い。
ただ、それなりの根拠がないと相手にすらされないだけでｗ
2010/04/03(土) 01:47:17

ちと聞きたいんだけど、
privateなメンバ変数、関数の頭にアンダースコアつけるマーチンファウラー式って、protectedなメンバ変数や関数にもアンダースコアつけるもの？

自分がよく見るJavaだと、privateに付けてるコードの中でもprotectedになるとバラバラな感じだけど、どっちが主流or論理的根拠があるのかな

つかファウラーたんはなんて言ってるんだろう？
2010/04/03(土) 11:20:33
それをマーチンファウラー式と呼ぶのは知らなかったｗ
2010/04/03(土) 15:40:03
名前をアンスコで始めるのはやめたほうがいいんじゃね？
厳密に言うと _MyFunc とか C++言語の規定違反だったと思うけど。

ま、つけるなら public 以外全部だな。
501498
垢版 |
2010/04/04(日) 11:44:39
>>499
ファウラーたんが発祥らしい

>>500
なるほど、public以外ぜんぶが主流か
自分はJavaが多いんで他あんまり知らないんだけど、C++は規約違反なのかあ
C#とかは末尾にアンスコつけるらしいね

2010/04/04(日) 13:48:42
> C#とかは末尾にアンスコつけるらしいね
　　　　　　　　　 　　　＿＿＿_
　　　　　　　　　　　／　　 　 　＼
　　　　　　　　 　／　─　 　 ─　＼
　　　　　　　　／ 　 （●） 　（●）　 ＼　　　
　　　　　　　　|　 　 　 （__人__）　 　　 |
　 　　　　　　 ＼　 　　 ｀ ⌒´ 　　 ,／
　r､　　　 　r､／　　　　　　　　　　ヘ
　ヽヾ　三　|:l1　　　　　　　　 　　　　ヽ
　　＼>ヽ/ |｀ ｝　　　　　　　　　 　　|　|
　　　ﾍ　lノ `'ｿ 　　　　　　　 　　　　|　|
　　　　/´　 /　　　　　　　　　　　　 |.　|
　　　　＼. ｨ 　　　　　　 　 　 　 　　|　 |
　　　 　 　 |　　　　　　　 　 　 　 　 | 　|
2010/04/04(日) 14:50:07
あ、ごめん
末尾にアンスコもC++か

「末尾 アンダースコア」でぐぐったらC++の話が出てくるから、さっきの規約違反回避のためにそうやるのかな？

つけておくとコードみたらすぐわかるし、thisとかいらなくなるし、コード内で名前重複しづらくなるし、メソッドでも付けるぐらい気にいってるけど、最近は付けない風潮なのかなあ
2010/04/04(日) 14:52:20
アンスコってアンダースコートの事かと思った
2010/04/05(月) 00:18:23
>>500
_[A-Z].* と __[A-Z].* が処理系予約って話だろ?
処理系の解釈も OS 込みとか, 言語処理系単体とかあるみたいだな
2010/04/05(月) 21:55:39
>>503
スコープを知りたくなること自体が、設計か実装が悪臭を放っている可能性を
示唆していると考える人は否定的になる。
プラグマチックに考えるなら、そのルールが有益になるチームはいくらでも
あるだろうと思う。
2010/04/05(月) 22:27:28
だからといって敢えて削除するメリットがあるとも思えないし
混乱を深めるだけだと思う
2010/04/05(月) 23:22:03
そうそう
付けないメリットより、付けるメリットの方が多い気がするんだよね

IDEが発達していらなくなるという主張も聞いた事あるけど、IDEだからこそ、一文字目からアンダースコアの有無による補完リストのフィルタリングとかできて便利だと思うんだが
2010/04/05(月) 23:59:24
一文字目アンスコはC/C++で規格違反になると何度言えば（ry
見苦しかろうが m_ とかにすれ
2010/04/06(火) 00:47:59
アンスコってアンインストールの事かと思った
511506
垢版 |
2010/04/06(火) 14:53:28
>>507
削除しろなんて言って無いし。

>>509
規格で予約されているのは、先頭のアンダースコアに続く大文字と、
出現位置を問わず二連続のアンダースコア。
先頭のアンダースコアに続いて小文字が現れるのは規格適合。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況