08/03/22 01:59:22
クラス名、変数名のつけ方に悩んだら書き込むスレです。
質問する人は、その変数に何を格納するのか(クラスだったらその役割)
プログラミング言語は何なのかを、それぞれ書いて、
いい変数名を思いついた人は、それに答えてあげましょう。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
>>2 英和・和英・英英など各国語辞書と翻訳サイト。
>>3 類義語(シソーラス)辞書、図形・数式・数学用語の英単語。
>>4 関連スレと、いろいろな言語規約。
>>2-10 諸事情によりリンクがずれた場合。
前スレ。
◆ネーミング倶楽部◆: URLﾘﾝｸ(pc3.2ch.net)
Part1: URLﾘﾝｸ(pc5.2ch.net)
Part2: URLﾘﾝｸ(pc5.2ch.net)
Part3: ｽﾚﾘﾝｸ(tech板)
Part4: ｽﾚﾘﾝｸ(tech板)
Part5: ｽﾚﾘﾝｸ(tech板)
Part6: ｽﾚﾘﾝｸ(tech板)
Part7: ｽﾚﾘﾝｸ(tech板)
Part8: ｽﾚﾘﾝｸ(tech板)
Part9: ｽﾚﾘﾝｸ(tech板)
Part10: ｽﾚﾘﾝｸ(tech板)
Part11: ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
08/03/22 02:00:18
英和・和英など各国語辞書と、翻訳サイト。
英和・和英辞典。
URLﾘﾝｸ(dictionary.goo.ne.jp)
URLﾘﾝｸ(www.excite.co.jp)
英英辞典のリンク集。
外国語広場： 英語： オンラインで使える英英辞典 英和・和英辞典
URLﾘﾝｸ(www.gaikoku.info)
英語←→各国語辞典。(英語)
Dictionaries
URLﾘﾝｸ(www.freedict.com)
日英・英日、日中・中日、日韓・韓日翻訳。
URLﾘﾝｸ(www.excite.co.jp)
POP jisyo.com
URLﾘﾝｸ(www.popjisyo.com)
訳GO YAKUGO.COM
URLﾘﾝｸ(www.yakugo.com)
3:デフォルトの名無しさん
08/03/22 02:00:42
専門語、類語辞書。
シソーラス（類語）検索
URLﾘﾝｸ(www.gengokk.co.jp)
Thesaurus - Yahoo! Reference (英語)
URLﾘﾝｸ(education.yahoo.com)
図形や数式などの英単語。
すうがく探検隊・数式と図形の英語
URLﾘﾝｸ(i.lekton.co.jp)
リスコレ No.24 図形の名前を英語で……
URLﾘﾝｸ(homepage1.nifty.com)
各業種いろいろ
250の辞書を一度に検索 Webdio
URLﾘﾝｸ(www.weblio.jp)
4:デフォルトの名無しさん
08/03/22 02:01:10
関連スレ。
変数名って、どの位こだわりますか？
URLﾘﾝｸ(pc.2ch.net)
ローマ字変数を使う奴は馬鹿
ｽﾚﾘﾝｸ(prog板)l50
ゲーム内で使う長い変数を縮めてあげるスレ
ｽﾚﾘﾝｸ(gamedev板)l50
★★★コーディングマナー★★★
ｽﾚﾘﾝｸ(tech板)l50
ちょっと待て！ハンガリアン
ｽﾚﾘﾝｸ(tech板)l50
Cのマナーいろいろ
ｽﾚﾘﾝｸ(tech板)l50
Cのマナー
ｽﾚﾘﾝｸ(prog板)l50
バカなコーディング規約
URLﾘﾝｸ(pc.2ch.net)
いろいろな言語規約。
Hungarian Notation(英語)
URLﾘﾝｸ(msdn.microsoft.com)
Java言語規定。6.8 名前付け規約
URLﾘﾝｸ(www.y-adagio.com)
参考書籍
翻訳に役立つGoogle活用テクニック
URLﾘﾝｸ(www.amazon.co.jp)
5:デフォルトの名無しさん
08/03/22 03:26:24
おつEx
6:デフォルトの名無しさん
08/03/22 08:53:54
>>1
おつおつ
7:デフォルトの名無しさん
08/03/22 09:10:07
appreciateSettingUpThread ( >>1, HARD) ;
8:デフォルトの名無しさん
08/03/22 11:49:48
以下の機能を持った関数の名前をお願いします。
様々なところから参照される汎用的なルーチンで、その関数そのものに固有の目的はありません。
(1)与えられた配列から、指定された範囲（例えば先頭～10番目）の要素をピックアップし新しい配列を生成する関数
(2)何らかのソートの後に、1を行う関数
9:デフォルトの名無しさん
08/03/22 12:02:30
Subarray, Subsequence
SortedSubarray, SortedSubsequence
10:デフォルトの名無しさん
08/03/22 12:43:05
SubarrayAfterSort
11:デフォルトの名無しさん
08/03/22 12:56:15
>>8
(1) MakeSubRange
(2) C++ なら MakeSubRange を多重定義してソート用のファンクタを渡す
12:8
08/03/22 13:05:48
ありがとうございます。
なるほど、よくあるsubstring関数とかのsubってことですね。
13:デフォルトの名無しさん
08/03/22 13:10:01
GetPartialArray
GetPartialArrayOfSorted
14:デフォルトの名無しさん
08/03/22 15:01:54
俺の出番はないようだ
15:デフォルトの名無しさん
08/03/22 16:08:05
arrayEx
冗談だぜ
16:デフォルトの名無しさん
08/03/22 18:29:00
newArrayWithRange
newSortedArrayWithRange
17:デフォルトの名無しさん
08/03/22 18:48:28
Slice
OrderedSlice
18:デフォルトの名無しさん
08/03/22 19:28:49
>>11
実装の話は禁止じゃないか。ファンクタ使えないとこだし
19:デフォルトの名無しさん
08/03/22 22:23:00
>18
C++ではないですが、
関数の名前は変えずに、ソート方法が指定してあるかどうかで振り分けたらどうか？と理解しました。
20:デフォルトの名無しさん
08/03/22 23:07:24
>19
簡単に実装するとこんな感じ→URLﾘﾝｸ(www.hsjp.net)
要はソートと処理が一体化するのがまともな実装というか
ソート方法を指定するような処理でもないのよ
素直に関数の名前変えたほうがいいと思うけど
21:デフォルトの名無しさん
08/03/25 18:01:22
クラスというか名前空間というかソース名というか
C++/CLIでC/C++な関数を使う時に
便利なマクロやinline関数等をまとめた
ヘッダーファイル名
は、何がいいでしょうか？
22:デフォルトの名無しさん
08/03/25 18:11:49
basicDefs.h/convenient.h
23:デフォルトの名無しさん
08/03/25 19:22:55
interoputil
24:デフォルトの名無しさん
08/03/25 20:39:08
bridgeutils.h
25:デフォルトの名無しさん
08/03/26 12:25:26
macross.h
26:デフォルトの名無しさん
08/03/26 13:29:08
愛、おぼえていますか？
27:デフォルトの名無しさん
08/03/26 22:12:52
protoculture.h
28:デフォルトの名無しさん
08/03/27 13:31:44
deculture.h
29:デフォルトの名無しさん
08/03/28 13:35:01
＞便利なマクロやinline関数等をまとめた
usb.h
/********************************
the ultra super benri header file
********************************/
30:デフォルトの名無しさん
08/03/28 15:36:28
('□`)…
31:デフォルトの名無しさん
08/03/28 20:56:53
oyakudati.h
32:デフォルトの名無しさん
08/03/29 22:17:28
OCamlでイラストロジックを遊ぶためのプログラムを書こうと思っています。
書くマス目の状態を表すヴァリアントを定義したいのですが、どのような名前をつけたらよいでしょうか。
とりあえず、塗られた状態、×印が付いた状態、何もされていない状態を表したいです。
33:デフォルトの名無しさん
08/03/29 22:18:09
書くマス目→各マス目
ですね。
34:デフォルトの名無しさん
08/03/29 22:21:21
>>32
塗：checked
×：rejected
無：none
35:デフォルトの名無しさん
08/03/29 22:26:42
>>34
rejectは思いつきませんでした。使ってみます。
ありがとうございました。
36:デフォルトの名無しさん
08/03/29 23:01:06
>>35
個人的な考えになるけど、イラストロジックってカラーがあったよね？
そういうの実装する可能性があるならchecked/noneじゃないほうがいいかな？とか思った。
いや、代替案があるわけじゃないんだけど・・・
37:34
08/03/29 23:10:02
>>36
おぉ、確かに。
俺はC#を趣味でやってるだけだから、良い方法なのかダメな方法なのかは分からないが、
enum BlockState : int{
Red = (unchecked)0xffff0000,
Blue = (unchecked)0xff0000ff,
...
White = (unchecked)0xffffffff,
Reject = (unchecked)0x00000000,
}
とか俺ならやる。
38:デフォルトの名無しさん
08/03/29 23:24:54
>>36
checkedじゃなくてfilledだったら違和感ないですかね。
色の拡張もこんな感じでできるかな。
type state = Filled of color | Rejected | Empty
まあ今作ってるのは入門書に載ってるちっちゃいプログラムを改造したようなやつなんで、
カラーに拡張するときはまた1から書き直すと思います。
39:デフォルトの名無しさん
08/03/29 23:29:09
俺なら
塗： Black (確定黒)
�ﾗ： White (確定白)
無：Undecided (未決)
40:デフォルトの名無しさん
08/03/29 23:39:08
rejected よりは protected かな
41:デフォルトの名無しさん
08/03/29 23:57:10
boardStateMap
MapはいらんけどMatrixでもいいのか。そういうこと？
42:デフォルトの名無しさん
08/03/30 01:38:34
URLﾘﾝｸ(en.wikipedia.org)
これ見ると英語的には
Box/Space/Emptyなのかね。なんか分かりにくいね
個人的には
Filled/Space/Markedとかかな
43:デフォルトの名無しさん
08/03/30 02:36:36
Tribool ::= False | True | Indeterminate
44:デフォルトの名無しさん
08/03/30 03:20:37
Nothing, Empty, Null
これらは同じ意味（確かVB
45:デフォルトの名無しさん
08/03/30 13:57:06
ポインタを格納する配列変数名にはapHoge使ってるんだけど
std::vector使うなら、vpHogeの方が分かりやすい？
それともapHogeのままの方が分かりやすい？
46:デフォルトの名無しさん
08/03/30 14:09:55
>>45 >>1
> 命名規則や設計の善し悪しについて議論するのは基本的に禁止。
47:デフォルトの名無しさん
08/03/30 14:20:11
そもそも ap だの vp だのつけることに何の意義がある？
48:デフォルトの名無しさん
08/03/30 14:21:03
手動マングリングです
49:デフォルトの名無しさん
08/03/30 15:52:15
ハンガリアンは宗教論争の元。
URLﾘﾝｸ(ja.wikipedia.org)
趣味なら自分がわかりやすい方で、仕事ならそこのコーディング規約に従う。
50:デフォルトの名無しさん
08/03/30 15:54:18
vctHogePtr
51:デフォルトの名無しさん
08/03/30 16:12:41
>>45 allHoges
52:デフォルトの名無しさん
08/03/31 05:11:57
hoge_ptrs
53:デフォルトの名無しさん
08/03/31 11:56:22
ファイルのオープンに失敗した時に送出する例外クラスの名前なんだけど、
Exception
↑
FileOpenException
って英語的に違和感ありますか
54:デフォルトの名無しさん
08/03/31 12:03:15
べつにいいんじゃね。
間にIOExceptionとかFileExceptionとか挟んどけばそれっぽい。
55:デフォルトの名無しさん
08/03/31 12:10:17
サンクス。了解です
56:デフォルトの名無しさん
08/03/31 16:53:53
>>53じゃないけど、O-V の形で色々作ると、
FileDeleteException
DirectoryChangeException
TableDropException
って感じになって、なんかシックリ来ない。
「File」を prefix的に使うのならFile の OpenExceptionということで FileOpenException は
妥当だと思うけど、英語的には OpenFileException の方が妥当な気もする。
57:デフォルトの名無しさん
08/03/31 18:36:45
>>56
FileOpenExceptionでおかしくないと思うし、君の解釈はちょっと変な気がするよ。
例によって「名詞句 + Exception」と解釈すべきだろう。
つまり
FileOpenException = Exception of 'File Open'
58:デフォルトの名無しさん
08/03/31 19:09:14
困ったときのGoogle Code Search
URLﾘﾝｸ(www.google.com) 56件
URLﾘﾝｸ(www.google.com) 92件
59:デフォルトの名無しさん
08/03/31 19:48:44
末尾Exceptionにこだわらないなら、FileOpenErrorとかFileOpenFailureとかどうかな。
～Errorはstdでも見掛ける命名規則だし。
60:56
08/03/31 20:03:48
>>57
ご意見ありがとうございます。
違和感を感じただけで、英語が得意というわけでもないので、英語的に根本的に間違ってる
かもしれませんが、 exception of to open a file / exception of opening a file を名詞句的にあつかうなら
open file exception なのかなぁとも思うのです。
61:デフォルトの名無しさん
08/03/31 20:14:08
FileCouldNotBeOpenedException
62:デフォルトの名無しさん
08/03/31 20:18:15
違和感は感じるな。覚えろ。
63:デフォルトの名無しさん
08/03/31 20:21:25
>>59
Errorは例外のうち復旧不能なものにつける場合が多いね
64:デフォルトの名無しさん
08/03/31 20:27:50
javaや.NETではFile<～>Exceptionだな
FileNotFoundが一般的すぎるから他のもそれに倣ってるんじゃね
65:デフォルトの名無しさん
08/03/31 20:30:42
違和感よりも一貫性優先じゃないか？
66:デフォルトの名無しさん
08/03/31 20:30:53
JavaだとFileNotFoundException
英語的な正しさを求めるならNotがないとおかしいかも
67:デフォルトの名無しさん
08/03/31 20:32:35
かぶったw
68:デフォルトの名無しさん
08/03/31 20:41:19
開けないのはファイルがない時だけじゃ無いけどね。
69:デフォルトの名無しさん
08/03/31 20:43:36
File open error. はおそらく英語として自然なんだと思うが、
しかし、だからといって File open exception が自然なのかどうか分からないのが困った所だな。
70:デフォルトの名無しさん
08/03/31 20:51:40
.NETでFileLoadExceptionというのがあるよ
自然かどうかはおいといて
71:デフォルトの名無しさん
08/03/31 21:22:34
>>60
自信ないけどopenfile/fileopenはどっちでもいいんじゃないのかな。
ドトネトでも一方ではOpenFileDialogとかあるわけで。
要は>>57で言いたかったのは、>>56の
＞「File」を prefix的に使うのならFile の OpenExceptionということ
この考えは変だということ。
>>69
純粋に自然な英語を目指すなら"file opening failure"とかじゃないの？
72:デフォルトの名無しさん
08/03/31 21:54:33
>>71
"file open error" に一致する英語のページ 約 42,300 件
"file opening failure" の検索結果 約 236 件
どう頑張っても日本語のページもひっかかって� �) 16:49:41
73:デフォルトの名無しさん
08/07/16 20:28:36
=も二項演算子の一つとみなせば（普通はそうじゃないの？）
命名する必要があるのは3つじゃなくて2つだな。
というわけでLeftValue, RightValueとか。
いや=はやっぱり「イコール」で特殊でしょ、っていうのなら
Result(Answer), Operandとか。
74:デフォルトの名無しさん
08/07/16 20:32:10
>>383-384
やっぱそんな感じなのかな
>>385
最初それを考えたんだけど、実際に欲しかったのはB,Cだったので考え直した次第で。
right1,right2に落ち着いた罠。
みんなありがとうー
75:デフォルトの名無しさん
08/07/16 22:52:52
演算子の左右で結果が変わる場合もあるから面倒だよな
76:デフォルトの名無しさん
08/07/16 23:19:00
right1,right2ならb,cと何も変わらないと思うけどなw
というか綴りから何も汲み取れないどころか場合によってはミスリーディングな上に
タイプ量が増えてるんだからかえってマイナスにしか思えない。
中途半端な付加情報ならかえって惑わすだけだからない方がずっといい。
77:デフォルトの名無しさん
08/07/16 23:29:19
数式パーサでも作ってんの？
78:デフォルトの名無しさん
08/07/16 23:42:52
なんらかの演算をする関数、って例えなんじゃないの？
79:デフォルトの名無しさん
08/07/17 11:21:20
スライドユニット的なものを、直線方向に行ったり来たりする制御をしています
Unit_move()内で、さらに順方向へ行く場合と、逆方向へ行く場合とで分岐させく、
逆方向へ行く関数は、Unit_move_reverse()としました。
では、順方向へ行く関数名は、どんなのが良いですかね？
80:デフォルトの名無しさん
08/07/17 11:23:46
順方向 Unit_move_forward
逆方向 Unit_move_backward
じゃないか?
81:391
08/07/17 11:26:10
>>392
素晴らしい！全くもってそれにします。
82:デフォルトの名無しさん
08/07/17 12:14:23
語順がOVなのは気持ち悪い。
83:デフォルトの名無しさん
08/07/17 12:46:37
アメリカ人のソースも、OVにしている人が結構居ると聞く
なんかの本でも、こっちを推奨してた
84:デフォルトの名無しさん
08/07/17 12:53:05
SVだよ
85:デフォルトの名無しさん
08/07/17 16:10:27
まあ、でも、似たような目的の変数や関数があるときに、
「共通部分_違う部分」という構成にしたくなる気持ちは分かる。すげー分かる。
86:デフォルトの名無しさん
08/07/17 17:24:40
「英語式語順は、自然な思考の順番に反する」研究結果
URLﾘﾝｸ(wiredvision.jp)
87:デフォルトの名無しさん
08/07/17 17:37:29
それ見た
88:デフォルトの名無しさん
08/07/17 19:37:58
>>397
俺はそんなの全然わからん。
たぶんそんな欲望に駆られるとしたら、それは設計が間違ってる（機能の分割が不適切で
クラスなりモジュールなりがデカ杉とか）んだよ。
＞順方向 Unit_move_forward
＞逆方向 Unit_move_backward
じゃないか?
OOPじゃないとしても冗長過ぎる命名じゃないか？
もっとシンプルに
ForwardUnit
BackUnit
にするよ。
89:デフォルトの名無しさん
08/07/17 19:59:56
ボツ
90:デフォルトの名無しさん
08/07/17 21:39:52
命名に使う語彙さえ示せば、あとは利用者が好きに使うだろ。
いい単語を思いつかないのが命名時の最大の悩みだ。
91:デフォルトの名無しさん
08/07/17 22:04:23
関数に｛形容詞＋名詞｝はねーよ
92:デフォルトの名無しさん
08/07/17 22:11:25
動詞（+副詞）（+目的語）かなぁ
93:デフォルトの名無しさん
08/07/17 22:17:10
Unitに関するAPIの接頭辞としてなら分かる。C的だけど。
94:デフォルトの名無しさん
08/07/17 22:20:50
それはない。
95:デフォルトの名無しさん
08/07/17 22:37:16
>>403
君アホでしょw
96:デフォルトの名無しさん
08/07/17 22:42:25
お前がアホ
97:デフォルトの名無しさん
08/07/17 22:45:32
いやまあアホの子のために一応解説しておくとw
forwardもbackも他動詞の用法もあるんだよ。
なんでもちょっと指先動かせば調べられる時代なんだから辞書ぐらい引けよw
98:デフォルトの名無しさん
08/07/17 22:51:31
それ意味が違うから
99:デフォルトの名無しさん
08/07/17 22:54:25
>>409
確かにメール転送するみたいなのは動詞のforwardだがよ
100:デフォルトの名無しさん
08/07/18 21:00:59
>>400
いいからわかれ。
メソッド命名のためだけにクラスを分割するほうが下策。
いろいろ事情があったりするかもしれないのに、
「設計が間違ってる」などと断定するな。
どうしてもしたいなら余所池。
101:デフォルトの名無しさん
08/07/18 21:11:00
＞いろいろ事情があったりするかもしれない
そういう自分に対する言い訳が、言い訳をしているという自覚もなく出てくるタイプは
何事につけ成長しないよ。
というか話を過剰に一般化しないこと。
少なくとも>>392に関しては冗長以外のなんでもない。
102:デフォルトの名無しさん
08/07/18 21:21:22
↑何これキモすぎ
103:デフォルトの名無しさん
08/07/18 21:22:14
あとついでに、
＞メソッド命名のためだけにクラスを分割するほうが下策
違うだろそんなこと言ってない。
分割統治の方法が間違ってるから、自然と（？）「苦しい」命名になっちゃうんだよ、
と言ってるんだよ。
104:デフォルトの名無しさん
08/07/18 21:24:58
＞それは設計が間違ってる（機能の分割が不適切で
＞クラスなりモジュールなりがデカ杉とか）んだよ。
105:デフォルトの名無しさん
08/07/18 21:51:32
>>1
106:デフォルトの名無しさん
08/07/18 23:42:40
自分の発想力の貧困さを棚に上げて、
やり方が違っているモノは全て設計が悪いとな
107:デフォルトの名無しさん
08/07/19 00:48:48
397の発言がそもそも理解できない。
似たような目的の変数や関数って例えばどういうのがあるんだろう?
draw_circle()とdraw_triangle()は似たような目的の関数で、
”draw"が共通部分、"circle"とかが違う部分?
aka_ranger, ao_rangerは似たような変数だが、
397はranger_aka、ranger_aoとしたい衝動にかられる?
108:デフォルトの名無しさん
08/07/19 01:01:59
>>419
駆られる。
すごい駆られる。
109:デフォルトの名無しさん
08/07/19 01:29:45
>>419
アカレンジャーアオレンジャーは固有名詞化してるから引き合いに出されても困る
110:デフォルトの名無しさん
08/07/19 01:34:46
>>419
かられる。かなり。
rangerというものがあって、そのバリエーションが並ぶ、
と考えることで、頭の中で把握しやすいので。
たぶん、系統分類的に整理できることがいいんだろう。
で実際にそうしたあと、
aka_kage
aka_oni
やらが出てきて、akaでまとめとくべきだったか、
と考え込んでしまうこともときどき。orz
111:デフォルトの名無しさん
08/07/19 01:38:59
バルイーグル
バルシャーク
バルパンサー
似たような変数だが、
419はイーグルバル、シャークバル、パンサーバルとしたい衝動に駆られる?
112:デフォルトの名無しさん
08/07/19 01:39:13
ゴレンジャーの例えはわかりやすくていいな。
113:419
08/07/19 01:43:47
>>421
だんだん分かってきた。
right_speacker_volume、left_speaker_volume等の変数名を見たら、
speacker_volume_right、speacker_volume_leftにしたいということかな?
114:デフォルトの名無しさん
08/07/19 01:51:34
volume_headphone
とか出てくると、更に順序を入れ替えたくなる。
115:397
08/07/19 01:56:39
一応本人。
id_foo
id_bar
とか、そういう流れ
116:デフォルトの名無しさん
08/07/19 02:39:12
id_foo、id_barってことは、型名をプレフィックスとして使うハンガリアン記法に
準ずるもの(というかこれが本来のハンガリアン記法だっけ?)ということだね。
117:デフォルトの名無しさん
08/07/19 02:49:44
>>425
すげぇしたくなる
>>427
それはアプリケーションハンガリアン
当然やるものだと思ってた
118:デフォルトの名無しさん
08/07/19 02:50:55
正直、ranger_akaの例えが秀逸すぎる
119:デフォルトの名無しさん
08/07/19 02:53:42
どこで悪い癖つけてきたんだかわからんのだけど
俺より10位、年下の奴がシステムハンガリアンなコード書きまくるんだよな・・・。
派遣だからなんもいわんけど。
120:デフォルトの名無しさん
08/07/19 02:54:58
>429
うん、そのアプリケーションハンガリアンの考え方があるから
それに倣ってみたいということね。
121:デフォルトの名無しさん
08/07/19 02:59:15
ハンガリアンの考え方自体はプレフィクスにするかポストフィクスにするかの選択とは直行してるだろ。
122:デフォルトの名無しさん
08/07/19 03:08:01
ハンガリアンってtype識別子をプレフィックスにすることが多いけど、
サフィックスでやれば>>425,426と一致するな
123:デフォルトの名無しさん
08/07/19 03:15:28
>>431
仕事なら命名規約ってあるんじゃないの?
って思ったけどなんとなくシステムハンガリアン記法の信者にかぎって
細かな命名規約を作りたがって、システムハンガリアン記法が眼中にない
人間は「分かりやすい名前をつけること」程度の命名規約しか作らない、
という傾向があるような気がする。
124:デフォルトの名無しさん
08/07/19 12:19:05
システムハンガリアン以外の命名法は、
ある程度ゆらぎというか幅が存在するから、厳密にしづらいってのもあるしな
125:デフォルトの名無しさん
08/07/19 12:25:00
>>435
なにか「規約」って言葉を勘違いしてない？いや君が。
個人が自分のポリシーで左右できるようなものは規約じゃないじゃんw
規約の目的は複数人での共同作業をつつがなくすることのはずだよ。
126:デフォルトの名無しさん
08/07/19 12:39:06
>>435じゃないが、何かおかしいか？
仕事だと上に立つやつがポリシーっていうか趣味で規約作ることが多いじゃん
ああ、下請け仕事とかやったことないのかな
127:デフォルトの名無しさん
08/07/19 12:49:09
小学生程度の読解力を身につけてから人に突っかかろうよ。
435は「不条理な規約を押し付けられて困ってる」という趣旨のこと言ってるか本当に。
128:デフォルトの名無しさん
08/07/19 13:41:05
システムハンガリアンって好きじゃないけど
プレフィックスあると予約語とかぶらなくて便利よね
129:デフォルトの名無しさん
08/07/19 14:24:59
>>437
> 個人が自分のポリシーで左右できるようなものは規約じゃないじゃんw
個人が自分のポリシーで左右できてしまうのでそのままにするとばらばらになるから、
規約作って共同作業をつつがなくすることができるようにするんだろ。
130:デフォルトの名無しさん
08/07/19 14:38:18
>>441
おいおい何を訳のわからない絡みかたしてるんだよ。
酔っ払ってるか生来頭が悪いのでなければ文脈をちゃんと読めよ。
131:デフォルトの名無しさん
08/07/19 16:06:51
>>437=>>442
いよいよ引っ込みがつかなくなってきたな。
次は、「そんなに必死になるなよ」かな？ (w
132:デフォルトの名無しさん
08/07/19 16:21:19
そうやってメタな方向にズレないこと。
君が婉曲的な表現で通じない（理解しなくない）「ガキ」なら直接的に言ってやるよ。
俺(437)は>>441と同じことを言ってるのであって、矛盾するようなことは何もいってない。
矛盾することを言っているのは>>435
133:デフォルトの名無しさん
08/07/19 16:22:05
というかむしろ必死で反論してくれ。
134:デフォルトの名無しさん
08/07/19 16:36:18
ついさっき、まともに読んだんだが、話がズレていってないか？
とりあえず、>>437の>>435に対するコメントはズレている、と思った。
135:デフォルトの名無しさん
08/07/19 16:41:50
>>444
あまりのおつむのヨさに絶句。本当に>>431, >>435読んでるの?
いいか? 俺の解釈を書くぞ? よく読めよ?
431 の元にはシステムハンガリアンなコードを書くやつがいる。
431 はそれに不満を持っているようだ。
それを読んだ 435 は、お前さん(431)の職場には規約がないのか?
それに従うように言えばいいんじゃないか? という疑問を持つ
しかし、考えてみるに
システムハンガリアンを使いたいと思わない人間の作る規約は、
「分かりやすい名前をつけること」
程度である事が多い。431 の職場はそういうとこなのだろう。
システムハンガリアンが、この規約に明確に反してるとはいえないよな。
だからきっと 431 は明確にダメ出しすることができないのだろうな、
と 435 は思った。
136:446
08/07/19 16:46:42
>>447の親切さに感動！
137:デフォルトの名無しさん
08/07/19 17:09:22
★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆
★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆
★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆★■▲●▼◆
138:デフォルトの名無しさん
08/07/19 17:11:50
>>447
親切すぎ噴いたｗｗ
139:デフォルトの名無しさん
08/07/19 17:44:01
全然意味がわからない。
＞システムハンガリアンを使いたいと思わない人間の作る規約は、
だからここが変でしょ。
システムハンガリアンを使いたいと思わない人間の作る規約？
"システムハンガリアンを使いたいと思わない人間" is one person
規約とは"one person"が作る類のものではない。
>>435もおそらくそれは頭では理解している。
頭で理解していることにそれと矛盾することを平気で書くから救いがたい。
140:デフォルトの名無しさん
08/07/19 18:01:22
>>451
>全然意味がわからない。
文章を精読する、ということを覚えた方が良いと思う。
あと、英語使う意味あるか？
141:デフォルトの名無しさん
08/07/19 18:04:31
＞規約とは"one person"が作る類のものではない。
理想を言えば、そうだよな。うん。
ちなみにウチには命名規約なんて崇高なもんはねぇぜ！ ヒャッハァ！
142:452
08/07/19 18:15:24
ちょっとだけ助け舟を出してやる。
たとえ話だ。
>>435は1+1+1=3という話をしていた。
そこへ
>>437は、ちげーよ、1+1=2だと主張してきた。
たしかに>>437はある意味で正しいことを言っているのかもしれないが
ちょっとピントがずれてる。
143:デフォルトの名無しさん
08/07/19 18:30:52
>"システムハンガリアンを使いたいと思わない人間" is one person
「達」か? 「達」って書けばお前さんは納得するのか?
じゃあ >>447 の当該個所に補完しといてくれ。
144:デフォルトの名無しさん
08/07/19 18:42:12
>>451
> 規約とは"one person"が作る類のものではない。
状況によって違うんだろうけど、色々議論はするにしても最終的に決定するのは
ある特定の人物である方が普通だと思うよ。
よってたかって素晴らしいもの作りましょうなんてやってたら、いつまでたって
も決まらないしな。
>>452
> あと、英語使う意味あるか？
いよいよ引っ込みがつかなくなってきたんだろ。
察してやってください。
145:452
08/07/19 18:55:08
>>456
ちょっとﾜﾛﾀ。
ﾏﾝﾄﾞｸｾって思ってたｹﾄﾞ、読んでて良かった。
ごめん、漏れとちょっと解釈が違う。
漏れの解釈だけど
>>435の意見の本質は「どちらの意見が採用された規約でも、システムハンガリアンは、
自分のコーディングスタイルで書くことができる」ってことじゃね？
146:457
08/07/19 19:01:05
>>456
ごめん。早とちりだった。
>>435のことぜんぜん関係なかったね。
疲れたから、消えるわ。
147:デフォルトの名無しさん
08/07/23 23:15:24
変数じゃないんだけど、opaque typeってなんて訳せば良いかな？
148:デフォルトの名無しさん
08/07/23 23:19:22
不透明な型
149:デフォルトの名無しさん
08/07/23 23:21:53
ありがとう
やっぱ普通にそれで良いよね
150:デフォルトの名無しさん
08/07/24 00:11:14
配列やらvectorやらの変数名をつけるとき、複数形語尾をどこに付けるか迷う。
windowsHandleかwindowHandlesか、はたまたwindowsHandlesか……
特にchild→childrenみたいな特殊な形のやつは迷う。
151:デフォルトの名無しさん
08/07/24 00:16:32
vector<FooBar> fooBars でよくないか
俺が考えなさすぎなのだろうか