クラス名・変数名に迷ったら書き込むスレ。Part22

1 ：デフォルトの名無しさん：2012/09/06(木) 17:19:40.71

クラス名、変数名のつけ方に悩んだら書き込むスレです。

命名規則や設計の善し悪しについて議論するのは基本的に禁止。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。

前スレ
クラス名・変数名に迷ったら書き込むスレ。Part21
http://toro.2ch.net/test/read.cgi/tech/1327197884/

2 ：デフォルトの名無しさん：2012/09/07(金) 11:59:30.87

木構造で葉に子要素を加えるときにその要素がルート出なかった場合に例外を投げたい

void Node::addChild(Node * p) {
assert(p);
if(p->hasParent()) {
throw XException("XMessage");
}
else {
container.insert(p);
p->parent = this;
}
}

このときXExceptionの名前とXMessageの内容は？

3 ：デフォルトの名無しさん：2012/09/07(金) 14:59:57.19

例外　Node::NotRootException
メッセージ　Node must be root.

4 ：デフォルトの名無しさん：2012/09/07(金) 19:44:47.02

そこまで例外を細分化させる事に意味があるのだろうか
普通にArgumentExceptionでいいんじゃね

5 ：デフォルトの名無しさん：2012/09/07(金) 21:58:31.79

>>2
InvalidNodeOperationException
AddNodeFailedException
NotRootNodeAddedException
--------
追加しようとしたNodeはルートノードではありません。

6 ：デフォルトの名無しさん：2012/09/08(土) 12:52:56.48

8/27ぶりに立ちました

7 ：デフォルトの名無しさん：2012/09/09(日) 13:06:29.03

動作確認で試したいだけなんだけど、TestFileかFileTestのどっちがいいかな

8 ：デフォルトの名無しさん：2012/09/09(日) 13:12:37.87

前者はファイルで
後者はテストやないか

9 ：デフォルトの名無しさん：2012/09/09(日) 15:36:52.72

末尾に_tつけるとかいうのもあるな。

10 ：デフォルトの名無しさん：2012/09/11(火) 00:16:42.32

webアプリで使うテンプレートファイル名なんですけど
2カラム（左サイドバー）テンプレート、
サイドバーなし1カラムテンプレートとかどういうファイル名にしたら良いでしょうか

template_2c_left.tpl これはちょっとなぁ

11 ：デフォルトの名無しさん：2012/09/11(火) 00:30:02.46

2カラム（左サイドバー）.tpl
サイドバーなし1カラム.tpl

12 ：デフォルトの名無しさん：2012/09/11(火) 14:17:53.82

sidebar_left.tpl
sidebar_no.tpl

13 ：デフォルトの名無しさん：2012/09/11(火) 19:29:50.23

どうもです・・・・

14 ：デフォルトの名無しさん：2012/09/12(水) 21:28:00.47

名前にこだわるうちは二流だよね

15 ：デフォルトの名無しさん：2012/09/12(水) 21:34:37.88

いい名前または、無難な名前を瞬間的に付けられるようになったら
一流と思う

16 ：デフォルトの名無しさん：2012/09/12(水) 21:38:43.66

名前がよくても結局のところ仕様を見ないやつはカスだから

17 ：デフォルトの名無しさん：2012/09/12(水) 21:40:10.69

>>16
なんかあったのなら、ここでぶちまけていいんだぞ。聞いてやる

18 ：デフォルトの名無しさん：2012/09/12(水) 21:57:50.61

>>14
リーダブルコードを読んだ後でも同じ台詞が吐けるなら、
同僚じゃなくて本当に良かったと思う

19 ：デフォルトの名無しさん：2012/09/12(水) 23:16:31.73

仕様がわからないのにいい名前ってどんな名前だよ

20 ：デフォルトの名無しさん：2012/09/12(水) 23:29:32.74

>>19
お前用のクラス用意しといてやる
CSpec072implementee

21 ：デフォルトの名無しさん：2012/09/13(木) 00:00:43.35

>>20
意味がわからんが

22 ：デフォルトの名無しさん：2012/09/13(木) 07:33:42.22

おれも正直分からん、誰か >>20 を解説してくれ。

話の流れから言って、なんかのギャグを言って >>19 を馬鹿にしているなぁ
ということは分かるが、内容が全く分からん。

23 ：デフォルトの名無しさん：2012/09/13(木) 09:27:35.09

CSpec BDDフレームワーク
072　しこしこ
implementee 実装されるもの

24 ：デフォルトの名無しさん：2012/09/13(木) 15:24:42.71

>>15
褒めてくれてありがとう

25 ：デフォルトの名無しさん：2012/09/16(日) 15:02:37.29

Pythonで送信者メールを格納するプロパティ
fromとtoにしたいけど、fromは予約語

さてどうしたものか

26 ：デフォルトの名無しさん：2012/09/16(日) 15:12:30.33

fromAddr
toAddr

fromAddress
toAddress

from_
to_

27 ：デフォルトの名無しさん：2012/09/16(日) 21:40:26.79

>>25
ffrom とか重ねておく妥協

28 ：デフォルトの名無しさん：2012/09/16(日) 23:27:44.36

Sender …はRFC的に意味があるから駄目か。

29 ：デフォルトの名無しさん：2012/09/17(月) 07:52:44.13

>>27
それするぐらいなら、from_ の方が意味がないだけマシじゃね？

まあ普通に fromAddress に一票。

30 ：デフォルトの名無しさん：2012/09/17(月) 07:56:21.06

既出の案とかぶらせないためにおかしな案持ち出すくらいなら賛成すればいいのにね

31 ：デフォルトの名無しさん：2012/09/17(月) 09:09:02.36

>>30
誰に言っている？

32 ：デフォルトの名無しさん：2012/09/17(月) 09:33:47.18

既出の案とかぶらせないためにおかしな案持ち出した人

33 ：デフォルトの名無しさん：2012/09/17(月) 09:47:46.96

迷う必要がないとこでしょ

34 ：デフォルトの名無しさん：2012/09/17(月) 10:29:00.99

迷ったからここに来てるんだろ

35 ：デフォルトの名無しさん：2012/09/21(金) 08:26:28.09

外積で、z が 0 の場合、
つまり 2D での cross product ってことで crossProduct2d って関数を作ってたんですが、
2次元の外積なんてない、と算数のエラい人に言われました。
よく使われる式じゃないかと思うんですが、何ぶん算数が苦手で名前も思い浮かびません。
いい名前をお願いします。

36 ：デフォルトの名無しさん：2012/09/21(金) 11:11:50.14

2次元空間で、としてなら多分そうなんだろう。

で、ここで真に重要なのは、2D云々じゃなく、
zが0のときにのみ使える「簡易版の外積」ってことなんじゃないだろうか。

37 ：デフォルトの名無しさん：2012/09/21(金) 12:28:30.13

>> 36
crossProductWithoutZ
こうですか？わかりません＞＜

38 ：デフォルトの名無しさん：2012/09/21(金) 20:40:35.82

>>35
そもそもz = 0の時専用の関数を用意しなきゃならん意味が全然分かりません

39 ：デフォルトの名無しさん：2012/09/21(金) 20:47:54.98

>>35
そもそも、その crossProduct2d 関数は、
何を引数にとって、何を返す、何のための関数なんだ？

まずはそこからしっかり説明してくれ。

40 ：デフォルトの名無しさん：2012/09/21(金) 21:47:56.12

>>38
> >>1
> > 命名規則や設計の善し悪しについて議論するのは基本的に禁止。

41 ：デフォルトの名無しさん：2012/09/22(土) 09:28:43.16

>> 38
その理由はクラスが Vector2d だからです。
Vector3d なら問題ないんです。
実際 AS3 だと交差判定やらなにやらで 2 次元座標を Vector3d の z = 0 で使ってたりします。
お前も真似して 3d クラス使えよってんなら話は終わりですが、気持ちが悪いなぁと。

>> 39
外積ってやつです。
引数は外積をとりたいもう一つのベクトルをとります。
2次元でも線の交差判定とかでちょいちょい出てきます。
戻り値は 3D ならベクトルなんですが、
2D の場合は z が 0 のため x, y が 0 になってしまうので事実上 z 座標の値を返す感じです。

42 ：デフォルトの名無しさん：2012/09/22(土) 09:36:47.35

>>35
算数とプログラミングを混同するな馬鹿って言っておけ
普通に2Dベクトル計算でも外積は定義するし関数名はCrossProdとかありきたりな名前を付ける
それでIT技術者には通じるしもし不安に思ったらドキュメントで仕様を確認するからそこに書いておけばいい

43 ：39：2012/09/22(土) 13:36:08.45

>>41
いや、表面上は外積を計算したがっているのは分かってる。
最初の質問にも書かれているから。

その外積の計算で、戻り値にどのゆうな意味を付与しているのかを知りたかった。
もし明確な意味があるのなら、その意味を端的に表す単語を名前に使えるから。
それが「何のための関数」を訊いた訳。
逆質問の仕方が悪かったのは謝る。

もし特定の意味はなく、汎用ライブラリ的な抽象度の高い計算関数であるなら、
たとえば determinant（行列式）はどうだ。
実際に計算していてるそれは外積ではなく2次正方行列の行列式だ。

44 ：デフォルトの名無しさん：2012/09/23(日) 00:00:27.76

>>41
結論から言うとcrossProduct2dでも、あるいは非OOPみたいだからVCT2D_OuterProduct
みたいな名前でよいのでは？

俺ももうそんな数学はさっぱり忘れたのでググって見たけど、2Dの外積は
xy平面(Z = 0)上の2つのベクトルの外積と考えることが多く、演算結果も
実用上ベクトルではなくスカラーとして扱う場合が多いらしい。

45 ：デフォルトの名無しさん：2012/09/23(日) 13:35:33.06

isUnique の対義語は何になりますか。

46 ：デフォルトの名無しさん：2012/09/23(日) 13:51:27.65

>>45
isCommon
isComparable
isGeneral
isUsual

などはどうだろうか。
それぞれ固有のニュアンスがあるから詳しくは英英辞典などで調べてくれ。

ちなみに、>>45 の書き方からして恐らく真偽値を扱う変数や関数だろうから、
紛らわしいので真偽値変数などに否定形の名前は避けるべき
という理由で安易な isUnunique はお勧めしない。

47 ：デフォルトの名無しさん：2012/09/23(日) 13:56:48.54

>>46
それは逆だと思うよw
明示的な名前にしたいのなら素直にisUnuniqueとかisNotUniqueにすべき。

なぜなら、例えば"common"であることはuniqueであることと必ずしも矛盾しないからだ。

48 ：46 じゃねーけど：2012/09/23(日) 14:01:55.40

>>47
> なぜなら、例えば"common"であることはuniqueであることと必ずしも矛盾しないからだ。

だから、「固有のニュアンスがあるから詳しくは英英辞典などで調べてくれ」って書いてるんじゃね？

49 ：デフォルトの名無しさん：2012/09/23(日) 14:05:17.18

何が「だから」か意味が分かりません。

50 ：デフォルトの名無しさん：2012/09/23(日) 14:18:10.26

>>47
> なぜなら、例えば"common"であることはuniqueであることと必ずしも矛盾しないからだ。

それは、Unique が Common の対義語になってないということだろ。
Unique も複数のニュアンスがあるから、対義語になってる語を選べと言ってるだけ。
>>46 に有るかどうかは知らんけど。

51 ：デフォルトの名無しさん：2012/09/23(日) 14:23:14.08

＞　>>46 に有るかどうかは知らんけど。
あるかどうか知らんってどういうことだよ。
あるから反論してるんじゃないのか。

52 ：46：2012/09/23(日) 14:32:36.50

>>47
設計の善し悪しに関わることだからここで言ってはいけないのかも知れないが、

if (肯定形 == true) { }
if (肯定形 == false) { }
if (否定形 == true) { }
if (否定形 == false) { }

if (肯定形 != true) { }
if (肯定形 != false) { }
if (否定形 != true) { }
if (否定形 != false) { }

これらがソース中に混在していると、
後からソースを見たときに処理が追いにくくなったり、
うっかりミスによるバグが発生する可能性が高くなる。
（実際、自分や他人のコードのこの手のうっかりミスを数多く直してきた）

だから、2つくらいに絞ってそれ以外は使わないようにする方がいいのだが、
わたしはその中で [肯定形 == true] と [肯定形 == false] の組みを勧めているだけ。
＊＊は真だ、＊＊は偽だと言った方が命題がはっきりしてわかりやすいと思うから。

もちろん、別の理由で [肯定形 == true] と [否定形 == true] の組みの方が
もっとわかりやすいとして勧める人も大勢いるだろう。

53 ：デフォルトの名無しさん：2012/09/23(日) 14:45:55.43

>>52
VBerじゃないんだから
if (isNotUnique){}

これで十分。
何でboolの値と比較しなきゃならんのよ

54 ：デフォルトの名無しさん：2012/09/23(日) 14:47:34.34

>>51
>あるかどうか知らんってどういうことだよ。

>>45 が Unique をどういうニュアンスで使ってるかは >>45 にしかわからんだろ JK

君、ちょっと論理的思考能力が欠けてるんじゃね？

>>52
前から不思議なんだがなんで if(肯定形 == true) とか if(否定形 == false) とか、
書くんだろう…

普通に if(肯定形) とか if(!否定形) って書けばいいと思うのだが…

ましてや if(否定形 != false) なんてありえへん…

>>53
だよねぇ。

55 ：デフォルトの名無しさん：2012/09/23(日) 14:50:51.03

>>54
じゃあはっきり言ってやる。
そもそもuniqueにニュアンスがあるとも思えないが、百歩譲ってあるとして
しかしいずれにせよuniqueの対義語になる言葉なんか>>46の案に一つも存在しない。

あるというなら明示的に言ってみな。

56 ：46：2012/09/23(日) 15:00:46.36

>>55
> uniqueの対義語になる言葉なんか>>46の案に一つも存在しない。

どれも、いくつかの antonym dictionary で unique を調べた結果です。

57 ：46：2012/09/23(日) 15:06:19.71

>>55
もう少し具体的に言うと

たとえば unique を incomparable（無類の）というニュアンスで使っているのなら、
対義語として comparable が挙げられるのではないか、というように、
unique に込めたニュアンスによっていくつかリストアップしてみました。

58 ：デフォルトの名無しさん：2012/09/23(日) 15:06:32.14

>>55
> しかしいずれにせよuniqueの対義語になる言葉なんか>>46の案に一つも存在しない。

だったら君が案を提示してやればいいんじゃね？

59 ：デフォルトの名無しさん：2012/09/23(日) 15:16:19.94

>>57
プログラミングの文脈でそんな文学的表現が要求される場面があるんだろうか。
むしろないと断言してよいと思うが...

>>58
何が「だったら」か意味が分からない。

60 ：デフォルトの名無しさん：2012/09/23(日) 15:21:48.62

>>59
> 何が「だったら」か意味が分からない。

マジでわからないの？
日本語勉強した方がいいんじゃね？

61 ：デフォルトの名無しさん：2012/09/23(日) 15:25:22.22

>>60
馬鹿はこれだからな。
俺がuiqueの対義語が（他に）存在する、というのなら君の言い方（「だったら」）は成立する。

俺がいつそんなことを言ったんだ？
むしろそんなものはないと考えるから>>47のように書いている。

62 ：デフォルトの名無しさん：2012/09/23(日) 15:31:26.46

いろんな人が、それぞれの理由でそれぞれの案を提示する。
あとは >>45 が選ぶだけ。
>>45 が案について質問してきたら、それに答える。

それじゃいかんの？
なんで感情むき出しにして馬鹿とか言ってるの？

63 ：デフォルトの名無しさん：2012/09/23(日) 16:37:07.92

>>45
is already exists

64 ：デフォルトの名無しさん：2012/09/23(日) 17:08:09.92

>>61
Unique の対義語は存在しないというのか？

別にその意見は言ってもいいと思うが、違う意見もあるというだけだろ。
例えば: http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1334342848

もう少し、他の人と会話すること覚えた方がいいぞ。

65 ：デフォルトの名無しさん：2012/09/23(日) 17:29:07.69

>>64
他人と会話できない幼稚な馬鹿はどっちだ。
下らないことグダグダ言ってないで建設的なことを言え。
uniqueの対義語ってじゃあ何だよ。一つでいいから挙げてくれ。
もちろんuniqueの用法のうちプログラミングの世界で意味を持つもののそれでなければ
何の意味もない。

66 ：デフォルトの名無しさん：2012/09/23(日) 17:30:53.60

>>65
プログラミングの世界でuniqueはどのような意味を持つ？

67 ：デフォルトの名無しさん：2012/09/23(日) 17:34:17.72

しかし、馬鹿で幼稚で無礼なテメエを棚に挙げてどういう言い草なんだ

68 ：デフォルトの名無しさん：2012/09/23(日) 17:44:13.65

>>65
> uniqueの対義語ってじゃあ何だよ。一つでいいから挙げてくれ。

なに熱くなってるんだよ、ちゃんと挙げてるだろ。
例えば: http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1334342848

これをお前が対義語と認めるかどうかは知らんが、こういう意見もあるというだけのことだ。

69 ：デフォルトの名無しさん：2012/09/23(日) 17:54:15.86

馬鹿の話ってかならずループするよね。
「こういう話はある」とか逃げるんじゃないの。
他人に偉そうなことをいうのならお前の意見を言え。
それもないのに偉そうに人に突っかかってきたのか。

70 ：デフォルトの名無しさん：2012/09/23(日) 17:57:32.55

誰だよ変な煽りしたのはｗ

71 ：デフォルトの名無しさん：2012/09/23(日) 18:12:05.49

>>69
死ねゴミ

72 ：デフォルトの名無しさん：2012/09/23(日) 18:44:18.35

まぁ落ち着け

>>45のレス待とうや

73 ：デフォルトの名無しさん：2012/09/23(日) 18:58:33.08

ある程度の判断材料は得られたし
馬鹿同士が罵り合ってるのでトンズラ

74 ：デフォルトの名無しさん：2012/09/23(日) 19:04:08.19

知恵袋へ

75 ：デフォルトの名無しさん：2012/09/23(日) 20:43:07.97

>>69
べつに URL 先の意見と同じって言うだけのこと。
何いきり立ってるんだ？

>>70
「自称英語得意な俺が間違ってるわけねーだろ」君でしょ。
厨坊なら見込みあるけど、高坊以上ならちょっと痛いレベル。

76 ：デフォルトの名無しさん：2012/09/23(日) 20:47:45.53

非ユニーク？ハイどうぞっ IsNonunique
別にisNotUniqueでもいいんじゃね

77 ：デフォルトの名無しさん：2012/09/23(日) 21:06:49.86

CSで「unique」といったらほぼ用例が決まっていて「一意な」とか「重複のない」
といことはその反対は「一意でない」、「重複している」。はい答え出た

質問者の補足が無い以上、それ以外の稀な用例なんて考慮する必要ないと思うがね

78 ：デフォルトの名無しさん：2012/09/23(日) 21:18:15.63

もう、それでいいわ

これでこの話は終わりだろ
質問者が適当に選べばいい

79 ：デフォルトの名無しさん：2012/09/23(日) 21:26:19.91

相当悔しかったんだな。
誰とは言わないけど (w

80 ：デフォルトの名無しさん：2012/09/23(日) 22:55:52.43

あぁ　すげー悔しいぜ
こんな思いするくらいなら　もう二度と書き込まん

81 ：デフォルトの名無しさん：2012/09/23(日) 23:12:39.88

>>77
CSで「high」といったらほぼ用例が決まっていて「高い」
といことはその反対は「高くない」。はい答え出た

馬鹿すぎ。(w

82 ：デフォルトの名無しさん：2012/09/24(月) 00:19:31.97

ユニーク制限がないんだから、フリースタイル

83 ：デフォルトの名無しさん：2012/09/24(月) 03:58:29.52

>>81
馬鹿すぎ

84 ：デフォルトの名無しさん：2012/09/24(月) 07:57:04.32

==TRUE比較はやめろ

85 ：デフォルトの名無しさん：2012/09/24(月) 12:46:28.25

今回の質問やそれに対するレスとは直接関係無いから、
みんなに反論するわけじゃなくて、ただのおっさんの一意見として聞いてくれ。

bool isActive        = false;
bool isNonunique  = false;
bool isVisuable      = false;

という感じのコードを読んでると、私は一瞬「ん？」ってつまずく事が多い。

他にも、もしクラスに isNonunique というメンバ変数があって、
書き込みしか許さない場合、そのアクセサ関数はどういう名前で、
どういう内部処理にになるんだろとか、まぁいろいろ余計なことを考えてしまう。

86 ：デフォルトの名無しさん：2012/09/24(月) 13:19:58.63

自分も否定文の変数名が存在するとこんがらがるな
だから自分のコードではそれを徹底して排除している

if (a.isActive() && b.isSelected() && !c.isDisabled())
みたいな簡単な式でも、何だろうな、ワーキングメモリが多く削られる

87 ：デフォルトの名無しさん：2012/09/24(月) 20:07:59.22

俺はそれは全然ないね。

というより、否定神学じゃないけど、世の中否定形でしか語れないとか、
そこまでいかなくても否定形で語った方が簡潔な概念もあるんですよ。

例えば物質の三態でisSolidOrLiquidより、素直にisNotGasの方が普通の頭の人には分かりやすい。

88 ：デフォルトの名無しさん：2012/09/24(月) 20:26:47.23

visuable・・・ってvisibleの事？

89 ：デフォルトの名無しさん：2012/09/24(月) 20:38:04.44

>>88
そうだった
単なるミス、恥ずかしい・・・

90 ：デフォルトの名無しさん：2012/09/24(月) 20:40:25.29

IsNullOrEmpty

91 ：デフォルトの名無しさん：2012/09/24(月) 20:43:29.14

>>87
!isGas

92 ：デフォルトの名無しさん：2012/09/24(月) 20:51:22.66

>>87
いや、そういうのは別に良いんだよ。

どうしても否定形じゃないと語れないとか、
否定形の方がはるかにわかりやすいとか、そりゃあると思う。
そういうのは躊躇せず否定形使うよ。

ただ私はプログラミングソースの中では
「できるだけ避ける」「安易に否定形は使わない」だけのこと。
理由は >>85

93 ：デフォルトの名無しさん：2012/09/24(月) 20:53:16.07

否定文そのものじゃなくても、show(false) と hide(true) みたいな問題もあるよね。

94 ：デフォルトの名無しさん：2012/09/24(月) 20:55:02.11

isEnable
isDisable

95 ：デフォルトの名無しさん：2012/09/24(月) 21:01:00.76

>>87
勝手にお前が普通の人代表すんな

96 ：デフォルトの名無しさん：2012/09/25(火) 07:18:52.61

普通は不通

97 ：デフォルトの名無しさん：2012/09/25(火) 17:43:42.75

「うぃんどｗｓ」と打ってみよう

98 ：デフォルトの名無しさん：2012/09/25(火) 22:03:40.36

なに未だにTONさんが居座ってるの？
毎度質問者が居なくなってからオレオレ解釈で大暴れするんだよなぁ

99 ：デフォルトの名無しさん：2012/09/26(水) 06:29:00.12

class Attribute { ... }
class x {
　Attribute earth, wind, fire, water;
}

クラス x の名前を教えてください
ただの集約クラスなら AttributeSet か AttributeContainer
まとめて何かしらの処理を行うのであれば AttributeManager にしようかなと

100 ：デフォルトの名無しさん：2012/09/26(水) 07:12:55.76

>>99
Attribute と x それぞれの役割や意味が分からない。

> ただの集約クラスなら
> まとめて何かしらの処理を行うのであれば

Attribute と x との関係がはっきりしない。

これらのことが分からないと、名前が決められないと思う。

101 ：デフォルトの名無しさん：2012/09/26(水) 08:00:13.00

>>100
同意

102 ：デフォルトの名無しさん：2012/09/26(水) 08:01:41.12

聞かれた事だけに答えろカス

103 ：デフォルトの名無しさん：2012/09/26(水) 08:03:16.71

ちなみに四大要素はelementalだからElementalManagerな

104 ：デフォルトの名無しさん：2012/09/26(水) 08:04:51.97

>>99
マクスウェルに決まってるだろテイルズ的に考えて。

105 ：デフォルトの名無しさん：2012/09/26(水) 10:05:05.39

自分ならむしろ

class Attribute
{
　　AttributeItem earth, wind, fire, water;
}

…にするかなあ。
-Itemじゃなくても-Objとか-Entityとか。

106 ：デフォルトの名無しさん：2012/09/26(水) 11:22:14.85

痛い人が混じってる == true

107 ：デフォルトの名無しさん：2012/09/26(水) 12:41:20.78

>>102
「クラス x の名前を教えてください」という質問に対して、
それだけでは決められない、理由はこうだと、
ちゃんと訊かれたことだけに応えたつもりだ。

108 ：デフォルトの名無しさん：2012/09/26(水) 14:02:21.34

> Attribute と x それぞれの役割や意味が分からない。
Attribute : 何の変哲もない、1つのクラスです

1. > ただの集約クラスなら
2. > まとめて何かしらの処理を行うのであれば
xについて、この2つのばあいの共通点は「いくつかのAttributeクラスをまとめる」ということ
1のばあい、上記の例では4つ以外のメンバ変数は持ちません
2のばあい、制御用の何らかの変数を持ちます
例では4つの変数を持ちますが、3つでも10つでもかまいません
ゲームが新要素として新しい属性を追加するようなアップデートでも起こらない限り、数は変更されません
また、4つの変数を固定長の配列で扱わないのは、単に見やすくするためです

> Attribute と x との関係がはっきりしない。
わざとにごらせたつもりです
Attribute を Unit、x 内の4つのメンバを alpha, bravo, ..., zulu にして扱っても構いません

109 ：デフォルトの名無しさん：2012/09/26(水) 14:04:21.01

そういう時のためにFooやHogeがあるんだろうってのと
機械的に名付けたいなら最初からそう書いて欲しかった。

110 ：デフォルトの名無しさん：2012/09/26(水) 14:58:33.54

いつもならhogeを使っているけど、今回は具体的な名前を使ったほうが分かりやすいと判断しました

111 ：デフォルトの名無しさん：2012/09/26(水) 20:12:51.40

一つ確実にいえること。
「集約している」とか「何かしら処理を行う」とか、そんな機能の記述としては
抽象度の高すぎて何の意味も持たない情報をベースに名前を付ける奴は、馬鹿。

112 ：デフォルトの名無しさん：2012/09/26(水) 23:33:17.22

>>111
すみません。言っていることをうまく理解できませんでした

template <typename T, typename U>
class Hoge { T key, U value; }

template <typename T>
class Piyo { T x, y; }

template <typename T>
class Fuga { T x, y, z, w; }

class Hogera { Attribute earth, wind, fire, water; }

これらのクラスはそれぞれ何と命名しますか？

113 ：デフォルトの名無しさん：2012/09/26(水) 23:39:14.81

>>112
上から順に

KeyValuePair
文脈による
文脈による
文脈による

114 ：デフォルトの名無しさん：2012/09/26(水) 23:46:55.69

>>113
「文脈による」項目に関して、名前が決まる具体例をお願いします

ちなみに自分であれば、見た地点で
KeyValuePair
Pair
Vector2（利用可能性が位置情報だけとは限らないので、Point2やCoord2とは名づけない）
Vector4
AttributeSet
と名づけます

115 ：デフォルトの名無しさん：2012/09/26(水) 23:47:20.97

>>112
死ねカス

116 ：デフォルトの名無しさん：2012/09/26(水) 23:51:47.03

>>112
ハンガリアンみたいだね。
Hoge: KeyValue
Piyo: XY
Fuga: XYZW
Hogera: マクスウェル

>>114
> 「文脈による」項目に関して、名前が決まる具体例をお願いします
例えばpiyoに関して、
位置情報であれば Point { T x, y; }
二次元であることを強調したければPoint2D { T x, y; }
などさまざまなバリエーションがあります。

117 ：デフォルトの名無しさん：2012/09/27(木) 00:24:24.88

>>116
では「全ての属性をまとめたクラスであること強調したい」ばあいにおいての、Hogeraクラスの名前を教えてください

118 ：デフォルトの名無しさん：2012/09/27(木) 00:28:08.23

>>117
AllAtributes

119 ：デフォルトの名無しさん：2012/09/27(木) 00:30:02.15

確かにシステムハンガリアンと似たようなものかもしれません
List<Hoge> に HogeList と名づけるのと同じです

120 ：デフォルトの名無しさん：2012/09/27(木) 06:13:54.39

>>115
class Shinekasu
こうですか？分かりません＞＜

121 ：デフォルトの名無しさん：2012/09/27(木) 20:21:44.52

1つの関数の実装が長くなると読みづらいから分割…
1行に式を詰め込むと読みづらくなるから分割…

こういうのってやった方がいいと思うのですが、関数や変数の命名が難しくなってきます。
１つの処理を３つのパートに分けた場合の関数の名前とか、途中式の結果を受け取る変数の名前とか。
命名に何かコツはないのでしょうか？
皆さんはどうしていますか？

122 ：デフォルトの名無しさん：2012/09/27(木) 20:32:38.89

>>121
CやJavaなら処理を{ }で区切る。または無名関数を使う。
つまり一々命名しない。

123 ：デフォルトの名無しさん：2012/09/27(木) 21:17:27.73

>>122
確かに1箇所しか呼び出しがない関数はわざわざ名前をつける必要もないですね。
途中式を代入する変数については、xやnみたいに意味のない名前か長くてわかりにくい名前かのどちらかになりがちだけど、
これは仕方ないか…

124 ：デフォルトの名無しさん：2012/09/27(木) 21:25:10.13

>>121
1つの関数の実装が長くなると読みづらいからというきっかけと、
分割したという結果の間に、もう一段明確にすべきものがある。

「何に」分割するのか

その「何」を端的に表す名前を付ければいい。

逆に言えば、「何」を明確にするように分割する。
明確にできないような形に分割してはいけない。
（こちらは設計の善し悪しにも関わるから、これ以上言わない）

125 ：デフォルトの名無しさん：2012/09/27(木) 22:50:26.59

>>124
それが難しいです。
処理Aを１つの関数で命名するのは簡単としましょう。
しかし、処理Aが大まかに３つの処理によって成り立っていて、３つの関数に分割する事を考えた場合、ぴったりとした命名が難しくなる場合があります（やたら長くて説明くさい名前になったりとか）。

126 ：デフォルトの名無しさん：2012/09/27(木) 23:13:28.20

意味を保ったままあるいは視点を変えたりして短くできるならすればいいが
短くしようとすると他の動作をするものと誤解しやすくなるようであれば
長くて説明臭いものも受け入れないといけない
それはそれがぴったりという事

127 ：デフォルトの名無しさん：2012/09/27(木) 23:15:43.86

>>125
やたら長くて説明くさい名前になって困った時に、
その処理や意味を丁寧に説明し、
現時点の自分の名前案を提示してアドバイスをもらうのが、
このスレの趣旨だと思うのだが。

> 処理Aが大まかに３つの処理によって成り立っていて

大まかにというのが、どうもぼやけた感じで引っかかるな。
明確に３つの処理に分けられるのなら、
それぞれの処理の役割や戻り値の意味を明確に説明できるはず。
であれば、後はセンスとボキャブラリの問題で、
自分で解決できなければここで質問すればいいだけだ。

もしかして、やたら長くて説明くさい名前になるのは、
分けた処理の境界がぼやけてはっきり説明できないからという可能性はないか？
（はっきり説明できないなら、長くても分割するなというのが俺の持論）

>>121
> 命名に何かコツはないのでしょうか？

書籍「リーダブルコード」に命名のコツや考え方がいくつか紹介されている。

128 ：デフォルトの名無しさん：2012/09/27(木) 23:22:46.41

こういう事はいろんな意味で程度問題だし
スパッと解決する理屈なんかないしな。
俺もその都度ここで質問しろって思うわ。

129 ：デフォルトの名無しさん：2012/09/27(木) 23:57:03.56

なんにでも名前が割り当てられると思ってるやつは理想主義者
意味のある名前が付けられないようなコード片なんていくらでもあるだろ

130 ：デフォルトの名無しさん：2012/09/28(金) 00:12:53.17

>>126
WinAPIなどのライブラリを見ても長い名前のもたくさんあるし、長くなるのもあるのは仕方ないのかもしれません。
しかし、プライベート関数の名前が長くなるのはなんだかなぁと思ってしまいます。

>>127
処理の境界がぼやけているというより、処理の内容が限定的、局所的で、その場でしか通用しないような名前になりがちというか…
リーダブルコード、新しい本ですね。読んでみたいと思います。

>>128
一般的な解決方法なんてなくて、ケースバイケースで考えるしかないと言われれば、まぁそうなんですけど。

>>129
どうも細かいところに拘るところがあるのかもしれないです。
8割の出来でいいから早く進めた方がいいと思いつつもつい…

131 ：デフォルトの名無しさん：2012/09/28(金) 00:25:03.68

namespace MyModule {
namespace { namespace MyFuncLocal { // ry

void MyModule::MyFunc(...) {
using namespace MyFuncLocal;
Process1(...);
Process2(...);
Process3(...);
}

これで良いんだよクソッタレが
インターフェースだけ気にしたらあとはしょんべんしてもう寝ろ

132 ：デフォルトの名無しさん：2012/09/28(金) 00:27:52.13

再利用の価値があるからこそ気合入れてキラキラネーム付けてるんだってことを多くのコーダーは忘れがち
ちゃんとしたPGはどうでもいいところは適当に済ませる
徹頭徹尾はPGとしては絶対に持ってはいけない精神だからもっと適当に生きよう

133 ：デフォルトの名無しさん：2012/09/28(金) 01:00:32.59

preなんちゃら
doなんちゃら
postなんちゃら

134 ：デフォルトの名無しさん：2012/09/28(金) 01:25:16.15

>>130
結局抽象的なことしか言ってないから抽象的な答えしか返ってこない訳で。

もう既に同様のことを言ってる人が居るけど、もちろん意味付けのできる（つまり名前を与えられるような）
処理に分割することが第一選択なのは間違いないが、だからと言ってどんな場合でもそれが可能とも
言い切れないのも確か。

無理に命名に困るような関数に分割するより、関数内でコメントで大雑把に仕切った方が
ましということもあると思う。

135 ：デフォルトの名無しさん：2012/09/28(金) 08:13:38.32

関数名を適切に付けれるようになったら、プロ

136 ：デフォルトの名無しさん：2012/09/28(金) 12:52:36.04

>>135
・納期を守る
・他人と意思疎通を図る
・識別子に適切な名前を付ける

これはプロのプログラマとして最低限持っていないといけない能力

137 ：デフォルトの名無しさん：2012/09/28(金) 16:56:52.56

>・納期を守る
　さらに付け加えれば、残業をせずに納期を守れることが好ましい
　残業は仕事ができないものがすること

>・他人と意思疎通を図る
　なぜか偉そうだったり、ケンカ口調で話すプログラマは非常に多い

>・識別子に適切な名前を付ける
　そもそも文章力の足りない者が多い
　理解しやすい命名をし、理解しやすいコメントを書けるように心がけるべき

138 ：デフォルトの名無しさん：2012/09/28(金) 19:24:51.49

人にうまく説明するのが苦手や
来年度から社会人なのにこんなんでやっていけるのか不安

139 ：デフォルトの名無しさん：2012/09/28(金) 19:43:17.00

スレ違い

140 ：デフォルトの名無しさん：2012/09/28(金) 20:03:02.57

http://anago.2ch.net/test/read.cgi/bizplus/1347365451/l50
この発言聞いて、ここの影の所有者って馬鹿だと思った。
コミュニケーション能力なんて全ての社会人に求められる最小要件だと思うんだが...

141 ：デフォルトの名無しさん：2012/09/28(金) 20:14:40.02

スレ違い

142 ：デフォルトの名無しさん：2012/09/28(金) 20:48:01.41

さぞや素晴らしいコミュニケーション能力をお持ちなんでしょうなぁ

143 ：デフォルトの名無しさん：2012/09/28(金) 20:52:44.01

スレ違い

144 ：デフォルトの名無しさん：2012/09/28(金) 21:41:36.14

機械語でコミュニケーション

145 ：デフォルトの名無しさん：2012/09/28(金) 21:56:59.00

ややスレ違い

146 ：デフォルトの名無しさん：2012/09/28(金) 22:03:55.80

http://ideone.com/mBgiB
イベント関連の名前付けが長くなってダサい気がする
もっとシンプルで十分正しい意味を示せるのない？

147 ：デフォルトの名無しさん：2012/09/28(金) 22:16:51.81

イベント関連の命名は魔境だからな・・・

NotifyValueChanged() → ValueChanged()
AddHandlerOnValueChanged() → AddValueChangedHandler()（変更しなくてもいいや）
mValueChangedHandlers

イベントハンドラは "主語" + ("過去分詞" | "現在進行形")
複数形を使うのは識別子の最後の単語だけ

あ、俺の規則ね

148 ：デフォルトの名無しさん：2012/09/28(金) 22:22:52.41

>>146
> シンプルで十分正しい意味を示せる

何が正しいのか、こちらには分からないのだが。

ソースの読み手に対して、関数名からどのような情報を伝える必要があるの？
それをはっきりさせないと、名前を考えることはできないよ。

例えば AddHandlerOnValueChanged メンバ関数の方。
最初にこの名前を付けた理由は何？

「値が変更された時に通知されるイベントのハンドラを加える関数であることを
関数名から分かるようにする」

という要望が（必要が）あるから、このような名前を付けたの？

149 ：デフォルトの名無しさん：2012/09/28(金) 22:27:30.42

なんだこいつうっとおしいな

150 ：デフォルトの名無しさん：2012/09/28(金) 22:31:40.61

"主語" + x
x = "現在進行形" → やる前 itemInserting
x = "過去分詞" → やった後 itemInserted, mouseClicked
x = "名詞" → やった後 mouseUp
x = "動詞" → やった後 mouseClick

151 ：デフォルトの名無しさん：2012/09/28(金) 22:32:59.39

>>148
まず自分の手法を示せよ
>>137の二項目にあたる人種か？

152 ：デフォルトの名無しさん：2012/09/28(金) 22:36:44.40

>>151
どのような情報を読み手に伝える必要があるのか

先ずはこれをはっきり決めなければ識別子の名前は考えられない。

153 ：デフォルトの名無しさん：2012/09/28(金) 22:37:46.17

いるよね1から100まで教えないとなにもわからない子って
中学生みたいな反応で滑稽だよ

154 ：デフォルトの名無しさん：2012/09/28(金) 22:49:04.78

ウザがられているようなので、今回の件から私は降ります。
>>148 および >>152 は無視してください。

155 ：デフォルトの名無しさん：2012/09/28(金) 22:50:24.70

あぁ、NotifyValueChangedに付けてるNotifyはそういうことか
イベントハンドラにValueChangedを使いたいから、イベントを通知する側はNotifyValueChangedにしたんだな
俺は通知する側のメソッドをOnValueChangedにするだろうけど、これって合ってるのかな

156 ：デフォルトの名無しさん：2012/09/28(金) 23:09:59.13

>>155
される側じゃなくて？

157 ：デフォルトの名無しさん：2012/09/28(金) 23:21:41.05

例えばAddHandlerOnValueChangedなんていうまどろっこしい名前が必要になるのは、
イベントが抽象化されてないからだと思う。

たぶん一般的なやり方じゃないと思うけど、Androidをちょっとかじったときには
イベントリスナを集約&イベントを通知する機能をEvent<T>みたいなクラスに分けて、
そのイベントを持つクラスは、

Event<EventArgs> ValueChangedEvent(){return mValueChangedEvent;}

みたいにその値を公開するようにした。
こうすれば、リスナを登録するのは、

hoge.ValueChangedEvent().Add(valueChangedHandler);

みたいに多少は簡潔になる。
いや長さはあんまり短くなってないが（笑）多少は可読性が上がってる（当社比）と思う。

158 ：デフォルトの名無しさん：2012/09/28(金) 23:43:51.25

>>156
Onを付けるのは通知される側なのかな。よく分からん

>>157
ほう・・・というか鬼なった
やっぱりメソッドチェインが最強かー

159 ：デフォルトの名無しさん：2012/09/29(土) 00:09:29.76

>>157
可読性は落ちたが、役に立ちそうな話だった

160 ：デフォルトの名無しさん：2012/09/29(土) 00:12:56.12

obj.OnValueChanged.Add(...);
obj.OnValueChanged().Add(...);
下はなんか気持ち悪くて許せない俺の心は狭いのか

161 ：157：2012/09/29(土) 00:14:09.95

ちょっとミスった。
イベントのオブジェクトを外部に公開するときには、当然適当なインターフェイスを
被せるべきだ。

外からイベント発火できるのは普通はマズいもんねw

162 ：デフォルトの名無しさん：2012/09/29(土) 00:17:14.91

>>160
readonlyのメンバ変数が作れれば()無くせるけど、C++にもあるんだっけ？

163 ：デフォルトの名無しさん：2012/09/29(土) 00:39:20.50

っていうか、C++なんだからポインタか参照を返さなきゃダメかw
C++よーわからんのでごめん

164 ：デフォルトの名無しさん：2012/09/29(土) 00:51:26.40

>>157
Event<EventArgs>をもっと別の名前にしたくなるのは俺だけだろうか
EventSenderとかEventMulticaster的な

そして非const参照を返す関数はAccess～()とう俺ルールがあって
あぁ、Add()はハンドラーを追加する関数だからAddHandler()にして

結果
hoge.AccessValueChangedMulticaster()->AddHandler(valueChangedHandler); ＼なげえ／

165 ：デフォルトの名無しさん：2012/09/30(日) 14:55:17.87

位置情報とか状態とかを格納する
クラスの親クラスの名前で良いのありませんかね?

166 ：デフォルトの名無しさん：2012/09/30(日) 14:58:29.33

Conteiner

167 ：デフォルトの名無しさん：2012/09/30(日) 15:00:13.92

>>167
ありがとうございます

168 ：デフォルトの名無しさん：2012/09/30(日) 16:28:41.12

container

169 ：デフォルトの名無しさん：2012/09/30(日) 16:32:08.50

>>165
State
Position
Condition
Location
Form
Body
Face

170 ：デフォルトの名無しさん：2012/09/30(日) 16:36:41.81

エスパーじみてるな

171 ：デフォルトの名無しさん：2012/09/30(日) 17:05:31.91

クラスの名前聞いてるのに「とか」って言われてもね...
うまい名前を付けられないのは、そういう名前が付けられないようないい加減な設計を
しているからだってどうして気が付かないんだろう。

172 ：デフォルトの名無しさん：2012/09/30(日) 17:33:26.04

設計の善し悪しは言うなよ

173 ：デフォルトの名無しさん：2012/09/30(日) 17:47:48.35

目的が間違ってるのに、間違った目的を不問に付して手段を考えろという奴は、馬鹿。

174 ：デフォルトの名無しさん：2012/09/30(日) 17:53:46.63

そういう趣旨のスレなんだから我慢しろ

175 ：デフォルトの名無しさん：2012/09/30(日) 17:59:17.74

>>174
じゃあ君は意味不明な機能のクラスの名前を要求する質問者にも「我慢して」
答えを与えるように。
偉そうに人に命令するんだから必ずやれよ。

というか、そもそも設計の話なんかしてない。
うまく名前が付けれらないのは付けられるような設計になってないからだと言っただけだ。

名前が付けられない理由の説明まで禁止する合理的な理由があるなら言ってみろ。

176 ：デフォルトの名無しさん：2012/09/30(日) 18:06:23.47

またウザイ奴が居ついちゃったな…

177 ：デフォルトの名無しさん：2012/09/30(日) 18:34:31.20

>>175
意味不明な機能のクラスの名前を要求する質問には「応えない」ようにしている

178 ：デフォルトの名無しさん：2012/09/30(日) 23:32:46.89

>>175
1よめぼけ

179 ：デフォルトの名無しさん：2012/10/01(月) 00:50:28.43

>>165
位置情報とか状態とかを格納するクラス
をHogeとしたばあい

位置情報とか状態とかを格納するクラスの親クラスの名前
はHogeBase

親クラスがインターフェイスであればIHoge
抽象クラスであればAHoge

180 ：デフォルトの名無しさん：2012/10/01(月) 08:00:16.90

IHogeの一種がAHogeなのに？

181 ：デフォルトの名無しさん：2012/10/01(月) 11:09:10.12

>>180
それはどこで教わったんだ？

182 ：デフォルトの名無しさん：2012/10/01(月) 11:53:08.55

>>180
抽象クラスの一種がインターフェイスだぞ
作成できないクラスが抽象クラス
C++でいうところの純粋仮想関数しか持つことができないのがインターフェイス

ただ、インターフェイスに関しては言語によって解釈が違う
抽象クラスみたいな扱いの言語もある

183 ：デフォルトの名無しさん：2012/10/01(月) 13:54:10.86

昔からよくある2DのRPGのフィールド(画像を将棋盤のように縦横並べたやつ)の事をなんと言いますか？

184 ：デフォルトの名無しさん：2012/10/01(月) 14:28:56.87

>>183
フィールドでいいじゃん？

185 ：デフォルトの名無しさん：2012/10/01(月) 14:32:08.41

>>183
フィールドだと意味が広いかなと思って・・・
画像を並べて作られたアレって典型的だから、何か用語がないかなと思いました。

186 ：デフォルトの名無しさん：2012/10/01(月) 14:42:21.73

grid, square, borad なんかは見た

187 ：デフォルトの名無しさん：2012/10/01(月) 15:18:49.84

>>186
うーん、やはり意味の広い名前しかないかなぁ。
fieldにします。どうもでした。

188 ：デフォルトの名無しさん：2012/10/01(月) 15:36:02.51

>>187
なら、アウトフィールド、ウィルダネスフィールド、バトルフィールドみたいにすれば
意味を多少狭く出来るんじゃない？

189 ：デフォルトの名無しさん：2012/10/01(月) 23:48:10.21

GameBoardをお勧めする

190 ：デフォルトの名無しさん：2012/10/01(月) 23:52:05.65

http://ideone.com/JqEqq
IXの名前はどうするとクール？

191 ：デフォルトの名無しさん：2012/10/02(火) 00:13:16.64

IEventじゃダメなんですか？

192 ：デフォルトの名無しさん：2012/10/02(火) 00:25:43.23

>>191
それだとFireも含まれててほしいイメージになります
Addに限定したインターフェースなのでそれはちょっとしがうかなと・・・

193 ：デフォルトの名無しさん：2012/10/02(火) 00:30:30.39

>>192
そんなこと無いのでは？
.NETのEventだって外部からはハンドラの登録しかできないよ。

194 ：デフォルトの名無しさん：2012/10/02(火) 01:23:57.20

EventMulticasterにしよう（提案）

195 ：デフォルトの名無しさん：2012/10/02(火) 02:12:35.80

>>190
重いけど、このＵＲＬ何

196 ：デフォルトの名無しさん：2012/10/02(火) 19:28:28.16

まだイデオンしらない人いるんだ

197 ：デフォルトの名無しさん：2012/10/02(火) 19:53:47.34

ガンダムの脇役機体を主役にしたスピンオフ作品なんだよね

198 ：デフォルトの名無しさん：2012/10/05(金) 18:06:14.34

ゲームで
・同じ種類のキャラクタならば共通で変化しないステータス
・固体ごとに変化するステータス
の名前は？

例として
struct ???Status {
std::string typeName;
int maxHP;
};

struct ???Status {
std::string name;
int currentHP;
};

199 ：デフォルトの名無しさん：2012/10/05(金) 19:02:02.26

>>198
同じ種類のキャラクタならば共通で変化しないステータス
CommonStatus
StaticStatus
GlobalStatus
PublicStatus

固体ごとに変化するステータス
IndividualStatus
VariableStatus
LocalStatus
PersonalStatus

まぁ、どれもイマイチな気がするが、これくらいしか思い浮かばん

200 ：デフォルトの名無しさん：2012/10/05(金) 19:35:21.69

>>198
種類の名前と個体の名前をそのままクラス名にします。

201 ：デフォルトの名無しさん：2012/10/05(金) 19:47:57.94

>>198
固体ごとに変化するステータスというのは、

・固体ごとにステータスのパラメータの値が変化する
・固体ごとにステータスの（パラメータの）種類が異なる

どっち？

202 ：デフォルトの名無しさん：2012/10/05(金) 20:17:14.05

>>198
特に理由がないならxxxStatusなんていう型を別途用意するのがそもそも間違い。
入れ子にせず、パラメータはキャラクターのクラスそのもののメンバーにする。

共通の値は静的メンバーで実装。
個体ごとの値はインスタンスメンバーで実装。

203 ：デフォルトの名無しさん：2012/10/05(金) 21:16:44.77

静的は無いわ

204 ：デフォルトの名無しさん：2012/10/06(土) 04:07:06.95

変化するしないのクラス名での表明は薄くなってしまうけど、
単純に所有元を、キャラクタ種類・キャラクタ(個体)に分けて、
CharacterTypeStatus
CharacterStatus
ではどうか。
んでstructじゃなくclass化。
これによりSetterを持つか否かで変化するしないを表明する。

まあどうしてもクラス名で強く表明したければ、
CharacterTypeStatusにBaseとかの単語を混ぜるといいんでない？
どこに挿入すべきかは英語詳しくないから分からんｗ

205 ：デフォルトの名無しさん：2012/10/06(土) 04:21:14.44

考えてて思ったんだけど、プログラミングでの命名時に
連語?って区切りを伝えるの難しくない？
例えば
CharacterType Status
キャラクタ種類　のステータス情報
Character TypeStatus
キャラクタ　の種類ステータス
のどっちにも取れない？
こういう場合って結構読み手の一般的推測に基いて判断されてる気がする。
英語の解釈的にはどちらの意味が優先されるとかあるものなの？
アンダースコアで区切れば良いかもしれないけど、
Javaとかではそんな不恰好な命名はされてないし‥。

206 ：デフォルトの名無しさん：2012/10/06(土) 04:24:49.46

自己レスすまん。
内部クラスで区切りを表すという方法があったわ。
でも内部クラスを使うまでもない、名前だけでのうまい区切り方法があったら教えて欲しいな。

207 ：デフォルトの名無しさん：2012/10/06(土) 08:09:19.34

かっこよくきめたいのなら連語やめてCharacterみたく一語にしたらいい。

208 ：デフォルトの名無しさん：2012/10/06(土) 08:54:50.06

単語の最後も大文字にする
CharacheRTypeStatuS -> character typestatus
CharacterTypEStatuS -> charactertype status

209 ：デフォルトの名無しさん：2012/10/06(土) 09:40:19.03

>>198
その例だと AbilityStatus / CapacityStatus と CurrentStatus かなぁ。
そもそも、Status とはちょっと違う気がする…

>>205
普通に StatusForCharacterType とか TypeStatusOfCharacter とかでいいんじゃね。

210 ：デフォルトの名無しさん：2012/10/06(土) 11:53:36.69

>>208
こいつとは仕事したくないな

211 ：デフォルトの名無しさん：2012/10/06(土) 11:54:44.55

>>210
じゃあアンスコ以外にほかにいい方法でもあんの？

212 ：デフォルトの名無しさん：2012/10/06(土) 12:01:20.15

>>205
コメントで余裕

213 ：デフォルトの名無しさん：2012/10/06(土) 14:46:04.14

前も書いたけど、アホなプログラマって何で前置詞や接続詞を使わないんだろうね。
205とか208みたいな意味不明な方向違いの努力をする。

使ったらカッコ悪いとでも思ってるんだろうか。
中学生か。

214 ：デフォルトの名無しさん：2012/10/06(土) 14:49:39.44

>>312
今回の件で使った例を挙げてくれ

215 ：デフォルトの名無しさん：2012/10/06(土) 14:51:33.43

>>213 だったw

216 ：デフォルトの名無しさん：2012/10/06(土) 15:28:04.25

前置詞とか接続詞とかダサいわ
「ヒカルの碁」とか名前最悪にだっさいやろ
でも「ドラゴンボール」はかっこいいスマート
これが「ドラゴンのボール」とかなってたら１巻打ち切り確定
その辺の美的センスっていうのPGにも持ってもらいたいんだよね

217 ：デフォルトの名無しさん：2012/10/06(土) 15:43:27.59

>>216
2語以上繋いだ名前も十分ダサい

ドラゴンボールとか、あずまんが大王とか

1語でズバッという名前は最高
HOLiCとか、ちょびっツとか

その辺の美的センスっていうのPGにも持ってもらいたいもんだ

218 ：デフォルトの名無しさん：2012/10/06(土) 15:47:43.54

「ワンピース」はダサすぎてやばいからその法則は信用できないな

219 ：デフォルトの名無しさん：2012/10/06(土) 16:04:42.99

ワンピースの最終回は
世界は一つのピースとか言うと予想

220 ：デフォルトの名無しさん：2012/10/06(土) 16:05:18.35

英語で　なんとか of なんとか
とかかっこいいとおもう

221 ：デフォルトの名無しさん：2012/10/06(土) 16:12:44.43

TheLordOfTheRingsとかだっせぇわ
Avengersのほうがかっこいいっしょ

222 ：デフォルトの名無しさん：2012/10/06(土) 16:16:09.64

>>218
ワンピースは「ワン」「ピース」で2語だタコ

223 ：デフォルトの名無しさん：2012/10/06(土) 16:17:19.78

>>222
は？

224 ：デフォルトの名無しさん：2012/10/06(土) 16:28:32.48

は？じゃない

そうなの

225 ：デフォルトの名無しさん：2012/10/06(土) 16:38:52.87

作中で一回でもそう明言されたか？
「ワンピース」っていう固有名詞でないとなぜ言い切れる？

226 ：デフォルトの名無しさん：2012/10/06(土) 16:47:33.49

もういいからその話は

227 ：デフォルトの名無しさん：2012/10/06(土) 16:50:16.20

>>225
http://www.j-onepiece.com/

ここの表記が「ONEPIECE」ではなく「ONE PIECE」になってるから2語

228 ：デフォルトの名無しさん：2012/10/06(土) 16:59:12.89

キモヲタ王に、俺はなる！まで読んだ。

229 ：デフォルトの名無しさん：2012/10/06(土) 17:09:44.40

売り上げで語れよ

230 ：デフォルトの名無しさん：2012/10/06(土) 17:29:04.45

日本語の接続詞も英語の接続詞（この話ではof）も似たようなものなのだよ・・・
だがソースコードに関してはXxxxYyyyZzzz→XxxxのYyyyのZzzzと確実に解釈される。ofは使われていない
更に装飾詞だっけ？XxxxYyyyFinallyやXxxxYyyy(that)Zzzzといった命名も嫌われる

231 ：デフォルトの名無しさん：2012/10/06(土) 17:33:10.08

>>228
かっこいいなｗ志が

232 ：デフォルトの名無しさん：2012/10/06(土) 17:34:03.64

英語圏のソースはどうなってんの？

233 ：デフォルトの名無しさん：2012/10/06(土) 17:37:42.42

>>232
自分でソースを読んでこればいいだろ

オープンソースなんて腐るほどある

234 ：デフォルトの名無しさん：2012/10/06(土) 17:46:28.65

>>233
で、お前の主張どおりなのか？

235 ：デフォルトの名無しさん：2012/10/06(土) 17:51:41.75

>>234
言ってる意味が分からん
俺は「自分でソースを読んでこればいいだろ」と言っただけだが

もしかして、「オープンソースなんて腐るほどある」
という主張が正しいかどうかを訊いてるのか？
それは俺の主観だから正しいもなにもないと思う

236 ：デフォルトの名無しさん：2012/10/06(土) 21:53:24.96

typedef std::shared_ptr<std::list<std::shared_ptr<Hoge>>> HogeShPtrListShPtr;

237 ：デフォルトの名無しさん：2012/10/06(土) 22:29:01.86

>>235
冷たい奴だな

238 ：デフォルトの名無しさん：2012/10/07(日) 00:52:55.87

キャメルケースとスネークケースが混じったコードに殺意を覚えた

239 ：デフォルトの名無しさん：2012/10/07(日) 08:03:03.02

え、まぜちゃダメなの？

240 ：デフォルトの名無しさん：2012/10/07(日) 09:06:23.34

混ぜていいよ

241 ：デフォルトの名無しさん：2012/10/07(日) 09:35:51.78

俺も混ぜていいと思う。
普通のプログラマなら普通に読めるだろ。

ただ、使い方はひとつのプロジェクトで統一して欲しいな。
キャメルケースを主で使って、補助としてスネークケースを使うとか。
for を表すときにアンダーバーを使うとか。

242 ：デフォルトの名無しさん：2012/10/07(日) 09:49:57.41

クラス分けすりゃいいんだけど、そこまでしなくてもいいかなあって時に使ってるなあ

243 ：デフォルトの名無しさん：2012/10/07(日) 09:51:00.06

プロジェクト単位でコーディングルール強制とか逆に効率わるいっしょ
インターフェースとかだけきっちりしてれば中身はクラス単位とかファイル単位で統一してくれれば十分だよ

244 ：デフォルトの名無しさん：2012/10/07(日) 21:46:51.19

238「windowsプログラミングでboost使ってるコードに殺意を覚える」

245 ：デフォルトの名無しさん：2012/10/07(日) 22:13:30.85

たまに使うよ、shared_ptr とか

246 ：デフォルトの名無しさん：2012/10/07(日) 22:31:30.97

>>244
どうして？

247 ：デフォルトの名無しさん：2012/10/07(日) 22:54:05.71

>>246
知らない。無用に潔癖症なんじゃないの？

248 ：デフォルトの名無しさん：2012/10/07(日) 23:22:58.28

>>208
キモ過ぎワロタ

249 ：205：2012/10/08(月) 01:50:40.07

色々情報くれてありがとう。

>>207
一語に出来る情報なんてそうそうないでしょｗ

>>208
きめえｗｗと思ったけどそれでもう一つ方法を思い出したよ。
強調したい連語単位で頭大文字化するやつ。例:CharactertypeStatus
有名オープンソースな何かで見た覚えがある。
まあでも可読性はアンダースコアのほうが良いよね‥。

>>209,213
確かに普通に接続詞を使うのも悪くない方法かと思うのだけど、

>>230
の書いてくれたように、ofとかあまり使わない印象があったんだよね。
そのきちんとした理由があれば使わないようにしてようと思ったけど、無いようなら使っちゃおうかな。

250 ：デフォルトの名無しさん：2012/10/08(月) 07:49:59.87

>>249
> ofとかあまり使わない印象

識別子は短いに越したことないから、省略しても問題ないなら省略することが
多いだろうけど、>>205 みたいなケースだと使った方がわかりやすいと思う。

CharacterTypEStatuS なんて言うのは個人でやるならいいけど、他の人には
逆にわかりづらいと思う。
まだ、キャメルとスネーク混在の方が間違った解釈されないだけマシ。

251 ：デフォルトの名無しさん：2012/10/08(月) 09:28:55.88

>>250
別の単語になっちゃう可能性もあるしな

252 ：デフォルトの名無しさん：2012/10/08(月) 14:13:15.88

getShare_ptrとかもOK?

253 ：デフォルトの名無しさん：2012/10/08(月) 16:28:33.58

>>252
個人的には無いかなー。
ただ、アクセサ等の命名は、既存の変数名に即したものにするべきという考え方も理解は出来る。

254 ：デフォルトの名無しさん：2012/10/11(木) 19:09:32.65

1次元の配列を2次元の配列に変換するクラスの名前
どんな名前にしようか悩んでる

255 ：デフォルトの名無しさん：2012/10/11(木) 21:16:05.77

シンプルに arrrayTo2D とかは？

256 ：デフォルトの名無しさん：2012/10/11(木) 21:26:23.44

gridFromVector

257 ：デフォルトの名無しさん：2012/10/11(木) 21:56:02.95

変換する目的とか方法は何？

258 ：デフォルトの名無しさん：2012/10/11(木) 21:56:24.72

>>254
split

259 ：デフォルトの名無しさん：2012/10/11(木) 23:03:38.19

「悩んでる」と言っているだけで誰も質問してない件。
そもそも機能の説明が曖昧すぎる。
まあ、

- 一次元配列を二次元配列に変換するというより、二次元配列をストリームとみなして
　それを初期化するイメージ

- row、columnの数と縦横それぞれのスキャン方向はコンストラクタで指定（変更不可）

こんな感じだと仮定してMatrixBuilderとか

260 ：デフォルトの名無しさん：2012/10/11(木) 23:14:57.85

>>259
> 「悩んでる」と言っているだけで誰も質問してない件。

それがどうした？　としか言いようがない

261 ：デフォルトの名無しさん：2012/10/11(木) 23:22:39.81

それがどうした。
っていうか馬鹿だろお前。

262 ：デフォルトの名無しさん：2012/10/13(土) 09:43:01.46

CPPであるインターフェイス(IHogeとする)を継承して、すべての仮装関数を「サポートされてない」という例外を投げる関数でオーバーライドした共通の基本クラスの名前は？

struct IHoge {
virtual void VMethod() = 0;
virtual void VMemFunc() = 0;
};

struct ? : IHoge {
void VMethod() { throw NotSupportedException(); }
void VMemFunc() { throw NotSupportedException(); }
};

struct SomeHoge : ? {
// ry

263 ：デフォルトの名無しさん：2012/10/13(土) 09:49:10.69

「基本クラス」でいいじゃん

264 ：デフォルトの名無しさん：2012/10/13(土) 11:02:52.47

>>262
IHogeNotSuppoerted

265 ：デフォルトの名無しさん：2012/10/13(土) 11:03:31.72

つづり間違えた。　IHogeNotSupported

266 ：デフォルトの名無しさん：2012/10/13(土) 11:52:28.56

ErrorHoge / InvalidHoge

267 ：デフォルトの名無しさん：2012/10/13(土) 13:35:15.15

>>263で終了だな。

268 ：デフォルトの名無しさん：2012/10/13(土) 15:12:56.56

基本クラスで良いに同意。
敢えて書けば、Java風にAbstructHoge。
そして各メソッドコメントに「デフォルト実装では、NotSupported例外を送出します。」を入れる。
派生クラスは基本クラスとis関係である、と自然に捉えられるか、を考えればこうなると思う。
最初はUnimplementedHogeって答えようと思ったけど、こいつを実装のある派生クラスが継承しているのは何か微妙に感じるでしょう？

269 ：デフォルトの名無しさん：2012/10/15(月) 17:18:25.80

>>264
実装するのだからインターフェイスではない。よって頭文字Iは却下
AbstractHoge（AHoge）やHogeBaseといった命名で茶を濁すのが一番
俺ならEmptyHogeかな

270 ：デフォルトの名無しさん：2012/10/15(月) 22:51:00.06

ゲームでアイテムやキャラクターをあらわすクラスってどう名前付けるべきか
たとえばポーション（体力回復薬）だったらゲーム仕様にあわせてそのまま「ポーション」で行くべきか
あるいは機能を明示的に示すように「体力回復薬」とするべきか
あ、もちろんコード上では英語です

271 ：デフォルトの名無しさん：2012/10/15(月) 23:03:59.05

ゲーム中での名称が一般名でなければコードでは一般名を使う
一般名として充分通じるならそのまま
体力回復以外のポーションもあるならポーションは使わない

272 ：デフォルトの名無しさん：2012/10/15(月) 23:07:54.80

「無敵」フラグが isStar だったりとか？

273 ：デフォルトの名無しさん：2012/10/17(水) 18:40:05.50

そもそも「potion」は一服の飲み薬のことだぞ
俺なら飲み物全般を「Drink」としてインターフェイス化する

274 ：デフォルトの名無しさん：2012/10/17(水) 21:52:26.04

ゲームに出てくる読み物って、大抵「薬」のような気もするけどもｗ

275 ：デフォルトの名無しさん：2012/10/18(木) 00:59:26.07

全てitemクラスの派生

276 ：デフォルトの名無しさん：2012/10/18(木) 02:20:21.58

汚水とかゲロゲロが飲料扱いのゲームもあるんですよ？

277 ：デフォルトの名無しさん：2012/10/20(土) 18:43:03.42

テーブル内の金額を合計するメソッドの名前いいの無いかな

278 ：デフォルトの名無しさん：2012/10/20(土) 18:52:06.99

流石に辞書引けよそれは。
それもできない低能なら同情するが

279 ：デフォルトの名無しさん：2012/10/20(土) 19:00:26.62

すみませんが詳しい方のみ回答をお願いします

280 ：デフォルトの名無しさん：2012/10/20(土) 19:15:07.34

>>279
俺はお前と違って辞書の使い方を知ってるから、むちゃくちゃ詳しいぞ
教えてやる

[英辞郎より]
合計する　／　cach up、count up、sum up、<<他動>> aggregate、count <<自他動詞>> summate

他の単語もあったが、まぁこの辺りから適当に選んでおけばいいだろ

281 ：デフォルトの名無しさん：2012/10/20(土) 20:06:21.11

>>277
sum

282 ：デフォルトの名無しさん：2012/10/22(月) 16:01:16.02

tally up

283 ：デフォルトの名無しさん：2012/10/23(火) 18:02:36.02

ラジアンの角度を表す実数を0以上2π未満の同じ位相の値にする関数
同様に-π以上π未満の同じ位相の値にする関数の名前は？

284 ：デフォルトの名無しさん：2012/10/23(火) 19:07:56.44

どちらも normalize

引数に渡すフラグや列挙子、数値などで範囲を指定

285 ：デフォルトの名無しさん：2012/10/23(火) 22:05:37.15

public static bool メソッド名<T>(this T target, params T[] prms)
{
　return prms != null && Array.IndexOf(prms, target) != -1;
}

何かいいメソッド名ある？
Inだと短すぎてやだ

286 ：デフォルトの名無しさん：2012/10/23(火) 22:13:02.02

exists
containts
has

287 ：デフォルトの名無しさん：2012/10/23(火) 22:21:08.43

それだと逆？なんだよ
使い方は、hoge.メソッド名(a, b, c) だから

288 ：デフォルトの名無しさん：2012/10/23(火) 22:25:09.48

notExists

289 ：デフォルトの名無しさん：2012/10/23(火) 22:31:39.71

その逆じゃないよ
Array.Contains()とかDictionary.Exists()みたいなのがあるから主語と述語が逆っつーか…

290 ：デフォルトの名無しさん：2012/10/23(火) 22:35:31.08

isContained

291 ：デフォルトの名無しさん：2012/10/23(火) 22:44:40.02

サンクス
IsContainedIn か ContainedIn にするわ

292 ：デフォルトの名無しさん：2012/10/23(火) 23:57:00.23

IsElementOf

293 ：デフォルトの名無しさん：2012/10/24(水) 08:49:33.74

find

294 ：デフォルトの名無しさん：2012/10/25(木) 02:15:36.97

existsIn

295 ：デフォルトの名無しさん：2012/10/31(水) 18:15:57.52

いずれか必須と言うかチェックをする関数名ぷりーず！

296 ：デフォルトの名無しさん：2012/10/31(水) 18:16:31.85

いずれか必須と言うチェック
でした

297 ：デフォルトの名無しさん：2012/10/31(水) 19:56:07.22

仕様にもよるが
　Or
　In
　Contains
あたりはどうか

298 ：デフォルトの名無しさん：2012/10/31(水) 19:58:01.21

validateRadioButton

299 ：デフォルトの名無しさん：2012/10/31(水) 19:58:07.04

テキスト1から3で一個は入れてくれって感じなんです

300 ：デフォルトの名無しさん：2012/10/31(水) 20:22:27.78

>>299
だから、毎度毎度言ってるように処理の意味を書こうよ。
そのプログラムでは「テキスト1から3で一個は入れてくれ」ることがどういう意味を持つんだ？

「3つのうちいずれかが～かどうかチェック」ってそんな具体的な処理内容から
普通は名前付けないって。

301 ：デフォルトの名無しさん：2012/10/31(水) 20:27:40.95

>>300
すまぬ
検索条件にテキスト1から3ませあって
検索前にいずれか必須のチェックをしたい
その関数名です、こんな感じで大丈夫でしょうか

302 ：デフォルトの名無しさん：2012/10/31(水) 20:28:06.48

>>299
validate
check
oneOrMore

303 ：デフォルトの名無しさん：2012/10/31(水) 20:31:58.12

requiredOneOrMore

304 ：デフォルトの名無しさん：2012/10/31(水) 20:36:51.62

>>302-303
ありがとう！
validateCheckかrequiredOneOrMoreにさせて頂きます

305 ：デフォルトの名無しさん：2012/11/01(木) 10:07:35.14

いやいやいや、何でvalidateとcheckを一緒にするんだよ
.validate()か.isValid()でいいだろ

306 ：デフォルトの名無しさん：2012/11/01(木) 10:12:38.82

validateとcheckって両方使うとしたらどう使い分ける?
validate(年齢).check(x => x < 30)
みたいな感じ?

307 ：デフォルトの名無しさん：2012/11/01(木) 14:36:29.11

英語とかさっぱりだから、ネイティブがどう思うかは分からんけど
自分なら……うーん。

validate：
正しい値かどうかを調べる。例えば、酒・タバコは20歳以上じゃないと購入できないなど。
正しい/正しくないという文脈が存在しないときには使わない。

正しくない場合は、それを呼び出し元に返したり、整合性フラグをfalseにしたりする。
基本的に値の修正はしない。したい場合はcorrect()などと組み合わせる。

check：
与えられたデータに対して、何らかのフラグを返したり、そのフラグをデータに書き込む。
確認済み、生成済みなど。

何らかの条件が付随する場合は、CheckFoo()やCheckIfBar()という名前にする。

308 ：デフォルトの名無しさん：2012/11/01(木) 19:34:42.10

>>306
check the validity of ～ = validate ～

309 ：俺的イメージ：2012/11/03(土) 01:44:26.82

validate = 正しいことを確認する。正しくて当たり前、正しくなかったらそりゃ大変。assertに近い
check = 単に何らかの確認をする。正誤とは限らない

310 ：デフォルトの名無しさん：2012/11/03(土) 02:00:36.00

ついでに聞くけどJavaとか.Netのvalidateメソッドの動作と名前が
意味的にどう結びついてるのかよくわからないんだが

311 ：デフォルトの名無しさん：2012/11/03(土) 06:10:15.27

assert = 力説する
　ブレーク判定専用句と化した先輩

check = 検査する
　プログラミングにおいて使い道が乏しい句
　if (obj.Check()) → objを検査しているようだが、どういう状況にあることを調査しているかわからない
　if (obj.Validate()) → objのParamが有効な状態にあることを確認する

validate = ものが正しい状態にあることを確認する。またはものを有効化する。
obj.Validate() 有効であるかどうかを示す。（有効化するかどうかは不明）
obj.IsValid() 有効であるかどうかを示す。本当に調べるだけであればこちらを推奨する

verify = 過程（プログラミングでいえばソースコード）が正しいことを確認する。
assertと同様に、ブレーク判定に使われる歴史があるので、それ以外での使用は推奨できない

312 ：デフォルトの名無しさん：2012/11/03(土) 06:16:40.98

つまり、obj.check～()とかobj.Verify()はほぼありえないと考えていい
obj.Assert～()はありえる
obj がインタプリタ言語のコードを示す変数だったら、obj.Verify()はありえ・・・やっぱりisValid()でいいや
但し、CDの焼きこみが正しく行われたことを確認することはVerifyという。これは例外

313 ：デフォルトの名無しさん：2012/11/03(土) 07:29:45.45

何か動作をしたあとにそれがすべて正しく行われたかがverify
今の状態が正しいかがis valid
今の状態が正しいか調べることを要求するのがvalidate

is validとvalidateの使い分けはコーディングルールによる
メソッドはすべてオブジェクトに対する命令だよルール(obj.DoSomething() = "Obj, do something.": オブジェに何かしろと命令をする)ならvalidate
基本的には命令だけどブールを返すだけのメソッドは例外的に命題形式(obj.Equals(x) = "Obj equals x.": オブジェがｘに等しいという命題の真偽を返す)ならis valid

314 ：デフォルトの名無しさん：2012/11/03(土) 12:16:28.70

>310

知ってる範囲では java.awt の validate は、コンポーネントの配置、親子関係を
正しく(valid)するという意味。副作用としてサイズ変更や再描画が発生する感じ。

315 ：デフォルトの名無しさん：2012/11/15(木) 20:37:24.21

set2Pointer

316 ：デフォルトの名無しさん：2012/11/20(火) 20:40:46.79

ゲームを作っています。
台車やトラックや荷車などを使って、荷物や人や岩などを運ぶゲームなんですが、
運ぶ手段となる性質を持つキャラの共通のインターフェースとして Carrier クラスを作りました。

質問は、運ばれる対象となるキャラの共通のインターフェースとして、
どのような名前のクラスがいいか、ということです。

例えば caller <--> callee のように carrier とちょうど対称になる単語があればいいのですが。

317 ：デフォルトの名無しさん：2012/11/20(火) 22:42:48.61

carrierにとってはどれもloadだけどどう？

318 ：デフォルトの名無しさん：2012/11/20(火) 22:58:20.03

別人だが。

>>317
loadってそういう意味なのか。
でもデータ読み込み以外の意味では使いにくそうだなｗ

319 ：デフォルトの名無しさん：2012/11/20(火) 23:06:54.68

loadの元の意味は積荷、負荷。
動詞だと搭載、積載すること。

320 ：デフォルトの名無しさん：2012/11/20(火) 23:17:10.78

ああ、load averageとかの意味か。

321 ：デフォルトの名無しさん：2012/11/20(火) 23:21:00.60

Carriable とかどうだろう

322 ：デフォルトの名無しさん：2012/11/20(火) 23:22:55.84

ごめん忘れて

323 ：デフォルトの名無しさん：2012/11/20(火) 23:24:11.51

ごめん忘れて

324 ：デフォルトの名無しさん：2012/11/21(水) 00:33:02.94

絶対に忘れないからー！

325 ：デフォルトの名無しさん：2012/11/21(水) 07:31:24.73

あかん、脳に深く刻み込まれてしまった

326 ：デフォルトの名無しさん：2012/11/21(水) 08:34:05.33

俺のニューロンも無駄遣いしやがったな

327 ：デフォルトの名無しさん：2012/11/21(水) 19:30:54.16

別にcarriee って造語作っても問題ないと思うけどなぁ。
そもそも運ばれるものが持つインターフェースってのがよくわからないけれど

328 ：デフォルトの名無しさん：2012/11/21(水) 20:53:09.62

Boy, you gonna carry that weight, carry that weight a long time.
っていうわけでweightとか。

でも、
＞台車やトラックや荷車などを使って、荷物や人や岩などを運ぶゲーム
なら、そんなインターフェイスなんか要らんような気がする。
どうせほとんどの物体クラスがそのインターフェイスを実装することになる。

329 ：デフォルトの名無しさん：2012/11/21(水) 21:36:19.21

家クラスとか、道路クラスとかにはないんじゃね？

330 ：デフォルトの名無しさん：2012/11/22(木) 14:18:36.64

template <typename T?> class Vector3 { ... };

このテンプレートクラスのテンプレート引数T?を変換する関数の名前と、そのスコープを決めたい
変換関数はこんな感じ

template <typename TargetType, typename SourceType>
void Cast?(const Vector3<SourceType> & input, Vector3<TargetType> * pOutput)
{
　pOutput->x = (TargetType) input.x;
　pOutput->y = (TargetType) input.y;
　...
}

1. T? の名称
2. Cast? の名称
を教えてほしい

例1）T? -> ContentType、 Cast? -> Vector3CastContentType
例2）template <U> Vector<T?>::CastTo(Vector3<U> * pNewValue) を作成する
例3）template <U> Vector<T?>::CastFrom(const Vector3<U> & source) を作成する

331 ：デフォルトの名無しさん：2012/11/22(木) 19:19:21.72

それでいいじゃん

332 ：デフォルトの名無しさん：2012/11/22(木) 21:01:10.02

ファイルパスとかpidlを処理するクラスで、
それらがネットワーク上の何かを指してるときに
タイムアウトするまで待たせるクラス

さらにそれがタイムアウトするまでユーザーに表示するウィンドウのクラス

お願いします

333 ：デフォルトの名無しさん：2012/11/23(金) 01:36:06.08

>>331
「それ」じゃわかんねぇんだよなぁ・・・

334 ：デフォルトの名無しさん：2012/11/23(金) 01:37:21.10

何が？

335 ：デフォルトの名無しさん：2012/11/23(金) 09:01:54.93

>>332
タイムアウトするまで待たせるクラス：　Get
タイムアウトするまでユーザーに表示するウィンドウのクラス：　Progress

336 ：316：2012/11/24(土) 18:38:26.00

提示された候補は下記の4つ

・load
・carriable
・carriee
・weight

ぱっと見て一番意味が分かりやすいのは carriable なので、
これでいく事にしました。

ありがとうございました。

337 ：デフォルトの名無しさん：2012/11/25(日) 19:17:41.04

ある値を一定範囲内にして返す関数名はなんとつけたらいいですか？

int 関数名( int value )
{
if( value > = 100 ) return 100;
if( value < 0 ) return 0;
return value;
}

338 ：デフォルトの名無しさん：2012/11/25(日) 20:33:10.13

round

339 ：デフォルトの名無しさん：2012/11/25(日) 20:42:27.58

>>337
定期的に出るなこれ
clampが定番

340 ：デフォルトの名無しさん：2012/11/25(日) 20:43:10.36

EnsureRange

341 ：デフォルトの名無しさん：2012/11/25(日) 21:09:15.06

trim
LimitedValue

342 ：デフォルトの名無しさん：2012/11/25(日) 22:49:53.29

2次元物理エンジンで有名なBox2Dもclamp採用してる

343 ：デフォルトの名無しさん：2012/11/25(日) 22:52:19.41

clampの元祖は何なんだろうな
広まった原因はDirectXのシェーダ関数だろうけど

344 ：sage：2012/11/26(月) 00:43:41.38

>>339
なるほどclampですか！

>>343
調べたらでてきました。
とても参考になりました！
ありがとうございました。

345 ：デフォルトの名無しさん：2012/11/26(月) 00:44:36.02

うは、sage入れるところ間違えた。

346 ：デフォルトの名無しさん：2012/11/28(水) 01:14:40.40

string Object::SetKariName(...) { this->kariName = ...; }
int Object::SetKariValue(...) { this->kariValue = ...; }
void Object::Update()
{
　...
　this->name = this->kariName;
　this->value = this->kariValue;
　...
}
string Object::GetName(...) const { return this->name; }
int Object::GetValue(...) const { return this->value; }

SetKariName()とSetKariValue()はどんな名前をつけるべきですか？
RequestSetName()とかにして、kariNameはrequestedNameなんてどうかな

347 ：デフォルトの名無しさん：2012/11/28(水) 01:24:06.53

値を返すセッター？

348 ：デフォルトの名無しさん：2012/11/28(水) 01:38:19.66

GetName()、GetValue()、GetXxx()が返す値は、Update()時に変更される
これらのプロパティはこれ以外のタイミングで変更されることはない
Update()時に設定される新らしい値は
SetKariName()、SetKariValue、SetKariXxx()で事前に設定しておく

349 ：デフォルトの名無しさん：2012/11/28(水) 01:45:30.23

SetNewName
SetTemporalName
SetNextName

350 ：デフォルトの名無しさん：2012/11/28(水) 09:43:09.27

>>346
アクセサメソッドはそういう内部の事情を隠蔽するのにも使うから
SetName
SetValue

351 ：デフォルトの名無しさん：2012/11/28(水) 14:01:11.39

>>349
Temporalは意味がちがう
Temporaryなら可

>>350
それは読む人を混乱させるよ

俺案
PrepareName

352 ：デフォルトの名無しさん：2012/11/28(水) 18:03:40.97

>>350
SetXxx()とGetXxx()が対にならないのは実際ややこしいので、そのセッタ（？）かゲッタのどちらかの名前を修飾したい

元々のソースでは>>346のメソッドが次のように命名されている
SetKariName -> SetName
GetName -> GetPrevName
つまり、
obj.SetName(...);
obj.SetXxx(...);
obj.Update();
NameTextArea.SetText(obj.GetPrevName());
XxxTextArea.SetText(obj.GetPrevXxx());
ようなコードになり、更新後の値をGetPrev...()で取り出さなければいけない。おかしい
なので、例のGetName()をGetOldName()みたいに修飾するわけにはいかない
つまり、SetKariName()側を修飾するべきだと自分は思った

>>351
自分でRequestSetName()みたいな例を挙げていて何だけど、GetKariName()が欲しくなったばあい
PrepareNameの対となるゲッタの名前はどうするべきだろうか
SetKariName -> SetNewName（>>349）として、GetNewName()を用意するのが一番わかりやすいんじゃないかと思ったが、どうだろうか

353 ：デフォルトの名無しさん：2012/11/28(水) 18:10:01.76

class Object {
public:
　string Object::GetName(...) const { return this->name; }
　int Object::GetXxx(...) const { return this->xxx; }

　void Object::Update()
　{
　　...
　　this->name = this->newName;
　　this->xxx = this->newXxx;
　　...
　}

　void Object::SetNewName(string newValue) { this->newName = newValue; }
　string Object::GetNewName() const { return this->newName; }

　void Object::SetNewXxx(int newValue) { this->newXxx = newValue; }
　int Object::GetNewXxx() const { return this->newXxx; }

private:
　string name;
　int xxx;
　string newName;
　int newXxx;
};

こんな感じでどうだろうか

354 ：デフォルトの名無しさん：2012/11/28(水) 18:10:44.37

kariNameはUpdateするまでに何回も変更されうるの？
それとも1回だけ？

355 ：デフォルトの名無しさん：2012/11/28(水) 18:19:44.51

>>354
kariNameはUpdateするまでに 0～N 回変更される
変更されない可能性もあるし、数回変更される可能性もある

356 ：デフォルトの名無しさん：2012/11/28(水) 18:31:34.01

kariObjを作っといて、そこから値をコピーするっていう方向性はないの？
でないと、属性ごとに、Newなんちゃら作ることになる。

357 ：デフォルトの名無しさん：2012/11/28(水) 18:36:05.96

>>356
それも考えたが、どのみちGetObject()とSetKariObject()が必要になるので、話の内容はほぼ変わらない

358 ：デフォルトの名無しさん：2012/11/28(水) 18:38:59.11

カリってwチンコクラスのメンバかよw

359 ：デフォルトの名無しさん：2012/11/28(水) 18:58:45.65

Object honmonoObj, kariObj;
で、kariObjはフラグがあってSetXxxができるけど、
honmonoObjはUpdate（というかkariObjのコピー）しか受け付けないみたいな。

360 ：デフォルトの名無しさん：2012/11/28(水) 19:43:30.09

>>346
"kari"を"pre"に変えればいいと思うよ。

361 ：デフォルトの名無しさん：2012/11/29(木) 10:26:46.73

「男性」「man」「male」など、男性を表す文字列を与えると真、
逆に「女性」「woman」「female」など、女性を表す言葉なら偽を返す関数の名前は何が良いでしょうか。

男性名詞/女性名詞を判別するというような大袈裟なものではなく、単純に正規表現でマッチさせるだけです。
性別を判断できない場合は、デフォルトの値を返します。

362 ：デフォルトの名無しさん：2012/11/29(木) 10:28:27.56

isMasculine

363 ：デフォルトの名無しさん：2012/11/29(木) 10:40:57.07

真か偽かじゃなくて男性か女性か判別できないか返した方がいいんじゃないのか？

364 ：デフォルトの名無しさん：2012/11/29(木) 11:45:32.78

>>362
ありがとう。それにしてみます。

>>363
コーディングの際にはそれも考えたんですけどね。

最終的に真偽値でしか使わず、判別できないときは一方に固定（あるいはランダム選択）する使い方しかしないので、
単に真偽値を返すだけの方が使いやすいかな、という判断。

365 ：デフォルトの名無しさん：2012/11/29(木) 12:10:39.60

つ ISO 5218

366 ：デフォルトの名無しさん：2012/11/29(木) 17:44:35.51

>>360
PreNameだと名前の前（についているもの）になってしまわないか？

367 ：デフォルトの名無しさん：2012/11/29(木) 18:17:59.24

new チンコ

368 ：デフォルトの名無しさん：2012/11/29(木) 18:45:08.61

>>366
じゃあ PreviousName とか？
レスあんまり読んでないけど、OldName でいいんじゃね？

>>367
生えてくるんかよwww

369 ：デフォルトの名無しさん：2012/11/29(木) 19:07:30.42

>>366
造語だから多少いろんな意味に取れるのは仕方がない。

(1) 意図する意味に取れて
(2) 一度その意味を理解すれば二度目に見たときはすんなり頭に入る

のなら何も問題はない。少なくとも他の案よりまし。

370 ：デフォルトの名無しさん：2012/11/29(木) 19:43:31.45

Nextがいいような気がしてきた！

371 ：デフォルトの名無しさん：2012/11/29(木) 20:04:05.58

Preとか糞すぎ

372 ：デフォルトの名無しさん：2012/11/29(木) 20:45:09.78

>>369
>>368が即効で勘違いしたように、Pre～は前とか事前の意味が強いのでNG
Previousの語源もPre～だからなぁ
逆にNextは確かに解かりやすいかもしれない
選択肢が以下の2つであれば、どちらが良いかな

1）SetNextXxx(Yyy newValue)
2）SetNewXxx(Yyy newValue)

373 ：デフォルトの名無しさん：2012/11/29(木) 21:19:39.27

>>372
センスない人とは意見が合わないね。

>>346が必用としているのは値を「事前に」入れておく入れ物の名前だから
英語のニュアンス的には接頭辞preが一番あっている。

preloadとかpreregistという用語を使う分野があるが、そのpreと同じニュアンスだ。

っていうかnextって何だよ。英語脳で考えずに日本語脳で考えるからそういう発想になる。

374 ：デフォルトの名無しさん：2012/11/29(木) 21:28:58.37

一応訂正しとく
× preregist
○ preregister

375 ：デフォルトの名無しさん：2012/11/29(木) 21:34:30.51

英語脳（）で考えるとpreregist とか引き合いに出しちゃうのかぁ
さすがゴミの考えは一味違いますね

376 ：デフォルトの名無しさん：2012/11/29(木) 21:44:13.79

registなんか日本人しかしない間違え方だし。
そんなんでよく英語脳とか言ってるよな。

377 ：デフォルトの名無しさん：2012/11/29(木) 22:36:00.93

>>373
脳が英語か日本語かというより、
そのプログラムコードを読むのは誰なのかの方が大事だと個人的には思う。

読む人が日本人なら、日本人の感覚を優先すべき。
外国の人も普通に読むのなら、国際的な感覚を優先すべき。

378 ：346：2012/11/29(木) 23:06:13.78

>>373
>>372は俺だわ
その命名方法でいくと、
SetPreXxx（事前Xxxを設定しろ）
PresetXxx（Xxxを事前設定しろ）
のどちらが良いですか？

379 ：デフォルトの名無しさん：2012/11/29(木) 23:43:39.90

>>378
純粋にメソッドの名前だけならPresetXxxの方が分かりやすい気がするけど、
それだとその値を保持するメンバ変数の命名でまた悩むことになるね。

というか、命名と関係ない話になるし既に誰か書いてた気がするけど、
本当はUpdateで適用する値だけを別のクラスか構造体にまとめて置いたほうが
分かりやすいような気がしないでもない。

380 ：デフォルトの名無しさん：2012/11/30(金) 00:12:05.54

命名に悩む設計は糞だってばあちゃんが言ってた

381 ：デフォルトの名無しさん：2012/11/30(金) 01:02:24.23

今日はrejisutoという関数名を見た。社内ライブラリなので直したら影響が大きそうだと思った

382 ：デフォルトの名無しさん：2012/11/30(金) 02:27:40.85

reserveName

383 ：デフォルトの名無しさん：2012/11/30(金) 03:01:30.97

registって見ると所詮その程度の奴なんだなって思う

384 ：デフォルトの名無しさん：2012/11/30(金) 03:03:08.79

resistと混ざる（´・ω・`）

385 ：346：2012/11/30(金) 06:44:03.41

>>379
レスさんくす
SetPreXxx(newValue) { this->preXxx = newValue; }
PresetXxx(newValue) { this->preXxx = newValue; }
どちらの場合でもpreXxxで良いんじゃないかと思った・・・が、ゲッタを作成するばあい
GetPresetXxx() { return this->preXxx; } になるのか・・・
自分的には名前を対照にしたいし、SetPreXxx()にしてみようかな

適応するプロパティなりをまとめるかどうかは検討中

386 ：346：2012/11/30(金) 06:46:25.94

長文スレ汚しになるが、実際こんな感じのクラス

class Relation { // Body同士の関係を表すクラス
public:
　void Update()
　{
　　size_t b1(this->spCache.HasContact() ? 1 : 0);
　　size_t b2(this->spPreCache.HasContact() ? 1 : 0);
　　this->state = StateTable[b1][b2];
　　this->spCache = this->spPreCache;
　　...
　}

　void SetPreContactCache(spNewValue) { this->spPreCache = spNewValue; }
　sp<ContactCache> SetPreContactCache(spNewValue) { return this->spPreCache; }

private:
　const BodyPair bodies;
　sp<ContactCache> spPreCache;
　sp<ContactCache> spCache;
　ContactState state;
};

map<BodyPairUniqueId, Relation> relations;
relations.insert(BodyPair.GetUniqueId(), Relation(BodyPair));

387 ：デフォルトの名無しさん：2012/12/01(土) 20:53:50.37

測定器の吐き出した実験データの書かれたファイルを
実験の種類別にサブフォルダにコピーして
決まった命名規則に従いリネームする
というプログラムの名前はなにがいいですか？

388 ：デフォルトの名無しさん：2012/12/01(土) 21:01:34.45

>>387
Makefile

389 ：デフォルトの名無しさん：2012/12/01(土) 21:28:57.86

>>387
Log Filer
DAQ Log Filer
Lab Aid

390 ：デフォルトの名無しさん：2012/12/01(土) 21:44:51.76

>>387
[分類する人]
classer
sorter

[分類器]
classifier

391 ：デフォルトの名無しさん：2012/12/01(土) 23:40:40.18

ライブラリのポーティングをしていて、とりあえず無理矢理ビルドを通すために
足りない関数などを定義したソースファイルをまとめて入れるためのフォルダ名は何がいい?

392 ：デフォルトの名無しさん：2012/12/01(土) 23:44:01.90

>>391
mysrc

393 ：デフォルトの名無しさん：2012/12/02(日) 00:10:59.44

>>391
どっかで missing/ ってのを見た。

394 ：デフォルトの名無しさん：2012/12/02(日) 00:37:55.37

>>391
別に普通に日本語でいいじゃん

395 ：デフォルトの名無しさん：2012/12/02(日) 01:38:21.14

not implemented

396 ：デフォルトの名無しさん：2012/12/02(日) 02:58:54.02

>>391
stub とか stubs とか

397 ：デフォルトの名無しさん：2012/12/02(日) 08:30:28.41

>>391
marshal
ヘッダーかと思ったらフォルダかよ・・・

398 ：デフォルトの名無しさん：2012/12/02(日) 11:08:58.62

ゲームを作っています。
キャラの当たり判定後の処理をする関数名が思いつきません。

キャラ同士や、キャラと背景とが当たったかどうかを判定する処理と、
判定後に、キャラにダメージを与えて表示を点滅させたり、
互いに弾かれて反対側へ飛ぶように速度ベクトルを変えたり、
背景にめり込まないように位置を調整したりする処理とを分けたいと思います。

当たり判定そのものは HitTester クラスが受け持ちます。
判定後の様々な処理は GameRule クラスが受け持ちます。
（GameRule クラスはその他の処理もいくつか受け持ちますが）

キャラが動いたら、そのキャラを HitTester::register 関数で登録し、
全ての移動キャラが登録されたら、HitTester::test 関数で判定します。
その後 GameRule::??? 関数で当たっているキャラに対して処理します。
この???関数の中ではHitTesterから当たっているキャラのリストを得て、
どのキャラ同士か、キャラと背景なのかによって処理をサブ関数に振り分けます。

その後、キャラが動くので再び HitTester で当たり判定をし、
GameRule::??? 関数で判定後の処理をし、当たらなくなるまで繰り返します。

この GameRule::??? 関数の名前は何がいいでしょうか。
私は postHitTest が思いついたのですが、この意味の post は動詞ではありません。
関数名はできるだけ動詞で始めたいのですが、なかなか思いつきません。

399 ：デフォルトの名無しさん：2012/12/02(日) 11:13:58.41

>>398
GameRule::Do( )

400 ：デフォルトの名無しさん：2012/12/02(日) 11:46:17.53

>>398
removeCollisions

401 ：デフォルトの名無しさん：2012/12/02(日) 12:02:53.44

handleHittestResults

402 ：デフォルトの名無しさん：2012/12/02(日) 14:41:17.15

>>398
dispatchToHitHandler

403 ：デフォルトの名無しさん：2012/12/02(日) 14:43:12.01

変数名で悩むってことは設計がもやもやしてる状態

404 ：デフォルトの名無しさん：2012/12/02(日) 14:45:35.98

拡張ポイントにするなら>>401-402の考え方
やることが決まってるなら>>400のように目的をはっきり名前にしたほうがいい

405 ：デフォルトの名無しさん：2012/12/02(日) 14:54:32.38

当時はなんとも思わなかったが、大昔のタイトーのバブルボブルみたいな処理って
自分で実装しようと思うとなかなか難しそうだな

406 ：デフォルトの名無しさん：2012/12/02(日) 15:03:26.86

>>399 >>400 >>401 >>402 >>404
みなさん、ありがとうございます。

>>404 にはとても説得力を感じました。
やることは「めり込みの解消」や「ダメージ処理」など複数あって、
GameRule::??? はそれを振り分けるだたのエントリーポイントになるので、
>>401 >>402 のような感じの名前が良さそうですね。

参考にしてもう少し考えてみます。

それと・・・

キャラが動いたら、そのキャラを HitTester::register 関数で登録し、と言いましたが、
VC++ では識別子に register という名前が使えないことを今知りました。
（言い忘れていましたが、使用言語は C++ です）

こちらの代わりの名前も、もう少し自分で考えてみます。

407 ：デフォルトの名無しさん：2012/12/02(日) 15:52:27.08

408 ：デフォルトの名無しさん：2012/12/02(日) 17:53:24.17

registerObjectとかregisterEntityとかでいいだろ

409 ：デフォルトの名無しさん：2012/12/02(日) 18:51:55.59

>>408
すいません、ODEでregisterを引いてみると、
どうもデータを「記録する」という意味合いが強いみたいです。
それも、どちらかと言えば大事な（公式な、公的な）データを。
また、今回の（毎フレーム当たり判定するキャラを設定する）様に
ころころと内容が変わるものにはあまり使わず、
もっと長い時間記録しておくものに対して使う感じですね。

なので、enterあるいはsetを使うことにしました。

410 ：デフォルトの名無しさん：2012/12/02(日) 20:25:11.31

>>407
Cのころからregisterは予約語よ。
賢いコンパイラにいろいろ任せて構わない環境では意識して使うことはあまりないけど。

411 ：デフォルトの名無しさん：2012/12/10(月) 04:57:33.87

revertとrestoreの違いって何？

412 ：デフォルトの名無しさん：2012/12/10(月) 07:55:46.61

ある値の最大値や最小値、デフォルト値などを規定するとき、どうしてる？

MAX_FOO や DEFAULT_BAR にする？
それとも FOO_MAX や BAR_DEFAULT にする？
あるいはそれ以外？

413 ：デフォルトの名無しさん：2012/12/10(月) 08:25:18.48

前者

414 ：デフォルトの名無しさん：2012/12/10(月) 09:21:08.89

>>411
過去に戻るのがrevert
過去を今に引っ張ってくるのがrestore

415 ：デフォルトの名無しさん：2012/12/10(月) 09:24:45.37

>>412
俺はオブジェクト指向のとき、Integerというオブジェクトがあったとすると最大値、最小値、デフォルト値を
Integer.MAX, Integer.MIN, Integer.DEFAULT　って定義するので後者。
インテリセンスで補完することを考えても、
ネームスペースをそろえる的な意味で、接頭辞は関連あるグループでまとめたい。

416 ：デフォルトの名無しさん：2012/12/10(月) 18:24:26.18

アドバイスありがとう。
迷ったけど、オブジェクト指向を意識して、階層分けをしてみることにする。

417 ：デフォルトの名無しさん：2012/12/17(月) 19:57:33.38

2つの文字列のリスト X、Y があり、
X の各要素 x について、Y の要素と同値かどうかを調べるとする。

このリスト X の事を base list、Y の事を target list と呼ぶのはおかしいか？

418 ：デフォルトの名無しさん：2012/12/17(月) 20:00:50.30

>>417
文脈がわかればもっと適切な名前が出てくるかもしれないけど、
別にbaseとtargetでも問題ないよ。

419 ：デフォルトの名無しさん：2012/12/17(月) 20:29:47.17

個人的にはsrc推し

420 ：デフォルトの名無しさん：2012/12/17(月) 20:30:59.83

srcにするならもう一方はdstだな

421 ：デフォルトの名無しさん：2012/12/17(月) 21:41:01.17

>>418
>>417 の処理をする関数の仮引数の名前、および、
その関数を使用する側の実引数として使う変数の名前をどうしようかと。

関数自体は２引数で、一方がリストX、もう一方がリストY。
（リストの要素の型が文字列かどうかは、実はどうでもよかったりする）

その関数を使う側でも、関数の中でも、どの引数がどういう意味なのか、
プログラムを見て直ぐにはっきりと分かるようにしておきたい。

プログラム言語は Haskell なので、式はシンプルにできると思い、
仮引数は特に意味のない xs と ys を使ってプログラムしてみたが、
意外にぱっと見どちらが各要素調べるリストで、
どちらがその要素と同値か調べるリストなのか分かりづらかった。
（たぶん、数ヶ月後にはもっと分かりづらくなっているだろう）

実は base と target にしても、どちらの意味で base を使っていて、
どちらの意味で target を使っているのか曖昧で、
分かりやすさという点では xs や ys とたいして変わらないような気がするのだが、
どうだろう？

422 ：デフォルトの名無しさん：2012/12/17(月) 22:04:59.02

積集合(intersection)を求めようとしているのかと思ったけど、
個々に調べるだけだから違ったか。

423 ：デフォルトの名無しさん：2012/12/17(月) 22:19:41.81

>>421
X: query, keywords, entry
Y: dictionary, base

もしXが入力されたコマンドのリストで、Yが受付可能なコマンドのリストとかいうのなら
XをcommandsにしてYをavailableにするとか

424 ：デフォルトの名無しさん：2012/12/17(月) 22:59:28.06

>>423
すまん、>>421 でも括弧内に書いたが、今回は汎用型関数なんだ。
（>>417 で文字列と言ったのは、初めはそのつもりでプログラムしてたから）

同値かどうか判定できる型なら何でもいいから、
仮引数としては具体的な名前は使いにくい。

ただ、keywords や commands などは実引数の方で大いに使わせてもらいたい。

また、やはりと言うべきか、Y の方を base と考える人もいる事が分かり、
これもあまり良くないと分かった。

entry と dictionary（dic）の対は結構良いかもしれない。
X の方は、辞書や図鑑などで調べようとしている単語や事物を抽象的には何という？
という問題と本質的には同じっぽい（具体的には word や dinosaur などだけど）。

425 ：デフォルトの名無しさん：2012/12/17(月) 23:18:26.19

bsearch(3) では探すものが key で探される集合が base だった。

探索アルゴリズムの解説なんかで、探すものがneedle、
探される集合がhaystackという文化もあるけど。

426 ：デフォルトの名無しさん：2012/12/18(火) 00:27:43.82

>>424
2つの引数は入れ替えても関数が返す値は常に同じ（数学でいう交換法則が成立する）
のように思えるから、むしろ意味がある名前を付けることこそ変に感じるけど。

x, yでいいじゃん。

427 ：デフォルトの名無しさん：2012/12/18(火) 12:55:54.96

>>426
では同値判定の時はそれで問題ないとして、大小比較判定の場合は？
あるいはもっと一般的に2引数をとって真偽値を返す関数による比較の場合は？

そう考えると、2つの引数は入れ替えても関数が返す値は常に同じというのは、
今回の問題の本質では無いような気がするのだが・・・

本質は >>424 でも少し言ったが、
辞書や図鑑などで調べようとしている単語や事物の方Ｘと、
辞書や図鑑などの方Ｙの名前が分かれば綺麗に解決すると私は思う。

428 ：デフォルトの名無しさん：2012/12/18(火) 21:24:32.29

例えば除算のように交換法則が成立する演算なら、被除数、除数というように
2つのパラメータを区別することに意味があるし区別しなきゃダメだけど、
乗算のように交換法則が成立する演算の場合は被乗数、乗数なんて区別しても
あんまり意味はない、そういうこと。

＞大小比較判定の場合は
src、dstがシンプルでいいと思うけどアセンブラ経験者じゃないと違和感あるかな。
reference、evaluatedとか

429 ：346：2012/12/19(水) 14:30:03.95

sourceの反対はdistination？だっけ？これだけじゃないぞ。targetも使える
俺なら>>426と同じ理由でlistA、listBと名づける
大小比較であれば、leftList、rightListだな

430 ：デフォルトの名無しさん：2012/12/19(水) 14:35:11.26

つ destination(dst/dest)

lhv/rhv(left/right hand value)ってのも

431 ：デフォルトの名無しさん：2012/12/19(水) 23:59:01.61

>>427
>では同値判定の時はそれで問題ないとして、大小比較判定の場合は？
これ関してはa/b、x/y等が広く使われてる

>あるいはもっと一般的に2引数をとって真偽値を返す関数による比較の場合は？
特化するならともかく一般化するならなおさらa/b、x/y等しか使えない

432 ：デフォルトの名無しさん：2012/12/20(木) 23:32:45.10

>>431
> 特化するならともかく一般化するならなおさらa/b、x/y等しか使えない

イメージとしては、リストＸから一枚カードを抜き、
「そのカードを使ってyと何かをする」という関数を
リストＹの全てのカードに順に施す。
という処理をリストＸの全てのカードに対して行う。

と言うことなのでＸとＹは非対称、というのが私の個人的な感覚。
なので、できれば非対称である事をイメージできる名前が欲しかった。

でも、一般化するなら非対称も何もないから x や y で良いだろという言い分も分かる。

感覚の違いで、議論は平行線のままだと思うので、ひとまずこれで終わることにする。
いろんな意見ありがとう、参考にさせてもらう。

433 ：デフォルトの名無しさん：2012/12/21(金) 00:22:06.22

トランプゲーム？
X=山札?
Y=手札？

434 ：デフォルトの名無しさん：2012/12/21(金) 00:41:04.65

やべ、名前突っ込んだままだったとは・・・

>>430
今時はlhv/rhvは使わない。流行っていない。オープンソースでも見たことがない
交換法則が存在するのであれば、引数はleft/right
しないのであれば、a/b
交換法則が存在するというか、算術演算ではなくて順番に価値があるならば、first/second/third/...

>>432
void func(List xxx, List yyy) {
　foreach (ListElement a : xxx) {
　　foreach (ListElement b : yyy) {
　　　process(a, &b);
　　}
　}
}

最初からこう（↑）説明するべきだったんじゃないかな。俺なら、
xxxはfactors,factorList
yyyはtargets,targetList

435 ：デフォルトの名無しさん：2012/12/25(火) 16:59:57.68

ClassA
ClassB
ClassC

と三つのクラスがあり、
渡されたインスタンスの型が A ならそのまま返し、
その他なら A に変換して返す、という関数の名前に迷ってます。
後者の場合は B.toA(), C.toA() のようなメンバ関数を実行して返すといった具合です。
Number(string) みたいなキャストと同じような動作を意識しています。
いいアイデアあったら教えて下さい。

436 ：デフォルトの名無しさん：2012/12/25(火) 17:30:46.79

toA()
ToA()

437 ：デフォルトの名無しさん：2012/12/25(火) 20:36:32.38

C++だったらAに型変換コンストラクタを定義するところかな?

438 ：デフォルトの名無しさん：2012/12/25(火) 20:45:02.25

>>435
asA

439 ：デフォルトの名無しさん：2012/12/25(火) 22:12:26.03

>>436
これ

440 ：デフォルトの名無しさん：2012/12/25(火) 22:22:06.66

そもそも関数ってのがね。

基本的に変換であれば、変換が必要だから変換していることが明示的に分かるように書くべきだし
（変換してるかもしれないししてないかもしれない、なんて気持ち悪い）
逆にある型をAとして扱いたいのなら普通に多態を使うべきじゃないかと思うんだけど。

441 ：デフォルトの名無しさん：2012/12/25(火) 23:41:42.27

> 命名規則や設計の善し悪しについて議論するのは基本的に禁止。

442 ：デフォルトの名無しさん：2012/12/26(水) 00:41:31.77

馬鹿はいつもそれだな。
馬鹿がそうやって建前を利用して他人をコントロールしたがるのは、
無能ゆえに自分の実生活を自分でハンドリングしている感覚がないからだ。

まあ言ってもわかんないだろうけど。

本気で哀れだ。

443 ：デフォルトの名無しさん：2012/12/26(水) 02:12:39.96

俺も>>436だな
AにもToAし得るのは.StringにもToStringがあるようなもんだと思って目をつぶる

444 ：デフォルトの名無しさん：2012/12/26(水) 02:33:16.91

俺は>>438だな。

445 ：デフォルトの名無しさん：2012/12/27(木) 01:03:52.26

Microsoft_Free_Every_Object_Convert_Returning_Type_Of_A(object sender){}

というのは嘘で、俺は型変換はすべて ConvA() みたいにしてる。
ネイティブのToStringなどと混同しないように。
何でもいいから自分の中で統一しておいたほうが楽だよ。

446 ：デフォルトの名無しさん：2012/12/28(金) 01:13:30.71

下位の型（Lower）から上位の型（Higher）の変換関数は
Higher LowerToHigher(Lower value);
void LowerToHigher(Lower input, Higher * pOutput);
void Higher::FromLower(Lower value);
static Higher Higher::FromLower(Lower value);
static void Higher::FromLower(Lower input, Higher * pOutput);

上位の型（Higher）から下位の型（Lower）への変換関数は
Lower HigherToLower(Higher value)
void HigherToLower(Higher input, Lower * pOutput)
Lower Higher::ToLower()
void Higher::ToLower(Lower * pValue)

同位の型(AaaとBbb）同士の変換関数は
Bbb AaaToBbb(Aaa value)
void AaaToBbb(Aaa input, Bbb * pOutput)
Aaa BbbToAaa(Bbb value)
void BbbToAaa(Bbb input, Aaa * pOutput);

ある型（Aaaとする）をメンバに持つクラスは、Aaaより上位である
つまり、組み込み型は最下位である
但し、文字列型（String）とある型（Aaa）との変換関数は
String Aaa::ToString()
void Aaa::ToString(String * pValue)
void Aaa::Parse(String value)
static Aaa Aaa::Parse(String value)
static void Aaa::Parse(String input, Aaa * pOutput);

とする

447 ：デフォルトの名無しさん：2012/12/28(金) 01:21:29.69

我が宗教を書き終わったのでボク満足
>>435？知らんな。「ToA」でいいんじゃね

448 ：デフォルトの名無しさん：2012/12/29(土) 18:15:56.84

引数名で迷っている　
2つのデータを関数に渡して、第一引数に第二引数の値をコピーする処理をしたいんだ

コピー元とコピー先って意味でいい言葉はないかな？

449 ：デフォルトの名無しさん：2012/12/29(土) 18:21:15.10

src, dst または dest
'source, destination)

450 ：デフォルトの名無しさん：2012/12/29(土) 22:22:36.04

ネイティブの人だと大抵src/destだよな
srcの逆ならどう考えてもdstの方が自然だと思うんだけど向こうの人の頭はどうなってるのか知りたい

451 ：デフォルトの名無しさん：2012/12/29(土) 22:25:59.18

dest と dist を区別するためだな

452 ：デフォルトの名無しさん：2012/12/29(土) 23:06:26.19

日本人は字数合わせたり几帳面なんだと思う

453 ：デフォルトの名無しさん：2012/12/29(土) 23:07:58.64

width＆height「呼んだ？」

454 ：デフォルトの名無しさん：2012/12/29(土) 23:23:56.81

>>450
参照してるソースが偏ってない？

英語ネイティブかどうか知らないけどジンガイの書いたコードやドキュメントでも
dstの方が多いように感じるが。

455 ：デフォルトの名無しさん：2012/12/29(土) 23:35:48.33

JavaのAPIはsrc/destが多い(arraycopy等)
WinAPIもだね

456 ：デフォルトの名無しさん：2012/12/29(土) 23:48:48.29

>>452
カラム合わせで思ったけど、アセンブラとかBASICとかFORTRANにPascal、それにCとかは等幅フォント。
C++やJavaになってくるとプロポーショナルのフォントの方が書いていて楽な感じがしてきた。

457 ：デフォルトの名無しさん：2012/12/30(日) 00:03:19.82

MS Pゴシックみたいに判読困難な文字が多いフォントは別として、ほとんどの場合は
確かにPフォントでも困らない。

とはいえ、コメントにAA使ったり参照テーブル的な配列を初期化する場合は
Pフォントだと困るケースがあるから、やはり等幅フォントの方が無難だと思う。

458 ：デフォルトの名無しさん：2012/12/30(日) 00:18:13.83

>>457
> とはいえ、コメントにAA使ったり参照テーブル的な配列を初期化する場合は

他にも enum を書く時にイコールの位置を揃えた方が見やすい場合もある。

あと、俺はこの手のも揃えたいな。

if (aaa > 3 && aaa < 5 ||
bbb > 7 && bbb < 11)

459 ：デフォルトの名無しさん：2012/12/30(日) 01:03:15.21

コードが図形のように理路整然としていると可読性が上がるね。見落としが減る。
クラス名や変数名も文字としてではなく図形として意識して命名すれば、見やすくなる。

460 ：デフォルトの名無しさん：2012/12/30(日) 12:12:05.17

>>459
前半は分かるが、後半がよく分からん。

図形として意識せず命名してしまった変数名やクラス名と、
ちゃんと図形として意識して命名した変数名やクラス名の例をいくつか挙げてみてくれ。

461 ：デフォルトの名無しさん：2012/12/30(日) 12:58:21.92

>>459の言いたいことかどうか分からないが、（特に末尾の）数文字しか違わない
名前が複数あると視認性が悪くなるというのは結構ありがちなことかも。

もっともそういうケースではほとんどの場合有効な解決法が他になかったりするけど。

462 ：デフォルトの名無しさん：2012/12/30(日) 14:55:27.52

スレチかもしれんが、プログラムのよく使う変数名の付け方とか、
こういう時はどんな変数名にしたらいいかが載ってる書籍とかサイト知らないですか？

1つ1つここで聞くのも無粋かと思うので・・・

463 ：デフォルトの名無しさん：2012/12/30(日) 15:05:04.66

あるといいよね。
俺が出版しようか

464 ：デフォルトの名無しさん：2012/12/30(日) 15:15:45.24

>>462
ここの過去ログを漁ってまとめればいいと思うが

465 ：デフォルトの名無しさん：2012/12/30(日) 20:17:04.64

>>462
とりあえず、適当な単語と
進行形(～ing)・完了形(～ed)・可否(can～/is～)をある程度、意識するようにしてる。

466 ：デフォルトの名無しさん：2012/12/31(月) 16:53:48.31

Cで質問。

struct Foo {int a; int b; int c;};

enum XXXXX {
FOO_A = 0x0001, FOO_B = 0x0002, FOO_C = 0x0004,
};

Foo構造体のどのメンバが有効かどうかを示す列挙型を作りたい。
複数のメンバが同時に有効になる場合があるから、ビットの論理和で表現する。
XXXXXに何て名前つけるべき？

467 ：デフォルトの名無しさん：2012/12/31(月) 17:30:56.90

enum FooFlags {
a = 0x0001, b = 0x0002, c = 0x0004,
};

でも無効なメンバーの値は0x80000000（どうせこんな値普通は使わない）にする約束にすれば
こんなフラグは要らない。

468 ：デフォルトの名無しさん：2012/12/31(月) 17:31:57.18

UseMask
AvailableMask

469 ：デフォルトの名無しさん：2012/12/31(月) 19:09:34.74

ValidMember

470 ：デフォルトの名無しさん：2012/12/31(月) 19:42:03.44

ゲーム作ってるんだけど、ゲーム画面に表示するものの位置を保存するメンバ変数で position と location で迷ってる。
こういうものの場合 Windows API だと position が多いような感じがする(SetWindowPos とか)。
でも、.NET Framework だと両方出てくるみたいで紛らわしい(Cursor.Position、TextBox.Location、
言葉の意味の違いはなく共に座標位置を表す数として扱われているようだ)。
言葉の意味を調べると意味にブレのない Location を使う方が正しいように思う。
しかし、こんなこと考えつつも、実際のプログラミングでは pos と表記したくなるジレンマ。

471 ：デフォルトの名無しさん：2012/12/31(月) 19:47:55.22

論理座標…location
描画などの点…position
で使い分けるのが自然に思う

472 ：466：2012/12/31(月) 19:55:49.74

>>467-469
サンクス。Maskがよさげな感じ。

473 ：デフォルトの名無しさん：2012/12/31(月) 22:49:20.71

>>471
よくわからない

474 ：デフォルトの名無しさん：2012/12/31(月) 23:13:46.98

>>473
ゲーム世界での位置を表すものはlocation
たとえばキャラが升目に載るタイプのゲームならlocationは升目単位
そうでないのはposition
個人的にはこうやって区別して使ってる

475 ：デフォルトの名無しさん：2012/12/31(月) 23:23:28.42

>>474
Cursor.Position、TextBox.Locationについてはどう解釈すればいい？

476 ：デフォルトの名無しさん：2012/12/31(月) 23:36:49.91

>>475
常に動くものや引数で指定するもののように定まってないのはpositionで
定まってるされてるものはlocationという使い分けなんじゃない?
WinFormsだとコントロールの位置はlocationで動的なマウスカーソルの位置はpositionだけど
マウスイベントが発生した時に発生時のカーソル座標を取得するプロパティはlocation

477 ：デフォルトの名無しさん：2012/12/31(月) 23:40:51.51

そもそも >>740 のプログラムの中で両者を使い分ける必要があるの？

478 ：デフォルトの名無しさん：2012/12/31(月) 23:44:06.86

どうせほぼ同じなんだから、あえて使い分けるならプログラムの性質に合わせて自己流でやればいいと思う
ゲームなら>>474の区別が便利なんじゃないの。逆でもどっちでもいいと思うけど。

479 ：デフォルトの名無しさん：2013/01/01(火) 00:20:22.34

position：点として扱われているものの位置、広がりは無視される。
location：広がりがある物として扱われているものの位置、広がりが意識されている。

こういう傾向があるように思うけど、いつもこれで区別されるわけではないとも思う。
ウインドウは広がりがあるものだけどSetWindowPosは左上の点で設定するのが
前提にあるからこのルールに矛盾しないものと解釈する事もできる。
だけどいずれにしてもXYで表されたりと結局どっちでもいいようなものは
開発者の視点の違いでしかないような気もする。

480 ：デフォルトの名無しさん：2013/01/01(火) 01:21:50.23

ちょっと無理がある区別のような気がするけどw

むしろ両者の違いは、positionは次元を問わない（1,2,3次元のどれにでも使える）のに対して、
locationは2次元（あるいは立体物の表面上）の位置というニュアンスが強い気はする。

2次元に限定すれば両者の意味はほぼ同じじゃないのかね。

481 ：デフォルトの名無しさん：2013/01/01(火) 02:25:10.72

3次元でも立体の表面上とか関係なくLocationが使われてるからそんな違いはなさそう

482 ：デフォルトの名無しさん：2013/01/01(火) 02:39:26.14

positionは抽象的なものにも使いうるっていうことでは？

483 ：デフォルトの名無しさん：2013/01/01(火) 03:36:45.91

たとえばpositionという言葉はスライダーとかボリームとか1軸しかないモーションコントロールなどでも
使用されるけど、locationは一般には使われないと思う。

>>481は違うというが、普通は3次元上の位置のことをlocationとはあまり言わないと思うね。

484 ：デフォルトの名無しさん：2013/01/01(火) 08:10:56.72

俺は容赦なくLocationで統一している
Positionを使うべき明確な理由が見つかったらPositionに置換しようかと

485 ：デフォルトの名無しさん：2013/01/01(火) 10:53:36.41

マウスカーソルの現在位置に関してはpositionが圧倒的みたいだな
locationは特定の位置に物体が束縛されている
positionは物体の観測結果としての位置
みたいなニュアンスなんだろうか

486 ：デフォルトの名無しさん：2013/01/01(火) 11:28:43.39

日本語で言う「場所」と「位置」程度のニュアンスの違いだ。

location : 場所
position : 位置

場所はある広がりを持った空間を指す。
位置はある点を指す。抽象度がより高いから立場とか順位いう意味にも使える。

例えば日本国内で映画の撮影に使う場所（空間）は location。
その場所でカメラをセッティングする位置（点）は position。

>>470 の目的だと、俺なら position を使う。

487 ：デフォルトの名無しさん：2013/01/01(火) 12:29:08.80

locationは、おおざっぱなもの。
positionは、細かいもの。

488 ：デフォルトの名無しさん：2013/01/01(火) 14:19:36.61

http://answers.yahoo.com/question/index?qid=20080609154640AAjCQkT
http://forum.wordreference.com/showthread.php?t=2125938

489 ：デフォルトの名無しさん：2013/01/01(火) 15:03:23.95

だから広がりとか大雑把とかそういうことではなくて
locationには平面状の位置というニュアンスがあるんだと何度も言ってるのに
懲りねえなまったく...

490 ：デフォルトの名無しさん：2013/01/01(火) 15:35:14.02

>>489
2次元には限定されないよ

491 ：デフォルトの名無しさん：2013/01/01(火) 15:44:42.11

みなさん

権威あるオックスフォード新英英辞典にも、
position と location についてそのような微妙なニュアンスや、
ましてや明確な違いなど説明されていませんよ。
互いが互いの言葉を使って循環的に説明されています。

平面も広がりも、点だろうが何次元だろうが関係ないです。
好きな方を使ってください。

プログラムソースの中ではどちらかに統一しましょう。

492 ：デフォルトの名無しさん：2013/01/01(火) 16:26:34.40

しょうがねえな。
たとえばLongmanのpositionの項にこうある

5 direction[countable] the direction in which an object is pointing

この用例を見れば分かると思うけど、これがpositionが次元を問わずに使える理由だと思う。

一方でlocationの項を見ると、"Choce:"とある囲い記事の中に
Location is used mainly in formal or business English to talk about where a building is

locationに平面上の位置というニュアンスが強いのはこのため。

493 ：デフォルトの名無しさん：2013/01/01(火) 16:56:34.95

やはり何次元でもいいんだな。

494 ：デフォルトの名無しさん：2013/01/01(火) 17:45:33.06

どうでもいい

最も気に入った案を信じてこの件は終わりだろ
明確な答えなんか出るわけないんだから

495 ：デフォルトの名無しさん：2013/01/01(火) 22:08:05.19

略称系のposにできることから、positionでいいんじゃね？

496 ：デフォルトの名無しさん：2013/01/01(火) 22:45:41.07

location も loc と略せるが

497 ：デフォルトの名無しさん：2013/01/01(火) 23:00:04.74

locは、一般的でない可能性がある。

498 ：デフォルトの名無しさん：2013/01/01(火) 23:02:41.98

どうでもいいよ
プロジェクト独自のルールを全く前提とせずに誰が読んでもすぐわかるコードなんて幻想

499 ：デフォルトの名無しさん：2013/01/01(火) 23:16:06.39

>>497
一般的です。

500 ：デフォルトの名無しさん：2013/01/01(火) 23:22:58.96

どちらでもいいと思いうけど、厳密に使い分けるなら自分ならこう定義するかな
Positionはあるモノの位置を表し、そのモノ重視で考え、その位置は複数のモノが存在する
単純にそのモノの位置を表すのに使う
例：ウインドウの位置

Locationはあるモノの位置を表し、その位置重視で考え、その位置は唯一のモノしか存在しない
Locationには探しだしてきた、見つけた位置ってニュアンスも含まれるから
それがその位置に設置できるかどうか判断するような場合が必要ならこれを使う
例：メモリ上の位置

501 ：デフォルトの名無しさん：2013/01/02(水) 00:24:55.56

>>500
だからそんな一人善がりの妄想で使い分けして意味があるのかと。

502 ：デフォルトの名無しさん：2013/01/02(水) 00:31:34.40

しかし、全然常識外れの議論が横行してるから、
こっちがちゃんと論拠まで添えてこの言葉のニュアンスはそうじゃなくてこうなんですよと
整理してるのに、人の話を全く聞かずに相変らずトンデモ話を展開する馬鹿、
言い負かされると「どうでもいい」とか言って自分の恥をないことにしたがる馬鹿、
このスレって本当ロクでもない奴が多いよな。

503 ：デフォルトの名無しさん：2013/01/02(水) 01:30:03.07

そう？
500のレスした者だけど
offとoutの違いみたいな感じで、英語的に的を射た考え方だと思ったけどな
Positionには方角や地位的なニュアンスもあるから、そのモノ視点
Locationは色んなものが存在する中に存在する、そのモノの位置視点
判りやすいけどなあ

504 ：デフォルトの名無しさん：2013/01/02(水) 01:31:37.06

肝心の主張内容がお前から出た言葉のみでそもそも論拠じゃないしな

505 ：デフォルトの名無しさん：2013/01/02(水) 04:33:36.00

このスレで初めて勉強になった

506 ：デフォルトの名無しさん：2013/01/02(水) 05:32:55.87

>>502
それお前

507 ：デフォルトの名無しさん：2013/01/02(水) 09:14:40.71

>>502
自分のレス番と、トンデモ話を展開する馬鹿のレス番をそれぞれ晒せ

508 ：デフォルトの名無しさん：2013/01/03(木) 05:50:03.86

ググったら、YAHOO! ANSWERSのページが最初の方に出てきて、おおよそ

locationは対象の位置それ自身を示すものだが、

positionは、座標軸を決めた上での対象の位置を表す数値を表しているだけで、
座標軸が変わると、同じ位置を表すのに異なる数値となるっぽいもの

的に読めた。ほんとかどうかは知らん

509 ：デフォルトの名無しさん：2013/01/03(木) 14:52:46.81

location = 地点, locate(英地点を定める)の名詞
position = 位置、姿勢, poser(仏置く)の名詞

結論 : どっちでもいい

510 ：デフォルトの名無しさん：2013/01/03(木) 14:54:01.84

まだ強弁するのか。
馬鹿は死ぬまで治らないって本当なんだな

511 ：デフォルトの名無しさん：2013/01/03(木) 14:57:01.02

>>510
だから、自分はどのレス番で、強弁する馬鹿はどのレス番か、はっきりさせろ

それとも、自演してるから明かせないのか？

512 ：デフォルトの名無しさん：2013/01/03(木) 15:01:46.38

そうやって問題を別の問題に摩り替えて誤魔化そうとする
馬鹿の常套句だな

513 ：デフォルトの名無しさん：2013/01/03(木) 15:10:50.67

それお前

514 ：デフォルトの名無しさん：2013/01/03(木) 15:29:15.65

location は住所
position は緯度経度高度

というニュアンスで使っている

515 ：デフォルトの名無しさん：2013/01/03(木) 16:07:52.48

location = あの店の中のどこかに居る
position = あの店の奥の左の柱の右角に立っている。

516 ：デフォルトの名無しさん：2013/01/03(木) 16:37:01.10

location = おっぱい
position = ちくび

517 ：デフォルトの名無しさん：2013/01/06(日) 15:52:32.06

作業の最初にすべきことを定義したメソッドの名前
　initialize
　setup
　など

作業の最後にすべきことを定義したメソッドの名前
　cleanup
　tear_down
　など

他にもあるだろうけど、それぞれニュアンスの違いって何かあるの？
例えば、ある状況では cleanup よりも tear_down の方が
処理の内容をより良く表しているとか。

518 ：517：2013/01/06(日) 15:58:01.39

ごめん、質問がよろしくなかった。

・作業の最初に、その作業で使うリソースを準備するためのメソッドの名前
・作業の最後に、使ったリソースを片付けるためのメソッドの名前

という事にして。

519 ：デフォルトの名無しさん：2013/01/06(日) 16:15:41.10

>>517
対象によってはそういうこともあるかもしれないね、としか言えない。
名前付けに迷ってるんなら対象も含めた相談にしてもらうのがいいと思う。

520 ：デフォルトの名無しさん：2013/01/06(日) 16:42:38.71

setup / tear down はテスティングフレームワークにおけるテスト環境作り
でしか見たことがない気がする。

521 ：デフォルトの名無しさん：2013/01/06(日) 16:44:12.96

pre prepare construct create build make open begin allocate
post dispose finalize close end free delete destroy

522 ：デフォルトの名無しさん：2013/01/06(日) 19:35:21.80

uninitialize もあるのだよ・・・

523 ：517：2013/01/06(日) 22:24:15.93

>>519
いや、今とくに何か困っている訳ではないんだ。

>>520
じつはテスト駆動開発の勉強をしてて、この単語に出会い、
なんで tearDown なんてマイナーな言葉を使うんだろと思って質問した。

他にも分かりやすい言葉があるだろうに、何か特別なニュアンスでもあるのかなと。
ついでに他の言葉の使い方なども分かればいいなと思って、広い質問の仕方をした次第。

もしかして、テスト対象で使ってる識別子とダブらないように、
わざとマイナーな言葉を使ってる？
それにしては setup はいたって普通だけど。

524 ：デフォルトの名無しさん：2013/01/07(月) 01:14:30.95

>>522
deinitializeじゃないのか？

525 ：デフォルトの名無しさん：2013/01/07(月) 01:23:46.52

tearDownなんて見たことないけど、辞書を見た感じだと、後始末というより
まとまっているものを部分にバラすというニュアンスのようだから、
参照を解放して依存関係を解消するとか、そういった感じの処理なんじゃないのかね。

526 ：デフォルトの名無しさん：2013/01/07(月) 21:15:44.32

>>524
deinitializeだとinitialize（の効果）を取り消して元に戻す、的な意味になる
uninitializeは意味が正しいかどうか知らないが、MSは使っていた
最近は・・・といっても2、3年前程度だが、setup/finalizeが多かったと覚えている
なんつーか、流行りモノだね

527 ：デフォルトの名無しさん：2013/01/07(月) 21:19:28.33

>>518
ん？よく見たら初期化/後始末関数のネーミングが欲しいわけではないのか

・作業の最初に、その作業で使うリソースを準備するためのメソッドの名前
　AllocateResources

・作業の最後に、使ったリソースを片付けるためのメソッドの名前
　DeallocateResources

でいいんじゃね

528 ：デフォルトの名無しさん：2013/01/07(月) 21:21:26.35

>>526
修正
流行ってたのはsetup/filanlizeじゃなくて、setup/cleanupだったわ

529 ：517：2013/01/07(月) 22:44:44.35

>>527
誤解させたようで、ごめん。
ネーミングが欲しいわけでもないんだ。

>>518 の用途で、>>517 のような名前や、
それ以降のレスで挙がったような名前がよく使われるけど、
ニュアンス的に使い分けるものなのかな？と。

発端は >>523 。
teardown なんて他では見ないけど、
特別なニュアンスでもあるのかなと疑問に思ったから。

530 ：デフォルトの名無しさん：2013/01/07(月) 22:52:05.33

具体的に何をするかを表さなくていい場合で、
基本的に一度だけ実行するものは initialize/finalize(設計次第で省略されることも) でいいかと。
ただ、この組み合わせは使用者がこのメソッドの処理内容を考えず、単純にそうするといったレベルで扱っていいものに限られる。
リソースがどうのこうのっていうのを意識させなければならないなら、普通にイメージ通りの英単語を選んでやればいい。
load_res/unload_resとかいろいろ思いつくだろう。

531 ：デフォルトの名無しさん：2013/01/07(月) 23:07:54.60

tear down は set up に対応して、 up と逆の意味を持つ down が含まれて、
かつ、終了/後片づけのニュアンスがある熟語を選んだと想像。

532 ：デフォルトの名無しさん：2013/01/08(火) 16:11:08.93

>>529
特に使い分けるものはない・・・と思うが、考えてみればsetupってinitializeより先に行うものだよな
アプリなりOSを導入して使用できる状態にすることはセットアップ
使用を開始してから初期状態に戻すことが初期化だよね
コンストラクタが「setup」であり、デストラクタが「cleanup」であると考えれば、
「initialize」は使う場所が無いな

533 ：デフォルトの名無しさん：2013/01/08(火) 19:29:01.68

>>5332
逆だな
initializeの中でいろいろ情報集めて、その情報をもとにsetup
setupは隠ぺいされるもの

534 ：517：2013/01/08(火) 19:31:30.64

>>532
> 考えてみればsetupってinitializeより先に行うものだよな

確かに。

> コンストラクタが「setup」であり、デストラクタが「cleanup」であると考えれば、
> 「initialize」は使う場所が無いな

理屈の上ではね。

実際は、コンストラクタでセットアップ的な処理の一部、
例えば動的メモリやソースなどの確保処理はすべきじゃないから、
必然的に残りのセットアップ処理は別関数にして後で呼ばなきゃならない。
その関数に initialize と命名することは良くある。

俺の中では initialize は局所的な状態の初期化で、
setup は全体の状態の構築というイメージがある。

それで言えば、「setupってinitializeより先に行うもの」と同意見だ。

535 ：517：2013/01/08(火) 19:33:25.65

>>534

>>533 のレスで自分の言葉足らずに気づいた。

> それで言えば、「setupってinitializeより先に行うもの」と同意見だ。

正確に言えば、

setup の中で各 initialize が呼ばれる感じだ。

536 ：デフォルトの名無しさん：2013/01/08(火) 20:31:56.44

>setup の中で各 initialize が呼ばれる感じだ。

それってつまりinitializeするメソッドだね。
わざわざ名前変えてわかりにくくする必要はないと思う。

537 ：デフォルトの名無しさん：2013/01/08(火) 20:54:40.95

initialize: 対象を削除して白紙にする
setup: 対象を現場で構築して使用可能にする

538 ：デフォルトの名無しさん：2013/01/08(火) 21:02:53.95

Initialize > 初期化
setup > 構築・設定
って感じで捉えてる。
setupメソッドの中で初期化するためにInitializeメソッドを呼ぶ感じだと思う。

539 ：デフォルトの名無しさん：2013/01/08(火) 21:32:21.87

setupって設計ミスだろ
普通はsetXXXで構築するからSetupメソッドなんて無いんだけどな

540 ：デフォルトの名無しさん：2013/01/09(水) 00:16:04.42

>>534
> 実際は、コンストラクタでセットアップ的な処理の一部、
> 例えば動的メモリやソースなどの確保処理はすべきじゃないから、

え？なんで？
むしろコンストラクタでこそ行うべき処理だろ。 RAII っていうぐらいだし。

541 ：デフォルトの名無しさん：2013/01/09(水) 01:18:11.01

>>540
ダメだったのは、例外処理の機構が組み込まれる前のＣ＋＋かな。
知っての通り、コンストラクタは戻り値を返せないから、問題が
起きたとしても呼び出し側にその情報を伝える手段が乏しかった
ため。
とは言え例外処理が組み込まれて以降でも、コンストラクタ中で例外
が発生するとデストラクタが呼び出されないのでリソースのリークが
発生する可能性があるため、コーディングが面倒になる。
結果、できればコンストラクタで複雑な処理や例外が発生する可能性
のある処理はすべきでないとする流儀がある。

542 ：デフォルトの名無しさん：2013/01/09(水) 01:28:52.93

やっぱコンストラクタでやっていいのか
安心した

543 ：デフォルトの名無しさん：2013/01/09(水) 01:43:20.59

C#とかでユーザーコントロールとか作ると、実質、IDEの関係で引数なしのコンストラクタしか使えないから
何か外部からパラメータやオブジェクト渡して初期化しようとすると、仕方なくSetupみたいなメソッドを
作ってしまうことはある。

544 ：デフォルトの名無しさん：2013/01/09(水) 03:31:43.90

>>541
[迷信] コンストラクタから例外を送出してはならない
http://www.kijineko.co.jp/tech/superstitions/dont-throw-exception-from-constructor.html

スマートポインタを使えば面倒でもなんでもない。
「スマートポインタを使わない」という（アホな）流儀が未だに存在するのはまことに遺憾ながら認める。

545 ：デフォルトの名無しさん：2013/01/09(水) 04:41:10.60

根本はgoto禁止みたいなアホルールのせいでしょ？ｗ

546 ：デフォルトの名無しさん：2013/01/09(水) 08:35:10.64

>>545
荒れるからそんな話持ち出すな

547 ：デフォルトの名無しさん：2013/01/09(水) 10:47:28.77

gotoなんか使いどころが確立してるから持ち出したって荒れんわ

548 ：デフォルトの名無しさん：2013/01/09(水) 10:58:32.53

日本語の「初期化」っていうのがあらゆるニュアンスを殺してるっていうか、名前としてふさわしくない気がしてきた。
しかしこれを「準備」とか「初期設定」に言い換えてもなんか嫌。
つまり、最初にやるべき一連の処理という概念そのものがあやふや過ぎて、名前を付ける対象として不適切。

549 ：デフォルトの名無しさん：2013/01/09(水) 19:00:31.17

オブジェクト（インスタンス）を宣言したばかりの状態「Object x;」
この状態は既に初期設定が済んでいる状態（OSのセットアップが済んだ状態）なのか、
それとも済んでいない状態なのか、どちらであるべきなんだろうか
特にC++でいえば、コンストラクタはそれが成功/失敗したかどうかを返せないので、
　Object * pNewValue(Object::TryCreate()); // Object * (static) Object::TryCreate() (nullable)
みたいに動的生成関数を用意するか、
　Object newValue;
　newValue.Try初期設定(); // bool Object::Try初期設定()
を用意するか

ここまで書いて「あ、これ命名に関係ないわ」と気付いた

550 ：デフォルトの名無しさん：2013/01/09(水) 22:33:02.81

>>549
> 特にC++でいえば、コンストラクタはそれが成功/失敗したかどうかを返せないので、

例外があるだろ。そんなめんどい細工が要るのは特殊な状況（環境）だけ。

551 ：デフォルトの名無しさん：2013/01/09(水) 22:46:08.16

例外は文字通り例外的な事が起こったことを知らせるためのものだから、
単に処理の成否を伝えるためだけに使わざるを得ないのは、
もしかしたら設計をミスっていることを示唆しているのかも知れん。

552 ：デフォルトの名無しさん：2013/01/09(水) 22:48:55.34

>>551
おまいはよく分かっている

553 ：デフォルトの名無しさん：2013/01/09(水) 22:51:25.13

とりあえずC++でエラーを例外として投げるのは一般的じゃないし、好まれていないし、あまり見ない
そもそもC++では例外自体が好まれていない。例外が投げられたら投げっぱなしが基本

554 ：デフォルトの名無しさん：2013/01/09(水) 22:54:25.89

Javaみたいに例外はキャッチして処理すべきものとして作られている言語はともかく、C++でそれはない
boostのlexical_castみたいに文字列のパースに失敗したら例外を投げる、みたいな関数は「クソ面倒くせぇ」と感じる

555 ：デフォルトの名無しさん：2013/01/09(水) 22:55:24.51

スレ違い
他所でやれ

556 ：デフォルトの名無しさん：2013/01/09(水) 23:20:55.76

>>549-554 ↓こちらへどうぞ。
例外を正しく使えないプログラマ多いね。その7
http://kohada.2ch.net/test/read.cgi/prog/1306646249/

557 ：デフォルトの名無しさん：2013/01/15(火) 23:17:54.32

XXXからYYYへのマップ・ディクショナリにつける変数名をお願いします。
XXXYYYs
それか、XXXを無視して単に
YYYs
どんな感じがいいでしょうか？

558 ：デフォルトの名無しさん：2013/01/15(火) 23:22:06.78

>>557
どっちも間違い
重要なのは中身じゃなくて目的

559 ：デフォルトの名無しさん：2013/01/15(火) 23:23:09.55

マップ・ディクショナリってなんですか。ググっても出てきません。

560 ：デフォルトの名無しさん：2013/01/15(火) 23:29:36.95

連想配列のことかな？

561 ：デフォルトの名無しさん：2013/01/16(水) 00:03:03.62

>>559,560
連想配列の事です。
>>558
目的ですか？目的は単にXXXの値をYYYの値に変換することです。

562 ：デフォルトの名無しさん：2013/01/16(水) 00:05:19.76

例としてXXXが数値の国コードでYYYが文字列の国名とかで、
国コードを対応する国名に変換したいだけです。

563 ：デフォルトの名無しさん：2013/01/16(水) 00:09:57.96

XXX2YYY[ key ]
YYYByXXX[ key ]

564 ：デフォルトの名無しさん：2013/01/16(水) 00:16:16.03

YYY[XXX]

565 ：デフォルトの名無しさん：2013/01/16(水) 00:20:12.52

>>562
だから、その例ならたとえばCountryNameTableみたいな名前を付けるでしょ。

>>558の言うとおりで、名前は結局そいつがどんな目的を担う何者であるかに
注目してそれが分かるような付け方をすべき。

「XXXからYYYへのマップ・ディクショナリ」なんて情報だけから命名しようなんて
センスがちょっと狂ってる。

566 ：デフォルトの名無しさん：2013/01/16(水) 00:43:58.19

>>565
じゃ、目的は変換ってことで、>>563みたく2(to)はさんだり、もうちょっと修飾
したほうがいいってこと？

>>563じゃ長いなと思ったのので、>>564みたな使い方になるわけで、
単にYYYでいいかなと思ったしだいです。まぁ、YYY[XXX]の場合、XXXに国コード渡すなんてことは
ジェネリックス型のクラス使うので、名前からわかりませんが。

567 ：デフォルトの名無しさん：2013/01/16(水) 00:46:47.43

いやだから今説明したじゃん...

568 ：デフォルトの名無しさん：2013/01/16(水) 00:51:35.48

>>CountryNameTableみたいな名前を付けるでしょ。
俺は末尾にTableの変わりに複数形のsをつけたわけです。君のと大差ありませんが？
とりあえず、どっちも、国コードを渡すって事は失われて。

569 ：デフォルトの名無しさん：2013/01/16(水) 01:03:22.05

つか、Java・C系ではマップ、.NETはディクショナリと、他で連想配列とか呼ばれるけど、
これらの使い方はXXXとYYYの対応・変換をつけることだろ？
>>「XXXからYYYへのマップ・ディクショナリ」なんて情報だけから命名しようなんて
>>センスがちょっと狂ってる。
対応・変換以外に何をすると思ってんの？大丈夫？

570 ：デフォルトの名無しさん：2013/01/16(水) 01:16:26.24

大丈夫？って上から目線で言われても困るし、まあこの手の御仁に説明してもわかるとも思えんが。

>>569みたいな人は、たとえば日常生活で「水と調味料と麺をラーメンに変換する店」
みたいな表現をするのかね。

>>569はそうかもしれないが普通の人はそんなまどろっこしい呼び方はしない。
普通の人は普通にそれを「ラーメン屋」と呼ぶ。

それが>>565に書いた「結局そいつがどんな目的を担う何者であるかに
注目してそれが分かるような付け方をすべき」の意味するところ。

571 ：デフォルトの名無しさん：2013/01/16(水) 01:23:40.01

>>570
だから、まどろっこしいと思ったから、
>>557の***最初の質問***で
おまえのTableを末尾につけるかわり単に複数形にするだけでXXXsでいいとおもう？っ聞いてんだろ・・・
何をおまえは言ってんだ・・

572 ：デフォルトの名無しさん：2013/01/16(水) 01:37:27.06

君が時刻表を「発車時刻たち」、献立表を「献立たち」と言い換えても違和感を
感じない人ならそれでもいいんじゃない？

573 ：デフォルトの名無しさん：2013/01/16(水) 01:43:42.02

>>572
その例え方は何か違う気がするぞ

574 ：デフォルトの名無しさん：2013/01/16(水) 03:42:43.29

>>570
あんたがアホだわ

575 ：デフォルトの名無しさん：2013/01/16(水) 06:07:37.49

指摘自体は尤もだがそんな事初めからわかってたってオチか
振り上げたこぶしの下ろし方がわからず
どうにか間違いに仕立てようとあれこれ画策してるわけか

576 ：デフォルトの名無しさん：2013/01/16(水) 06:11:27.65

LUT使うようなときは、だいたいget_country_name(int country_code)みたいな関数経由にするから、
配列名なんてtableだけで済ませちまうなぁ

577 ：デフォルトの名無しさん：2013/01/16(水) 09:46:32.06

変数名に連想配列であることを明示したいのであれば、
システムハンガリアンの作法にのっとるべきだろう。
よって map_YYY[XXX]

578 ：デフォルトの名無しさん：2013/01/16(水) 11:37:45.06

公開関数の内部で使う変・関数数とかだと、結構泥臭い名前になっちゃいがちだよね

579 ：デフォルトの名無しさん：2013/01/16(水) 11:43:38.42

コード内でどう扱われている部分なのかわかりにくい
実際のコード書いてほしい

580 ：デフォルトの名無しさん：2013/01/16(水) 22:59:27.54

>>573-575
これが「バカの壁」なんだな。

「XXXからYYYへのマップ・ディクショナリ」なんて情報（だけ）から
命名しようという考え方がそもそも間違っている、というのは分かってる人には
何を当たり前のことをって話だと思うんだが、バカの壁の向こうの住人には
こういう当たり前の話がまったく通じない。

581 ：デフォルトの名無しさん：2013/01/16(水) 23:33:35.28

アンカー先間違えてねぇ？

582 ：デフォルトの名無しさん：2013/01/16(水) 23:34:02.19

必死すぎるwwwwwwwwwww

583 ：デフォルトの名無しさん：2013/01/17(木) 02:44:54.11

盛り上がっているような何より。俺ルールだと

とあるクラスが？→itemの連想配列を1つだけ持っているばあい、
その連想配列を「items」または「itemMap」またはと命名する

とあるクラスが？→itemの連想配列を2つ以上持っているのであれば、
例えば連想元が「index」と「name」であれば、それぞれ
「indexToItemMap」「nameToItemMap」と命名する

class Simple {
　Map<int, Item> itemMap; // 又はitems
};

class NotSimple {
　Map<int, Item> indexToItemMap;
　Map<String, Item> nameToItemMap;
};

584 ：デフォルトの名無しさん：2013/01/17(木) 18:44:01.06

↑
mapってmapとして動作するの？
itemとして動作するなら最後にmap付けたらおかしいよね
itemなんだから

585 ：デフォルトの名無しさん：2013/01/17(木) 19:26:38.20

おかしくないね

586 ：デフォルトの名無しさん：2013/01/17(木) 19:34:25.20

itemってのは、要素だろ？
mapとかitemsってのは、itemの集合体を表す。

要素一つを表すか、集合を表すかの違い。

587 ：デフォルトの名無しさん：2013/01/17(木) 19:47:02.90

キーを指定して配列が取れるときは複数形にするけど、そうじゃない場合は複数形にはしないなあ.

588 ：デフォルトの名無しさん：2013/01/17(木) 19:59:58.09

それは一般的でない

589 ：デフォルトの名無しさん：2013/01/18(金) 03:38:58.73

俺583だけど、俺も連想配列は複数形を使いたくないという頭がある
複数形を使うようにするばあい、>>583の class NotSimple 内の2つの連想配列の名前をどうしようか迷う
indexToItems？indicesToItems？

590 ：デフォルトの名無しさん：2013/01/18(金) 05:04:02.67

俺は逆だな、複数形にして単純化できるならしたい頭がある
プリ/サフィックスつけるとすると、今度は何をつけるかでまた悩みそうだから。
JavaならMapインターフェースあるし、標準の呼び名であるMapでいいかもしれんけど、
言語・環境毎につけるプリ/サフィックスかえるのかとか、
言語・環境に依存しないような例えばここででてきたTableにするかとかで、悩むのだるいし。

ということで、
>indexToItems？indicesToItems？
を議論しよう。俺はこの場合、今までindexToItemsを使ってたな

591 ：デフォルトの名無しさん：2013/01/18(金) 05:55:26.07

俺はitemsかindexToItem

592 ：デフォルトの名無しさん：2013/01/18(金) 08:18:46.97

>>591
>>583のNotSimpleではどうする？itmesは一つしか宣言できないぞ

593 ：デフォルトの名無しさん：2013/01/18(金) 08:23:52.58

だからindexToItem

594 ：デフォルトの名無しさん：2013/01/18(金) 08:43:04.20

複数あったら変えるという時点で破綻だ

595 ：デフォルトの名無しさん：2013/01/18(金) 08:49:57.48

全然

596 ：デフォルトの名無しさん：2013/01/18(金) 08:57:21.46

俺も基本的に>>583と一緒
接尾辞のMapつけない点以外は

597 ：デフォルトの名無しさん：2013/01/18(金) 10:09:03.32

ofを使うと英語っぽくなる

int i = zip_code_of["○○町"]; // ○○町の郵便番号
string[] s = country_names_of["Asia"]; // アジアの国名(複数)

598 ：デフォルトの名無しさん：2013/01/18(金) 11:02:51.04

ネイティブのコードってあんまりof使われない気が

599 ：デフォルトの名無しさん：2013/01/18(金) 11:14:52.13

id_of_colorとかいかにもファッキンジャップ臭がする

600 ：デフォルトの名無しさん：2013/01/18(金) 11:24:19.72

index ofとか見たことない？
ofの後に指定されたもののindexを返す

601 ：デフォルトの名無しさん：2013/01/18(金) 11:36:06.41

>>599
id_of_colorじゃなくて、color_id_of["Blue"]

602 ：デフォルトの名無しさん：2013/01/18(金) 13:50:50.88

そういう名前は配列じゃなくて関数（やマクロ）につけるべきじゃないのか？

603 ：デフォルトの名無しさん：2013/01/18(金) 15:08:40.54

colors
zipCodes

604 ：デフォルトの名無しさん：2013/01/18(金) 18:55:55.50

index_ofは関数名じゃないのかな
これが変数名だとしたら、なんつーかオシャレすぎる
indexからcolorを取得する関数にしても、最近はgetColorByIndexみたいにByを使うことが多いが

605 ：デフォルトの名無しさん：2013/01/18(金) 20:24:11.22

ofを使う使わない以前に添字がついたときのみ意味が通る変数名なんてあり得ない。
さすがにネタだろうと思ったら何かマジで言ってるっぽいから怖い

606 ：デフォルトの名無しさん：2013/01/18(金) 22:30:32.57

いや、冗談なんですけどね
連想配列って特別な配列ってわけじゃないんだから専用の名前なんて要らないじゃん
>>603ので十分だ

607 ：デフォルトの名無しさん：2013/01/19(土) 04:29:20.11

>>580
TONさんまだ生きてたのか

608 ：デフォルトの名無しさん：2013/01/19(土) 04:31:38.15

① Key：数字、Value：色
② Key：名前、Value：色
この2つの連想配列が1つのスコープに存在するときの、それぞれの命名方法はどうするの？

609 ：デフォルトの名無しさん：2013/01/19(土) 04:34:27.19

なんでスコープ分けないの？

610 ：デフォルトの名無しさん：2013/01/19(土) 04:40:22.33

>>608
そんなもん一つに纏めてしまいましょうで終わり

611 ：デフォルトの名無しさん：2013/01/19(土) 06:39:04.61

① Key：数字、Value：色
② Key：名前、Value：数字

612 ：デフォルトの名無しさん：2013/01/19(土) 06:53:08.93

>>611
そんな間抜けな状況は20行程度で終わるはずだから c1 c2 でいいよ

613 ：デフォルトの名無しさん：2013/01/19(土) 06:55:24.78

ボツ

614 ：デフォルトの名無しさん：2013/01/19(土) 07:01:21.45

>>613
こんなアホな状況に対して真面目に名前考える方がアホだぞ？
どうせだれにも読めないクソコードなんだから時間かけるだけ無駄って奴だ

615 ：デフォルトの名無しさん：2013/01/19(土) 07:06:01.37

このスレに君の出番は無いんでお引き取りを。

616 ：デフォルトの名無しさん：2013/01/19(土) 07:09:43.93

実際に困ってるんならともかく>>608 >>611はくだらない屁理屈こねてるだけじゃん

617 ：デフォルトの名無しさん：2013/01/19(土) 07:11:23.89

1 ：デフォルトの名無しさん：2012/09/06(木) 17:19:40.71
クラス名、変数名のつけ方に悩んだら書き込むスレです。

命名規則や設計の善し悪しについて議論するのは基本的に禁止。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。

618 ：デフォルトの名無しさん：2013/01/19(土) 07:14:33.56

ただの質問に見えたが屁理屈だったのか
詳しく説明してくれ

619 ：デフォルトの名無しさん：2013/01/19(土) 08:05:21.95

>>597
今度使ってみるわ

620 ：デフォルトの名無しさん：2013/01/19(土) 11:27:10.30

colorsByIndex
colorsByName

621 ：デフォルトの名無しさん：2013/01/19(土) 14:32:51.49

C++で優先度つきキューを実装してるんだけど、
データを格納するためのメンバ変数の名前を何にしようかと考えてる。

今はこのキューを使う側のプログラムのテストのためにモックとして作ってて、
キューの内部では処理速度は考えずに std::list クラスを使ってる。
キューにデータをプッシュする度にリストの先頭から検索して
ちゃんとソートされるようにデータを配置する。

で、そのデータを格納するメンバ変数の名前なんだが、
最初は適当に item_list とか data_list とか考えた。

でも、今はモックとして作るが、実際の運用では処理速度が求められるから、
内部の実装は恐らく平衡二分探索木あたりを使うことになるだろう。
あるいは、もっと運用に適したデータ構造があるかもしれん。
そうすると、item_list や data_list ではおかしい（というか紛らわしい）。

まぁ、その時になったら名前を考えてリファクタリングすればいいかもしれんが、、
結局いつかは適切な名前を付ける必要があるから、今から候補は考えておきたい。

今のところ sorted_items という名前がひとつ思い浮かんだんだが、
他に何かあるだろうか。

622 ：デフォルトの名無しさん：2013/01/19(土) 14:47:41.32

sorted_hoges、いい名前じゃん。
特にソートされることを強調する必要もなければ単にhogesでもいいと思う。

623 ：デフォルトの名無しさん：2013/01/19(土) 15:01:12.73

>>621
実際の運用では優先度ごとにキューを並べる可能性もあるので
ソートすること前提とか、メンバ変数は一つだけなのが前提とか
それすらも怪しい。

現状に合った名前ということなら>>622が言うようにhogesでいいと思う。
具体的にはitems, tokens, packetsみたいな感じで。

624 ：デフォルトの名無しさん：2013/01/19(土) 16:06:10.15

>>623
> ソートすること前提とか、メンバ変数は一つだけなのが前提とか
> それすらも怪しい。

なるほど、たしかに。

>>622 >>623
ありがと、単純に items にするよ。

625 ：デフォルトの名無しさん：2013/01/31(木) 10:54:55.68

マルチプロセスやマルチスレッドでは fork-join というペアが用語としてよく使われますが、
fork-join に似た他の言葉はありませんか。
joinというとどうしてもSQLのjoinをイメージしてしまうので、よく似た別の言葉がほしいです。

626 ：デフォルトの名無しさん：2013/01/31(木) 11:09:43.23

>>625
俺も同様だったが今は慣れた。SQLんときにjoinが頻発してたように、
マルチスレッドやるなら今後joinいっっっぱい出てくるから自然と受け入れられるようになる。
むしろ、joinで通っているものを別のものにしてしまうことの問題について考えてほしい。

627 ：デフォルトの名無しさん：2013/01/31(木) 11:18:08.85

とある情報系の絵本ではフォークとスプーンという言葉が使われていた。

628 ：デフォルトの名無しさん：2013/02/01(金) 07:49:51.88

ログメッセージの書き方の質問もここで良いの？

629 ：デフォルトの名無しさん：2013/02/01(金) 08:15:40.56

今閑古鳥だからいいよ

630 ：デフォルトの名無しさん：2013/02/01(金) 12:49:21.25

じゃ、お言葉に甘えて。

アプリケーションをプログラムしていて、
デバッグ用にエラーメッセージや変数の変化の推移などをログとして
ファイルに記録する機能を作ってるんだが、
英語のエラーメッセージの主語って何するのが普通なの？

たとえば「テクスチャオブジェクトの作成に失敗した。」というメッセージの場合、
さすがに I や we ではおかしいよね。
かといって it でもなんか違和感あるし。

あと、「データファイル "パス" を見つけられなかった。」というメッセージなどで、
文の最後にパスを引用符で囲って記述するんだけど、
この場合、ピリオドって引用符の外に出すんだよね。
（普通の会話の引用符などだと中に入れるけど）

ちなみに、日本語で書けというアドバイスはもっともだが、
今は英語で書くというのが前提なんだ。

631 ：デフォルトの名無しさん：2013/02/01(金) 15:24:17.11

主語なしで動詞から始めることが多いんじゃない。
海外製ソフトのログとか更新履歴はたいていそうだよね。

Failed to create a texture object.
Couldn't find a file "...".

とかなんとか。

632 ：デフォルトの名無しさん：2013/02/01(金) 16:03:40.75

テクスチャオブジェクトの作成に失敗した
↓
テクスチャオブジェクトの作成は失敗した

明確な主語はある。あとは英語で書けるかどうかだけ

633 ：デフォルトの名無しさん：2013/02/01(金) 17:37:42.09

当たり判定の補正値の変数名に困っています。
ちなみにバウンディングボックスで判定を取るつもりでいます。

634 ：デフォルトの名無しさん：2013/02/01(金) 19:09:15.50

bounding boxの補正値と言ってもいろいろあるから、それだけの情報で名前をつけろと言われても

635 ：630：2013/02/01(金) 19:18:05.44

>>631
> 主語なしで動詞から始めることが多いんじゃない。

なるほど、主語は省くのか。

>>632
たしかに言い方を変えれば主語は明確になるけど、
安易にこの手の言い換えをすると、ちょっと修飾するだけで
頭でっかちの文になるじゃん。

たとえば「頂点シェーダー用のシェーダーオブジェクトの作成は失敗した」
==> Creation of a shader object for vertex shader failed.

で、頭でっかちはキモいから、意味の主体を後ろに持ってくると、

==> It failed creation of a shader object for vertex shader.

この It をどうしようかと、最初の疑問に戻ってくる。

636 ：デフォルトの名無しさん：2013/02/01(金) 19:24:34.39

a vertex shader objectでええやん

637 ：デフォルトの名無しさん：2013/02/01(金) 19:32:13.36

>>630
自分のPCのCドライブを"*.log"で検索してみるんだ。Iやweを避ける表現がいろいろ見つかる。
Vertex shader object creation failed.
Unsuccessful creation of a vertex shader object.
Failed to create a rtex shader object.
などなど。

ピリオドを引用符の外に書くのはピリオドがパスの一部だという誤解を防ぐため。
外に書くべき。

638 ：デフォルトの名無しさん：2013/02/01(金) 19:58:33.64

日本語を直訳するんじゃなくて、見やすい表現やわかりやすい表現にしよう

639 ：デフォルトの名無しさん：2013/02/01(金) 20:06:41.96

>>635
完成した英文にすることにこだわらなくてもいいんじゃないかね。
Creation Failed: Vertex shader object.
みたいな書き方でもいい。

640 ：630：2013/02/01(金) 20:29:40.50

>>636
ちょっと修飾するだけで頭でっかちの文になる
==> 主体を後ろ持ってくる
==> 結局、主語をどうしようかという問題が出る

という事を説明するために出した例なんで、
この例文自体にとくに意味は無い。
ぱっと思いついただけ。

>>637
避け方以前に、主語を避けるのか付けるのか、
普通はどちらなのかがまず知りたかったんだ。
避けた方が良いよねという事が分かったんで、
テクニックは *.log も含めて色々調べてみるよ。

> 外に書くべき。
分かった。

>>638
うん、心がけるよ。

>>639
ごめん、ちょっとは拘りたい。
この手の英語の表現方法に興味がわいてきた、というのもある。

スレチ気味な質問につきあってくれて、みんなありがと。

641 ：デフォルトの名無しさん：2013/02/01(金) 21:43:48.96

日記とかも、動詞で始めたりするよね。
logという意味では同じか。

642 ：デフォルトの名無しさん：2013/02/01(金) 23:24:09.06

こういう場合、その失敗したとか、成功したとかの実行者が主語になるね
つまりIが主語なんだけど、そのIはLogを吐き出している実行ファイル（exe）やプログラムね
対話だと思えば判りやすいんじゃないかな

ヘッダのコメントでも
This function returns an integer value obtained by adding the two arguments specified. みたいに書かずに
Returns an integer value obtained by adding the two arguments specified. みたいに書いてあったりするね
その関数の説明だから、いらんよね

643 ：デフォルトの名無しさん：2013/02/01(金) 23:43:34.31

manの内容も動詞から始まってる事多いな
主語がコマンドやオプションであると明確だから
そういう場合は英語でも主語を省略するんだね

644 ：デフォルトの名無しさん：2013/02/02(土) 11:52:03.92

無生物主語っていう概念に気付くと便利だな。

645 ：デフォルトの名無しさん：2013/02/02(土) 14:09:05.63

今話題になってるのはブッシュ（←なぜか変換できない）構文じゃなくてただの
主語の省略。

知ったかぶりして適当なこと言わないこと。

646 ：デフォルトの名無しさん：2013/02/02(土) 14:12:37.05

↑無知

647 ：デフォルトの名無しさん：2013/02/02(土) 14:25:05.67

単に>>644の説明不足だろ
省略出来る主語が関数なりコマンドなりの場合、
主語を省略するために関数なりコマンドなりが主語になる文を作ると便利って話だと思うが
簡単には伝わらない

648 ：デフォルトの名無しさん：2013/02/02(土) 14:26:05.58

>主語を省略するために関数なりコマンドなりが主語になる
言ってて矛盾に気づかないならどうかしてる。

649 ：デフォルトの名無しさん：2013/02/02(土) 14:35:06.62

そもそも今の議論で最初から疑問だったのは、プログラマの書く英文に主語がない
物が多い背景に「（主語を書くのはなんとなくかっこ悪いからw）なるべく主語を使わずに済まそう」
という動機があることを想定していること。

そんな動機なんかないよ。
単純に主語が冗長なケースでそれが省略してあるだけ。

650 ：デフォルトの名無しさん：2013/02/02(土) 14:35:57.60

>>648
関数なりコマンドなりが主語になる文を作って、主語を省略するんだよ
流石にそれが分からないのは読解力がなさすぎ

651 ：デフォルトの名無しさん：2013/02/02(土) 14:42:49.38

>>650
だからそういう意味不明なことを言うのは、>>649みたいに勘違いしてるから。

物主構文を使うのはそれが英文的に自然だからそうしているだけのことで、
"program"とか"code"みたいな主語を使いたくない（だってかっこ悪いからw）みたいな
中二病的動機がある訳ではない。

652 ：デフォルトの名無しさん：2013/02/02(土) 14:45:28.15

っていうか、>>650は物主構文とただの主語の省略の区別がついてないのかね。
両者はまったく別問題。

653 ：デフォルトの名無しさん：2013/02/02(土) 14:48:54.03

俺はそんな事言ってないな
勘違いしすぎ

日本人がそういう文章を作ると
つい日本語的な発想の主語を持った文を作ってしまい
主語が省略不能になりがちで冗長になるので
意識を転換した方がいいとというくらいの話しかしてない

654 ：デフォルトの名無しさん：2013/02/02(土) 14:59:18.68

で？

655 ：デフォルトの名無しさん：2013/02/02(土) 15:00:46.62

誤解して恥ずかしかったからって、ごまかしｲｸﾅｲ

656 ：デフォルトの名無しさん：2013/02/02(土) 20:25:08.85

>>651
失せろゴミ

657 ：デフォルトの名無しさん：2013/02/03(日) 05:27:12.10

入門書等を見てて気になったことがあります。

例えば既存の関数 Foo( ) があったとして、それと同じような機能の自作関数の名前が MyFoo( )、
Foo( ) を拡張するような自作関数を FooEx( ) と名付けたりしています。

また、デザインパターンのサンプルコードでは、クラス等にそのデザパタ名を付ける、
例えばStateパターンなら BarState のような名前にしているのを見かけます。

こういった「My」のようなプリフィクス/サフィックスは、実際のコードでも広く使われる命名でしょうか。
それともこれも一種のメタ構文変数と捉えるべきでしょうか。

658 ：デフォルトの名無しさん：2013/02/03(日) 06:16:51.47

メタだよ

659 ：デフォルトの名無しさん：2013/02/03(日) 06:31:49.59

ありがとう

660 ：デフォルトの名無しさん：2013/02/03(日) 08:11:18.99

FooEx( ) は、使ったことある。

My～( ) とか Bar～( ) は、流石にないな。

661 ：デフォルトの名無しさん：2013/02/03(日) 17:31:39.03

>>657
その条件なら、
FooEx→windowsのAPI
BarState→Javaで～Strategyとかあるはず
MyFoo()→ありえるが、広いスコープでは使われない

662 ：デフォルトの名無しさん：2013/02/03(日) 18:34:43.60

>>660-661
わざわざ実体験＆実例をありがとう

663 ：デフォルトの名無しさん：2013/02/03(日) 18:53:09.92

>>661
My とか Bar はありえないだろ。
何を意味してるかわからないから。

664 ：デフォルトの名無しさん：2013/02/03(日) 18:53:16.58

Myは.NETの同等クラスに足りない機能を実装する際に使ってるね
MyMathとか

665 ：デフォルトの名無しさん：2013/02/03(日) 18:59:27.16

Myを実際に使ってしまうのはVB使いのイメージ

666 ：デフォルトの名無しさん：2013/02/03(日) 19:05:48.98

>>663
～Stateはありえる
本当に「Bar」という単語を使って、Bar～というクラスを作成したりはありえない

667 ：デフォルトの名無しさん：2013/02/03(日) 19:09:23.58

>>663
barは、fooやhogeと並ぶメタ変数構文だよ。

668 ：デフォルトの名無しさん：2013/02/03(日) 19:10:22.27

間違えた、メタ構文変数。

669 ：デフォルトの名無しさん：2013/02/03(日) 19:24:34.67

>>666
>～Stateはありえる

そっちの議論じゃないから。

>>667-668
だから、メタ構文変数自体を実コードに使うかという話をしているんだが…

670 ：デフォルトの名無しさん：2013/02/03(日) 19:25:09.96

え？本当にBarStateって名前をつけるかって？
あり得ないあり得ない

671 ：デフォルトの名無しさん：2013/02/03(日) 19:33:28.78

棒の状態を表すのであれば普通に使うと思うが
そういう話ではないのだろう？

672 ：デフォルトの名無しさん：2013/02/03(日) 19:36:21.44

>>671
すまん、そのケースは忘れてたわ (w

673 ：デフォルトの名無しさん：2013/02/03(日) 19:38:53.89

棒の状態てw

674 ：デフォルトの名無しさん：2013/02/03(日) 19:56:58.27

ゲーム作ってるならありそうか

675 ：デフォルトの名無しさん：2013/02/03(日) 20:08:29.19

棒管理ソフトウェアとか

676 ：デフォルトの名無しさん：2013/02/03(日) 20:24:33.82

ブロック崩し

677 ：デフォルトの名無しさん：2013/02/03(日) 20:30:31.99

>>669
ああ、失敬。
勘違いしてるみたいだけど、-State -Strategy のようなデザパタ名がメタなのかって話

678 ：デフォルトの名無しさん：2013/02/03(日) 20:40:02.20

>>657 から読み返してください。

そもそもなんで、-State -Strategy のような具体的な名前をメタとか
思うのか理解できないけど。

679 ：デフォルトの名無しさん：2013/02/03(日) 20:53:14.58

俺だけかも知れないけど、Myは既存のライブラリとは違うプライベートなライブラリの
パッケージ名、名前空間名、クラス名に付けたりするね。

たとえばMyMathとかMyIOとかといった具合に。

680 ：デフォルトの名無しさん：2013/02/03(日) 20:56:11.38

>>679
>>664

681 ：デフォルトの名無しさん：2013/02/03(日) 20:58:15.61

ああ、失敬。
まあ誰でも考えそうなことだよなやっぱりw

682 ：デフォルトの名無しさん：2013/02/03(日) 21:04:37.63

でもメソッドにMyは付けないな
それより大きな枠でMyを付けるからだけど

683 ：デフォルトの名無しさん：2013/02/03(日) 21:07:03.21

同感。メソッドはないね。

684 ：デフォルトの名無しさん：2013/02/04(月) 00:14:47.31

>>679
俺はMathHelperとかIOUtilsみたいにするなあ

685 ：デフォルトの名無しさん：2013/02/04(月) 00:19:47.73

MyMathは酷いｗ
どんなMathか全くわからんｗ
作者の数学レベルによってはとんでもないゴミクラスかもしれないｗ

686 ：デフォルトの名無しさん：2013/02/04(月) 00:37:28.93

馬鹿ですね。
MathにどんなMathもこんなMathもないと思うが、仮に「こんなMath」のクラスだと
明示する必要があるとして、もちろんそんな場合にMyMathなんて名前は使わないよ。

687 ：デフォルトの名無しさん：2013/02/04(月) 00:44:27.28

MyMathは既存のMathと同じようなもの、というのがよく見て取れる名前だと思うけど

688 ：デフォルトの名無しさん：2013/02/04(月) 00:46:00.51

既存のクラス名などとかぶる場合、MathExのようにExを付けてるけど…

689 ：デフォルトの名無しさん：2013/02/04(月) 00:48:01.11

MyMathもMathExもMathHelperもMathUtilsも
どれも別に問題ないんじゃない？
どれも即座にMathに足りないものを補うものなのだろうなあと判断出来る

690 ：デフォルトの名無しさん：2013/02/04(月) 00:52:17.17

この世界ではありふれた表現だけど初心者には異様に見えるのかもね

691 ：デフォルトの名無しさん：2013/02/04(月) 01:02:37.09

>>687
Exは普通Extendedの略だと思うからMathExはちょっとどうかなと思うけど

692 ：デフォルトの名無しさん：2013/02/04(月) 05:12:22.93

>>690
> この世界ではありふれた表現だけど初心者には異様に見えるのかもね

お前の世界を基準にされても…

693 ：デフォルトの名無しさん：2013/02/04(月) 05:38:22.20

涙拭けよゴミ

694 ：デフォルトの名無しさん：2013/02/04(月) 07:22:11.56

変だと思うのが自分だけと知って慌てているようだ

695 ：デフォルトの名無しさん：2013/02/04(月) 07:42:49.23

Myは誰のだよ糞がって思うし、他人に触られる事を一切想定してないんだろとも思う

Exは超手抜きで何も考えずに名前付けやがったなと思う

-Stateはそのデザパタ使ってるって名前に付けてまで知らせないと多大な影響を及ぼすなら付ければ良い
でもリファクタリングが制限されるから基本的に糞

696 ：デフォルトの名無しさん：2013/02/04(月) 08:38:48.31

じゃあWinAPIのCreateWindowに対して、CreateWindowExはどういう名前にするんだ？
いつものことなんだけど、否定的な意見を書くのはもちろん構わないが、同時に「俺ならこうする」という意見を書かないと議論にならないんだよね

俺はよく使う関数やクラスを namespace my に突っ込んでいる
もちろん、多数参加のプロジェクトではそんなことできないが、自分用に作ったものはmyにまとめてある
仕事で、Mathの延長線上のクラスなりを作成するのであれば、MathExかな

697 ：デフォルトの名無しさん：2013/02/04(月) 08:50:44.94

CreateWindowでいい

698 ：デフォルトの名無しさん：2013/02/04(月) 08:54:01.21

そりゃCreateWindowのままに決まってるだろ
言語仕様上の理由以外にCreateWindowExにすべき理由なんて無い

699 ：デフォルトの名無しさん：2013/02/04(月) 09:00:17.34

特殊なウィンドウを作る関数なら具体的な名前をつけるべきだけど、
CreateWindowExの機能自体はCreateWindowと同じだからな。
オーバーロードの可能な言語ならCreateWindowだろうし、オーバーロードできない言語なら
CreateWindowEx とか CreateWindow2 とか、具体性のない名前のほうがいいケースだろう。

700 ：デフォルトの名無しさん：2013/02/04(月) 10:32:01.29

Win32APIで言うならCreateFileなんて名前と機能が一致してないよね

701 ：デフォルトの名無しさん：2013/02/04(月) 10:52:05.55

ファイルそのものではなくファイルハンドルを作成するのだと自分を納得させている。

702 ：デフォルトの名無しさん：2013/02/04(月) 11:47:36.44

Win32APIなんて長年の互換性のために気持ち悪い事になってるんだから、態々そんなゲテモノを参考にするなって話だな

703 ：デフォルトの名無しさん：2013/02/04(月) 20:05:04.84

>>696
基本的にExなんてサフィックスする命名は手抜きでよくないのはまあその通りだね。
ちゃんと、どの辺りがEx(tended)なのかを明示的に名前に盛り込むべきだと思う。

Myについては、もちろん社内とかグループ内とか自分だけとかで使うプライベートな
ライブラリ以外では使うべきじゃない。

だから俺は>>679でそう書いたつもりだけど、他の人もそんなことは言わずもがなだから
あえて触れてないだけじゃないの？

704 ：デフォルトの名無しさん：2013/02/04(月) 20:14:07.18

そうやって代わりに頭をひねって作った名前も
他人から見れば実際には大差ない代物だから
気にし過ぎという他ない

705 ：デフォルトの名無しさん：2013/02/04(月) 20:40:23.28

何でも名前に盛り込めばいいってもんじゃないし

706 ：デフォルトの名無しさん：2013/02/04(月) 20:43:23.05

勝手に「普通の人は分からないに違いない」と思い込む人っているよね

707 ：デフォルトの名無しさん：2013/02/04(月) 20:48:47.91

著名なライブラリとクラス名かぶらなきゃ何でもいいんじゃね

708 ：デフォルトの名無しさん：2013/02/05(火) 01:15:43.08

>>703
二人以上存在する時点でMyなんて使うなよｗ
未来永劫自分以外がコードを目にしないなら辛うじてMyを使う余地があるだけで
それが守られないならMyを使っていいケースは無い

709 ：デフォルトの名無しさん：2013/02/05(火) 01:33:44.54

いつもいつもきっちりした場面でもないし
共通認識が有れば別に構わん

710 ：デフォルトの名無しさん：2013/02/05(火) 01:38:36.26

そもそも例題内でFooに対して自分が作成したものという意味でmyFooって付けられているだけで
クラスや関数に付けるようなプレフィックスじゃないと思うわ
そのコードを見た人視点であるべきで、そのコードを書いた人視点になってしまう

ってばっちゃが言ってた

711 ：デフォルトの名無しさん：2013/02/05(火) 01:48:24.00

Ownは使う機会はあるかもなー

712 ：デフォルトの名無しさん：2013/02/05(火) 03:20:26.30

まぁ入門書読む初心者にMyを使って良いとか言ってる奴は総じて馬鹿なんだろうな

713 ：デフォルトの名無しさん：2013/02/05(火) 19:39:31.17

>>708
まあこれが馬鹿の壁かなとだけ言っておく。

714 ：デフォルトの名無しさん：2013/02/05(火) 19:54:14.36

My使うなって言ってる奴も、
実はMyがどういう時に使われるか分かってんだろ？

715 ：デフォルトの名無しさん：2013/02/05(火) 20:16:55.16

>>713
こういう場合の「馬鹿の壁」というワードは、どういう意味で使ってるの？

716 ：デフォルトの名無しさん：2013/02/05(火) 20:18:44.84

そういう質問をする時点で

717 ：デフォルトの名無しさん：2013/02/05(火) 20:27:16.33

>>716
失せろゴミ

718 ：デフォルトの名無しさん：2013/02/05(火) 20:32:10.97

図星だったか

719 ：デフォルトの名無しさん：2013/02/05(火) 20:35:53.99

>>718
失せろゴミ

720 ：デフォルトの名無しさん：2013/02/06(水) 00:46:59.78

思考に気をつけなさい、それはいつか言葉になるから。
言葉に気をつけなさい、それはいつか行動になるから。
行動に気をつけなさい、それはいつか習慣になるから。
習慣に気をつけなさい、それはいつか性格になるから。
性格に気をつけなさい、それはいつか運命になるから。
　- マザー・テレサ -

721 ：デフォルトの名無しさん：2013/02/06(水) 01:01:45.05

なるほど、コピペマンなてめえの行動は気にならないってわけだ。

722 ：デフォルトの名無しさん：2013/02/06(水) 01:09:19.31

>>720
失せろゴミ

723 ：デフォルトの名無しさん：2013/02/12(火) 08:38:39.27

結局Myを使うべき理由やシチュエーションってなんだったんだよ？
そんなもの存在しないって事で良いのか？

724 ：デフォルトの名無しさん：2013/02/12(火) 12:22:40.30

>>723
荒れる原因だから、チームの場合は使うなってことだろ、きっと。

725 ：デフォルトの名無しさん：2013/02/12(火) 12:33:53.20

使うべきだなんて誰か言ってたっけ？

726 ：デフォルトの名無しさん：2013/02/12(火) 19:10:40.51

荒らしてんのは一人だけだけどな

727 ：デフォルトの名無しさん：2013/02/13(水) 00:40:11.16

>>725
使うべきとまでは言ってないけど、使ってると言ってる奴はいたな。
俺には、信じられないけど。

728 ：デフォルトの名無しさん：2013/02/13(水) 00:50:47.50

だからそれが「バカの壁」。
君はきっとバカの壁の向こう側の人なんだよ。
どっち側がどうとはあえて言わないけどw

729 ：デフォルトの名無しさん：2013/02/13(水) 00:56:53.60

最近知った言葉かのように「バカの壁」を使いたがる奴こそ、
バカに見えるわw

730 ：デフォルトの名無しさん：2013/02/13(水) 01:02:56.78

よくわからん理屈。

731 ：デフォルトの名無しさん：2013/02/13(水) 04:01:53.38

>>728
失せろゴミ

732 ：デフォルトの名無しさん：2013/02/13(水) 04:12:10.44

>>728
孤独な環境でMy使いまくってるから引くに引けずに他者をバカ呼ばわりか

733 ：デフォルトの名無しさん：2013/02/13(水) 04:18:43.57

>>732
失せろゴミ

734 ：デフォルトの名無しさん：2013/02/17(日) 10:01:07.46

>>733
失せろゴミ

735 ：デフォルトの名無しさん：2013/02/17(日) 10:06:45.48

>>734
失せろゴミ

736 ：デフォルトの名無しさん：2013/02/17(日) 10:22:49.80

>>735
失せろゴミ

737 ：デフォルトの名無しさん：2013/02/17(日) 10:23:43.08

>>736
失せろゴミ

738 ：デフォルトの名無しさん：2013/02/17(日) 21:41:30.18

>>737
失せろゴミ

739 ：デフォルトの名無しさん：2013/02/17(日) 22:01:17.77

>>738
失せろゴミ

740 ：デフォルトの名無しさん：2013/02/17(日) 23:10:56.61

>>739
失せろゴミ

741 ：デフォルトの名無しさん：2013/02/17(日) 23:20:38.53

>>740
失せろゴミ

742 ：デフォルトの名無しさん：2013/02/18(月) 02:24:32.51

>>742
失せろゴミ

743 ：デフォルトの名無しさん：2013/02/18(月) 12:59:38.34

配列で先頭・最後の要素を取得しつつ削除するメソッド名は
shift, pop ですが
単一の変数で、データを取得しつつ削除するメソッド名は
何がいいでしょうか

例えば以下のBool型の this.data というものがあり
this.data を取得しつつ this.data に null を代入するような場合です。

function ???(){
　var n = this.data;
　this.data = null;
　return n;
}

取り敢えず現在は getAndResetData というメソッド名にしています。

744 ：デフォルトの名無しさん：2013/02/18(月) 13:03:59.78

>>743
move

745 ：デフォルトの名無しさん：2013/02/18(月) 13:12:07.75

>>743
pop

746 ：デフォルトの名無しさん：2013/02/18(月) 13:15:25.21

remove

747 ：デフォルトの名無しさん：2013/02/18(月) 13:40:34.19

rc (reac and clear)

748 ：デフォルトの名無しさん：2013/02/18(月) 14:21:06.68

take
takeAway

749 ：デフォルトの名無しさん：2013/02/18(月) 14:38:38.20

後になるほどカスい案しか出てこなくなっててﾜﾛﾀ

750 ：デフォルトの名無しさん：2013/02/18(月) 15:08:57.47

煽るだけのアホはスルーで

751 ：743：2013/02/18(月) 15:12:23.94

>>744-748
ありがとうございます。
全体のコーディング内容から見て
合いそうな選択をしていきたいと思います。

752 ：デフォルトの名無しさん：2013/02/18(月) 15:16:46.86

>>743
transfer

753 ：デフォルトの名無しさん：2013/02/18(月) 20:06:13.08

>>743
日本語で言えば「空にする」でいいと思う。
空にするメソッドが返値を持つなら、何を返すかは自明でしょ。

moveもいいと思うけど、インテルのアセンブラのニーモニックだとmov(e)は
データのコピーだからちょっとミスリーディングかもしれないと思う。

というわけで、
setNull
null （使う言語で可能なら）
nullize

754 ：デフォルトの名無しさん：2013/02/18(月) 20:17:49.45

moveはC++11のmoveのイメージだな
でも、あれは移動元がどうなるかまで保証しないので
それはそれで紛らわしいかもしれない

755 ：デフォルトの名無しさん：2013/02/24(日) 00:27:32.76

staticクラス「Hoge」に対して、同機能のインスタンスを作成して使うクラスってどう命名する？
HogeInstanceとか？

756 ：デフォルトの名無しさん：2013/02/24(日) 00:30:16.84

同機能のインスタンスって何？
命名以前にOOP理解してない臭がするんだけど...

757 ：デフォルトの名無しさん：2013/02/24(日) 01:05:01.91

むしろこういう風に半シングルトン(デフォルトインスタンス)にするだろ
class Hoge {
　public static readonly Hoge Default = new Hoge();
　public void Do() { }
}

758 ：デフォルトの名無しさん：2013/02/24(日) 01:06:08.01

クラス名にInstanceって付けるとはかぶいてるな

759 ：デフォルトの名無しさん：2013/02/24(日) 07:30:32.91

>>756
「同機能の、インスタンスを作成して使うクラス」という意図

staticクラスの実装を、インスタンスを作成するクラスに任せる感じ

760 ：デフォルトの名無しさん：2013/02/24(日) 07:46:49.86

コードでおk

761 ：デフォルトの名無しさん：2013/02/24(日) 08:02:33.64

こんな感じ
static class Hoge {
　private static HogeInstance instance = new HogeInstance();
　public static void Foo() { instance.Foo(); }
}

762 ：デフォルトの名無しさん：2013/02/24(日) 08:44:52.28

HogeImplementation

763 ：デフォルトの名無しさん：2013/02/24(日) 11:04:58.00

HogeImpl だな

764 ：デフォルトの名無しさん：2013/02/24(日) 11:18:11.87

抽象クラスかインターフェイスだよね?
それだと実際の実装クラスがHogeImplImplにならね?

765 ：デフォルトの名無しさん：2013/02/24(日) 11:20:03.67

これ何パターンなの？
実装を交換できるっていう感じなんだよね？

766 ：デフォルトの名無しさん：2013/02/24(日) 11:21:50.01

インタフェースならIHogeImplで

でもまず何がしたくてこういう形にしたのかがよく分からん

767 ：デフォルトの名無しさん：2013/02/24(日) 11:25:27.00

依存する他のクラスを単体テストするために静的メソッドを差し替えるやつでしょ
そこまでしてわざわざ静的メソッドでラップしなくても>>757で十分だとは思うけど

768 ：デフォルトの名無しさん：2013/02/24(日) 11:32:47.36

質問者が明言した意図しか信用しない

769 ：デフォルトの名無しさん：2013/02/24(日) 12:06:56.77

インターフェース　IHoge
抽象クラス　HogeBase

770 ：デフォルトの名無しさん：2013/02/24(日) 13:00:26.64

Java の SL4J の、LoggerFactoryだと、
LoggerFactory の静的メソッドである getLoggerを
インタフェース ILoggerFactory の同名のインスタンスメソッド getLogger に
委譲している気分

771 ：デフォルトの名無しさん：2013/02/24(日) 14:33:24.03

>>759
結局、それだとHogeの仲間のクラス（Hogeと同じ名前の静的メンバを持ってるけど機能が違うクラス）
全体の呼称が決まってないと名前付けられないんじゃない？

仮にそのインターフェイスをIMetaと名付けたとすると、なんかJavaっぽいから、
HogeにIMetaを実装した無名クラスのインスタンスを返す静的メソッドを実装すれば
いいんじゃないんだろうか。

つまり結論は、そもそも質問者が望んでいるような名前はいらんと。

772 ：デフォルトの名無しさん：2013/02/24(日) 16:02:00.35

>>755
ある機能を提供する手段として
インスタンスを作成しないで使えるstatic Hogeと
インスタンスを作成して使う○○があるわけだな。
どっちも同じ機能だし、Hoge2でいいんじゃね。

あるいは、インスタンスを作る方を普通のHogeにして、
staticな方はシステムハンガリアンの流儀に従って sHogeにする。

773 ：デフォルトの名無しさん：2013/02/24(日) 19:52:12.04

>>772
こっちが正解です
具体例出すと、.netでImageAnimatorってstaticクラスがあるんだけど、機能が足りてないんでExImageAnimatorクラスを作った
でも、コントロールの実装で使う際、staticクラスなのも微妙だと思ってインスタンスクラスで実装しようとして名前に迷った・・・

774 ：デフォルトの名無しさん：2013/02/24(日) 20:21:15.94

いやそれstaticでいいじゃん

775 ：デフォルトの名無しさん：2013/02/24(日) 20:31:43.01

PictureBoxのソース見てみるとImageAnimatorを使ってなくて内部でアニメーション実装してたんだ
だからコントロールのアニメーション処理は独立させた方がいいのかと

それにアニメーション処理はやってること同じだからインスタンスクラスにしたら便利なんじゃね？と思い至った

776 ：デフォルトの名無しさん：2013/02/24(日) 20:41:24.95

不正解者はボッシュート

　　　　　　　　ｼｭｯ
　　　　　　| | | | | | | 　　ﾁｬﾗｯﾁｬﾗｯﾁｬｰﾝ♪ﾐﾖﾖﾖｰﾝ…
　　　＿＿＿＿＿＿＿＿.
　　　＼　　∧＿∧ ｱｳｯ　|＼
　　　　＼（； ´∀｀）　　　|　＼
　　　　　　￣￣￣￣￣￣￣￣

777 ：デフォルトの名無しさん：2013/02/24(日) 21:17:19.38

やっぱり普通に考えて質問者がOOPよく分かってないだけのような...

staticで済む（状態を持つ必要がない）ものを無理にインスタンス化できるようにしたら
後で混乱すると思わないのかな。

こういうのこそMyImageAnimatorでいいよ。
っていうか、最初から具体的に質問してれば話はずっと早かったのに。

778 ：デフォルトの名無しさん：2013/02/24(日) 21:25:05.11

でもMSDN見るとImageAnimatorって何か妙な設計のクラスだな。

確かにこれならImageをコンストラクタにとってインスタンス化できるように
作った方が自然なような気もする。

よく読んでないから何か事情があるのかもしれんけど

779 ：デフォルトの名無しさん：2013/02/24(日) 22:37:26.34

>>>777
ImageAnimatorは状態持ってる
staticな配列で

780 ：デフォルトの名無しさん：2013/02/24(日) 22:45:09.31

>>778
スレッドを共有するためだと思う
インスタンスを作るようにしても結局どっかでまとめて管理しないといけないから
ある意味素直な設計

781 ：デフォルトの名無しさん：2013/03/02(土) 03:24:19.88

ある物体が他の物体に近づいていく場合に
表面同士の距離がゼロになるとそれ以上近づけない性質の事は何と言えばいい？

782 ：デフォルトの名無しさん：2013/03/02(土) 03:30:46.88

「それ以上はらめぇ」

783 ：デフォルトの名無しさん：2013/03/02(土) 08:18:05.55

unoverlappability なんて単語は多分ない
実際に英語にあるのは　inability to overlap とかか。

784 ：デフォルトの名無しさん：2013/03/02(土) 08:20:19.45

剛性(rigidity)?

785 ：デフォルトの名無しさん：2013/03/02(土) 09:52:39.21

exclusion

786 ：デフォルトの名無しさん：2013/03/02(土) 13:34:51.76

>>782-785
ありがとう
exclusionにしようかな
長くならないし一番馴染みが有るし

787 ：デフォルトの名無しさん：2013/03/02(土) 13:35:42.94

>>782-785
ありがとう
exclusionにしようかな
長くならないし一番馴染みが有るし

788 ：デフォルトの名無しさん：2013/03/02(土) 13:38:10.86

通り抜ける方は、トンネル効果

789 ：デフォルトの名無しさん：2013/03/02(土) 14:03:08.99

質問は「表面同士の距離がゼロになるとそれ以上近づけない性質の事」なんだから
exclusionじゃなくてexclusivityでしょ。
日本語で言えば排他性。

790 ：デフォルトの名無しさん：2013/03/02(土) 15:18:36.57

>>781
AT-Field

791 ：デフォルトの名無しさん：2013/03/02(土) 15:26:23.06

>>781
keep out
territory
barrier
fence

792 ：デフォルトの名無しさん：2013/03/03(日) 23:05:01.74

座標が与えられて、その座標に回転行列を掛けてから描画する関数の名前を迷ってる
というか回転行列を掛けるという動詞が見つからん
DrawRotationMatrixed(...)とか造語作るのも嫌だしな

793 ：デフォルトの名無しさん：2013/03/03(日) 23:07:00.28

描画関数のオーバーロードの1つでいいんじゃね？

794 ：デフォルトの名無しさん：2013/03/03(日) 23:22:34.07

>>792
無理に詰め込み過ぎだからでしょ。

(1) 中心座標と角度を指定して変換行列（回転行列）を求める関数

(2) 変換行列で座標を変換する関数

(3) 座標（の配列）を描画する関数

全部分けるべき。

795 ：デフォルトの名無しさん：2013/03/03(日) 23:26:06.47

>>792
行列を渡すなら変換は回転とは限らないんじゃないの?
回転のみと決まってるんだったら"行列"は要らないんじゃないの?

796 ：デフォルトの名無しさん：2013/03/03(日) 23:41:21.96

>>792
「掛ける」という動詞が知りたい、というのが質問なのでしょうか。
たとえば「4 に 9 をかける」は英語で multiply 4 by 9 です。
あとは受動態でも何でも変形すれば良いでしょう。

ただ、私も 1>>794 や >>795 に同意です。
ですが、なにか事情があるのでしょう。
とやかく言うつもりはなく、深入りはしません。

797 ：デフォルトの名無しさん：2013/03/03(日) 23:58:20.29

>>792
DrawRotated

798 ：デフォルトの名無しさん：2013/03/04(月) 00:10:24.28

Drawでいいよ別に

799 ：デフォルトの名無しさん：2013/03/04(月) 00:39:58.42

DrawInRotatedSystem

800 ：デフォルトの名無しさん：2013/03/04(月) 00:42:13.11

行列かけるんならDrawAffineでいいんじゃない

801 ：デフォルトの名無しさん：2013/03/04(月) 00:45:48.06

>>792
draw(Point p, Matrix m)

802 ：デフォルトの名無しさん：2013/03/05(火) 13:41:12.20

選択ボタンがクリックされたかどうかを判定するフラグ変数は
selectBtnIsClicked
でしょうか？

803 ：デフォルトの名無しさん：2013/03/05(火) 14:14:35.48

IsSelectButtonClicked

804 ：デフォルトの名無しさん：2013/03/05(火) 14:15:46.36

>>802
クリック対象が選択ボタンだけならclicked
他にもボタンがあるならselectButtonClicked
構造体やクラスが使えるならselectButton.clicked

805 ：802：2013/03/05(火) 14:43:01.41

ありがとうございます

806 ：デフォルトの名無しさん：2013/03/05(火) 14:52:27.76

>>802さんに恨みはないし当てつけるような形になるのは申し訳ないがどうか気にしないで欲しい。

ボタンをbtnとするような略をみると脳内で「のわああ！！！！」ってなる。
今まで何度もこうなったし、今後死ぬまであと何度そうならなきゃいけないのかビクビクしてる。

変数名をヘタにケチって、一体何がどうなるというのだ！！！

807 ：802：2013/03/05(火) 15:12:21.27

サーセン
おっしゃられるその通りです。
昔の慣習が染み付いていて
略語を現在でも結構使ってしまっています。

808 ：デフォルトの名無しさん：2013/03/05(火) 19:53:08.91

クリックなんて用語を使う世界なら、そもそもフラグ変数なんていう前時代的な
ものを使うの止めた方がいいんじゃないの？

本当にフラグ変数なんか使わなきゃならないような世界ならクリックじゃなくて
ダウン/アップでしょ。

bSelectKeyUpとかbSelectKeyDownとかそんな感じ。

809 ：デフォルトの名無しさん：2013/03/05(火) 20:13:39.73

click は「押下して、上がる」ところまでを含むことがあるので、
用途によってはup/downと等価ではなくなるね。

810 ：デフォルトの名無しさん：2013/03/06(水) 00:49:53.09

>>808
> そもそもフラグ変数なんていう
> 前時代的なものを使うの止めた方がいいんじゃないの？

プログラミングに関してはスレ違いだけど
使えばなんだかんだで何にでも応用が効くプログラミングが可能

使わないと
フラグ変数を前時代的などと言ってしまう
勘違いプログラマが考えるようなプログラミングを強制されるだろうね

811 ：デフォルトの名無しさん：2013/03/06(水) 00:59:04.32

クリックをダウンorアップとかいってる時点で
物を知らなすぎる
虚栄を貼りたいお年ごろの駆け出しプログラマ感丸出しで
初々しい

812 ：デフォルトの名無しさん：2013/03/06(水) 01:08:10.26

>>811
失せろゴミ

813 ：デフォルトの名無しさん：2013/03/06(水) 11:49:07.72

ちくしょう、「失せろゴミ」に勝てそうな言葉が見当たらない

814 ：デフォルトの名無しさん：2013/03/06(水) 12:41:55.64

Usellow Gommy さんの AA はまだかね

815 ：デフォルトの名無しさん：2013/03/06(水) 14:21:54.97

>>812
死ねゴミ

816 ：デフォルトの名無しさん：2013/03/06(水) 14:27:35.61

>>815
死ねゴミ

817 ：デフォルトの名無しさん：2013/03/06(水) 18:51:19.06

Item というクラスを継承して、
表示/非表示を切り替えれる機能を付加した ItemEx の名前が思いつかない
なんかいいアイデアない？

818 ：デフォルトの名無しさん：2013/03/06(水) 18:56:00.13

Itemっていうクラス名はそもそもどうなの？

819 ：デフォルトの名無しさん：2013/03/06(水) 19:09:23.12

>>818
それ例だから気にしないで

820 ：デフォルトの名無しさん：2013/03/06(水) 19:22:09.82

Itemには表示機能があるの？
表示/非表示を切り替えられる機能って何？
単にフラグがあるだけ？描画までするの？

821 ：デフォルトの名無しさん：2013/03/06(水) 19:29:09.56

Itemは通常で表示されてんの？
Itemの時点で何者かわからんから無理

822 ：デフォルトの名無しさん：2013/03/06(水) 19:53:23.63

>>817
TogglableItem

823 ：デフォルトの名無しさん：2013/03/06(水) 20:08:17.12

>>811
＞クリックをダウンorアップとかいってる時点で
馬鹿だろお前。
そんなこと言ってない。

824 ：デフォルトの名無しさん：2013/03/06(水) 20:11:15.96

>>817
だから、「表示/非表示を切り替えれる機能を付加した」なんて情報をベースに
名前を付けたってだいたいろくな名前にならない。

これ毎度毎度このスレで言われてること。

825 ：デフォルトの名無しさん：2013/03/06(水) 20:18:45.02

命名規則や設計の善し悪しについて議論するのは基本的に禁止。

826 ：デフォルトの名無しさん：2013/03/06(水) 20:21:13.78

>>823
失せろゴミ

827 ：デフォルトの名無しさん：2013/03/06(水) 20:27:54.21

>>822
サンキュー

828 ：デフォルトの名無しさん：2013/03/06(水) 20:29:37.67

>>824
ごもっとも

829 ：デフォルトの名無しさん：2013/03/06(水) 22:27:20.00

～ableItem だろうな

830 ：デフォルトの名無しさん：2013/03/07(木) 11:57:53.37

>>820
Modelとviewが混じってるようなイヤナ予感するよなｗ

831 ：デフォルトの名無しさん：2013/03/07(木) 12:19:23.42

>>830
Item って例が悪かったと思ってる
表示/非表示の設定できないコントロールがあると思ってくれればいいよ

832 ：デフォルトの名無しさん：2013/03/07(木) 17:42:08.96

それにしたってコントロール（？）自体が拡張されるべきかどかはアレだよな。
Map<Control, bool>の変数一個でまかなえないの？とも、
コントロールを所有してるやつのレベルでなんかを切り替えるメソッドを公開し、
その裏でチョコチョコうごくうちの一つとして、それらのvisibleを管理してやりゃ十分って肝。

833 ：デフォルトの名無しさん：2013/03/07(木) 19:26:06.15

>>832
うん。だから外から管理するようにした
いい名前が浮かばないときは設計が悪いって身にしみたよ

834 ：デフォルトの名無しさん：2013/03/07(木) 20:09:33.92

>>833
あるあるｗ

835 ：デフォルトの名無しさん：2013/03/09(土) 17:24:42.50

『C言語を用いた変換機』を英語にすると次のどちらでしょうか
「Converter By C」
「Converter With C」

『手法』は by を用いるとの事なので「Converter By C」が正しいのかな
と思いつつ
プログラミング言語は『道具』でもあるわけで
「Converter With C」なのか？と頭の中でループ中

836 ：デフォルトの名無しさん：2013/03/09(土) 17:30:14.87

C言語を用いて何を何に変換するの？

837 ：デフォルトの名無しさん：2013/03/09(土) 17:43:20.38

>>835
『C言語を用いた変換機』は日本語としてもちょっとおかしい。
普通は『C言語で書かれた変換機』とかでしょう。
つまり "a converter written in C"

838 ：デフォルトの名無しさん：2013/03/09(土) 18:01:18.59

Cコンパイラの類かと思った

839 ：デフォルトの名無しさん：2013/03/09(土) 18:05:15.34

Converter By C

840 ：デフォルトの名無しさん：2013/03/09(土) 18:58:23.30

a converter implemented w/ C

841 ：デフォルトの名無しさん：2013/03/10(日) 00:21:39.84

>>835
英語はモノの関係がはっきりしていたら、日本語のように曖昧な関係を書けない
くどい説明を考えてみたらいいね
「これは、C言語で書かれ、コンパイルされた何かしらのコンバータである」
>>837が正解だね

842 ：デフォルトの名無しさん：2013/03/10(日) 00:23:49.29

converter in C だけでいいんじゃないの？
「in ～」だけで「～語で」って意味になる
written があっても別にいいけど

843 ：デフォルトの名無しさん：2013/03/10(日) 00:47:39.46

>>842
それじゃ「Cの中の変換機」。
そもそも"in C"は副詞句だと思われるから修飾するのは普通動詞でしょう。

844 ：デフォルトの名無しさん：2013/03/10(日) 00:55:42.84

This converter is written in C language. とreadmeに書いておけば万事解決。

845 ：デフォルトの名無しさん：2013/03/10(日) 01:03:44.74

使用した言語名を明示する意味あんの？

846 ：デフォルトの名無しさん：2013/03/10(日) 01:06:02.39

>>843
ググれば普通に出てくる表現だぞ

847 ：デフォルトの名無しさん：2013/03/10(日) 01:06:59.23

>>846
では具体的にどうぞ

848 ：デフォルトの名無しさん：2013/03/10(日) 01:10:26.08

>>847
ttps://www.google.co.jp/search?q=%22converter+in+C%22

849 ：デフォルトの名無しさん：2013/03/10(日) 01:13:22.85

それ具体的か？

850 ：デフォルトの名無しさん：2013/03/10(日) 01:13:39.85

具体的だなぁ。

851 ：デフォルトの名無しさん：2013/03/10(日) 01:17:08.76

例によってバカの壁だな。

"in C"が副詞句以外の用法で使われている具体例を出せと言ってるのに
得意げに検索結果を出して何の意味があるのか全然理解できない。

852 ：デフォルトの名無しさん：2013/03/10(日) 01:18:29.55

ああやっぱこのアホか

853 ：デフォルトの名無しさん：2013/03/10(日) 01:19:38.83

「C区画にあるコンバータ」なんて誤訳されないように文脈は整える必要があるな。

854 ：デフォルトの名無しさん：2013/03/10(日) 01:20:55.74

File converter in C plus plus とか
Currency converter in C とか
いくらでも検索に引っかかってんじゃん

855 ：デフォルトの名無しさん：2013/03/10(日) 01:22:36.29

副詞句とかそれっぽい言葉持ち出しても英語力が無いのが隠しきれてないね

856 ：デフォルトの名無しさん：2013/03/10(日) 01:22:42.37

もちろん文脈的に動詞が自明な時に省略して書くということはあるはずだけど、
そんなのは文字通り文脈に依存した書き方なわけでいつでも使えるわけじゃない。

857 ：デフォルトの名無しさん：2013/03/10(日) 01:24:13.47

Numerical Recipes in C も読んだ事無いんだろう

858 ：デフォルトの名無しさん：2013/03/10(日) 01:25:28.48

>>854
だからそれはwrittenとかdeveloppedが省略されているだけ。

省略できるかどうか（読み手がそれを省略と理解できるかどうか）は文脈に依存するわけで、
文脈自由にそんな書き方が出来るわけがない。

859 ：デフォルトの名無しさん：2013/03/10(日) 01:27:18.76

converter 自体がプログラムなんだから
その状態で in C と言えば C 言語以外の何者でもないだろう

860 ：デフォルトの名無しさん：2013/03/10(日) 01:28:32.23

その検索結果の場合だと
ある特定、あるいは不特定のコンバータではなく、総称としての名称に付けられているな
冠詞や不定冠詞が付くような名称であれば明確にした方がいいんでない？
>>835が何のコンバータを示しているのか分からんけど

861 ：デフォルトの名無しさん：2013/03/10(日) 01:32:17.43

>>859
>>843
こういう指向回路の人が他人には読解不能なコードを量産してるんだろうな。
曰く「それぐらいわかるだろ？」

わからねえってw

862 ：デフォルトの名無しさん：2013/03/10(日) 01:32:39.35

馬鹿が蛇足でゴチャゴチャ言ってるようだけど
結局Converter in Cでいいわけか

863 ：デフォルトの名無しさん：2013/03/10(日) 01:38:23.22

短く行くならそうだな

864 ：デフォルトの名無しさん：2013/03/10(日) 01:41:35.60

馬鹿だと思われても良いなら、の間違いでしょ。

もちろん日本語だって正確に使える奴は実は少ないわけで、
質問者には悪いけど仕事仲間が「C言語を用いた変換機」みたいな日本語に
何も疑問を感じないレベルなら、そりゃ恐らく何の問題もない。

865 ：デフォルトの名無しさん：2013/03/10(日) 01:43:19.17

やっぱ馬鹿だねぇ

866 ：デフォルトの名無しさん：2013/03/10(日) 01:45:45.60

こんなありふれた表現に今更何を言ってるのやら
ttps://www.google.co.jp/search?q=%22codes+in+C%22

867 ：デフォルトの名無しさん：2013/03/10(日) 01:59:51.12

Cは言語なので、byやwithでなくinが自然
副詞句でないとと言ってるアホがいるが、
プログラムの世界では「～による」という形容詞句で普通に使われる

868 ：デフォルトの名無しさん：2013/03/10(日) 02:02:21.43

>>867
だから、一つでも具体例を出したら？

869 ：デフォルトの名無しさん：2013/03/10(日) 02:04:18.55

>>868
Numerical Recipes in C

870 ：デフォルトの名無しさん：2013/03/10(日) 02:07:26.67

ここはいつから英語のスレになったんだ

871 ：デフォルトの名無しさん：2013/03/10(日) 02:08:12.09

バカの壁君のバカの壁が一番高い

872 ：デフォルトの名無しさん：2013/03/10(日) 02:08:24.89

英語コンプレックスを持つバカの壁君が来てから

873 ：デフォルトの名無しさん：2013/03/10(日) 02:14:11.66

即レスしてたバカの壁君が
急に黙ってﾜﾛﾀ

874 ：デフォルトの名無しさん：2013/03/10(日) 02:20:11.59

>>869
だからそれはwrittenが省略されてるだけ。
その場合はほぼ確実にそう推測可能だから良いが、いつでもそうじゃない。

875 ：デフォルトの名無しさん：2013/03/10(日) 02:24:05.54

writtenが略されてるわけじゃねーよ

876 ：デフォルトの名無しさん：2013/03/10(日) 02:24:58.30

省略ではなくwrittenを付け足すこともできるだけ

877 ：デフォルトの名無しさん：2013/03/10(日) 02:25:15.64

この場合written付け足したらおかしくならないか？

878 ：デフォルトの名無しさん：2013/03/10(日) 02:31:30.64

それもそうか

879 ：デフォルトの名無しさん：2013/03/10(日) 03:51:21.76

>>874に追記。
今思いついたが、"Numerical Recipes in C"は、writtenが省略されているという以外の
別の解釈も可能だとは思う。

それは、例えば"reading skill in English"のinの用法と同じだという解釈。
つまりこの解釈で直訳すると「Cにおける数値（解析）のレシピ」

どっちの解釈がより正しいのか正直よく分からないが、いずれにせよこちらのinの用法は
>>835には使えない。

880 ：デフォルトの名無しさん：2013/03/10(日) 03:54:54.95

使えるよバーカ

881 ：デフォルトの名無しさん：2013/03/10(日) 04:54:00.25

「in Japanese please.」（訳：日本語でおｋ）
「～ in C」は「C（言語）による～」と訳すことができる

「by C」なら「C言語によって変換機」語訳はともかく、変換機を作ったのはC言語じゃない。プログラマだ
「with C」なら「C言語と共の変換機」C言語と共に歩んできた変換機？

882 ：デフォルトの名無しさん：2013/03/10(日) 06:41:27.64

それは speak を略してるから副詞句
バカの壁君に隙を見せてはいけない

883 ：デフォルトの名無しさん：2013/03/10(日) 10:33:38.13

numerica recipes in C はC言語で数値計算するためのレシピ集であって、
レシピがC言語で書かれているという意味ではない。
converter in C はconverterがCで書かれているというよりも
yaccやlexのようなC言語による記述を支援するためのコンバータな印象を受ける。

884 ：デフォルトの名無しさん：2013/03/10(日) 11:05:21.39

>>835
converter implemented by C だから、ニュアンス1個抜けてるやん

885 ：デフォルトの名無しさん：2013/03/10(日) 11:06:17.54

>>840
w/ ってトイレにしたかっただけ？

886 ：デフォルトの名無しさん：2013/03/10(日) 11:33:48.59

>>837はドン臭い

887 ：835：2013/03/10(日) 12:10:58.11

元日本語が確かに変でしたね
みなさんのご意見どれもとても参考になりました
ありがとうございました

888 ：デフォルトの名無しさん：2013/03/10(日) 13:24:59.29

>>883
前半、まあそうかもしれない。

つまり
"Numerical Recipes in C"
は
"numerical recipes in programming with C"
と解釈する方が正しいかもしれない。

どっちにしろ、少なくとも>>835の意図する意味で"converter in C"とは書けない。

889 ：デフォルトの名無しさん：2013/03/10(日) 14:27:07.33

書けるよバーカ

890 ：デフォルトの名無しさん：2013/03/10(日) 16:32:16.49

まぁお前ら間違ってる間違ってないでスレ浪費してないで、いっちょセンス良い奴を頼むよ

891 ：デフォルトの名無しさん：2013/03/12(火) 12:58:28.69

改行コードが混在した文字列の改行コードを統一する関数名てなにがいいかな

892 ：デフォルトの名無しさん：2013/03/12(火) 13:45:19.76

NormalizeLineFeedCode とかどうだろう。長いなら最後は -LF でもいいが

893 ：デフォルトの名無しさん：2013/03/12(火) 14:01:05.42

fixLF

894 ：デフォルトの名無しさん：2013/03/12(火) 14:26:03.84

RegularizeLineFeed()

改行コードを第1引数で指定できるなら
RegularizeLineFeedTo()

ちょっと意味合いが違うかな？？

895 ：デフォルトの名無しさん：2013/03/12(火) 15:17:31.79

replace newline

896 ：デフォルトの名無しさん：2013/03/12(火) 16:04:22.45

LineFeedを使うとLFと誤解しかねない

897 ：デフォルトの名無しさん：2013/03/12(火) 16:12:40.27

normalize newline

898 ：デフォルトの名無しさん：2013/03/12(火) 17:51:32.04

fix newline

899 ：デフォルトの名無しさん：2013/03/12(火) 18:08:49.43

そのメソッドがどこに置かれてどれだけ使われるかだな。
どうもprivateメソッドで十分に見えるし、そうなら、__normalize(String raw)にして、
改行だけじゃなくてほかのことも一緒にするわ。漢字コードとか。

900 ：デフォルトの名無しさん：2013/03/12(火) 18:48:15.11

たいていユーティリティ系で使う
privateはありえない

901 ：デフォルトの名無しさん：2013/03/12(火) 19:02:23.38

そう？
入力直後付近や出力直前でケアすりゃ十分に見えちゃうけどな。

902 ：デフォルトの名無しさん：2013/03/12(火) 19:03:24.84

>>897でいいんじゃね
俺なら「NormalizeNewline"s"」にしているだろうが、この複数形は合っているんだろうか

903 ：デフォルトの名無しさん：2013/03/12(火) 21:09:58.28

normalizeはこの場合ちょっと違うな。
fixの方が適切だと思う。
あとはsanitizeとかuniformとかもあるけど、やっぱりfixが短くていいな

904 ：デフォルトの名無しさん：2013/03/12(火) 21:31:23.80

↑アホ

905 ：デフォルトの名無しさん：2013/03/12(火) 21:36:56.80

ReplaceNewLine

906 ：デフォルトの名無しさん：2013/03/12(火) 22:14:54.34

RegularizeNewLine

907 ：デフォルトの名無しさん：2013/03/12(火) 23:32:12.74

UniformNewLine

908 ：デフォルトの名無しさん：2013/03/12(火) 23:37:01.63

uniformて動詞じゃないやん

909 ：デフォルトの名無しさん：2013/03/12(火) 23:42:03.39

>>908
辞書ぐらい引こうよ。生きてるうちに

910 ：デフォルトの名無しさん：2013/03/12(火) 23:43:51.15

uniform 【他動】
～を均一［同一・同型・一様・同様］にする、そろえる、等しくする
～にユニフォーム［制服］を着せる

911 ：デフォルトの名無しさん：2013/03/12(火) 23:48:10.23

unifyかと思った

912 ：デフォルトの名無しさん：2013/03/12(火) 23:53:15.64

nkfL

913 ：デフォルトの名無しさん：2013/03/13(水) 00:28:54.52

unifyだと集めて合体させるイメージ

914 ：デフォルトの名無しさん：2013/03/13(水) 00:36:01.69

>>891
よりどりみどりだな

915 ：デフォルトの名無しさん：2013/03/18(月) 15:40:01.21

偶数か奇数かを格納する変数の名前を付けたいんですが日本語でもなんていうのかよくわかりません。
変数の中には odd か even が入る予定です。

916 ：デフォルトの名無しさん：2013/03/18(月) 15:40:54.36

ぱりてぃ

917 ：デフォルトの名無しさん：2013/03/18(月) 15:47:06.68

>>916
まさにその意味です。ありがとうございます。

918 ：デフォルトの名無しさん：2013/03/18(月) 15:54:35.56

どういたしまして

919 ：デフォルトの名無しさん：2013/03/18(月) 16:24:48.95

言葉ではとうてい言い尽くせないほど感謝しております。
ほんとうにほんとうにどうも有難うございました。

920 ：デフォルトの名無しさん：2013/03/18(月) 16:58:54.51

礼には及ばんよ

921 ：デフォルトの名無しさん：2013/03/18(月) 17:46:58.61

変数名ではないが、同じ軸で反対向いてたり、それらの軸が直交してたりする場合の総称って誰かうまくできる？
上下、左右、上下左右、東西、南北、東西南北、前後。
けっきょく人類は、それらをくっつけただけで総称しているようだが…。
むかしこれ考えようとして何一つ良いの思い浮かばなかった。

922 ：デフォルトの名無しさん：2013/03/18(月) 17:48:02.81

いや、東西南北に対しては方角、という言葉があるか。

923 ：デフォルトの名無しさん：2013/03/18(月) 18:26:28.88

ならば
上下左右は方向だな

924 ：デフォルトの名無しさん：2013/03/18(月) 18:33:47.08

>>923
天才キタコレ。
というかひょっとして俺がドアホなだけだたのかorz

925 ：デフォルトの名無しさん：2013/03/18(月) 19:18:38.02

正直、質問の意図も回答の意味のよう分からんが、問題が解決して何より

926 ：デフォルトの名無しさん：2013/03/18(月) 19:24:46.07

>>925
具体的に言うのなら、以下のxxxに良い名前当てはめれる人いる？ってこと。
enum xxx {LEFT, RIGHT};
enum xxx {UP, DOWN};
enum directions {LEFT, RIGHT, UP, DOWN};

927 ：デフォルトの名無しさん：2013/03/18(月) 19:29:45.14

>>926
directionLRとかUDにするかなぁ。

928 ：デフォルトの名無しさん：2013/03/18(月) 19:30:32.06

x directions
y directions

929 ：デフォルトの名無しさん：2013/03/18(月) 19:36:42.45

directionH
directionV

930 ：デフォルトの名無しさん：2013/03/18(月) 19:49:08.49

NorthSouthEastWest.North　←冗長？
Directions.North　←一見ほどよく抽象的だが、日本語で言う方角と方向を使い分けれない？
NSEW.North　←簡潔にして十分？

931 ：デフォルトの名無しさん：2013/03/18(月) 20:36:45.32

>>930
全方向については >>926 を見る限り directions で解決してるっぽいが

932 ：デフォルトの名無しさん：2013/03/18(月) 20:45:11.14

「向き」というニュアンスだと orientation もそこそこ見かけるかなぁ。

933 ：デフォルトの名無しさん：2013/03/18(月) 21:37:16.17

.netだとOrientation.Vertical／Horizontal

934 ：926：2013/03/19(火) 09:09:13.95

おまいら、沢山のご回答どうもありがとうございました！
ありがたく参考にさせてもらいます。

935 ：デフォルトの名無しさん：2013/03/19(火) 09:30:51.07

どういたしまして

936 ：デフォルトの名無しさん：2013/03/19(火) 15:18:51.19

海外でも似たような質問見てるけど、おまえらってやっぱり馬鹿なんだなｗ

937 ：デフォルトの名無しさん：2013/03/19(火) 16:20:32.81

煽るだけの馬鹿はスルーで

938 ：デフォルトの名無しさん：2013/03/19(火) 21:03:08.00

このスレを訪れた皆様へ

　
　
　
　
　　
　
　
　
　
　

　　
　
　
　

　　
　
　
自分で考えろゴミｗｗ

939 ：デフォルトの名無しさん：2013/03/19(火) 21:39:17.65

↑他人との議論がいかに大事か知らないガキ

940 ：デフォルトの名無しさん：2013/03/19(火) 21:59:14.24

明らかに議論などいう流れじゃない件

941 ：デフォルトの名無しさん：2013/03/19(火) 22:20:43.64

ものすごく馬鹿ｗ

942 ：デフォルトの名無しさん：2013/03/19(火) 22:31:26.83

大した技術力もなしに議論すること自体おかしい

943 ：デフォルトの名無しさん：2013/03/19(火) 22:33:02.41

ゴミスレｗ

944 ：デフォルトの名無しさん：2013/03/20(水) 12:30:05.45

東西南北などの方向は direction
向き（横向き、縦向き、など）は orientation
方位角は azimuth

945 ：デフォルトの名無しさん：2013/03/20(水) 13:20:35.44

向きといえば、

縦長がportrait(肖像画)
横長がlandscape(風景画)

やっぱり美術分野で長い伝統がある用語なんだろか。

946 ：デフォルトの名無しさん：2013/03/20(水) 13:54:30.71

俺は今すべてのレスがウザいと感じているんだ

947 ：デフォルトの名無しさん：2013/03/20(水) 16:04:02.10

何その不自然な日本語訳みたいな文章

948 ：デフォルトの名無しさん：2013/03/21(木) 14:40:34.63

方向がdirection
姿勢がorientation

カメラがある方向を向いているとする
そのカメラはどんな状態でその方向を向いているだろうか
90度回転させて、横に撮ることもできるし、地面が上にあるように撮ることもできる
どの方向を向いて、その方向を軸にどれだけ回転させるのか、これが「姿勢」である
「方向」にはその回転量が含まれないので、例えば頭がどの方向を向いているかが分からない

949 ：デフォルトの名無しさん：2013/03/21(木) 17:37:25.39

…と、考える小学生であったｗ

950 ：デフォルトの名無しさん：2013/03/21(木) 18:12:18.14

Microsoft.Xna.Framework
Matrix#CreateLookAtのcameraUpVectorみたいな話？＞姿勢
public static void CreateLookAt (
ref Vector3 cameraPosition,
ref Vector3 cameraTarget,
ref Vector3 cameraUpVector,
out Matrix result
)

951 ：デフォルトの名無しさん：2013/03/21(木) 18:13:07.02

おっと。
Matrix.CreateLookAt でよかったね。

952 ：デフォルトの名無しさん：2013/03/21(木) 18:15:21.90

heading, pitch, roll

953 ：デフォルトの名無しさん：2013/03/21(木) 18:51:09.23

馬鹿

954 ：デフォルトの名無しさん：2013/03/21(木) 21:14:35.97

俺の心の琴線に触れたから、このスレの奴らは馬鹿

955 ：デフォルトの名無しさん：2013/03/21(木) 23:15:21.63

>>950
方向：GetNormalized(cameraTarget - cameraPosition)
姿勢：CreateLookAt()のresult

方向はVector3で現すことができるが、姿勢はMatrixかQuaternionが必要になる（3D話）

956 ：デフォルトの名無しさん：2013/03/22(金) 00:36:33.38

なんだその条件ｗ

957 ：デフォルトの名無しさん：2013/03/22(金) 20:00:44.21

イミフメイ

958 ：デフォルトの名無しさん：2013/03/22(金) 21:13:08.05

イミフメイって文字をみるとフジイフミヤを思い出す

959 ：デフォルトの名無しさん：2013/03/22(金) 21:15:02.83

フジイフミヤ

960 ：デフォルトの名無しさん：2013/03/23(土) 05:47:10.05

視線方向のベクトルだけでは頭の方向が分からないでしょ
cameraTarget - cameraPosition を正規化したものが視線方向のベクトル
cameraUpVector は頭方向のベクトル
CreateLookAt()は、視線方向のベクトルと頭方向のベクトルから、姿勢行列を作る関数
方向と姿勢の違いがお解かりか？宜しいか？

961 ：デフォルトの名無しさん：2013/03/25(月) 22:56:52.69

ゲームでオブジェクトが破壊可能かどうか、破壊するメソッドをbreakを使わないで言うと？

962 ：デフォルトの名無しさん：2013/03/25(月) 23:07:07.95

destroy

963 ：デフォルトの名無しさん：2013/03/25(月) 23:18:39.65

>>961
破壊可能か？： isDestructible isRemovable isCleanable isClearable isFreeable...
破壊する： destroy remove clean clear free delete release shift eliminate

964 ：デフォルトの名無しさん：2013/03/25(月) 23:23:50.81

　　　　　　　　　_＿＿
　　　　　　　　 |　　　|
　　　　　　　　 |　　　|
　　　　　　　　 |　>>1.|
　　　　　　　　 |　の　|
　　　　,,,.　　 |　墓　|　　,'"';,
　　　､''ﾞﾞ;､).　 |　　　|　､''ﾞﾞ;､),､
　　　ﾞ''!ﾘ''　i二二二二!ﾞ''l!ﾘ'''ﾞ
　　　　 ∥　｀i二二二!´　∥
　　　　昌　|:￣￣￣￣:|　昌
　　　　|￣:|_|;;;l"二二ﾞﾞl;;|_|￣:| 　ﾁｰﾝ
　　　　|　 :|::::::| |;;;;;;;;;;| |::::|　 :|
　　　　| 　:|::::::|┌─┐|::::|　 :|
　.／ﾞﾞ└‐┴ ┴l,,,,,,,,,,l┴┴‐┘ﾞﾞﾞﾞ＼
　|￣￣￣￣￣￣￣￣￣￣￣￣￣|
　￣|三|三三|三三三三|三三|三|￣
　　 |　 |:::　　|: :　　　 : : |:: 　　|　 |
　　 |　 |:::　　|: :　　　 : : |:: 　　|　 |
　　/＿|:::　　|: : 　　　: :.|::　　:|＿ヽ
　_|＿__|;;;;;;;;;;|,;,;,,,,,,,,,,,,,,,;,;,|;;;;;;;;;;|＿__|_
　l;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;l

965 ：デフォルトの名無しさん：2013/03/25(月) 23:48:27.17

うめ

966 ：デフォルトの名無しさん：2013/03/27(水) 06:42:43.43

新学期のクラス名をどうしよう

967 ：デフォルトの名無しさん：2013/03/27(水) 07:12:39.13

もも組オススメ

968 ：デフォルトの名無しさん：2013/03/27(水) 08:01:29.20

すみれ、もも、さくら

969 ：デフォルトの名無しさん：2013/03/28(木) 17:32:06.18

次スレは

970 ：デフォルトの名無しさん：2013/04/01(月) 05:04:15.33

ある変数が一定以上の値か調べるbool関数

971 ：デフォルトの名無しさん：2013/04/01(月) 05:07:09.06

liuhrvu2hr2urhp498rhvp4iuhtp3984y5o7438y5ovcwuho5vuhpo285hop3ho3489h5o9b8hovbo43ho598vho4h8o7

972 ：デフォルトの名無しさん：2013/04/01(月) 10:27:28.81

>>970
check, validate, equal_or_greater, equal_or_higher

973 ：デフォルトの名無しさん：2013/04/01(月) 12:24:30.81

GreaterEqual

974 ：デフォルトの名無しさん：2013/04/01(月) 19:37:24.40

>>970
悪いけど提示してる条件にセンスの無さが出ちゃってる。

そういう関数の名前を付けるときに重要になるのは、それが「一定以上の値か調べる」
ものであるなんて情報じゃない。

重要なのは、その比べる対象である閾値が何であるかだ。

975 ：デフォルトの名無しさん：2013/04/01(月) 20:16:20.42

何が言いたいのかさっぱり

976 ：デフォルトの名無しさん：2013/04/01(月) 22:34:05.88

>>974
バカの壁

977 ：デフォルトの名無しさん：2013/04/01(月) 23:23:07.24

要は、
たとえば
ある変数がある値以上だったらある文字列が編集可能である

という条件だったら
isEditable
にしたりするのであって、

具体的に何が実現されるのかやどういう状態なのかを変数名にしなきゃいけない。

「一定以上」だとか未満だとかよりも大切な情報があるはずだってことでしょ。

978 ：デフォルトの名無しさん：2013/04/01(月) 23:59:55.90

>>974は閾値が重要と言ってるけど？

979 ：デフォルトの名無しさん：2013/04/02(火) 05:08:46.76

>>970

>

980 ：デフォルトの名無しさん：2013/04/02(火) 05:09:33.40

…ごめん、>= だな

981 ：デフォルトの名無しさん：2013/04/02(火) 07:01:37.33

>>977
初めからそう言えばいいのに、
なんでわざわざ「センスの無さ」なんて余計なこと言うの？

気づかない間に人を傷つけてるよ

そういう性格なら、もうどうしようも無いから仕方ないけど

982 ：981：2013/04/02(火) 07:02:39.47

>>977
もしかして >>974 とは別人？
だったらごめん

983 ：デフォルトの名無しさん：2013/04/02(火) 07:15:32.88

無慈悲な一等ごめん待機

984 ：デフォルトの名無しさん：2013/04/02(火) 10:09:15.14

とはいえ、色んな処理の更に内部で使うような関数だと、
上手く抽象化出来ない、あるいはしないほうが良い場合もあるよなー。

そういう時どうしてる？
内部用なんだから関数名なんか気にする必要ないじゃん！と言われればそれまでなんだけども。

>>980
次スレお願いしてもいい？

985 ：デフォルトの名無しさん：2013/04/02(火) 12:28:20.53

>>984
ごめん、スレ立て無理ぽ…
>>986 に頼む！

986 ：デフォルトの名無しさん：2013/04/02(火) 12:56:27.93

よしきた

987 ：デフォルトの名無しさん：2013/04/02(火) 13:01:15.86

クラス名・変数名に迷ったら書き込むスレ。Part23
http://toro.2ch.net/test/read.cgi/tech/1364875204/

988 ：デフォルトの名無しさん：2013/04/02(火) 18:59:43.49

>>982
別人です　まぎらわしかったか

内部用というかほんの一時的な処理に使うだけの変数は、きちんとした名前をつけると、
なにか重要なことに使ってるような誤解を与えかねないから、適当につけてる。
hogeCountとかsplitedFooとか。

あとこまかいところのコードをいじるのはたぶん重大なインシデントがある時だと思うから、
わかり辛い箇所なら、変数名よりもコメントに労力を割くべきだと思ってる

989 ：デフォルトの名無しさん：2013/04/02(火) 20:29:03.50

>>988
わざと適当に付ける、か。
なるほどそういう考え方もあるのか。

>>987
おつー

990 ：デフォルトの名無しさん：2013/04/02(火) 22:02:17.13

ファイルのパスと、そのファイルのサイズを格納する構造体の名前は、
何が良いでしょうか

struct ????? {
　const char * p_path;
　size_t size;
};

FileDescriber では少し意味が曖昧な気がします。

何というか、ディレクトリツリーという一つの大きな入れ物の中で、
あるファイルはここからここまでの範囲にあるという事を示すイメージです。
p_path で先頭ポインタを指し、size で大きさを示す、みたいな。

991 ：デフォルトの名無しさん：2013/04/02(火) 22:14:39.11

>>990
ファイルを複数選択するイメージなら Item

992 ：990：2013/04/02(火) 22:23:57.49

>>991
ありがとうございます。

しかし、Item も Describer と同じように、
今回の要求に対しては懐が広すぎる感があります。

どのようなファイルかという情報はまったく無いです。
単にファイルの位置と大きさという２の情報を格納するだけです。
たとえば後で、この構造体にファイル拡張子の情報も入れようとか、
そんなことはありません（むしろ入れてはいけない）。

これがもしファイルではなく幾何学的な空間を表しているなら、
Range とか Region などと名付けたいところです。

993 ：デフォルトの名無しさん：2013/04/02(火) 22:39:40.30

>>992
だったら path_and_size

994 ：デフォルトの名無しさん：2013/04/02(火) 22:41:56.93

995 ：デフォルトの名無しさん：2013/04/02(火) 22:49:16.50

>>990
その「ファイル」っていうのは俺様用語？

同じ値をパスって言ったり位置って言ったりもそうだが、それ以外にも
全体的に何を言ってるのかよくわからない。

996 ：990：2013/04/02(火) 22:56:28.71

>>995
いえ、ファイルは Linux や Windows などの普通のファイルです。

>>992 でパスの事を位置と言ったのは、
その後の「もしファイルではなく幾何学的な空間を表しているなら」
という喩えを理解していただけるようにと、伏線を張っただけで、
同じ意味です。

> 全体的に何を言ってるのかよくわからない。

最初に言いましたが、ファイルのパスとサイズを格納する構造体の名前を考えています。

すいません、どの辺りが分かりにくいでしょうか。
できる限り詳しく説明したいと思います。

997 ：デフォルトの名無しさん：2013/04/02(火) 23:02:57.18

少なくともパスとサイズが範囲を表現している、という発想は謎だなあ。

998 ：デフォルトの名無しさん：2013/04/02(火) 23:05:11.23

俺もItemが良いと思うが…
それならFileじゃだめなのか？

999 ：デフォルトの名無しさん：2013/04/02(火) 23:09:34.70

やっぱり何度読んでも質問者の意図が理解できないなあ。
いつでもファイルシステムから取得できるはずのサイズを、なぜあえてパスと一緒に
構造体にキャッシュしておきたいのか、そのあたりの動機を説明しないと
適切な命名は難しいと思う

1000 ：デフォルトの名無しさん：2013/04/02(火) 23:10:48.18

ちーん

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。