07/02/04 23:28:42
カッコの位置や変数名のつけ方から、何で規約なんて決めるのという話まで
コーディング規約・スタイルに関するスレ
前スレ
コーディング規約 第2条
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
07/02/05 00:24:35
ずるしてらくしてかれいに２げっとかしらかしら～
3:デフォルトの名無しさん
07/02/05 11:52:53
3ゲットですぅ
4:デフォルトの名無しさん
07/02/05 13:34:58
for ( int cnt = 3; cnt < EOThread; cnt++ )
{
5:デフォルトの名無しさん
07/02/05 16:34:21
break;
6:デフォルトの名無しさん
07/02/05 17:10:48
}
printf("%d", cnt);
7:デフォルトの名無しさん
07/02/05 17:30:28
printf("監督の背番号は%dです\n", cnt);
8:デフォルトの名無しさん
07/02/05 17:54:27
cnt は カントク の略ですか?
9:デフォルトの名無しさん
07/02/05 20:05:29
ｽﾚﾘﾝｸ(tech板:991番)
ﾜﾛﾀｗ
10:デフォルトの名無しさん
07/02/05 21:34:46
GNUみたいにスペースとタブを混在したりしなければ何でもいいなあ
てゆーかインデントレベル2でタブ幅8はやめてくださいおながいします
11:デフォルトの名無しさん
07/02/05 21:40:30
プロジェクト内で統一されてるならそれで。
12:デフォルトの名無しさん
07/02/06 10:47:20
インデント幅とタブ幅は全く別問題だな。
タブ幅は一般的には幅8だが、これはエディタ依存で4に設定してる奴もいるだろう。
インデント幅はあくまでコーディングスタイル。
インデントにタブを使ったり、それどころかスペースと混ぜるなんてアホすぎる。
もっとマトモなエディタ使えよ、と。
俺はEmacs使ってるが・・・Emacs自体はGNUのウンココーディングスタイルで書かれてんだよなぁ。。
13:デフォルトの名無しさん
07/02/06 17:35:42
俺はタブを使ってインデントしてるんだが（ハードタブっていうのか？）
こうしておけば各自見やすいタブ幅に設定しておけるしいいんじゃないかと思っている。
14:デフォルトの名無しさん
07/02/06 18:23:12
要は
スペース派 == これが俺のインデント幅だ。従え。
タブ派 == インデント幅は各自好きにしろ。
15:デフォルトの名無しさん
07/02/06 18:42:19
あとは、さしずめ
混在派: 考えたこともない。
てとこか?
16:デフォルトの名無しさん
07/02/06 19:32:25
コピペするからスペースにしとこ派
17:デフォルトの名無しさん
07/02/06 19:39:50
VCのデフォルト派
18:デフォルトの名無しさん
07/02/06 21:05:15
こういう風に書く人なら、ハードもソフトも関係ないが
int i;
char c;
struct dirent dirs;
こういう風に書く奴が多いじゃん？
int i;
char c;
struct dirent dirs;
タブストップの設定が違うと
int i;
char c;
struct dirent dirs;
19:デフォルトの名無しさん
07/02/06 21:14:59
タブとスペース使い分けたいんだけどね。
>>18 みたいなケースではスペース使って、
インデントにはタブ。
□をタブ、_ をスペースとして、↓みたいに。
□□func(a, b, c,
□□______d, e, f);
20:デフォルトの名無しさん
07/02/06 21:58:24
>>19
すこしずれてる
21:デフォルトの名無しさん
07/02/06 22:29:53
>>18
俺は
func() {
<TAB>int<SP><SP>i;
<TAB>char<SP>c;
}
みたいにする。
要するに、TABは必ず行頭から連続しているようにする。
言ってることは>>19と同じ罠
22:デフォルトの名無しさん
07/02/06 23:12:34
>>18
2番目の書き方は C の構造体のメンバ変数宣言とかでよく見るけど
最高に自己満足な気がする。
後で長い名前の変数作ることになったら
シコシコとスペースなりタブなり追加するんだろうか。
時間の無駄だからさっさとやめろと言いたい。
規約で強制されそうになったら頑として抵抗する。
23:デフォルトの名無しさん
07/02/06 23:34:43
へ? 普通そういうのってエディタのマクロでやるでしょ。
プログラマなんだからさ。
24:デフォルトの名無しさん
07/02/06 23:46:51
漏れもIDEで変数宣言の部分を範囲選択して整形コマンド一発かとオモタ。
でも簡単にリファクタリングできるからって意味もなくしまくっていいわけでもないだろ。
本質的でない変更がdiffに混ざったりすると混乱する
(リファクタリングだけでちゃんとコミットしてればいいんだが)
25:デフォルトの名無しさん
07/02/07 00:52:06
>>24
最近のdiff/merge系のツールは賢いから、
そーゆー本質的でない変更は無視できるように設定できるだろ。
26:デフォルトの名無しさん
07/02/07 01:00:41
それよりも。ここで何故
リファクタリング
という言葉が出てくるのかがわからない
27:デフォルトの名無しさん
07/02/07 03:21:27
さういうツールがろくに普及してないから
インデントの設定とかが、議論のネタになるんだろｗ
ソースだけ引き継ぐこともあるしなあ
（完成品だけ引き継いで、バージョンアップしたこともあるがｗ）
28:デフォルトの名無しさん
07/02/07 03:30:31
おまいら、三項演算子をどう思うよ。
29:デフォルトの名無しさん
07/02/07 03:38:16
・アホは三項演算子使用禁止（そして、お前はアホだ）
・「( 論理式 ) ? 式1 : 式2」という書き方は禁止
全体を括弧でくくって、「( 論理式 ? 式1 : 式2 )」と書け
30:デフォルトの名無しさん
07/02/07 07:54:28
>>26
リファクタリングを、コードの整形レベルのことだと思ってるってこと
だろう。
31:デフォルトの名無しさん
07/02/07 09:22:23
>>28
普通に使うよ。使った方がコードが読みやすくなると思ったら迷わず使う。
32:デフォルトの名無しさん
07/02/07 10:09:26
>>29
なんで、三項演算子使っちゃいけないの？
33:デフォルトの名無しさん
07/02/07 10:51:29
よく言われるのは、「読みにくいから」かな・・・
まー使ったほうが綺麗に読みやすくなる場合もあると思うんだが、
アホに使用を許すと場をわきまえずバンバン使って、えらく読みにくくなる場合が多い。
どうせ構文砂糖なんだから、禁止しても害は無いので禁止しちまえ、という事らしい。
34:デフォルトの名無しさん
07/02/07 10:52:26
はいはい、そうですか。
35:デフォルトの名無しさん
07/02/07 12:10:12
ふたこと、言わせててくれ
三項演算子より条件演算子が正しい表現ではないのか
条件演算子はネスト禁止
36:デフォルトの名無しさん
07/02/07 12:12:32
なるほど、君が言いたい事はよーくわかったぞ。
37:デフォルトの名無しさん
07/02/07 12:37:07
HRESULT hr;
FALSE |
FAILED(hr = ...) |
FAILED(hr = ...) |
が30行ぐらい延々とつづくコードをみたことがある。
中で三項演算子もばっちり使ってた。
生暖かく見守ってたらやっぱりメンテで叫んでた。
38:デフォルトの名無しさん
07/02/07 12:38:43
うーむ、そうかそうか。
39:デフォルトの名無しさん
07/02/07 13:21:16
そう言えば、オープンソースのプロジェクトの規約ってどんなんなってんだ？
規約のリンク集みたいなサイトってある？
40:デフォルトの名無しさん
07/02/07 13:25:56
そんなもんあるかボケェ
41:デフォルトの名無しさん
07/02/07 13:42:20
オプソだからといって全体がどこかの規約に従ってるわけじゃなく
プロジェクトごとに定めているのがふつーだわな。
Linux kernel coding style(ソースツリーにも入ってる)
URLﾘﾝｸ(pantransit.reptiles.org)
1インデント幅が8スペース分のTAB。
GNU Coding Standards
URLﾘﾝｸ(www.gnu.org)
変態的な{}の使い方が特徴。
Code Conventions for the Java Programming Languag
URLﾘﾝｸ(java.sun.com)
オプソじゃないけどJavaでは有名。
Mozilla Coding Style Guide
URLﾘﾝｸ(www.mozilla.org)
いろいろC++の機能の利用を制限しているのがつらそう。
ぐぐるとjakartaのとかもあるな。
42:デフォルトの名無しさん
07/02/07 16:35:13
GNUキモいな
43:デフォルトの名無しさん
07/02/07 17:18:07
>>42
gccとemacsの世話になりっぱなしだが、あれだけはイヤ。
44:デフォルトの名無しさん
07/02/07 18:07:33
あの規約のおかげで、コードが流用されたときに
出所がすぐ分かるとかｗ
ねーか、キモいからか書き換えられる悪寒
45:デフォルトの名無しさん
07/02/07 20:07:06
>41
おー、こんなの読みたかった、thx
しかしGNUのブレースの書き方…ｗ
Mozilla は和訳もあるみたいね。
URLﾘﾝｸ(www.mozilla-japan.org)
46:デフォルトの名無しさん
07/02/07 22:27:45
>>13
> 俺はタブを使ってインデントしてるんだが（ハードタブっていうのか？）
> こうしておけば各自見やすいタブ幅に設定しておけるしいいんじゃないかと思っている。
>>14
> タブ派 == インデント幅は各自好きにしろ。
char *hoge = {"hoge", "piyo",
"fuga"};
if (hoge ||
piyo)
function(arg1,
arg2);
行頭だけタブ使っていても、一行が長くなる時には改行入れるでしょ。
その時にどうしてもタブとスペースが混ざったり、混ざらない場合でも
人によっては見苦しい汚いコードになるわけだ。
他人に公開するソースにはタブなんて使うもんじゃないよ。
Tabs are evil
URLﾘﾝｸ(www.google.com)
47:デフォルトの名無しさん
07/02/07 22:53:35
じゃあ
URLﾘﾝｸ(www.jwz.org)
は？
48:デフォルトの名無しさん
07/02/07 23:13:59
TABな人です。
継続行は元の行より1レベル余計にインデントするだけで、
位置あわせは全くやりませんね。
49:デフォルトの名無しさん
07/02/08 00:23:01
>>28
ローカル変数を const にしたいときに使うので良く使う。
こういうときに匿名関数とか欲しくなる。
50:デフォルトの名無しさん
07/02/08 02:47:20
なんで人間がソースコードを整形するんだよ。
インデントなんか何だっていいんだよ、
チェックインする前に自動整形かければ済むことだ。
人様のコードを読む時も、自動整形かければ済むことだ。
まぁ、インデントがスペースだと文句を言う人は、
キーボードの→を押して、ぼーっと画面を眺めるような間抜けだろう。
51:デフォルトの名無しさん
07/02/08 06:34:06
そうかそうか、よーくわかったぞ。
52:デフォルトの名無しさん
07/02/08 14:08:08
>>50
なんで人間がソースコードを整形しないんだよ。
インデントって重要なんだよ、
チェックインする前には、必ず手作業で整形する習慣をつけるべき。
人様のコードを読む時に、自動整形するなんて言語道断。
まぁ、自動整形がいいんだと文句を言う人は、
世の中には例外というものがあって、自動整形することで
醜くなるソースコードがあることすら理解できない間抜けだろう。
53:デフォルトの名無しさん
07/02/08 16:30:10
なるほど、そうかそうか。
54:デフォルトの名無しさん
07/02/08 21:57:34
>>52
一本とれてよかったね。
55:デフォルトの名無しさん
07/02/09 04:31:13
なんか、ソースが世代ごとに、違う整形ツールで整形を受けていって、
しまいにゃあ、いろんなところが崩壊して行きそう
マイケルジャクソンみたいに
56:デフォルトの名無しさん
07/02/09 07:26:37
・使う整形ツールを規約で規定する
・ツール側の非互換な変更に備えて、バージョンまで指定する
・ツールを変更した場合、そのツールで全ソースを整形し直す
くらいで解決できそう。
57:デフォルトの名無しさん
07/02/09 15:12:40
>>46
その例だと、こうする。TABの幅が変わってもずれない。（可変幅fontな奴はさすがにいないだろう）
<TAB>char *hoge = {"hoge", "piyo",
<TAB> "fuga"}; // TABのあとに14文字スペース。前の行のcharのc前までがTAB
まあ個人的なコードで他人関係ないならこう書くけど
<TAB>char *hoge = {
<TAB><TAB>"hoge",
<TAB><TAB>"piyo",
<TAB><TAB>"fuga",
<TAB>};
58:デフォルトの名無しさん
07/02/09 16:13:50
>>57
等幅フォントという前提自体が美しくない。
まぁ、>57の前者程度であれば空白が詰まろうとたいした問題ではないが。
駄菓子菓子、パラメータや型名の後を揃えたがるのはどうにもこうにも美しくない。
Ex.
sumType_t funcName(
int foo, /* この行にfooとbarをそろえるための空白を入れている */
const char * bar
)
{
59:デフォルトの名無しさん
07/02/09 20:07:14
プロポーショナルフォントなど使うスットコドッコイは逝ってしまえ的な
60:デフォルトの名無しさん
07/02/09 20:57:01
>>59
現にここに貼ってもプロポーショナルフォントで見る羽目になるわけで。
61:デフォルトの名無しさん
07/02/10 02:21:33
そういえばプロポーショナルなフォントでソースコード書かないね。
ハードウェア・ソフトウェアとも、十分プロポーショナルフォントで行ける環境はあるのに。
メールなんか、Outlook Expressやらのせいで、どちらかというと等幅の方が劣勢だよね。
62:デフォルトの名無しさん
07/02/10 02:22:05
フォント自体は等幅なのだが、
キーワードが太字になったり斜体になったりして
結局揃わない罠。
63:デフォルトの名無しさん
07/02/10 02:25:49
>>61
フォント変えられるエディタで好きに書けよ
64:デフォルトの名無しさん
07/02/10 03:04:12
double mat[9] = {
1.0, 10,0, 100.0,
125.0, 1.0, 12.4,
45.0, 1250.0, 25.0
};
こんな感じのを書くときとか、やっぱ都合が悪いわけで
65:デフォルトの名無しさん
07/02/10 12:22:00
>>61
等幅等幅いってんのは日本人だけだろ？
66:デフォルトの名無しさん
07/02/10 12:52:45
そりゃそうだろ。アラビア語とか等幅の概念自体ありえないし
67:デフォルトの名無しさん
07/02/10 13:01:35
>>64
Tabを使えとあれほど
68:デフォルトの名無しさん
07/02/10 13:03:21
手持ちの英語で書かれてる本は、コード部分は等幅クーリエの模様だな。
アラビア語の書籍は持ってないので分からん。
69:デフォルトの名無しさん
07/02/10 13:07:45
よく考えたらソースコードにアラビア文字は使わないか。
日本語プログラミング言語が基本的にゲテモノ扱いなのと一緒で
70:デフォルトの名無しさん
07/02/10 13:40:11
プロポーショナルフォントでコーディングはないだろ。
むこうでもタイプライタ系の等幅フォントだよな。Courier NewとかConsolasとか。
71:デフォルトの名無しさん
07/02/10 13:49:46
Pascalのソースってプロポーショナルで印刷したりしない? Delphiは知らないけど
72:デフォルトの名無しさん
07/02/10 14:12:43
ストラウストラップの本のコードは確かプロポーショナルだったような
73:デフォルトの名無しさん
07/02/10 14:38:29
プロポーショナルだったら不要な宗教戦争はなかったかもなあ。
74:デフォルトの名無しさん
07/02/10 15:34:14
Pascal覚え立ての頃、+=の本をまねしてソースコードを
pretty printすることはあったけど今はやらないなぁ。
だいたいソースコードを印刷すること自体まずやらん。
75:デフォルトの名無しさん
07/02/10 16:29:50
COBOLとかRPGとか、桁位置に意味がある言語だとプロポーショナルはつらいなｗ
76:デフォルトの名無しさん
07/02/10 16:30:22
>72
D&Eだっけ？すごく読みにくかった記憶が。
77:デフォルトの名無しさん
07/02/10 16:36:58
印刷されているものだと、実際のソースコードではなく、擬似コードっぽいものだと
プロポーショナルで書かれていることもあるみたい。
今見たら、ソフトウェア博物誌とかそうなってた。
78:デフォルトの名無しさん
07/02/11 01:28:35
>>74
> だいたいソースコードを印刷すること自体まずやらん。
EclipseからわざわざソースをエクスポートしてDFで差分を表示して
印刷してレビューとかしてます。いやさせられてます。もうアホかと
79:デフォルトの名無しさん
07/02/11 02:09:36
>>67
タブじゃ全然無理
場所によって桁数がちがうだろ、よく見ろ
80:デフォルトの名無しさん
07/02/15 11:03:40
コードの整形ツールって皆さん何使ってますか？
URLﾘﾝｸ(sourceforge.net)
これ？
81:デフォルトの名無しさん
07/03/12 01:51:52
indent
82:デフォルトの名無しさん
07/03/12 03:04:05
手元にあるJavaクイックリファレンスでは
プロポーショナルでびっしり印刷してある。
パッと視界に収まるのは良いけど。
83:デフォルトの名無しさん
07/03/13 23:50:45
ところで、<winnt.h>を見たら、その中で使われている構造体のメンバには
さっぱりハンガリアン記法が使われていなかった。
このヘッダ自体は古くからあると思うんだけど、
そこでハンガリアンが使われていないということが意外だった。
84:・∀・）っ-○◎●
07/03/14 00:44:27
Win 9xのチームとNTチームは元々別で、
ハンガリアンマンセーなのは9xのほう。
ってばっちゃが言ってた
85:・∀・）っ-○◎●
07/03/14 01:31:56
ちなみに,NETではハンガリアン記法一切ない
86:デフォルトの名無しさん
07/03/14 05:29:57
NTカーネルモードのコードにもハンガリアン使われてないしね
87:デフォルトの名無しさん
07/03/14 05:50:47
カトラーがハンガリアンを嫌ってなかったっけ。
88:デフォルトの名無しさん
07/03/14 05:58:41
カーソル合わせりゃ型が出てくる統合環境で
iHoge とか dwFoo とか書く意味はまるでないッ
その変数の「意味」を頭に書き加えるのならやってもいいッ
89:デフォルトの名無しさん
07/03/14 06:15:43
デイヴ・カトﾁｬﾝ
90:デフォルトの名無しさん
07/03/14 08:14:01
本来のハンガリアン記法は型名略記なんかじゃなかったんだよな。
91:デフォルトの名無しさん
07/03/14 09:13:06
↓間違ったコードは間違って見えるようにする
URLﾘﾝｸ(tinyurl.com)
型名プレフィックスをつけるだけの記法を
ハンガリアンと読んでいる奴はアホ。
その記法をマンセーしてる↓みたいな奴はもっとアホ。
URLﾘﾝｸ(homepage2.nifty.com)
92:デフォルトの名無しさん
07/03/14 14:06:04
>>91
激しく同意
93:デフォルトの名無しさん
07/03/14 23:21:44
ハンガリアンを積極的に使うつもりはないけど、
HWND hWnd;
とか書いちゃってるなあ。
HWND windowHandle;
でいいはずだが。
94:デフォルトの名無しさん
07/03/14 23:41:47
ハンドルのhはむしろアプリケーションハンガリアンに近いものだと俺は思っている。
（やや苦しいかもしれないが）例えばC#なんかだとみんなIntPtrになるからハンドルにhを付けるのも生きてくる。
C/C++のtypedefは型名にアプリケーションハンガリアンを適用するためにも使えるという見方もできる。
（それが行き過ぎて型名とプレフィックスを結び付けるシステムハンガリアンになってしまったのかもしれないが）
そういう訳もあって俺はウィンドウハンドルの変数名・プレフィックスをhWndとするのではなく、hwndとしている。
HANDLE hHoge = hwndHoge;なんて有り得ない。
95:・∀・）っ-○◎●
07/03/15 00:09:41
なにかとATL::CWindow使ってる俺は wnd～ もしくは ～Window
96:デフォルトの名無しさん
07/03/15 03:32:04
GUI部品に btnHoge や tblFuga はありだと思う。
だってボタンやテーブルなんだし。
97:デフォルトの名無しさん
07/03/15 04:08:24
hogeButton とか fugaTable とか、略さず書くべきだと思うんだ。
妙な略語は読みにくい。
今時の環境なら補完くらいしてくれるから、長くてもtypoは起きにくいし。
へたすると、短くて補完効きづらい名前のがtypoしやすいくらい。
それに、 button とか table とかは接頭辞じゃなくて接尾辞にすべきだと思う。
型より意味のが重要なんだから。
98:デフォルトの名無しさん
07/03/15 05:04:25
できればcamel caseはやめてほしい…
などと言い合いの軸をもう一つ増やしてカオスに追い込んでみようかな。
99:デフォルトの名無しさん
07/03/15 05:25:13
camel caseやめると語のつなぎは_かえ？
100:デフォルトの名無しさん
07/03/15 09:10:00
俺は変数は_繋ぎの小文字で関数はCamelにしてる。
変数に大文字が混入するのは何となく嫌だ。
101:デフォルトの名無しさん
07/03/15 09:51:22
>>97
頭に持ってくるか尻に持ってくるかは、
どっちの意味を重視するか、どっちから探したいかによるかと。
俺の頭の中ではボタンは型ではなくて、単にボタン。
hoge するものであること以上に
画面上のボタンであることをイメージするので
(hoge という意味もボタンという意味も持つ。型はない。)
頭に持ってきたいんです。
なんだけど、hogeButton の方が自然な名称だとは思う。
まぁ規約に従いますよ。
102:デフォルトの名無しさん
07/03/15 10:15:28
ボタン型であるquit(型ハンガリアンだが)じゃなくて
quitボタンという画面部品だから、付けるならquitButtonだなー。
quitButtonで呼ぶ処理ルーティンの名前はquitかもしれぬ。
103:デフォルトの名無しさん
07/03/15 10:21:36
quitButton を見て「変数名に型情報入れるなボケ」
とか言ってくるやつがたまに居るんだが
どうやって対処したらいいんだろ。
型じゃねーよと言っても分かってもらえない。
104:デフォルトの名無しさん
07/03/15 10:31:57
>>103
ボタン型より抽象的な型（コンポーネントとかウィジェットとか）で
保持してやればいいんじゃね？名前はそのまんまで。
で、本当にボタンとして使うときには毎回キャスト。
一回やってみせて、できあがったアフォコード見せてやればきっと
納得してくれるよ。
105:デフォルトの名無しさん
07/03/15 11:02:06
アフォをもってアフォを制す・・・か
106:デフォルトの名無しさん
07/03/16 20:26:03
逆に次からもそうしろってなったら嫌だなｗ
107:デフォルトの名無しさん
07/03/17 23:30:31
C言語だと、
a += 2;
{
懿｡疂nt tmp = a;
懿｡畭 = b;
懿｡畸 = tmp;
}
みたいに{ }を使うこともあると思うけど、これに if else をつけると、
if (a > 0)
懿｡畭 += 2;
else
懿｡痣
懿｡癧疂nt tmp = a;
懿｡癧畭 = b;
懿｡癧畸 = tmp;
懿｡痾
のように、一行コードと{ }のブロックが同じインデントになってるから、
GNUのスタイルは一応理にかなってはいるなと思っただけ。
108:デフォルトの名無しさん
07/03/17 23:34:09
C言語だと、
a += 2;
{
□int tmp = a;
□a = b;
□b = tmp;
}
みたいに{ }を使うこともあると思うけど、これに if else をつけると、
if (a > 0)
□a += 2;
else
□{
□□int tmp = a;
□□a = b;
□□b = tmp;
□}
のように、一行コードと{ }のブロックが同じインデントになってるから、
GNUのスタイルは一応理にかなってはいるなと思っただけ。
#化けたのでもう一度書きます。すんません。。。
109:・∀・）っ-○◎●
07/03/17 23:45:16
& n b s p ;をスペース入れずに使いましょう
110:デフォルトの名無しさん
07/03/18 00:07:54
>>108
GNUの{}がキモイと言っている奴らは
そういう理屈を理解した上でなおキモイと言っているんだと思われ
111:デフォルトの名無しさん
07/03/18 00:20:47
何しろ「キモイ」なんだから理屈じゃないわな
112:デフォルトの名無しさん
07/03/18 00:24:12
>>110
オレは { } を使わない if がそもそもキモイと思う。( >>108 の a += 2; の部分 )
113:デフォルトの名無しさん
07/03/18 00:34:00
URLﾘﾝｸ(www.linux.or.jp)
＞まずは「GNU 標準プログラム書法」
＞(GNU coding standards)を入手して印刷してみてください。でも、読むために
＞印刷するのではありません。印刷した物を燃やすのです！この儀式は晴れがま
＞しい決意表明なのです！ V^_^V
By リーナスたん
114:デフォルトの名無しさん
07/03/18 01:23:23
まあ確かに理屈どうこうじゃねーな。
とにかく気持ち悪い。
115:108
07/03/18 02:14:49
>>112
見ていて一番自然なのは K&R のスタイルだとは思うけど、
それでも、{ } を使わない if は普通に出てくるよ。
116:デフォルトの名無しさん
07/03/18 09:17:27
>>115
自分では単文の時も必ず{}で括るようにしているが、
そうでないソースがあったとしてもキモいとまでは思わないな。
117:デフォルトの名無しさん
07/03/18 14:04:35
if (hoge)
a = 1;
else {
int b;
a = 1;
b = 2;
}
1行コードと {} のインデントを同じにしなきゃならん理由がわからん
ifとelseの中身が同じインデントレベルの方が見て把握しやすい
GNUはやっぱキモイわ
リーナスたんが言うようにGNUのウンココーディングスタイルなんて燃やすべきだ！
118:デフォルトの名無しさん
07/03/18 15:32:05
別にどっちでも大差ないでしょ
俺様wayに頑なに固執するのは俺的には精神分析の対象だと思う。
どっか幼児性が切断されてないところがあるんじゃないの？
気色悪い、という感情はコードのお作法に対してより、
むしろそういう自分自身をこそ向けられるべきだね。
119:デフォルトの名無しさん
07/03/18 15:36:57
とはいえ、人間はパターン認識の動物だから、
異なるパターンのコードを行ったり来たりするのは疲れることは確か。
だとしたらフリースタイルというcの思想がそもそも間違ってるのかもね。
まあ、自由というドグマに囚われた不自由なアメリカ人が作ったものだからな。
120:デフォルトの名無しさん
07/03/18 15:38:38
単文とか複文という概念が無いModula2最強ってことでｗ
121:デフォルトの名無しさん
07/03/18 15:59:53
GNUのスタイルがキモいと思ってる人間は少くないんだから
コミッターや開発者の間で民主的に多数決でもとって GNU v2 のスタイルでも
決めてくれればいいものを。
一部の変人がコーディングスタイルを決めて、それがデファクトスタンダードになって
しまってる現状に疑問を投げかけてもいいんじゃない？
>>118みたいに人格攻撃しかしないバカには理解できないだろうけど
122:デフォルトの名無しさん
07/03/18 16:32:19
GNUよりも>>118がキモイ
123:デフォルトの名無しさん
07/03/18 16:38:14
結論：>>118はキモイ
124:デフォルトの名無しさん
07/03/18 23:11:13
>>118の反響の大きさにﾜﾗﾀ
125:デフォルトの名無しさん
07/03/18 23:19:30
>>118のキモさに泣いた
126:デフォルトの名無しさん
07/03/18 23:54:09
>>118になにがしか反応せずにはいられないやつがこれだけいるとはw
127:デフォルトの名無しさん
07/03/18 23:58:36
>>118だと聞いて飛んできました。
128:デフォルトの名無しさん
07/03/19 00:03:09
幼児性って分断させるものなん？
129:デフォルトの名無しさん
07/03/19 11:06:30
この勢いだと>>118が切断されそうです＞＜
130:デフォルトの名無しさん
07/03/19 13:00:16
>>121
「デファクトスタンダード」の意味調べて来い。
131:デフォルトの名無しさん
07/03/19 15:56:43
>>130
>>121は、FLOSSなどと呼ばれるソフトウェアはLinuxカーネルを除いて
みなGNUスタイルで書かれてるとでも思っているのではないだろうか。
132:デフォルトの名無しさん
07/03/19 22:09:09
>128
俺は一瞬「幼児を分断」と読んで萎えた
133:デフォルトの名無しさん
07/03/20 01:27:02
そんなつまんないレスすると。負けずに
正しくは「幼児性の払拭」だね
なんつう、つまんないレスを(ry
134:デフォルトの名無しさん
07/04/10 13:58:05
C++使いです
関数名、変数名の大文字小文字でずっと悩んでいますが、
スタイルはJavaやMSDNでいいと思っています
でも、STLやBoostを使うと、バランス悪くなりませんか？
135:デフォルトの名無しさん
07/04/10 14:49:21
それがC++標準のスタイル。気にしないのがベスト。
必要以上の一貫性は無意味だ。
136:デフォルトの名無しさん
07/04/29 03:20:35
>>101
それはいつも悩んでます。俺はVBでcmdOkとかcmdCancelみたいなのに
慣らされてきたから、C#になったときにbuttonOkとかbuttonCancelとか
やってみたんだけど、確かに探しやすいんだがなんか気持ち悪い。
次のプロジェクトではokButton、cancelButton式にしたんだけど、やっぱり
探しづらい。どうしても「UI要素の分類」をキーボードから打ったあとで
候補から↑↓で選ぶ方が探しやすいと思うのだ。
そうして小さなプロジェクトを作るごとにあーだこーだ悩んだ末、
今ではプロジェクトごとにばらばらだ。それが一番ダメなんだってｗ
137:デフォルトの名無しさん
07/04/29 07:21:40
プロジェクトごとにばらばらなのは許容範囲でしょ。
ダメなのはプロジェクト内で統一されてない時。
138:デフォルトの名無しさん
07/05/01 03:41:22
>136
_をofと考えて、button of ok → button_ok
139:デフォルトの名無しさん
07/05/09 03:02:45
/**
* ←このアスタリスクがめんどい
*/
140:デフォルトの名無しさん
07/05/09 03:13:07
C/C++/Java の複数行コメントのスタイルについて。
/*
* ←このアスタリスクがめんどい
*/
はじめに書くときにも面倒だし、後でコメント内のインデントを上げ下げ
するときにも激しくウザイ。そしてこの面倒さに対するメリットがよくわからない。
いっこだけ検索して見つけたのが、その行がコメントであることを行自身に
明示させる働きがあるとのこと。だけどそんなのエディタで開けば
色分けしてくれるし、そうじゃなくてもコメントとコードの区別は目で見れば
簡単に判別できる。機械的に判別させるためであれば、行頭アスタリスクで
始まるコードも書けてしまうので結局曖昧なままだし。
なんでこのスタイルがこんなに普及してるのか、知ってる人がいたら教えて欲しい。
141:デフォルトの名無しさん
07/05/09 03:15:14
見た目がどうこうとかもっともらしい理由が言われ続けているから、ではなかろうか。
142:デフォルトの名無しさん
07/05/09 03:16:50
モノクロの世界だと区別が分かりやすいってのはあるかもね。
いちいち打つのは面倒だからやりたくないね。
エディタが勝手に埋めてくれるから埋めとくかって感じだけど。
143:デフォルトの名無しさん
07/05/09 03:18:15
>>139
それがそんなにめんどいなら、そのアスタリスクを付加するフィルタを簡単に作れるようになるべきかと。
固定文字列対応のことを考えるとめんどいけど
144:デフォルトの名無しさん
07/05/09 03:20:35
>>142
そのエディタ、コメントの中のインデント調整してもアスタリスクの位置だけ
保持してくれたりする？
145:デフォルトの名無しさん
07/05/09 03:33:15
んなもん頭に*つけたり外したりするのなんざエディタの仕事だろうが。
プログラマなんだからそれくらいエディタにやらせろよ。
146:デフォルトの名無しさん
07/05/09 13:41:49
GNUは極度の後方互換とストールマソの趣味であんな規則になってるんでしょ
ところで単語の区切りはどうしてる？
do_somethingで単語を区切る方が好きだけどC++やJavaも使うから泣く泣くdoSomethingみたいに大文字で区切ってる
147:デフォルトの名無しさん
07/05/09 14:05:50
>>140
javadocのせいじゃないの？
148:デフォルトの名無しさん
07/05/09 18:05:54
MFC で C++ を覚えた俺から見ると DoSomething が一番自然に見えるｗ
C# と Java やり始めてようやく doSomething 式にしたけどまだ違和感があるな
149:デフォルトの名無しさん
07/05/09 19:42:35
俺てきとうだなぁそのへん。
とりあえず周りに合わせる感じ。
C++でソロだとdo_something系だな、今は。
150:デフォルトの名無しさん
07/05/09 21:31:46
>>148
C#はDoSomethingだろ
マイクロソフト様のガイドラインに書いてある。
151:デフォルトの名無しさん
07/05/09 21:34:24
do.somethingみたいな具合に
doやsomethingそのものも柔軟に定義できてそれらの直行性を使って
複合的な機能が実装できればいいのに
152:デフォルトの名無しさん
07/05/09 21:39:04
日本語おｋ
153:デフォルトの名無しさん
07/05/09 21:59:36
放っておけ奴は「直行性」と言いたいだけだ
直交性に読み替えてみてもさっぱり意味が(ry
・・・もしかしてニモニック？
154:デフォルトの名無しさん
07/05/09 22:07:17
>>150
マジすか
明日から堂々と DoSomething って書くわ、むろん Java でも
155:デフォルトの名無しさん
07/05/09 22:11:06
>>154
Javaでのメソッド名、変数名についてはdoSomethingでたのむにょろ。
156:デフォルトの名無しさん
07/05/09 22:34:40
変数名とメソッド名の見た目が同じなのが嫌という理由で
変数名は小文字アンダースコア区切り、メソッド名はCamelな俺。
157:デフォルトの名無しさん
07/05/09 22:36:15
名前の途中に大文字だけの単語が出てくると
命名しててなんか気持ち悪くなるんだよね。
158:デフォルトの名無しさん
07/05/10 00:26:29
>>146
変数名と関数名は全部小文字で単語間をアンダースコアで区切る。
クラス名はキャメルケースを使う。
という風に使い分けてる。
159:デフォルトの名無しさん
07/05/10 13:35:57
Javaをアンダーバーで切ると標準ライブラリで見づらくなるじゃない？
160:デフォルトの名無しさん
07/05/10 14:57:56
クラス名の先頭は大文字にしとけ
161:デフォルトの名無しさん
07/05/11 02:03:18
クラス・関数・変数・定数・etcの区別に拘っている方に聞きたい。
関数ポインタとかファンクタ、デリゲート、const変数等はどう名付けてます?
162:デフォルトの名無しさん
07/05/11 02:52:04
使用するライブラリに合わせるかなぁ。
>>161
デリゲートって悩むよねー
MS様のガイドラインではイベントハンドラ以外のは
～Callbackにしろって書いてあったと思うけど、
明らかに守られてないし。(MethodInvokerとか)
あんまし関係ないけどWin32APIの定数はできるだけ
constの変わりにenum使うようにしてる。
163:デフォルトの名無しさん
07/05/14 13:48:41
変数 ＝＞ 全部小文字／アンスコ
メソッド ＝＞ 先頭小文字／キャメル
クラス ＝＞ 先頭大文字／キャメル
定数 ＝＞ 全部大文字／アンスコ
かな。
164:デフォルトの名無しさん
07/05/14 21:40:44
>>154
publicな名前はDoSomethingで、
privateな名前はdoSomethingと覚えておけばいい
165:デフォルトの名無しさん
07/05/14 23:26:27
privateメソッドはどう名前をつけようが窯湾だろ。
166:デフォルトの名無しさん
07/05/15 02:20:54
c++だとバッティングするリスクがあるのでちょっとは気にした方がいい。
167:デフォルトの名無しさん
07/05/15 21:43:21
そのバッティングするリスクとやらをどうぞ
168:デフォルトの名無しさん
07/05/16 02:25:30
URLﾘﾝｸ(www.mozilla-japan.org)
> C++ 標準規格 17.4.3.1.2 節 グローバル名 [lib.global.names] 第1パラグラフによると:
>
> 名前と関数シグネチャのある特定の組は、実装によって常に予約されています:
> 二重のアンダースコア（__）が含まれる名前、または後ろに大文字 (2.11) が付くアンダースコアで始まる名前は、
> ある目的のために実装によって予約されています。
> アンダースコアで始まる名前は、グローバルな名前空間で使う名前として実装によって予約されています。
169:デフォルトの名無しさん
07/05/16 08:11:48
doxygen で @param に付く in, out って、つけたほうがいいんでしょうか？
ほとんど [in] だし、ポインタに const ついてなければ [out] または [in,out] なんで、
あんまり手動でつけて回るメリットが無いような気がしてます。
170:デフォルトの名無しさん
07/05/16 08:27:30
>>169
私のところでは、過去との互換性でconstついてないポインタの時にはつけてる。
171:デフォルトの名無しさん
07/05/16 09:11:58
クラスというか、抽象的に状態を保持してるオブジェクトを
渡すときは in も out も何かしっくりこないしねぇ。出したり入れたり
じゃなくて状態を変更するかどうかが重要って感じ？
172:デフォルトの名無しさん
07/05/16 12:50:24
通常それをピストンというのでは？
173:デフォルトの名無しさん
07/05/16 14:45:20
ほしゆ
174:デフォルトの名無しさん
07/05/21 04:21:30
ケースセンシティブをなくせばこんな宗教戦争は解決するんじゃない？
175:デフォルトの名無しさん
07/05/21 10:20:53
>>174
自動車をなくせば交通事故は無くなるんじゃない？
176:デフォルトの名無しさん
07/05/21 10:25:26
>>175
いいえ、自動車以外の交通事故は残ります。
→ケース問題を除く宗教戦争は残ります。
177:デフォルトの名無しさん
07/05/21 13:07:30
BASICって確か大文字小文字区別しないけど、
あの言語ってケース問題に関する宗教戦争ってないのか？
178:デフォルトの名無しさん
07/05/21 13:33:11
8bit時代のBASICならいざしらず、VisualBaiscとか今時のBASIC使ってるヤツで
「大文字小文字同一視だぜ」とか言ってるやつはみたことないな。
普通に大文字小文字区別して「どう書こう？」ってやってる。
179:デフォルトの名無しさん
07/05/21 13:51:21
Delphiが「大文字小文字同一視だぜ」なんだけど、
書籍やIT系サイトのチュートリアルっぽいコードで、たまに無茶苦茶なのを見かける。
一般向けに晒すコードなら、プロパティ名とかメソッド名はオンラインヘルプに記述されているとおりに書け。
# Delphiのヘルプは酷いから、そもそもオンラインヘルプで記述が統一されていないってのもあるが。
180:デフォルトの名無しさん
07/05/21 14:43:03
MSDN見習わせたらエラー処理はしないしファイル番号は固定だし……
ってのは兎も角。
>>178
VisualBasicは大文字小文字を区別できるんですか?
例えばdim aa as integer, AA as integer, Aa as integerみたいに?
私ゃ保存はされるけど区別はできないと思っていたのだが。
181:178
07/05/21 15:01:39
>>180
いや、区別しない。
>>178で言いたかったのは
「区別されないからAbcDefメソッドをABCDEFで呼ぶぜ」なんてやつはおらず、
VBでも「『AbcDef』がいいか『abcDef』がいいか(大文字小文字を意識して)どう書こう？」って
やってる、ってこと。
書き方悪かったかも。ごめん。
182:デフォルトの名無しさん
07/05/22 15:38:32
でも自動車を無くせば自動車事故は起きなくなるね
#こういう考え方はいかん
#エロサイトを封じれば性犯罪が減ると思ってやがる
183:デフォルトの名無しさん
07/05/22 19:08:06
>>182
コメントへの野暮なレスですまんが、
もとの「自動車を無くせば自動車事故は起きなくなる」に対応する
のは「エロサイトをなくせばエロサイトへの接続が無くなる」では。
# 縦読みを仕込みたかったが出来なかった。
184:デフォルトの名無しさん
07/05/22 20:21:39
エロサイトを封じたら、性犯罪は増えるんじゃないの？
185:デフォルトの名無しさん
07/05/23 00:14:54
>>183
エロサイトを封じればエロサイトの広告、迷惑メールなどが減る。
→でもその他の広告などは残る。
186:175
07/05/23 01:40:16
大文字小文字の区別をつけるか否かは、言語設計者が決めることだから、
その言語を使用する側が制御できることではないし、どうこう言うべきことでもない
と言いたかったのですが。
187:デフォルトの名無しさん
07/05/23 05:03:55
最近はCOMとか.NETとかスクリプティングとか言語設計者の都合だけでは
決められない要素も出てきた
188:デフォルトの名無しさん
07/05/23 06:51:31
COMは最近ではないと思うけど、まあそうだね。
189:デフォルトの名無しさん
07/05/23 13:52:32
機械語
190:デフォルトの名無しさん
07/05/30 08:01:29
そういえばスペースだけでコーディングする言語あったよね
あれなら宗教戦争はなくなる
191:デフォルトの名無しさん
07/05/30 08:23:20
ホワイトスペルマだっけ？
192:デフォルトの名無しさん
07/06/02 00:19:25
しばらく開発から離れた仕事をしていたうちにハンガリアンはあまり使われなくなったみたいですが、どういった理由でですか？
カーソルをあわせれば型が出るからですか？
自分はカーソルあわせるのが面倒なのでハンガリアンで書いてますが・・・
193:デフォルトの名無しさん
07/06/02 00:25:52
>>192
templateをゴリゴリつかったプログラミングなんかが流行ったこととかが関係してると思う。
ハンガリアンだと型を変えたときに名前まで変えなきゃならんしね。
↑これは型に対するハンガリアンのことであって、意味に対するハンガリアンは
いまでもそこそこ使われてると思うけど。
194:デフォルトの名無しさん
07/06/02 00:41:42
変数のスコープがやたらでかくなってないか、
関数でかすぎるせいでそうなってないか、
一回見直したほうが良い。
195:デフォルトの名無しさん
07/06/03 21:19:31
悪しきシステムハンガリアンが消えて
本来のアプリケーションハンガリアンを用いる人が増えただけ
196:デフォルトの名無しさん
07/06/20 05:09:57
ハンガリーってどこらへん?
197:デフォルトの名無しさん
07/06/20 11:45:17
X系はdoSomething、GNU系はdo_something
ディストリをメンテしているオレの戦いは今日もつづく
198:デフォルトの名無しさん
07/06/20 16:30:30
>>196
URLﾘﾝｸ(www.namamono.com) (02年3月上旬)
199:デフォルトの名無しさん
07/06/20 16:37:28
無駄に探す労力を割かす上につまんねぇ…
なんという糞レス…
200:デフォルトの名無しさん
07/06/21 20:07:08
>>199
おーrrらー
201:デフォルトの名無しさん
07/06/28 01:08:52
今までこう書いてたけど
変数 ＝＞ 全部小文字／アンスコ
メソッド ＝＞ 先頭大文字／キャメル
クラス ＝＞ 先頭大文字／キャメル
定数 ＝＞ 全部大文字／アンスコ
>>163さんと同じにした方がみやすいんじゃん
っておもた
でも先頭が小文字のキャメルは不自然に感じてしまう
202:デフォルトの名無しさん
07/06/28 01:33:07
C#だけど結局
プライベートフィールド・ローカル変数 ：ローワーキャメル
名前空間・クラス・関数・プロパティ・定数 ：アッパーキャメル
に落ち着いた。
フィールドにアクセスするときは必ずthis付けるようにしてるから
ローカル変数と混同することはないはず。
今MSDNのガイドライン読んだらプライベートメンバの
名前付けに関してはなんでもいいみたいだな。
203:デフォルトの名無しさん
07/06/28 23:17:56
>>202
構造体・クラス・列挙体にはリーディングタグつけないやっぱり？
C#だとやってる人ほとんどいないなどういうわけか。
enumはともかく、クラスと構造体の違いは勘違いしてると致命的になる場合が
あるから、つけた方がぜったいコード読みやすいと俺は思うんだけど。
204:デフォルトの名無しさん
07/06/29 00:11:27
MS的にNGな気がする。
205:デフォルトの名無しさん
07/06/29 01:18:09
>>163氏の命名法で
変換テーブル的に使う変数(例えば数値→文字へに使うようなmap型の変数)や
関数オブジェクトのインスタンスなら関数と同じような命名法である
>先頭小文字／キャメル
を適用したいのです
こういう類の変数で初期化時に設定してあとは殆ど変更しなかったり、
初期化部分以外での扱い方が関数的(mapの例だとmap[x]でxに対応する値の取得に使われる)たりで
メソッドとみなしてメソッドに対する命名法を適用しても問題ない気がするんですがどうでしょう？
それでも変数である以上変数に対するルールを出来る限り使用するべきでしょうか？
206:デフォルトの名無しさん
07/06/29 10:02:57
>>203
C# は結局、VS のインテリセンスに頼ること前提だから、
クラスと構造体の勘違いは気にしなくてもいいのかも。
207:デフォルトの名無しさん
07/06/29 12:44:20
P/Invoke以外で構造体作ったこと無いなー。
208:デフォルトの名無しさん
07/07/01 18:08:36
>201
Javaだと先頭小文字のキャメルってよく使うよ。
何せ標準ライブラリがそうなってるからな。
M$は先頭大文字キャメルLoveみたいだが。
209:デフォルトの名無しさん
07/07/01 20:11:36
.NETは、
名前空間名、型名、パブリックメンバ名はPascalCase、
関数の引数名はcamelCase
210:デフォルトの名無しさん
07/07/16 02:29:48
正直Camelで区別するのって、ハンガリアンと同じモノを感じるのは漏れだけですか。
211:デフォルトの名無しさん
07/07/16 03:07:50
ハンガリアンはハンガリアンでもアプリケーションハンガリアンは全然おｋだよ
getXXXとかのgetのようなものも役目としてはこれに近いから同じように感じるのも無理はない
212:デフォルトの名無しさん
07/08/16 16:52:56
C#でLogというクラスを作ったわけですよ。で、ログの種別を
区別するための列挙型をLog.Typeと命名したんですね。
.NETのライブラリでもアッパーキャメル規約になってるっぽいですから。
で、メンバ変数としてType Log.typeを定義したのです。ここまでは
分かりますね。さらにLog.typeを外部から直にアクセスして欲しくないので
typeにアクセスするプロパティを定義すると。MS式の記法だと、やっぱり
Log.Typeが妥当かな？
型 'Log' は 'Type' の定義を既に含んでいます。
213:デフォルトの名無しさん
07/08/17 01:04:30
>>212
キャメル云々はそれでよいと思う。
名前が重複する件は、列挙型はTypeでよくて、プロパティの方は「○○のためのType」という
○○の部分をうまく補ってあげればいいんじゃないかな。
214:212
07/08/17 03:18:25
「○○のためのType」がこの場合、本当に「ログのためのType」としか
表現のしようがないのが辛いです。
列挙型はLog.Typeで、プロパティはLog.LogType…うーむ。
余談ですが、列挙型の識別子を“TYPE”と全部大文字表記
（長い場合はアンダースコア区切り）にすることも考えました。
しかしその方法でも内部クラスとかの命名になるとお手上げ…。
215:デフォルトの名無しさん
07/08/18 00:09:00
TypeIdとかTypeNoとか。
216:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/08/24 04:29:23
>>216
isNeet = false とかがキモイのもあって、 neetFlag とかにしちゃうかな。
m_neet もアリだな。
218:デフォルトの名無しさん
07/08/24 10:53:28
>>216
メソッド名を大事にしたいならフィールド名にちょっと引込んでもらうしかないのでは。
自分ならサフィックスにアンダーバーつける。
>>217
「isNeetを内部で保持するのはneetFlag」みたいなのって、頭使うの面倒じゃない？
まれにはそういう置きかえがピッタリいくこともあるけど、ほとんどの場合は
機械的に「プレフィックスつけてるっすー」とかの方が、余計なことに気を回す必要がなくて楽だと思う。
219:デフォルトの名無しさん
07/08/25 00:44:34
_*
m_*
がいいよ。
メンバ変数を他の変数と区別できるようにするのは、
CodeCompleteでも薦められてるようなよくやるパターンです
220:デフォルトの名無しさん
07/08/25 01:21:18
メンバ変数はname_にしてる。
221:デフォルトの名無しさん
07/08/25 01:27:52
>219
_FollowedByUppercaseLetterはコンパイラ＆ライブラリ実装者用の予約語なので、
_nameも避けといた方が無難。
＃double__underscoreもね
222:デフォルトの名無しさん
07/08/25 01:32:37
前にアンダーバー置くのはイクナイね。
223:デフォルトの名無しさん
07/08/25 01:35:48
某所で、初心者にえらそうに教えてるやつが、Cなのに構造体のメンバにm_をつけてた。
意味をわかってつけてるのか。
224:デフォルトの名無しさん
07/08/25 03:11:13
>>219
_name をつけるほど自信家じゃない
grepしたときやたらと似たようなのが引っかかりそうだし
それにエディタの行位置表示を下線にしてあるから、見えなくなる
225:デフォルトの名無しさん
07/08/25 03:16:23
＞それにエディタの行位置表示を下線にしてあるから、見えなくなる
これが理由なら、阿呆だ。
226:デフォルトの名無しさん
07/08/25 06:17:51
>>223
member の m なら C の構造体でも間違いではないだろ。
227:デフォルトの名無しさん
07/08/25 09:51:01
>>221
たぶんそれ、グローバルな名前がそうなだけ
228:デフォルトの名無しさん
07/08/25 09:53:05
予約識別子だから、マクロ名を含めて、ソースコード中に出現してはならんよ。
229:227
07/08/25 11:29:28
すまん>>221は、_の後に大文字が来るのが最もマズいって言ってんのか
230:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/08/25 22:37:30
class Hoge {
private:
struct {
int x;
int y;
} m;
}
232:227
07/08/26 00:16:02
>>231
やめなさいｗ
233:デフォルトの名無しさん
07/08/26 01:06:27
>>231
とてもアリな気が今した!
234:デフォルトの名無しさん
07/08/26 20:47:53
>231
コレ継承先から継承元の変数見るのが面倒では…
あー、もしや変数は全部privateにしろって事?
235:デフォルトの名無しさん
07/08/26 21:13:48
>>234
＞あー、もしや変数は全部privateにしろって事?
当たり前じゃん。
236:デフォルトの名無しさん
07/08/27 00:31:17
>>234
structなしでint m_x;とか書いたのに比べて、なにか不便になることってあるの?
237:デフォルトの名無しさん
07/08/27 00:41:08
2～3行増える。
素直にint x_, y_;にしとけばタイプ量も減る。
238:デフォルトの名無しさん
07/08/27 01:24:03
231のmをポインタにした感じのコードなら書いたことある。
例外にも強いしコピー・交換も楽で速いしなんて思っていたら、
どうみても劣化pimplです、本当にありがとうございましたというオチ。
239:デフォルトの名無しさん
07/08/31 23:34:42
>>237
タイプ量だけ?
>>234 の継承とかなんとかは関係ないの?
240:デフォルトの名無しさん
07/09/01 22:41:02
>>237
メンバ数が多いと、逆にタイプ数は減らないか？ｗ
241:デフォルトの名無しさん
07/09/04 00:15:46
アフォな質問ですまん。
>231の例でx,yの初期化ってどうやって書けば良い?
242:デフォルトの名無しさん
07/09/04 00:38:14
>>241
普通にコンストラクタの初期化部で書けばよろしいかと。
243:241
07/09/05 00:12:31
>242
サンプルコードを書いて貰えませんか?
少なくとも漏れの知ってる書き方をみる限りでは、
>231の方法はやっぱダメだとしか思えませぬ。
244:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/09/06 00:18:43
x,yがconstか参照で、かつコンストラクタの引数経由で
外部から初期値渡したい場合は?
それ考えると>231はやっぱ使い物にならん。
246:デフォルトの名無しさん
07/09/06 00:54:42
struct に名前を付けてコンストラクタ書けばいいだけの話じゃないの？
247:デフォルトの名無しさん
07/09/06 01:14:03
最早>231はどうでもいいがw
＞x,yがconstか参照で、かつコンストラクタの引数経由で
＞外部から初期値渡したい場合は?
条件後出ししていいなら、構造体に名前つけさせてくれ。
248:デフォルトの名無しさん
07/09/06 20:24:05
>246,247
structに名前付けるのはいいけど、
通常1回書けばすむはずの処理を、2回書かなきゃダメだよね?
そうじゃないスマートな書き方を知っているなら是非ご教授を。
249:デフォルトの名無しさん
07/09/07 13:03:53
>>248
2回って、何で？ Hoge は InnerHoge に丸投げするだけでしょ。
250:デフォルトの名無しさん
07/09/08 00:21:38
>>249
Hogeのコンストラクタとその内部構造体のコンストラクタで
2回初期化を書かなければいけない（そしてそれがスマートでない）
と248は言っているのだろう。
251:デフォルトの名無しさん
07/09/18 16:57:12
あーの、Windowsでアンダースコア区切りの命名規則を採用している方に質問なのですが、
皆さんはWinMainの引数とかAPIのコールバック関数にもアンダースコア区切りで命名しますか？
それともWinAPIに関連する変数は例外的にハンガリアン+CamelCaseで命名しますか？
当方、先週Windows畑に飛ばされたばかりのへっぽこPGなんですが、
どうにも気になって気になって。。。
252:デフォルトの名無しさん
07/09/20 02:06:24
Gtk+なんかだとAPIそのもの以外は徹底的にアンダースコア区切りで命名してるな
253:1/2
07/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
07/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:デフォルトの名無しさん
07/10/05 00:58:07
>>253
コード読んでないけど、駄目って言う理由がないんならどうでもいいんじゃね？
256:デフォルトの名無しさん
07/10/05 01:31:13
メソッドチェーンするのに便利だしthisを返しておいた方がいいと思ったんだけど、
駄目って言う理由はなんなんだろう。
257:デフォルトの名無しさん
07/10/05 01:58:23
>>256
ちょっとよくわからないで言うけど
this を返してもらった奴がこれを使うときにthisの実体がなくなっちゃてたりするケースってない？
258:デフォルトの名無しさん
07/10/05 03:18:25
>>257
だって呼び出している側がインスタンス保持しているのに、
なくなっているってことが通常ある?
259:デフォルトの名無しさん
07/10/05 03:53:45
>>257
コード見る限り Java だから、それはありえない。
260:デフォルトの名無しさん
07/10/05 05:18:48
入出力関係のオブジェクトだと閉じてる可能性はあるね。
261:デフォルトの名無しさん
07/10/05 15:25:15
まじわからないで言う、ごめん
インスタンスを持っているならthisを返す意味はある？
汎化という目的で独立性を高めるために他の処理でこれを使うことを考慮したら
インスタンスが失われることを考えてthisを返してはいけないとか
262:デフォルトの名無しさん
07/10/05 15:26:27
if を使ってる処理のほうが、「何をしているか」がよくわかる
263:デフォルトの名無しさん
07/10/05 19:00:26
>>261
instance.foo().bar().baz()
とかやりたいってことない? これを指してメソッドチェーンといったんだけど。
264:デフォルトの名無しさん
07/10/05 20:10:40
operator overloading なんかだと this を返さないと成り立たないけどねw
まあ、java にはないから関係ないけど
265:デフォルトの名無しさん
07/10/09 15:59:59
副作用がある場合はthisを返さないってポリシーはあるな。
266:デフォルトの名無しさん
07/10/09 20:15:56
>>253
シンプルどころか複雑怪奇になってる。
さらにメモリ使用量も増えてるし、速度も遅くなっていそう。
そして、return this;よりはreturn SecondPrinter.instance;の方がいいだろう。
最悪なのは、親クラスのクラス変数を子クラスで隠蔽しているところだな。
267:デフォルトの名無しさん
07/10/09 20:35:42
個人的に思ったのは、
「this を返すAPI を作るな」っていうコーディング規約は、
「メソッドチェーンを前提にした API を作るな」っていうのが本来の意図であって、
そうでなければオーケーなんじゃないかと。
>>266
今回はサンプルがはじめからシンプルだったために、結果的に複雑怪奇になってしまったわけで、
実際にはトレードオフで適用すればいいのだと思います。
＞最悪なのは、親クラスのクラス変数を子クラスで隠蔽しているところだな。
親クラスで定義しているのは抽象メソッドだけで (つまり実質的にインタフェースといえる)、
クラス変数は存在しないはずなのですが・・・
＞return this;よりはreturn SecondPrinter.instance;の方がいいだろう。
あー。確かに。言われてみれば。
ただ、今回は Printer をシングルトンで実装できたけど、
例えば任意のセパレータの文字を指定して CSV ファイルを構築できるように
Printer を改造したような場合は、各インスタンスが状態を持つようになるので
this を返すような実装になると思う。
まあ、この場合でも Printer をイミュータブルになるように設計して
Flyweight の getter メソッドを活用して this を返さないような仕組みにすることは出来るけど
そこまでやると冗長になる気がする。
268:デフォルトの名無しさん
07/10/23 19:22:00
保守代わりに転載。
C++0x 2
ｽﾚﾘﾝｸ(tech板:172番)
269:デフォルトの名無しさん
07/12/15 02:35:34
private:
bool isHoge_;
だけでなく、
private:
void doHoge_();
とか、
template<class Hoge_>
のように準ローカルな名前全てにアンダーバーを付けたくてウズウズしてしまうのですが、
そのようなコーディング規約が見付かりません。
常識的にあまり推奨されないのでしょうか？
270:デフォルトの名無しさん
07/12/15 02:39:55
>>269
どうして？
271:デフォルトの名無しさん
07/12/15 03:03:06
>>270
発端は、templateのタイプ名が外部の通常のクラス名と衝突してしまったため、
冗長にせざるを得ない場面があったからです。
ならばメンバ変数に習い、「末尾にアンダーバー」イコール「スコープ限定」にしてしまえば、
衝突も避けられるし、読む時にも迷子になり難いのではないかな・・・と。
272:デフォルトの名無しさん
07/12/15 03:44:57
>>271
そんな局所的な理由で規約になるわけないんじゃないの？
273:デフォルトの名無しさん
07/12/15 04:41:14
後ろにアンダーバーなんて始めて見たな。
前ならそうしてる人結構いるよ。
274:デフォルトの名無しさん
07/12/15 04:59:49
前につけるとすぐ予約名になるまたは予約名とまぎらわしいから、やめといたほうがいい。
275:デフォルトの名無しさん
07/12/15 07:12:05
>>271
つまりボキャブラリが貧弱なのを _ でごまかそうということですね
英語の辞書を買ったらどうでしょう
冗長といっても、いくら長くてもいいと思う
あとで別の人間が解析するときに、
grepをかけたら似た様なのがゾロゾロって
猛烈に格好悪い
276:227
07/12/15 07:45:38
>>274
これっていつから言われてるの？
昔は＿ 前だったのに・・・
>>271
それってローカル側優先で処理されるよね?
TXxxx
とかにするってのもどうかね
277:デフォルトの名無しさん
07/12/15 09:53:59
>>276
> これっていつから言われてるの？
「言われてる」ってのが何のことかわからないけど、予約名の規定自体は
知ってる範囲では ISO C++98, C99 とかで決められてる。たぶんそれより前の
C89 からそんなに変わってないと思うから、少なくとも 10 年以上前から使っちゃ
マズイってことにはなってたはず。
278:デフォルトの名無しさん
07/12/15 10:26:40
>>276
MS-DOS の初期のころから内部の実装で使われていた気がする
279:デフォルトの名無しさん
07/12/15 11:02:48
>>273
オレは何度も見たことあるよ。
280:デフォルトの名無しさん
07/12/15 12:33:25
>>279
確かに、C の関数の場合は後ろに _ をつけると()と離れて絵的に悪くないかも知れないけど
いまひとつ _ を前後に使う意味がわからないな
_ があることでなにかを示すようには見えないな
もっと、適切な方法があるならそれを選んだほうがいいように思う
見てわかるような名称にするように文になっていたっていいと思う
昔の関数名なんか変なのあるよな
creat() なんて何を考えてるんだかｗ
'e' 一文字を省く理由がわからない
281:227
07/12/15 12:39:05
>>277-278
ごめ。
_ は前に普通に付ける時代があったんだけど（本とかで載っていた）
最近後ろに付ける勢力が急拡大している感じ。
いつからだろうと。
282:デフォルトの名無しさん
07/12/15 12:49:04
>>281
前につけることの問題を知らずに本を書いちゃうようなアホが淘汰されたんだろう。
いつからってこともないと思うぜ。
283:デフォルトの名無しさん
07/12/15 12:57:38
>271
利点、欠点を考えて判断すりゃいいんじゃない？
利点：ローカルスコープの関数・変数が一目でわかる
欠点：メンバー変数とメンバー関数のバッティングが発生する可能性がある（C++の場合）
-->別の命名規則で回避する必要あり
ぐらいかね？
ローカルスコープなんだし好きにすれば？という気もするけど。
284:デフォルトの名無しさん
07/12/15 13:28:58
>>282
_ 前に付けて問題になったことなど一度たりともないけどな。
メンバ変数なんてローカルだし。
__descspecとかのキーワードなんて __ だしな
285:デフォルトの名無しさん
07/12/15 13:56:19
>>280
creat()については名付け親がそうつけてしまったことを深く恥じているのだから、
もうそっとしておいてあげたらどうだw
286:デフォルトの名無しさん
07/12/15 15:40:04
釣りか本気か微妙な流れだw
287:デフォルトの名無しさん
07/12/15 23:55:12
>>284
__declspecはむしろ正しい使い方。
処理系予約の識別子なのだから。
288:デフォルトの名無しさん
07/12/16 00:04:35
>>287
？
いや、その通りだけど、>>284の趣旨は、「そういうのは"__"だから、"_"を前につけても問題が起こったことはない」でしょ。
289:デフォルトの名無しさん
07/12/16 01:34:46
ﾅｲｼﾌｫﾛｰ
290:デフォルトの名無しさん
07/12/16 01:42:20
>>280
歴史的なもの
識別子に5文字しか使えなかったシステムで付けられた名前を引きずってるだけ
291:デフォルトの名無しさん
07/12/16 02:50:52
>>284
一度もないのは分かるけど、
規格で「予約」と明記されているものをあえて使う理由が分からん。
ローカル名については「マナー」程度なのかな？
他の言語だと「予約」だったりするんだろうか。
292:デフォルトの名無しさん
07/12/16 07:00:04
2重の__ は予約かも知れないが、
グローバルの_ はstdio.hとかのライブラリと被るので
~~~~~~~~~~~~~~~
注意ってことじゃなかったかって気がするんだが。
手元に資料がないから確認は取ってないが
293:デフォルトの名無しさん
07/12/16 07:04:09
あ、一つ思い出した。
そういやBUFSIZ ってシンボル使えないよなｗ
294:デフォルトの名無しさん
07/12/16 11:04:04
>>292
どっちも「予約」だよ。識別子の利用範囲が違うだけ。区別するのがメンドイから
自分とこで作るルールに書くときは一括でダメってことにするのが簡単。
295:デフォルトの名無しさん
07/12/16 11:26:03
URLﾘﾝｸ(www.alles.or.jp)
ちょっと見つけた
296:デフォルトの名無しさん
07/12/16 13:52:19
>>295
うーーー。意味わかんない；
ごめんオレ馬鹿すぎ。エロイ人教えて。
297:296
07/12/16 13:58:19
あ、泣くほど読んだらわかった；
298:デフォルトの名無しさん
07/12/16 13:59:11
>>296
>281-282 にある
> _ は前に普通に付ける時代があった
> 前につけることの問題を知らずに本を書いちゃうようなアホ
の例じゃね？
299:デフォルトの名無しさん
07/12/16 15:05:06
まぁ明日ARMでも読んでみるわ。
メンバ変数名は、
グローバルなネームスペースを汚してるわけじゃないしね
300:デフォルトの名無しさん
07/12/17 02:42:38
っ >168
301:デフォルトの名無しさん
07/12/17 02:50:17
なぜ予約語とぶつかる可能性のあることをしようとするのか
いまひとつわからない
たしかに、かっこいいかもしれないけど
_や__が予約語に多いのだから、他人が見たら、
これらは予約語としてみられる可能性があるということでしょ？
できるだけ、必然的であるべきだと思うのだけど
でないと後で見てわからない気がするんだけどな
名称を考えるのがめんどくさいだけに思えるのは、オレが世間知らずだから？
302:デフォルトの名無しさん
07/12/17 02:54:48
C/C++ の入門書や入門サイトがそういうインクルードガードを書いてたり。
そういうのを見て覚えた奴が自己弁護のために抵抗してるだけ。目的なんか無い。
303:デフォルトの名無しさん
07/12/17 08:01:37
_で始まる予約語に何があるか言ってみろよ
304:デフォルトの名無しさん
07/12/17 08:05:56
>>300
やっぱ答え出てるじゃないか。
メンバ変数はグローバルじゃねえ。
関数名とグローバル変数に問題があるだけだろうな
305:デフォルトの名無しさん
07/12/17 11:48:40
>>301,303 予約語じゃなくて、予約識別子ね。
306:デフォルトの名無しさん
07/12/17 15:58:27
>>303
_STDLIB_H_
307:デフォルトの名無しさん
07/12/18 00:11:07
>>305
それならわかるわ
検索してみたら、いいページ掛かったわ
308:デフォルトの名無しさん
07/12/18 06:32:30
結局 _ をつけたがるのは
自分の作ったのを予約語扱いしてもらいたい 「格好つけしー」 か
考えるのが面倒で、 _ でもつけとけの 「横着者」 のどっちか
でいいの？
309:デフォルトの名無しさん
07/12/18 08:17:39
>>308
_ のあとの小文字は問題ねーってよ
310:デフォルトの名無しさん
07/12/18 08:33:41
>>309
昔のDOS系、MSのLIBなんかは _ の関数だらけ
これを予約語といえるかわからんが
それと同列のものにしたいということだろ？
311:デフォルトの名無しさん
07/12/18 11:31:02
>>309
何が問題ねーの？予約識別子じゃないの？
312:デフォルトの名無しさん
07/12/18 11:46:38
_ のあと小文字は、グローバルスコープ（ファイルスコープ）のみで予約。以下 >294
313:デフォルトの名無しさん
07/12/18 12:17:43
>>168の短い文章を理解するのに一体何レス費やせば気が済むんだ？
314:デフォルトの名無しさん
07/12/18 12:21:59
「ある目的のために」とか、わかりにくい誤訳が入ってたからじゃね？
315:デフォルトの名無しさん
07/12/18 22:50:44
グローバルな名前空間でとわざわざ限定してくれてるからじゃん
316:デフォルトの名無しさん
07/12/19 05:46:36
「感染してますが、コンドームをつけてれば大丈夫です」と言われてもやる気はしないのと同じ
例えが、ちがうか；
317:デフォルトの名無しさん
07/12/23 23:54:01
( ﾟдﾟ )
¶ノ ¶ノ |
／￣￣￣￣￣＼
./ （,） （,） ヽ
| |￣| |
ヽ ￣￣ /
| | | | |
.ノ .ﾉ ヽ ノ .ﾉ .|
(＿ノ (＿ノ .|
／ ／ ￣／ ／
< < .< <
ヽ ヽ ヽ ヽ
318:デフォルトの名無しさん
07/12/25 07:53:47
あ、そうそう そうすると
#ifndef _FILENAME_H
#define _FILENAME_H
はどんなシンボル名にしてんの？
#define H_FILENAME_H
とか？( ﾟдﾟ)
319:デフォルトの名無しさん
07/12/25 10:30:28
FILENAME_HでもMACRO_OF_FILENAME_Hでもお好きなものをどうぞ。
320:デフォルトの名無しさん
07/12/26 04:02:28
MACRO_OF_*は却下
321:デフォルトの名無しさん
07/12/26 04:09:12
#pragma onceでいいよもう
322:デフォルトの名無しさん
07/12/26 04:10:30
せっかくポータブルな方法があるのに、
そうじゃない手段をわざわざ使うのは気が引けるよ
323:デフォルトの名無しさん
07/12/29 11:30:30
規律正しいおまいらなら
#ifndef
の使用はもうやめたんだろ？
324:デフォルトの名無しさん
07/12/29 13:41:22
両方使うのは意味があるのかな？
325:デフォルトの名無しさん
07/12/30 00:07:39
>>323
なんで ifndef はいけないと思うの？
326:デフォルトの名無しさん
08/02/19 01:14:20
皆さんのスタイルを、GNU indentの引数で表現するってのはどうでしょか。
俺は単純に
indent -kr hoge.c
です。
327:デフォルトの名無しさん
08/02/19 14:45:58
>>325
名前がぶつかるかも知れない恐怖が
328:デフォルトの名無しさん
08/03/16 18:09:35
ソースのフルパスをマクロ名に入れとけば無問題ｗ
329:デフォルトの名無しさん
08/04/13 15:16:47
そんなにぶつかるのが怖いなら、GUIDでいいんじゃないか？インクルードガードなんか入力することなんかないんだからさ。
330:デフォルトの名無しさん
08/07/28 01:19:20
URLﾘﾝｸ(lolo.jp)
331:デフォルトの名無しさん
08/07/30 22:41:39
はてなで話題になってたが
URLﾘﾝｸ(d.hatena.ne.jp)
これを厳密に守るのはきついな……
332:デフォルトの名無しさん
08/08/07 15:47:21
これはJAVAを念頭に置いてるのか？
333:デフォルトの名無しさん
08/08/09 21:26:02
>>331
goto有害論並に偏りすぎてねぇか？
334:デフォルトの名無しさん
08/08/09 22:46:42
手続き型脳を矯正するには多少極端なくらいのショック療法が必要ってことだろ
335:デフォルトの名無しさん
08/08/25 00:22:16
OO厨だった学生時代はそういう病的に分割されたコードばっか書いてたな。
だけど、働き始めて周りの人間にソース追いにくいだのなんだの
不評だったせいでいつのまにか書かなくなったが。
336:デフォルトの名無しさん
08/10/01 21:55:22
C++でオペレータの宣言・定義するときにoperator=とかくのかoperator =とかくのかそういうのって決まってるの？
337:デフォルトの名無しさん
08/10/01 21:56:36
それは多分、インデントの量とか中括弧の位置なんかと同じテーマだと思うんだが。
338:デフォルトの名無しさん
08/10/01 23:43:18
>>336
検索しやすいように空けない。
339:デフォルトの名無しさん
08/10/02 00:07:24
operator\w= で検索すればおｋ
340:デフォルトの名無しさん
08/10/02 00:08:04
↑*追加しといて
341:デフォルトの名無しさん
08/10/02 20:45:35
\w じゃダメだろ。
342:デフォルトの名無しさん
08/10/03 01:01:52
じゃあ
operator\wktk=
343:デフォルトの名無しさん
08/10/09 08:01:21
elevaterⅡ
escalator⊿