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

1 ：12/01/22 〜 最終レス ：12/07/05

クラス名、変数名のつけ方に悩んだら書き込むスレです。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
前スレ
クラス名・変数名に迷ったら書き込むスレ。Part20
http://toro.2ch.net/test/read.cgi/tech/1311942721/

2 ：

>>1乙
> 前スレファイル名議論
住所の最後が名前、
パスの最後がファイル名、みたいなもんだな。
できるだけ簡潔なものを選ぶ余地がある。

3 ：

1おつ
>>前1000
極論ではなく一般論
それもコーディングだけではなく自然言語も含めたより広い世界での一般論
極論してるのはそっちだよ

4 ：

>>3
馬鹿は来るな

5 ：

>>4
じゃあお前が帰れよ

6 ：

>>5
だからお前が失せろ

7 ：

>>6
だから馬鹿はお前なんだからお前が消えねーとだめだろ
説明しないとわからんほど馬鹿なのか

8 ：

>>7
さっさと失せろ馬鹿

9 ：

>>8
>>4

10 ：

>>9
>>4

11 ：

小学校かここは

12 ：

前スレ>>992
それ同じ事を言い方を変えただけ。
「その機能や概念を示す」のと「機能を読み取れること」のどこが違うんだ。
それなりに複雑な機能をもったクラスやメソッドの機能を短い名前で完全に表現
できないのは当たり前で、仔細な点は捨象して大枠の機能を抽象した名前を付けるに決まっている。
馬鹿じゃないのか。

13 ：

>>12
>「その機能や概念を示す」のと「機能を読み取れること」のどこが違うんだ。
例を出して言えば「オイラー方程式」が前者で「理想流体の運動法則」が後者だ
どちらも同じ物を示しているが前者は機能や概念を隠蔽した名称だ
ぜんぜん違うだろ？
そして議論で使うのはどちらが自然かといえば前者だ
後者をいちいち使うのはあまりにもクドい

14 ：

前スレ >>990
> だったらutf8だとかeucだとか文字エンコードも併記すべきな気がするぞ…
併記すべきかどうかは場合による
複数の文字コードを扱っているのであれば、併記しなければ分からない
扱っている文字コードがOSや環境のデフォルトだけであり、
あるファイルフォーマット内の文字列部分を処理しているなどなら、
文字エンコードを併記する必要性は感じない

15 ：

>それなりに複雑な機能をもったクラスやメソッドの機能を短い名前で完全に表現
>できないのは当たり前で、仔細な点は捨象して大枠の機能を抽象した名前を付けるに決まっている。
あと一応言っておくが俺はクラス名やメソッド名を短く省略しろとは言っていない
狭い範囲、スコープに限定された文脈の中では短いものを使えと言っているのだ
>馬鹿じゃないのか。
それを読み取れなかったお前がBAKAです

16 ：

>>15
まだいたのか
消えろ馬鹿

17 ：

>>16
>>16

18 ：

>>17
>>16

19 ：

論破されると罵倒するしかできないってなんか可哀想だな
神様ももうすこしIQ平等に分けてあげればよかったのに罪なことするぜ

20 ：

>>13
なるほど俺の誤解みたいだね。っていうかまさかそこまで馬鹿とは思わなかったw
要するに、
String.GetLength()
などという機能をそのまま表現した名前はよくないから、
String.func001()
String.YamadaTarou001()
のように単なる識別子以上のものではない名前を付けろという訳だ。
関数名と機能の対応を参照するバインダーがないと読めないコードが存在するって
都市伝説、あれは本当だったんだなw
こんなガチ馬鹿がどうしてこんなスレにいるんだろう。

21 ：

>>20
>>15
ちょっと前のレスも読めない馬鹿がなんでいまだに生きてるんだろう

22 ：

>>21
よ馬鹿

23 ：

>>22
>>19

24 ：

>>23
>>19

25 ：

>>20
それはクラスというひとつの大きな単位の中のメソッド名ですよね
>>15 で彼は
> あと一応言っておくが俺はクラス名やメソッド名を短く省略しろとは言っていない
> 狭い範囲、スコープに限定された文脈の中では短いものを使えと言っているのだ
と言っているので、それは反論の方向としては間違っていると思うのですが
たとえば、
void func () {
＊＊＊ = String.GetLength()
場合の＊＊＊の部分などの場合の事だと思います

26 ：

>>21
間違いを指摘されると「俺の真意はお前の理解と違う」ってか。
みっともない奴だな。
前スレの>>992は俺が書いた>>982に対する反論なんだから、そんな言い訳が通用する訳がない。
どんなクルクルパーだよ。

27 ：

それから、メソッドやブロックのスコープ内でも明示的な名前を使え、
なんて言ってる奴が一人でも居たか？
そんな奴いねえよ一人も。
誰と戦ってるつもりなんだろうなまったく。

28 ：

http://awabi.2ch.net/test/read.cgi/poverty/1327050821/3

29 ：

スコープが広域であれば、略さず完全な名前を付ける
　superHogeCountWithPiyo
　pugeraDescription
スコープの狭さに応じて単語を省く
例えばローカル関数であれば、
　countWithPiyo もしくは count
　pugeraDesc または desc
できる限り略語を使わない
　×superHogeCountWithPiyo → shCountWithPiyo
　×pugeraDescription → pDesc, pdesc
そもそも短い単語を略す必要はない
　×cnt ○count
　×idx ○index

30 ：

○　c
○　i

31 ：

・・・とは書いてみたものの、狭域スコープでは hogeCount を nHoges みたいに略すことがある
単語を略すのであれば、number (of) → num みたいな中途半端な略し方ではムラが生じてしまう（numでは生じないだろうが）ので、一文字 number (of) → nまで略す
その単語の略語にムラが生じることはないだろうと自分で確信が持てるのであれば、使うことはある
例えば、Description は desc 以外に略語を持たないと判断できるし、Information は info 以外の略語を持たないので、狭域スコープではこれを使う
Temporary は temp と tmp が存在するので、略したいときは 一文字「t」まで略する

32 ：

>>30
ごく短い、例えば3行以下の関数ローカルスコープであれば一文字でもかまわない
またはループカウンタとしてのcやiは、自分では許可している

33 ：

> ごく短い、例えば3行以下の関数ローカルスコープであれば一文字でもかまわない

34 ：

変数名をゴッチャリ飾って区別しないといけないようなのは、
既にメソッドが大きすぎるか、メンバ変数の場合はそれらが多すぎる。
fooBarBazList = 
appleBeerList = 
codeDoorList = 
みたいに併記しているような場合、うまくいくと
list = 
これで住むような可能性がある。

35 ：

>>34
うむ。コーディングの技術がしっかりしてればほとんどの識別子は最低限まで縮めても問題は起こらないよね
というか問題が起こらないように作れると良い設計になってることが多い

36 ：

いやいや大きいとか多いとかじゃなくて対象コードブロックの中に機能や状態を持ち込み過ぎ
struct A{int x,y;}a;のaじゃなく
後から読み解く奴の身になってx,yのどちらか必要な方だけを取り出して書けよと

37 ：

現実問題、英語で言ったら形容詞抜きの"list"だの"count"だので十分説明の機能を果たすような
クラスはまずあり得ない。
皆無とは言わないが、むしろ例外的。
そういう特殊な前提がないと成立しないようなアホみたいな議論はするだけ時間の無駄。

38 ：

>>35
丁寧なコメントが消臭剤でしか無いような場合があるのと同様に、
説明的な変数が消臭剤でしか無いような場合があるな。
早い段階ですべきは、元の悪臭漂うクソ構造を改めること。

39 ：

就活中
(p)http://livedoor.blogimg.jp/jin115/imgs/3/1/31a6f8e6.jpg
就職後
(p)http://livedoor.blogimg.jp/jin115/imgs/2/b/2b790359.jpg
街の人（やらせ業者）募集中です

40 ：

その画像独り歩きしてるけど
２枚の画像は１年間開いてるからね
その娘は就活うまく行ってそのインタビュー場所の近くの会社に勤めてるって事

41 ：

後ろに居る男も横断歩道の向こう側にいる人も
インタビュワーも停まってる車も天候も変わってないな

42 ：

偶然ってあるもんなんだな

43 ：

Google Code Searchがなくなったのは痛すぎるな。
とりあえずつけたクラス名やメソッド名が外人的にあり得るか？否かをしらべるのに便利やった。

44 ：

ええーーっ！！　ちょっと見ない間に無くなったのか！

45 ：

google code

46 ：

>>30
count_hogeもcHogeもほとんど見易さ変わらないだろ

47 ：

ch

48 ：

>>47
もはやなんだかわからんだろそれ

49 ：

決まってんだろ
チャンネルだよ

50 ：

入門書とか読むと、よく「チャネル」って書いてあるよね
その発音の方がより本物に近いのは分かるが、なんか気取ってて嫌

51 ：

俺はにちゃねらー

52 ：

お前らはアニモー。

53 ：

>>50の中では「JISに合わせること＝気取っている」なのか

54 ：

　前スレの、chrとかcharの974です。
　まさか論争に発展するとは見通し甘かった。
　私が書いているのはゲームの為の周辺ツールで、個人作業です。
　ですから厳密な命名規則が欲しいって程でもないんです。
＃報告
　一度フルスペルで書いたのですが、書き進める内に用途が広がって
キャラクターの意味に相応しくなくなったので一切なくなってしまいました。
　計画性のないプログラムは、これだから・・・！

55 ：

>>53
違う
JISに合わせる、合わせないは全く関係ない
チャネルという言い方が気取っているように感じるだけ
>>53の中ではたった一例を挙げて、それがたまたまJISに合ってただけで
「JISに合わせること＝気取っている」と解釈するのか

56 ：

>>54
論争になったらなったで、それを話題に盛り上がる訳で、面白いものなのだよ・・・

57 ：

hashtable = {
　"foo.name": "value1",
　"foo.text": "value2",
　"bar.name": "value3",
　"bar.text": "value4"
}
みたいなデータから
{ "foo.name": "value1", "foo.text": "value2" }
だけをとりだす関数の名前を考えて下さい。
prefix = "foo."
print func(hashtable, prefix) #=> { "foo.name": "value1", "foo.text": "value2" }
今の候補
・get
・matched
・retrieve
お願いします。

58 ：

find

59 ：

find_by_key_prefix

60 ：

複数候補だからenumかfindfirst→findnext

61 ：

>>57
PickUpPrefixMatches

62 ：

filterByPrefix

63 ：

ウィンドウが画面の外に出ないように防ぐ処理
をお願いします

64 ：

関数名？引数や返り値は何？

65 ：

関数名です
戻り値なし、引数は画面のRECTとウィンドウのRECTです

66 ：

その関数の副作用は何？

67 ：

「ウィンドウが画面の外に出ないように防ぐ処理」じゃなくて
「（ウィンドウが画面の外に出ないように防ぎつつ）ウィンドウ移動する処理」なのでは？

68 ：

>>57
Perlっぽいけどfilterできんじゃねーの？

69 ：

要するにそういう細かいことをまとめて行う処理です

70 ：

ちっとも細かくないやん 基本処理にしか見えん

71 ：

ではそろそろ
ウィンドウが画面の外に出ないように防ぐ処理
をお願いします

72 ：

MoveWindowInScreen

73 ：

avoid-tilesaw

74 ：

void MoveWindowInsideScreen(
　const RECT & windowRect,
　const RECT & screenRect);

75 ：

void MoveWindowInsideScreen(
　const RECT & windowRect,
　const RECT & screenRect,
　RECT * pOutput);

76 ：

>>71
消えろゴミ

77 ：

なんでMOVEなんだよｗ

78 ：

void ウィンドウが画面の外に出ないように防ぐ処理(
矩形 const & ウィンドウ,
矩形 const & スクリーン,
矩形 & 結果) ;
いい加減英語識別子から脱却しろ
いちいち名前付なんてくだらない作業で悩む必要がなくなって捗るぞ

79 ：

preventとかcropとかかなぁ？captureはちと違うか。

80 ：

confine

81 ：

「ウィンドウが画面の外に出ないように防ぐ処理」って何だかよく分からないな。
この手のことをする場合、例えばWindowsなら普通は、
(1) 移動中にデスクトップの上下左右いずれかの隅に達したら、その方向にはそれ以上
移動できないようにする。
(2) 移動完了（マウスアップとか）時、ウィンドウがデスクトップの上下左右のいずれかの隅を
超えていたらデスクトップの範囲内に戻す。
のどちらかじゃいかと思うんだが、ニュアンス的にどっちとも取れないな。

82 ：

>>71
KeepInsideDisplay()

83 ：

ProcessingPreventedSoThatAWindowMeyNotComeOutOfAScreen

84 ：

略してMoveWindow

85 ：

日本語の段階で既におかしいのにそれを英語にしても無駄

86 ：

2つのリスト（配列でもいいですが）a=[a1, a2, a3, ・・・]　b=[b1, b2, b3, ・・・] を
c=[a1, b1, a2, b2, a3, b3, ・・・] の様に1つのリストに合成するのは interleave ですが、
この逆方向の様にリスト c をリスト a とリスト b に分ける関数の名前は何が良いでしょうか
単純にリスト c のある要素を境に2つに分けるなら split や break が適切だと思いますが・・・
とりあえず今のところ、トランプカードを配る様に見えるので deal と名付けていますが、
もっと適切な名前はありますか？

87 ：

どういう基準で分けるかぐらい書けば？

88 ：

>>87
いや、だから interleave とは逆なんですけど・・・
c=[a1, b1, a2, b2, a3, b3, ・・・] を
a=[a1, a2, a3, ・・・] と b=[b1, b2, b3, ・・・] に分ける

89 ：

>>87
言葉で説明すると
リストcの n/2 番目の要素をリストaのn番目の要素に
リストcの (n/2)+1 番目の要素をリストbのn番目の要素に入れる
そんな分け方です

90 ：

すいません、間違ってました
リストcの 2n 番目の要素をリストaのn番目の要素に
リストcの 2n+1 番目の要素をリストbのn番目の要素に入れる
でした

91 ：

>>86
distribute なり divide とかでいいんじゃね？

92 ：

Cutでいいよ

93 ：

プロジェクト名ってどうやって決めてますか？
公開するとなるとさらに慎重になりますよね

94 ：

>>86
interleave ⇔ deinterleave
で良いのでは？
単に1つ(or n)おきに取り出すだけならdecimateもありだと思う。

95 ：

uninterliveか、 >>94 が挙げている deinterleave か、迷った。
>>94
decimateはdec-に「10ごと」という意味があるのと、
その10ごとの1を「処刑する」という意味があるのがよろしくない気がする。

96 ：

decimateは普通のプログラマはあまり使わないかも知れないが、間引きを表す術語みたいなものなんですよ。

97 ：

>>93
状況次第だけど、ソフトウェアの名前そのまま、もしくは逆に一般名詞にすることが多いかなあ。

98 ：

あえて全然関係ないコードネームにする
そうするとカフェで仲間と話し合うときにハッカーっぽさがましてカッコイイ気分になれる

99 ：

一周を[0, 1)で正規化した角度のことをなんて名付けるべきかな
（0.5なら弧度法でのpiに、1.0なら弧度法での2piに相当する）

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【汚物】痛い変数名・関数名【破廉恥】 (730)
形態素解析と日本語処理 (468)
【バグ管理】 BTS使ってる？【追跡】 3 (909)
おまいら最強のシストレFXプログラムをしてみろよ (391)
訃報: C 言語の開発者、デニス・リッチー氏が死去 (559)
C言語なら俺に聞け（入門編）Part 103 (335)
--log9.info------------------
【18きっぷ】遠征総合スレPart17【夜行バス】 (769)
◆昇格だめぽ◆J2中位スレ◆降格セーフ◆part1 (233)
【新潟の星】矢野貴章５【世界へ】 (405)
J2サポが豊富な知識を町田、山雅サポに教えるスレ 2 (449)
【おこしやす】京都サンガFC観光案内・一条通店 (234)
↑↑↑　ＡＡサンフレッチェ広島Part2　↑↑↑ (836)
京都サッカースタジアム推進スレ その25【球技場】 (484)
☆☆☆☆☆サガン鳥栖応援スレPart1☆☆☆☆☆ (469)
【攻撃的】青木剛【鹿島】 (253)
【FC東京】ポポビッチ監督は辞任せよ！ (244)
【桜】セレッソが勝ったら喋れるスレ◆19【大阪】 (377)
今時Ｊリーグ入りを目指す物好きクラブ・その57 (753)
新潟に与えても良いハンデを考えるスレ (531)
【G4】柏 仙台 横浜 広島 新4大ビッグクラブ (297)
鹿島ガンバの時代は終わり、Jは名古屋の１強時代へ (374)
川崎フロンターレはアジアを超越したビッグクラブ (517)
--log55.com------------------
最近のSUMCOってどうよ！その12
【日本TI】日本テキサス・インスツルメンツ Part14
愛三工業　NO7
日本ケミコン Part4
【パナとは無関係】タワージャズ【半導体】
SMK
富士電機10
昭和電工 Part5