[表示 : 全て 最新50 1-99 101- 201- 301- 2chのread.cgiへ]
Update time : 11/13 08:16 / Filesize : 78 KB / Number-of Response : 344
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

コーディング規約 第3条



1 名前:デフォルトの名無しさん mailto:sage [2007/02/04(日) 23:28:42 ]
カッコの位置や変数名のつけ方から、何で規約なんて決めるのという話まで
コーディング規約・スタイルに関するスレ

前スレ

コーディング規約 第2条
pc10.2ch.net/test/read.cgi/tech/1068752664/

199 名前:デフォルトの名無しさん mailto:sage [2007/06/20(水) 16:37:28 ]
無駄に探す労力を割かす上につまんねぇ…
なんという糞レス…

200 名前:デフォルトの名無しさん mailto:sage [2007/06/21(木) 20:07:08 ]
>>199
おーrrらー

201 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 01:08:52 ]
今までこう書いてたけど

変数 => 全部小文字/アンスコ
メソッド => 先頭大文字/キャメル
クラス => 先頭大文字/キャメル
定数 => 全部大文字/アンスコ

>>163さんと同じにした方がみやすいんじゃん
っておもた
でも先頭が小文字のキャメルは不自然に感じてしまう

202 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 01:33:07 ]
C#だけど結局

プライベートフィールド・ローカル変数   :ローワーキャメル
名前空間・クラス・関数・プロパティ・定数 :アッパーキャメル

に落ち着いた。
フィールドにアクセスするときは必ずthis付けるようにしてるから
ローカル変数と混同することはないはず。

今MSDNのガイドライン読んだらプライベートメンバの
名前付けに関してはなんでもいいみたいだな。

203 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 23:17:56 ]
>>202
構造体・クラス・列挙体にはリーディングタグつけないやっぱり?
C#だとやってる人ほとんどいないなどういうわけか。

enumはともかく、クラスと構造体の違いは勘違いしてると致命的になる場合が
あるから、つけた方がぜったいコード読みやすいと俺は思うんだけど。

204 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 00:11:27 ]
MS的にNGな気がする。

205 名前:デフォルトの名無しさん [2007/06/29(金) 01:18:09 ]
>>163氏の命名法で

変換テーブル的に使う変数(例えば数値→文字へに使うようなmap型の変数)や
関数オブジェクトのインスタンスなら関数と同じような命名法である
>先頭小文字/キャメル
を適用したいのです

こういう類の変数で初期化時に設定してあとは殆ど変更しなかったり、
初期化部分以外での扱い方が関数的(mapの例だとmap[x]でxに対応する値の取得に使われる)たりで
メソッドとみなしてメソッドに対する命名法を適用しても問題ない気がするんですがどうでしょう?

それでも変数である以上変数に対するルールを出来る限り使用するべきでしょうか?

206 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 10:02:57 ]
>>203
C# は結局、VS のインテリセンスに頼ること前提だから、
クラスと構造体の勘違いは気にしなくてもいいのかも。

207 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 12:44:20 ]
P/Invoke以外で構造体作ったこと無いなー。



208 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 18:08:36 ]
>201
Javaだと先頭小文字のキャメルってよく使うよ。
何せ標準ライブラリがそうなってるからな。
M$は先頭大文字キャメルLoveみたいだが。

209 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 20:11:36 ]
.NETは、
名前空間名、型名、パブリックメンバ名はPascalCase、
関数の引数名はcamelCase

210 名前:デフォルトの名無しさん mailto:sage [2007/07/16(月) 02:29:48 ]
正直Camelで区別するのって、ハンガリアンと同じモノを感じるのは漏れだけですか。

211 名前:デフォルトの名無しさん mailto:sage [2007/07/16(月) 03:07:50 ]
ハンガリアンはハンガリアンでもアプリケーションハンガリアンは全然おkだよ
getXXXとかのgetのようなものも役目としてはこれに近いから同じように感じるのも無理はない

212 名前:デフォルトの名無しさん mailto:sage [2007/08/16(木) 16:52:56 ]
C#でLogというクラスを作ったわけですよ。で、ログの種別を
区別するための列挙型をLog.Typeと命名したんですね。
.NETのライブラリでもアッパーキャメル規約になってるっぽいですから。

で、メンバ変数としてType Log.typeを定義したのです。ここまでは
分かりますね。さらにLog.typeを外部から直にアクセスして欲しくないので
typeにアクセスするプロパティを定義すると。MS式の記法だと、やっぱり
Log.Typeが妥当かな?


  型 'Log' は 'Type' の定義を既に含んでいます。

213 名前:デフォルトの名無しさん mailto:sage [2007/08/17(金) 01:04:30 ]
>>212
キャメル云々はそれでよいと思う。

名前が重複する件は、列挙型はTypeでよくて、プロパティの方は「○○のためのType」という
○○の部分をうまく補ってあげればいいんじゃないかな。

214 名前:212 mailto:sage [2007/08/17(金) 03:18:25 ]
「○○のためのType」がこの場合、本当に「ログのためのType」としか
表現のしようがないのが辛いです。
列挙型はLog.Typeで、プロパティはLog.LogType…うーむ。

余談ですが、列挙型の識別子を“TYPE”と全部大文字表記
(長い場合はアンダースコア区切り)にすることも考えました。
しかしその方法でも内部クラスとかの命名になるとお手上げ…。

215 名前:デフォルトの名無しさん mailto:sage [2007/08/18(土) 00:09:00 ]
TypeIdとかTypeNoとか。

216 名前:デフォルトの名無しさん [2007/08/24(金) 04:14:41 ]
C++だけど、こんな感じで関数名と変数名がバッティングするときどうします?

class Ore {
public:
  bool isNeet() const { return isNeet; }
  // if (ore.isNeet()) { ... } とか呼びたい

private:
  bool isNeet;
};

1. こういうの嫌だから関数を大文字で始めてるYO(isNeet()をIsNeet()に)
2. こういうの嫌だから変数にプリフィックスなどをつけてるYO(isNeetをm_isNeetやisNeet_に)
3. 変数名を変えちゃうYO(isNeetをneetとか……形容詞ならともかく名詞だと変な気が。
  なんかもっといいネーミングとかありますかね)

なんかJavaだと↓で普通に通っちゃうんだけど。理屈はわかりませんが。

class Ore {
  public boolean isNeet() { return isNeet; }
  private boolean isNeet;
}

関数名が小文字で始まるほうがコードが柔和な気がするのでC++でもそうしたいんですが、
(メイヤーズ先生も小文字で始めてるし)
どうもここがちょっと引っかかって。

217 名前:デフォルトの名無しさん mailto:sage [2007/08/24(金) 04:29:23 ]
>>216
isNeet = false とかがキモイのもあって、 neetFlag とかにしちゃうかな。
m_neet もアリだな。



218 名前:デフォルトの名無しさん mailto:sage [2007/08/24(金) 10:53:28 ]
>>216
メソッド名を大事にしたいならフィールド名にちょっと引込んでもらうしかないのでは。
自分ならサフィックスにアンダーバーつける。

>>217
「isNeetを内部で保持するのはneetFlag」みたいなのって、頭使うの面倒じゃない?
まれにはそういう置きかえがピッタリいくこともあるけど、ほとんどの場合は
機械的に「プレフィックスつけてるっすー」とかの方が、余計なことに気を回す必要がなくて楽だと思う。

219 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 00:44:34 ]
_*
m_*
がいいよ。

メンバ変数を他の変数と区別できるようにするのは、
CodeCompleteでも薦められてるようなよくやるパターンです

220 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 01:21:18 ]
メンバ変数はname_にしてる。

221 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 01:27:52 ]
>219
_FollowedByUppercaseLetterはコンパイラ&ライブラリ実装者用の予約語なので、
_nameも避けといた方が無難。
#double__underscoreもね

222 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 01:32:37 ]
前にアンダーバー置くのはイクナイね。

223 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 01:35:48 ]
某所で、初心者にえらそうに教えてるやつが、Cなのに構造体のメンバにm_をつけてた。
意味をわかってつけてるのか。

224 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 03:11:13 ]
>>219
_name をつけるほど自信家じゃない
grepしたときやたらと似たようなのが引っかかりそうだし
それにエディタの行位置表示を下線にしてあるから、見えなくなる

225 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 03:16:23 ]
>それにエディタの行位置表示を下線にしてあるから、見えなくなる
これが理由なら、阿呆だ。

226 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 06:17:51 ]
>>223
member の m なら C の構造体でも間違いではないだろ。

227 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 09:51:01 ]
>>221
たぶんそれ、グローバルな名前がそうなだけ



228 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 09:53:05 ]
予約識別子だから、マクロ名を含めて、ソースコード中に出現してはならんよ。

229 名前:227 mailto:sage [2007/08/25(土) 11:29:28 ]
すまん>>221は、_の後に大文字が来るのが最もマズいって言ってんのか

230 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 13:13:08 ]
外からしか扱わないメンバに m_ とかつける必要は無いだろ。

struct Point { int m_x; int m_y };
Point p0 = { 0, 0 };
Point p1;
p1.m_x = p0.m_x + 1;

とか無意味。
scope の間違えようがない。

231 名前:デフォルトの名無しさん mailto:sage [2007/08/25(土) 22:37:30 ]
class Hoge {
private:
struct {
int x;
int y;
} m;
}


232 名前:227 mailto:sage [2007/08/26(日) 00:16:02 ]
>>231
やめなさいw

233 名前:デフォルトの名無しさん mailto:sage [2007/08/26(日) 01:06:27 ]
>>231
とてもアリな気が今した!

234 名前:デフォルトの名無しさん mailto:sage [2007/08/26(日) 20:47:53 ]
>231
コレ継承先から継承元の変数見るのが面倒では…
あー、もしや変数は全部privateにしろって事?

235 名前:デフォルトの名無しさん mailto:sage [2007/08/26(日) 21:13:48 ]
>>234
>あー、もしや変数は全部privateにしろって事?
当たり前じゃん。

236 名前:デフォルトの名無しさん mailto:sage [2007/08/27(月) 00:31:17 ]
>>234
structなしでint m_x;とか書いたのに比べて、なにか不便になることってあるの?

237 名前:デフォルトの名無しさん mailto:sage [2007/08/27(月) 00:41:08 ]
2〜3行増える。
素直にint x_, y_;にしとけばタイプ量も減る。
 



238 名前:デフォルトの名無しさん mailto:sage [2007/08/27(月) 01:24:03 ]
231のmをポインタにした感じのコードなら書いたことある。
例外にも強いしコピー・交換も楽で速いしなんて思っていたら、
どうみても劣化pimplです、本当にありがとうございましたというオチ。

239 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 23:34:42 ]
>>237
タイプ量だけ?
>>234 の継承とかなんとかは関係ないの?


240 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 22:41:02 ]
>>237
メンバ数が多いと、逆にタイプ数は減らないか?w

241 名前:デフォルトの名無しさん mailto:sage [2007/09/04(火) 00:15:46 ]
アフォな質問ですまん。
>231の例でx,yの初期化ってどうやって書けば良い?


242 名前:デフォルトの名無しさん mailto:sage [2007/09/04(火) 00:38:14 ]
>>241
普通にコンストラクタの初期化部で書けばよろしいかと。

243 名前:241 mailto:sage [2007/09/05(水) 00:12:31 ]
>242
サンプルコードを書いて貰えませんか?
少なくとも漏れの知ってる書き方をみる限りでは、
>231の方法はやっぱダメだとしか思えませぬ。

244 名前:デフォルトの名無しさん mailto:sage [2007/09/05(水) 00:47:14 ]
structが無名だから初期化できないね。ま、コンストラクタで代入するってことで。
--
class Hoge {
struct {
int x;
int y;
} m;
public:
Hoge() {m.x = 0; m.y = 0;}
Hoge(int x, int y) {m.x = x; m.y = y;}
};

245 名前:デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:18:43 ]
x,yがconstか参照で、かつコンストラクタの引数経由で
外部から初期値渡したい場合は?
それ考えると>231はやっぱ使い物にならん。

246 名前:デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:54:42 ]
struct に名前を付けてコンストラクタ書けばいいだけの話じゃないの?

247 名前:デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:14:03 ]
最早>231はどうでもいいがw
>x,yがconstか参照で、かつコンストラクタの引数経由で
>外部から初期値渡したい場合は?
条件後出ししていいなら、構造体に名前つけさせてくれ。



248 名前:デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:24:05 ]
>246,247
structに名前付けるのはいいけど、
通常1回書けばすむはずの処理を、2回書かなきゃダメだよね?
そうじゃないスマートな書き方を知っているなら是非ご教授を。

249 名前:デフォルトの名無しさん mailto:sage [2007/09/07(金) 13:03:53 ]
>>248
2回って、何で? Hoge は InnerHoge に丸投げするだけでしょ。

250 名前:デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:21:38 ]
>>249
Hogeのコンストラクタとその内部構造体のコンストラクタで
2回初期化を書かなければいけない(そしてそれがスマートでない)
と248は言っているのだろう。

251 名前:デフォルトの名無しさん mailto:sage [2007/09/18(火) 16:57:12 ]
あーの、Windowsでアンダースコア区切りの命名規則を採用している方に質問なのですが、
皆さんはWinMainの引数とかAPIのコールバック関数にもアンダースコア区切りで命名しますか?
それともWinAPIに関連する変数は例外的にハンガリアン+CamelCaseで命名しますか?

当方、先週Windows畑に飛ばされたばかりのへっぽこPGなんですが、
どうにも気になって気になって。。。

252 名前:デフォルトの名無しさん mailto:sage [2007/09/20(木) 02:06:24 ]
Gtk+なんかだとAPIそのもの以外は徹底的にアンダースコア区切りで命名してるな

253 名前:1/2 [2007/10/05(金) 00:49:37 ]
なんか、コーディング規約で this を返すのは駄目っていうのをどっかで読んだんだけど
こういうのはどうなの?
(サンプルソースの意図は、oldTest() の if 文を無くして test() のようにシンプルにすること)

public class Test {
    private static void oldTest(String[] params){
        for (int i = 0; i < params.length; i ++) {
            if (0 < i) {
                System.out.print("," + params[i]);
            }
            else {
                System.out.print(params[i]);
            }
        }
    }
    private static void test(String[] params){
        Printer printer = FirstPrinter.instance;
        for (String param : params) {
            printer.print(param);
            printer = printer.nextPrinter();
        }
    }
    public static void main(String[] argv){
        test(argv);
    }
}


254 名前:2/2 [2007/10/05(金) 00:50:41 ]
abstract class Printer {
    abstract void print(String param);
    abstract Printer nextPrinter();
}
class FirstPrinter extends Printer {
    static final FirstPrinter instance = new FirstPrinter();
    void print(String param){
        System.out.print(param);
    }
    Printer nextPrinter(){
        return SecondPrinter.instance;
    }
}
class SecondPrinter extends Printer {
    static final SecondPrinter instance = new SecondPrinter();
    void print(String param){
        System.out.print("," + param);
    }
    Printer nextPrinter(){
        return this;
    }
}

255 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 00:58:07 ]
>>253
コード読んでないけど、駄目って言う理由がないんならどうでもいいんじゃね?

256 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 01:31:13 ]
メソッドチェーンするのに便利だしthisを返しておいた方がいいと思ったんだけど、
駄目って言う理由はなんなんだろう。

257 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 01:58:23 ]
>>256
ちょっとよくわからないで言うけど
this を返してもらった奴がこれを使うときにthisの実体がなくなっちゃてたりするケースってない?




258 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 03:18:25 ]
>>257
だって呼び出している側がインスタンス保持しているのに、
なくなっているってことが通常ある?

259 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 03:53:45 ]
>>257
コード見る限り Java だから、それはありえない。

260 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 05:18:48 ]
入出力関係のオブジェクトだと閉じてる可能性はあるね。

261 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 15:25:15 ]
まじわからないで言う、ごめん

インスタンスを持っているならthisを返す意味はある?
汎化という目的で独立性を高めるために他の処理でこれを使うことを考慮したら
インスタンスが失われることを考えてthisを返してはいけないとか


262 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 15:26:27 ]
if を使ってる処理のほうが、「何をしているか」がよくわかる


263 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 19:00:26 ]
>>261
instance.foo().bar().baz()
とかやりたいってことない? これを指してメソッドチェーンといったんだけど。


264 名前:デフォルトの名無しさん mailto:sage [2007/10/05(金) 20:10:40 ]
operator overloading なんかだと this を返さないと成り立たないけどねw
まあ、java にはないから関係ないけど

265 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:59:59 ]
副作用がある場合はthisを返さないってポリシーはあるな。


266 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 20:15:56 ]
>>253
シンプルどころか複雑怪奇になってる。
さらにメモリ使用量も増えてるし、速度も遅くなっていそう。
そして、return this;よりはreturn SecondPrinter.instance;の方がいいだろう。
最悪なのは、親クラスのクラス変数を子クラスで隠蔽しているところだな。


267 名前:デフォルトの名無しさん mailto:sage [2007/10/09(火) 20:35:42 ]
個人的に思ったのは、
「this を返すAPI を作るな」っていうコーディング規約は、
「メソッドチェーンを前提にした API を作るな」っていうのが本来の意図であって、
そうでなければオーケーなんじゃないかと。

>>266
今回はサンプルがはじめからシンプルだったために、結果的に複雑怪奇になってしまったわけで、
実際にはトレードオフで適用すればいいのだと思います。

>最悪なのは、親クラスのクラス変数を子クラスで隠蔽しているところだな。
親クラスで定義しているのは抽象メソッドだけで (つまり実質的にインタフェースといえる)、
クラス変数は存在しないはずなのですが・・・

>return this;よりはreturn SecondPrinter.instance;の方がいいだろう。
あー。確かに。言われてみれば。

ただ、今回は Printer をシングルトンで実装できたけど、
例えば任意のセパレータの文字を指定して CSV ファイルを構築できるように
Printer を改造したような場合は、各インスタンスが状態を持つようになるので
this を返すような実装になると思う。

まあ、この場合でも Printer をイミュータブルになるように設計して
Flyweight の getter メソッドを活用して this を返さないような仕組みにすることは出来るけど
そこまでやると冗長になる気がする。



268 名前:デフォルトの名無しさん mailto:sage [2007/10/23(火) 19:22:00 ]
保守代わりに転載。
C++0x 2
pc11.2ch.net/test/read.cgi/tech/1191842951/172

269 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 02:35:34 ]
 private:
  bool isHoge_;

だけでなく、

 private:
  void doHoge_();

とか、

 template<class Hoge_>

のように準ローカルな名前全てにアンダーバーを付けたくてウズウズしてしまうのですが、
そのようなコーディング規約が見付かりません。
常識的にあまり推奨されないのでしょうか?

270 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 02:39:55 ]
>>269
どうして?

271 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 03:03:06 ]
>>270
発端は、templateのタイプ名が外部の通常のクラス名と衝突してしまったため、
冗長にせざるを得ない場面があったからです。
ならばメンバ変数に習い、「末尾にアンダーバー」イコール「スコープ限定」にしてしまえば、
衝突も避けられるし、読む時にも迷子になり難いのではないかな・・・と。

272 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 03:44:57 ]
>>271
そんな局所的な理由で規約になるわけないんじゃないの?

273 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 04:41:14 ]
後ろにアンダーバーなんて始めて見たな。
前ならそうしてる人結構いるよ。

274 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 04:59:49 ]
前につけるとすぐ予約名になるまたは予約名とまぎらわしいから、やめといたほうがいい。

275 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 07:12:05 ]
>>271
つまりボキャブラリが貧弱なのを _ でごまかそうということですね
英語の辞書を買ったらどうでしょう

冗長といっても、いくら長くてもいいと思う
あとで別の人間が解析するときに、
grepをかけたら似た様なのがゾロゾロって
猛烈に格好悪い

276 名前:227 [2007/12/15(土) 07:45:38 ]
>>274
これっていつから言われてるの?
昔は_ 前だったのに・・・

>>271
それってローカル側優先で処理されるよね?
TXxxx
とかにするってのもどうかね

277 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 09:53:59 ]
>>276
> これっていつから言われてるの?

「言われてる」ってのが何のことかわからないけど、予約名の規定自体は
知ってる範囲では ISO C++98, C99 とかで決められてる。たぶんそれより前の
C89 からそんなに変わってないと思うから、少なくとも 10 年以上前から使っちゃ
マズイってことにはなってたはず。



278 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 10:26:40 ]
>>276
MS-DOS の初期のころから内部の実装で使われていた気がする

279 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 11:02:48 ]
>>273
オレは何度も見たことあるよ。

280 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 12:33:25 ]
>>279
確かに、C の関数の場合は後ろに _ をつけると()と離れて絵的に悪くないかも知れないけど

いまひとつ _ を前後に使う意味がわからないな
_ があることでなにかを示すようには見えないな
もっと、適切な方法があるならそれを選んだほうがいいように思う
見てわかるような名称にするように文になっていたっていいと思う

昔の関数名なんか変なのあるよな
creat() なんて何を考えてるんだかw
'e' 一文字を省く理由がわからない


281 名前:227 mailto:sage [2007/12/15(土) 12:39:05 ]
>>277-278
ごめ。
_ は前に普通に付ける時代があったんだけど(本とかで載っていた)
最近後ろに付ける勢力が急拡大している感じ。
いつからだろうと。

282 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 12:49:04 ]
>>281
前につけることの問題を知らずに本を書いちゃうようなアホが淘汰されたんだろう。
いつからってこともないと思うぜ。

283 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 12:57:38 ]
>271
利点、欠点を考えて判断すりゃいいんじゃない?

利点:ローカルスコープの関数・変数が一目でわかる
欠点:メンバー変数とメンバー関数のバッティングが発生する可能性がある(C++の場合)
   -->別の命名規則で回避する必要あり
ぐらいかね?

ローカルスコープなんだし好きにすれば?という気もするけど。

284 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 13:28:58 ]
>>282
_ 前に付けて問題になったことなど一度たりともないけどな。
メンバ変数なんてローカルだし。
__descspecとかのキーワードなんて __ だしな

285 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 13:56:19 ]
>>280
creat()については名付け親がそうつけてしまったことを深く恥じているのだから、
もうそっとしておいてあげたらどうだw

286 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 15:40:04 ]
釣りか本気か微妙な流れだw


287 名前:デフォルトの名無しさん mailto:sage [2007/12/15(土) 23:55:12 ]
>>284
__declspecはむしろ正しい使い方。
処理系予約の識別子なのだから。



288 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 00:04:35 ]
>>287

いや、その通りだけど、>>284の趣旨は、「そういうのは"__"だから、"_"を前につけても問題が起こったことはない」でしょ。

289 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 01:34:46 ]
ナイシフォロー

290 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 01:42:20 ]
>>280
歴史的なもの
識別子に5文字しか使えなかったシステムで付けられた名前を引きずってるだけ

291 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 02:50:52 ]
>>284
一度もないのは分かるけど、
規格で「予約」と明記されているものをあえて使う理由が分からん。
ローカル名については「マナー」程度なのかな?
他の言語だと「予約」だったりするんだろうか。

292 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 07:00:04 ]
2重の__ は予約かも知れないが、
グローバルの_ はstdio.hとかのライブラリと被るので
~~~~~~~~~~~~~~~
注意ってことじゃなかったかって気がするんだが。
手元に資料がないから確認は取ってないが

293 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 07:04:09 ]
あ、一つ思い出した。
そういやBUFSIZ ってシンボル使えないよなw

294 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 11:04:04 ]
>>292
どっちも「予約」だよ。識別子の利用範囲が違うだけ。区別するのがメンドイから
自分とこで作るルールに書くときは一括でダメってことにするのが簡単。

295 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 11:26:03 ]
ttp://www.alles.or.jp/~torutk/oojava/codingStandard/writingrobustjavacode_pid86_c3.html#doc1_662
ちょっと見つけた

296 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 13:52:19 ]
>>295
うーーー。意味わかんない;
ごめんオレ馬鹿すぎ。エロイ人教えて。

297 名前:296 mailto:sage [2007/12/16(日) 13:58:19 ]
あ、泣くほど読んだらわかった;




298 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 13:59:11 ]
>>296
>281-282 にある

> _ は前に普通に付ける時代があった
> 前につけることの問題を知らずに本を書いちゃうようなアホ

の例じゃね?

299 名前:デフォルトの名無しさん mailto:sage [2007/12/16(日) 15:05:06 ]
まぁ明日ARMでも読んでみるわ。
メンバ変数名は、
グローバルなネームスペースを汚してるわけじゃないしね

300 名前:デフォルトの名無しさん mailto:sage [2007/12/17(月) 02:42:38 ]
っ >168

301 名前:デフォルトの名無しさん mailto:sage [2007/12/17(月) 02:50:17 ]
なぜ予約語とぶつかる可能性のあることをしようとするのか
いまひとつわからない
たしかに、かっこいいかもしれないけど
_や__が予約語に多いのだから、他人が見たら、
これらは予約語としてみられる可能性があるということでしょ?

できるだけ、必然的であるべきだと思うのだけど
でないと後で見てわからない気がするんだけどな
名称を考えるのがめんどくさいだけに思えるのは、オレが世間知らずだから?

302 名前:デフォルトの名無しさん mailto:sage [2007/12/17(月) 02:54:48 ]
C/C++ の入門書や入門サイトがそういうインクルードガードを書いてたり。
そういうのを見て覚えた奴が自己弁護のために抵抗してるだけ。目的なんか無い。

303 名前:デフォルトの名無しさん mailto:sage [2007/12/17(月) 08:01:37 ]
_で始まる予約語に何があるか言ってみろよ

304 名前:デフォルトの名無しさん mailto:sage [2007/12/17(月) 08:05:56 ]
>>300
やっぱ答え出てるじゃないか。
メンバ変数はグローバルじゃねえ。

関数名とグローバル変数に問題があるだけだろうな

305 名前:デフォルトの名無しさん mailto:sage [2007/12/17(月) 11:48:40 ]
>>301,303 予約語じゃなくて、予約識別子ね。

306 名前:デフォルトの名無しさん mailto:sage [2007/12/17(月) 15:58:27 ]
>>303
_STDLIB_H_

307 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 00:11:07 ]
>>305
それならわかるわ

検索してみたら、いいページ掛かったわ



308 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 06:32:30 ]
結局 _ をつけたがるのは
自分の作ったのを予約語扱いしてもらいたい 「格好つけしー」 か
考えるのが面倒で、 _ でもつけとけの 「横着者」 のどっちか
でいいの?


309 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 08:17:39 ]
>>308
_ のあとの小文字は問題ねーってよ

310 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 08:33:41 ]
>>309
昔のDOS系、MSのLIBなんかは _ の関数だらけ
これを予約語といえるかわからんが
それと同列のものにしたいということだろ?

311 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 11:31:02 ]
>>309
何が問題ねーの?予約識別子じゃないの?

312 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 11:46:38 ]
_ のあと小文字は、グローバルスコープ(ファイルスコープ)のみで予約。以下 >294

313 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 12:17:43 ]
>>168の短い文章を理解するのに一体何レス費やせば気が済むんだ?

314 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 12:21:59 ]
「ある目的のために」とか、わかりにくい誤訳が入ってたからじゃね?

315 名前:デフォルトの名無しさん mailto:sage [2007/12/18(火) 22:50:44 ]
グローバルな名前空間でとわざわざ限定してくれてるからじゃん

316 名前:デフォルトの名無しさん mailto:sage [2007/12/19(水) 05:46:36 ]
「感染してますが、コンドームをつけてれば大丈夫です」と言われてもやる気はしないのと同じ

例えが、ちがうか;

317 名前:デフォルトの名無しさん mailto:sage [2007/12/23(日) 23:54:01 ]

                ( ゚д゚ )
              ¶ノ ¶ノ |
          / ̄ ̄ ̄ ̄ ̄\
          ./  (,)    (,)  ヽ
         |     | ̄|     |
         ヽ     ̄ ̄    /
          |  |   |  |   |
         .ノ .ノ ヽ ノ .ノ   .|
         (_ノ  (_ノ    .|
            / /  ̄/ /
           < <   .< <
            ヽ ヽ   ヽ ヽ




318 名前:デフォルトの名無しさん [2007/12/25(火) 07:53:47 ]
あ、そうそう そうすると

#ifndef _FILENAME_H
#define _FILENAME_H

はどんなシンボル名にしてんの?

#define H_FILENAME_H

とか?( ゚д゚)

319 名前:デフォルトの名無しさん mailto:sage [2007/12/25(火) 10:30:28 ]
FILENAME_HでもMACRO_OF_FILENAME_Hでもお好きなものをどうぞ。

320 名前:デフォルトの名無しさん [2007/12/26(水) 04:02:28 ]
MACRO_OF_*は却下

321 名前:デフォルトの名無しさん mailto:sage [2007/12/26(水) 04:09:12 ]
#pragma onceでいいよもう

322 名前:デフォルトの名無しさん mailto:sage [2007/12/26(水) 04:10:30 ]
せっかくポータブルな方法があるのに、
そうじゃない手段をわざわざ使うのは気が引けるよ

323 名前:デフォルトの名無しさん [2007/12/29(土) 11:30:30 ]
規律正しいおまいらなら
#ifndef
の使用はもうやめたんだろ?

324 名前:デフォルトの名無しさん mailto:sage [2007/12/29(土) 13:41:22 ]
両方使うのは意味があるのかな?

325 名前:デフォルトの名無しさん mailto:sage [2007/12/30(日) 00:07:39 ]
>>323
なんで ifndef はいけないと思うの?

326 名前:デフォルトの名無しさん mailto:sage [2008/02/19(火) 01:14:20 ]
皆さんのスタイルを、GNU indentの引数で表現するってのはどうでしょか。
俺は単純に
indent -kr hoge.c
です。

327 名前:デフォルトの名無しさん mailto:sage [2008/02/19(火) 14:45:58 ]
>>325
名前がぶつかるかも知れない恐怖が




328 名前:デフォルトの名無しさん mailto:sage [2008/03/16(日) 18:09:35 ]
ソースのフルパスをマクロ名に入れとけば無問題w


329 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 15:16:47 ]
そんなにぶつかるのが怖いなら、GUIDでいいんじゃないか?インクルードガードなんか入力することなんかないんだからさ。

330 名前:デフォルトの名無しさん [2008/07/28(月) 01:19:20 ]
lolo.jp/orecode/

331 名前:デフォルトの名無しさん mailto:sage [2008/07/30(水) 22:41:39 ]
はてなで話題になってたが
tp://d.hatena.ne.jp/akkt/20080424/1209051266
これを厳密に守るのはきついな……

332 名前:デフォルトの名無しさん mailto:sage [2008/08/07(木) 15:47:21 ]
これはJAVAを念頭に置いてるのか?

333 名前:デフォルトの名無しさん mailto:sage [2008/08/09(土) 21:26:02 ]
>>331
goto有害論並に偏りすぎてねぇか?


334 名前:デフォルトの名無しさん mailto:sage [2008/08/09(土) 22:46:42 ]
手続き型脳を矯正するには多少極端なくらいのショック療法が必要ってことだろ

335 名前:デフォルトの名無しさん mailto:sage [2008/08/25(月) 00:22:16 ]
OO厨だった学生時代はそういう病的に分割されたコードばっか書いてたな。
だけど、働き始めて周りの人間にソース追いにくいだのなんだの
不評だったせいでいつのまにか書かなくなったが。

336 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 21:55:22 ]
C++でオペレータの宣言・定義するときにoperator=とかくのかoperator =とかくのかそういうのって決まってるの?

337 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 21:56:36 ]
それは多分、インデントの量とか中括弧の位置なんかと同じテーマだと思うんだが。



338 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 23:43:18 ]
>>336
検索しやすいように空けない。

339 名前:デフォルトの名無しさん [2008/10/02(木) 00:07:24 ]
operator\w= で検索すればおk

340 名前:デフォルトの名無しさん [2008/10/02(木) 00:08:04 ]
↑*追加しといて

341 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 20:45:35 ]
\w じゃダメだろ。

342 名前:デフォルトの名無しさん [2008/10/03(金) 01:01:52 ]
じゃあ
operator\wktk=

343 名前:デフォルトの名無しさん mailto:sage [2008/10/09(木) 08:01:21 ]
elevaterU
escalator






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](*・∀・)<78KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef