クラス名・変数名に迷ったら書き込むスレ。Part23
3げと
4 :
前スレ990 :2013/04/02(火) 23:47:41.81
前スレで、ファイルのパスとサイズを格納する構造体の名前を質問した者です。 動機は、あるゲームを作っていて、そのゲーム内で 仮想的なファイルシステム(みたいなもの)を作る必要があるからです。 そういうデータ構造を作った方が処理が効率的なるという類いのものではなく、 ゲームの「遊びの根幹」に関わるものなので、すいません、今は詳しくは説明できません。 「ファイル」も OS が提供するファイルシステムのファイルではなく、 ゲーム内に独自に作るファイルシステムのファイルですが、 概念としては同じものですので、「パス」というものも普通にあります。 ただ、普通なら「ファイルシステムから取得できるはず」のサイズですが、 そのファイルシステムをゲームの仕様に合わせて独自に作るのに、 ファイルのパスとサイズという2つの情報をセットにした構造体が必要なんです。 (必要、というか、これらをセットにした方がゲーム仕様上管理しやすい) すいません、できる限り詳しく説明したいと言っておきながら、 動機という痛いところを突かれてあまり詳しく説明できませんでした。
5 :
前スレ990 :2013/04/02(火) 23:52:02.00
Item や File だと、格納する情報はパスとサイズだけでなくても良いですよね。 たとえばそこに、ファイル作成日時という情報を追加しても、 Item や File という名前で良いわけです。 ですが今回はパスとサイズだけです。 この2つの情報を端的に表した言葉は何かないか、ということです。 その際に、もう少し抽象化して考えれば何かいい名前が閃くかと思いました。 パスは言わばディレクトリツリー内の位置を表すのではないかと。 すると、位置とサイズから連想したのが範囲とか領域といった概念です。 たとえば 前スレ 992 で言った Range や Region という名前からは、 「ここには色の情報は入っていはないな」と直ぐに分かりますよね。 始点と終点、あるいは始点とサイズ、これらの情報を表すのだろうと分かります。 このような考えから、ファイルのパスとサイズを格納する構造体の名前も、 そこから作成日時などの情報は入っているのかと余計な事は考えず、 名前から直感的にファイルのパスとサイズだと分かれば理想的だろう、と思いました。 Item が懐が大きすぎると言ったのは、何が情報として入っているのか、 色んな事が想像できてしまう余地があるという意味です。 その点からは、前スレ 993 の path_and_size は悪くなく、素直なネーミングだと思います。 ただ、識別子に接続詞はできるだけ使いたくない、というのが我が儘ですが本音です。 他により良い候補がなければ、これを使わせてもらいます。
やっぱり何でその組み合わせが必用なのかの背景が分からないと難しいよね。 極座標のradiusとthetaとか、複素数のrealとimaginaryみたいな一般的な 組み合わせではないわけだから。 まあ、どうしてもというなら、パスとサイズ以外の情報は入ってないことを端的に 表すことは諦めて、FileInfoとかChunkInfoとか
slot: ファイルを収めるべき場所(プレステのメモリカード風味) allocation: ファイルの配置 reserved: ファイルを置くために予約された場所
8 :
デフォルトの名無しさん :2013/04/03(水) 00:37:12.92
Node?
その仮想敵なファイルシステムみたいなものにカッコいい名前を付けて、 それを前置して「なんとかFile」みたいな感じで。
>>6 > FileInfoとかChunkInfoとか
一連の流れは読んでないがあるあるワロタw
こういう名前に着地しかかったら自己嫌悪になるわな。
かといって、考えた挙句のことだからどうしようもないわけだが。
先ほど Partition を思いつきましたが、
考えてみると、やはり紛らわしいですね。
どうもこれといったものがなさそうなので、
path_and_size を使わせてもらうことにしました。
分かりやすさではピカイチなので。
>>9 いや、そういうのホント嫌いなんです。
〜〜バトルシステムとか。
営業的にはやらざるを得ないものもありますが。
レスを戴いた方々、ありがとうございました。
拙い質問で申し訳なかったです。
なんとかinfoとか なんとかmanagerとか なんとかstatusとか なんとかdataとか なんとかargsとか ;' ':;,, ,;'':;, ;' ':;,.,.,.,.,.,,,;' ';, ,:' : :、 ,:' \ ,,. 、./ ノ( ::::::::', :' ● ● ⌒ :::::i. i ''' (_人_) '''' * :::::i : {+ + +} :::::i `:,、  ̄ ̄ ::::::::: / ,:' : ::::::::::::`:、 ,:' : : ::::::::::`:、
14 :
デフォルトの名無しさん :2013/04/04(木) 20:48:17.54
checkなんとかも入れてやってくれ(場合によるけど)
解決したらしいけど俺はregion気に入ったなw
なんとか還元水
2フレーム目に4など、 アニメーションに使うデータが定義されているクラスの名前は何が良いでしょうか
> 2フレーム目に4など、 意味不明
>>17 大雑把だな
フレーム毎にアニメーションに関連する何かしらのデータを保持しているってこと?
例えば、画像データとか
>>19 説明不足すみません
そうです、テクスチャ座標とかそういうのです
Animation
>>17 名前を求めているのはフレームに関する情報を持っているクラスそのものなのか、
それともそれを集約しているクラスなのか。
なんとなく後者の方のような気がするけど、後者にしても機能的にいろいろバリエーションが
ありえそうな気がする。
例えばSequenceとSequencerじゃ担う機能がまったく違う印象を受ける。
とにかく、いい加減な説明では他人はあんたのクラスの要件を理解できるわけがないし、
したがって適切な命名も出てこないよ。
まずは母国語が堪能でないとな
>>17 map<int, int>じゃだめなんw
本質的には、xフレーム目にyみたいなもんは配列よ。連想配列よ。
それがクラスというもんであって、変数名が多分frameindex2animeidよ。
プログラムの起動時、あるいはヘルプメニューで情報表示を選択肢たとき、 ソフトウェア名称やバージョン番号、開発者情報などが表示されることがあると思う。 これらのうち、ソフトウェア名称を格納する定数名は何が良いだろうか? ApplicationName、ProductName、SoftwareName あたりが今のところの候補。もし使い分けがあれば教えて欲しい。 補足 ・実行ファイル名や内部名などではなく正式名称 ・バージョン番号はVersion、開発者情報についてはDeveloperNameとDeveloperAddressを予定 ・プログラム内の別の箇所でも、例えば「このプログラムのバージョンは<Version>です」と書けば そこが「1.0.0」などの実際の値に置換されるような処理を行う
>>25 MyNameIs
ApplicationNameでいいんじゃね?
>>26 UNIXコマンドのwhoisやwhoamiみたいだなw
冗談はさておき、ApplicationNameにしたよ。ありがとう。
>>25 autoconfにならってPACKAGE_NAME
>>28 ありがとう。
せっかくなので内部名の方で使ってみる。
お知恵を拝借したい。 とあるプログラムで Person というクラスがあり、名前通り人のいろんな情報や振る舞いを持ってます。 このプログラムには時間軸がないため、Personクラスはある特定の瞬間のデータしか格納していません。 このたびプログラムを拡張することになり時間軸が加わりました。 時間tをforループで回し、各時間tでそれぞれ沢山のPersonインスタンスが生成されます。 ただこれだと扱いづらいので、同一人物のPersonインスタンスをまとめる新しいクラスを作ることにしました。 つまり時間概念のある人のクラスで、単純に言うといままでのPersonの配列のようなものです。 元のPersonクラスはPersonという名前のままであるとして、この時間軸を持った人のクラスに付ける名前としては何が適当でしょうか? ○○Personみたいな名前(TimerangePersonとか)になるのかなとは何となく考えているのですが。 データ解析プログラムなのでAnimatedPersonなんかはちょっと合わない気がしてます。
Person4D, PersonHistory,
TimeslicedProfile Transitional〜 Momental〜 すまん長い。
33 :
30 :2013/04/22(月) 08:33:03.63
>>31-32 ありがとうございます。
改めて考えると
>>31 さんのPersonHistoryが今回の意図にも近くしっくりくるのでこれを採用しようと思います。
自分で考えていてもこの名前は出てこなかった気がするので大変参考になりました。
別のバリエーションを提案して頂いた
>>32 さんにもお礼を申し上げたいです。
34 :
30 :2013/04/22(月) 08:39:06.44
参考までに追記: もしこちらで良い案が挙らないようであれば、あのあと自分で考えた MultitimePerson という名前にしようかと考えておりました。
普通は名前や性別などの属性が時間に従属して変わると思えないから 時間で変わる属性だけを時間を引数にとるメソッドに 変更する方がまっとうに思えるよね
>>30 その瞬間瞬間でPersonは「何を」格納しているの?
それがPersonの主要な使われ方なら、それにピッタリの単語があるかもよ
38 :
デフォルトの名無しさん :2013/04/22(月) 23:31:12.39
ゲーム作ってて悩んでる。 1.キャラの画像読み込みとかの準備する関数名 2.キャラクターの位置とか初期化する関数名 同じクラスで別々にしたいんだけどわかりやすい名前ないかしら
1. load 2. initialize
さげんの忘れてた
>>39 ありがとう。
そんな感じで行く
アバウトなお方w
「準備」ならprepareだと思うが・・・
prepareはデータベースっぽいイメージがあるなあ(偏見
ready
foreplayがしっくり来るな。
47 :
30 :2013/04/24(水) 01:53:22.37
>>35-37 この時間軸追加はオプション対応なので、もとの骨格であるPersonクラスは動かさないというのが前提なのです。
Personが持ってるプロパティは同一性確認用の識別文字列以外全部時間によって異なるので、
継承してそれらを全部変更するよりも、ガッと配列的にもって新たにメソッドとか足した方が今回の場合実装がらくなのです。
ちなみに位置座標とか計算した評価数値とかそういうのが入ってる。
プログラムの全貌を書いてないからこんなモヤモヤとした返答で申し訳ない。
時間が取れたら根本から拡張しやすいように設計しなおした方がいいのかもしれないけど、まだちょっとそれは骨が折れるなぁ。
今後の課題にします。
>>47 >>35 だが、なるほど。確かにネーミングが難しいね。histric personとか嫌だし、
トランザクションデータではあるんだが。
Historyとほぼ同義語でJournalっつうのもある
>>47 ゲームかな?ステータスヒストリーとかでどう?
キーボードのキーをチェックするクラスを作ったのですが、 キーを押した瞬間、離した瞬間を知るメソッド名で悩んでます 何かいいメソッド名ないでしょうか? ちなみに単純にキーが押されてるか知るメソッドはbool IsKeyDown(uint vkcode)って名前にしてます
>>51 > キーを押した瞬間、離した瞬間を知るメソッド
というのがよく分からんのだが、そのメソッドを呼ぶと、
いつキーを押したかという時刻(秒数?)が帰ってくるのか?
それなら GetTimePressedKey や GetTimeReleasedKey でいいと思う。
>>52 いや時刻を返すメソッドではないです
キーを離している状態から押されている状態に切り替わった1度だけを知りたい時に使うメソッドです
ソース上での話だと、C++でWin32APIでGetKeyboardStateでキーの状態を取り、
キーが押下されている状態だと最上位ビットが立って、
キーが押下されてない状態だと最上位ビットが倒れてるんです
1フレーム前にGetKeyboardStateで取得したキーの状態と
今回のフレームでGetKeyboardStateで取得したキーの状態で比較し
最上位ビットが立っている状態から倒れている状態になった時(キーを押した瞬間)と
最上位ビットが倒れている状態から立っている状態になった時(キーを離した瞬間)を知るメソッドです
説明下手でごめんなさい
それメソッドというよりイベントじゃないの
イベント(ウィンドウメッセージ)の方でもできるかもしれないですけど メッセージループの中でキーを取得したいんです
GetKeyPressedStickyStateAndClearIt
IsKeyBeingPressed とか?
beingてw
>>51 キーボードイベントの定番だと
up/downは「上げっぱなし」/「押しっぱなし」の意味で使う。
released/pressedは「離された」/「押された」時に1度だけ発行される。
IsKeyReleased()とIsKeyPressed()にしようと思います 変じゃないですよね??? 変だったら教えてください 教えてくれた方々ありがとうございました
説明下手杉 〜な瞬間を知る(返す)メソッド、〜になった時を知る(返す)メソッド じゃなくて 〜になった直後だけtrueを返すメソッドってことだろ? 俺だったら単純にnowをつける
その瞬間に「呼ばれる」んならわかるが、呼ぶってのがわからん、、
>>60 isって変じゃね?
俺ならkeyDidPressedとkeyDidReleasedにする
メソッドというよりトリガイベントな気がするけど
メソッドなのだとしたら動詞で始めるべき。 返すのがbooleanなのだったら3人称単数、isとかhasとか。
トリガ名ならwhenをつけて繋がる名前、Bool返すなら"This function returns true if it ---"の---の部分をメソッド名にする
67 :
66 :2013/04/27(土) 00:00:47.35
だからisKeyPressedはあまりよくない気がする
68 :
66 :2013/04/27(土) 00:03:42.14
戻り値がYESかNOと仮定してIs key pressed? Yes. と捉えることもできるのか? いや、やっぱりhasKeyPressedだな 連投スマソ
isは今押されてるか、hasは既に押されたかで分けてるな俺は。
英語能力もプログラミング経験も無い奴がおるな
be動詞は受動態、has+過去分詞は能動態の現在完了。主語が違うんだからそれがタイミングで使い分けられるわけがない。
boolだと三人称単数になるのは、その文章に対して正しい(true)か正しくない(false)かを返すから。
基本的には親となるクラスが主語でそれに対する動詞、で引数が目的語。
クラスとなるオブジェクトがKeyなら、key.isPressed()。
直後感(?)を出したいなら、まぁ hasBeenPressed() くらいか?
クラスがkeyそのものではなく引数だったら(今回の場合)、それをメソッド名に含めて isKeyPressed(key)もしくは、hasKeyBeenPressed(key)。
hasKeyPressedだったら「Keyが(何かを)プレスしたか」、になる。ナンセンス。
>>60 で良いと思う。
どっか間違えてたらツッコミよろしく。
72 :
71 :2013/04/27(土) 03:05:03.22
訂正。
>>71 > be動詞は受動態、has+過去分詞は能動態の現在完了。
はもちろん
be動詞+過去分詞は受動態、has+過去分詞は能動態の現在完了。
のことですね。
現在完了形でイベントを表現するって発想はなかったw 言うまでもなくそんな考えは完全に間違ってる。
質問者の話であいまいだと思うのは、求めているのが次のどちらなのか
はっきりしない点
(1) 「今」が特定のキーの押し下げ/解放イベントが発生したタイミングか
どうかを検査するメソッド
(2) 押し下げ/解放イベントが発生したキーを取得するメソッド
GetKeyboardStateを使うって言っているから、そこだけ聞くと(2)の方のように思えるが、
でも
>>60 で挙げてる候補は(1)っぽい。
75 :
51 :2013/04/27(土) 12:10:05.19
色々とありがとうございます あと下手な説明でごめんなさい 下手すぎる説明よりソースのがわかりやすいと思いますので 綺麗なソースではないですが必要そうな部分をアップします 一応winmain関数くっつけて動くようにしておきました パスワードはcppです ichigo-up.com/Sn2/download/1367031651.zip
keyboard.GetKeyDown(VK_UP) keyboard.GetKeyUp(VK_UP)
77 :
デフォルトの名無しさん :2013/04/30(火) 16:16:02.36
関係ないけどさ、プログラミングって英語力が必要とされるよね。 変数名や関数名とかを単に直訳しただけで、第3者が見たとき意味不明な単語が多いと理解するまでに時間がかかったりするから。 たまに単語の意味と処理の内容が違う時は本当にイラっとする。
あと、複雑すぎるメソッド名はやっぱり、設計で間違ってると思う。 リファクタリング本には、説明的なメソッド名は良しとされているようにあったが。 可能な限りギリギリまでシンプルにしたら使いまわし安いし、 やっぱり実装も堅牢だわな。
英語力も必要ないとは言わないが、命名が下手な人はそれ以前の段階で躓いてることが 多いように思う。 命名が下手な人は抽象化能力がないんだよ。 抽象化能力があればとりあえず母国語で名前を考えることはできるはずだが、 そもそもこれができない人が多い。 母国語で命名ができれば、ほとんどの場合はあとは辞書を引くだけ。
関数名ってそのクラスが主語で共通、後は動詞+目的語なわけで この目的語がそのクラスのやることに内包されているかどうかなわけだよね 究極的に言えば、目的語がなくても主語と動詞だけで何をしようとしているのか 分かるのが一番だな、引数が目的語の代わりになったりするし 英語力って言うよりもモジュール化とコンポーネント化の違いだな
・日本人には余り馴染みがないが、英語的に正しい単語&文法 ・ネイティブだと少し違和感がある(通じなくはない)が、日本人にも比較的分かりやすい命名 どっちを取るべきか迷うって人は居るんじゃない?
82 :
デフォルトの名無しさん :2013/05/01(水) 08:23:26.46
>>81 そういう場合は前者を取るべきだな。
後者だと、自分が勝手に思い込んでいるケースもあるから。
>>79 >命名が下手な人は抽象化能力がないんだよ。
あるある、頭の中が整理できてないのが手に取るように分かるコードとかw
…そんなのの後始末させられるとか勘弁してほしいもんだが
文字列データを保存する処理で文字列の中身が無い(nullやブランク)場合 に保存するかしないかのフラグを持たせるんですが、そのフラグ名は何が いいと思いますか? True:データ無しで保存しない、False:データなしでも空を保存で考えています。 NoDateNoSave とか? なんかスタイリッシュないいの無いかな・・・。
85 :
84 :2013/05/09(木) 13:50:46.63
× NoDateNoSave ○ NoDataNoSave
is required field
逆でもいいなら allow empty
SaveForced
90 :
84 :2013/05/09(木) 14:41:42.32
おー、やっぱり自分じゃ思いつかない単語で嬉しい。 どれも良さそうなので、大いに参考にします。
空文字かnull参照なら破棄 DiscardsIfNullOrEmpty
引数名で悩んでいます。 その関数は、ある値を引数に渡した値だけ加算していく処理をしています。 「変化量」的な意味の言葉を1単語ですっきり表現したいのですが・・・何か良い名前はないでしょうか。
Succ Inc
incrementをincと略すのは、少々危険じゃないかい?
dif
>>95 アセンブリ言語でもそう略してるし有名な略だと思うけど
>>98 CやC++だとincludeって言葉があるよ。そっちもincと略されることがある。
delta
101 :
デフォルトの名無しさん :2013/05/17(金) 08:16:17.17
step, amount
日毎の予約可能人数とすでに予約済みの人数を保持したいのですがどんな名前がいいでしょう。自分は 予約可能人数:MaxCount、PossibleCount 予約済み人数:UsedCount、ReserveCount ぐらいしか思いつきません。もしこれだ!ってのがあったら使いたいのでいいの有ったらよろしくです。
>>102 予約可能人数:AvailableCount, VacatedCount, LeftCount
予約済み人数:ReservedCount, BookedCount
>>99 CやC++だととわざわざ限定しているという事は、
インクルードファイルの読み込みに使う #include の事を指しているのですよね。
それを inc と略してコード内で記述することはできないはずです。
この意味での include がどのようなシーンで inc と略されるのでしょうか。
ディレクトリ名とか?
>>102 acceptable / reserved
>>103 個人的に、こういう場合はcountよりnumが好みだなあ。numReservedとか。
予約可能な人数なら、reservableやcapacityの語を入れるのも良いかも?
>>104 実際、インクルードガードや、内部用ヘッダファイル名なんかで見たことはあるくらいかなー。
ふと、Googleで「プログラミング inc」で調べてみたら、最初に「インクルード」の語が来たので、
ある程度の数は inc=インクルード と連想する人が多いんじゃなかろうか。
>>108 capacityだと、「全予約可能数」というニュアンスになって、予約云々が抜け落ちるよ
110 :
109 :2013/05/17(金) 14:10:11.24
なんか変な文章になったので、英英辞典から。 capacity: the maximum amount or number that can be received or contained; cubic contents; volume キャパ1,000人だけど、今日の予約可能人数は800人、みたいなイメージの違い。
なるほど、あくまで全体の数ってイメージなのか
>>102 ReservationCapacity
Reserved / ReservedCount
>>109 だからこそcapacityでいい。
a: 予約済み人数
b: ネット(残りの予約受付可能人数)
c: グロス( = a + b)
今回のお題で求められているのはbではなくcであるという含意だから、
それならcapacityはピッタリの言葉だと思う。
プログラミングではコレクションの容量をcapacity表現することが多いと思うが、
capacityと聞いてクレクションの容量の最大値のことだと思う人はまあ少ないよね。それと同じこと。
>>92 それは関数名をちゃんとつければ引数の名前は
valueでもxでも何でもよいケースにしか思えない。
>>99 アセンブラでもinclude疑似命令はよく見かけるぞ
>>115 逆を言えば日によって変らない定数であるはずの値を、
ある日に関する変数として実装する馬鹿はいない。
だからcapacityという変数名を見て、それがTPOに依存しない物理的な制約による
予約数の上限だと勘違いすることは考えにくい。
なに頑張ってんだか
ああ、英語能力もプログラミング経験もない馬鹿の壁君か
>>102 予約可能人数: nToReserve, numToReserve, nCapacityToReserve
予約済み人数: nReserved, numReserved
>>121 は?意味わからん
自分の意見が否定されたからって、俺をdisってもお前の糞意見の価値が上がらないし
nとかないわー
>>122 は?意味わからん
自分の意見が否定されたからって、俺をdisってもお前の糞意見の価値が上がらないし
>>120 ,122 はこんな偏狭のスレに来て なんであんなにハイテンションなんだ
え、俺めっちゃローテンションなんだけど n単語とかいう変数名付ける奴がいきってるとなんか凹むわ
numでもnbでもnbrでもお前の好きなのにしたらええやん。 スレ的には邪魔
nReserved とかいうセンスには閉口する
え、nObjectsとかnumObjectsってダメなん……?
よし、みんな集まれ
命名規則や設計の善し悪しについて議論するのは基本的に禁止。 命名規則や設計の善し悪しについて議論するのは基本的に禁止。 命名規則や設計の善し悪しについて議論するのは基本的に禁止。
愛国心は悪党の最後の拠り所とよく言うけど、
悪党(というより馬鹿)が愛国心を笠に着る動機と、
>>130 みたいな卑しい奴の
動機は恐らくそんなに違わないと思う
nReservedが駄目だって思われる可能性があるってわかって良かったね。
長い変数名つけるだけなら誰でもできるよね、翻訳ソフトの結果を CamelCaseで繋げばいいんだから
頭悪い指摘だな わざとなんだろうけど
nReservedじゃ意味分かんねえよ numReservedも数字予約済で????
変数っていうのは数値(number)とか数量(amount)を保持するのはある意味当たり前なので 一度num○○とか使い出すとそこら中に氾濫することになる。
>>119 何でToを使うかわからん。
長いけど、NumOfAvailableReserverとかrestBooksとかの方が他人が見てわかると思うが。
英語ができないんだよ 察してやれ
restOfBooks なら兎も角、restBooks はないよ
もっと無い
NumOfAvailableReserverもないわー
よほど悔しかったんだね
予約制限数:Subscribable 判断つかなそうならLimit、Amount、Countとか付ければいいかな 予約者数:Subscribers 複数形にしてそれが数であるように示す reserveのが一般的だけど上記の方が意味が掴み易いかもしれない reserverだと意味合いが変わってくるし
>>137 俺の使ってるプログラミング言語では変数は文字列やアドレスやその他抽象データ型にも使えるんだぜ。
自称英語通、いいかげんウザいよ?
最近は統合環境などの予測変換やってくれるんだから、 コメント減らすようにもう文章で書いちゃえよ。 VBとかC#なら 予約可能人数=10 とかでできるだろ。 まあ、俺はNumOfAvairableReservationsとするけどな。
>>136 the number of products reserved
→ numOfProductsReserved
→ numProductsReserved (ローカル変数ならProductsまでいらんし)
→ numReserved
the number that reserved products
→ numReserved
>>148 長いお。そういう変数が1行に3つもあるとかなり苦しいソースだYo!
avairablewww
なんかネタにして低レベルなレスが続いてるけど、
>>112 に書いたグロスとネットの区別が付かないような名前じゃ話にならないだろう。
>>151 最近のモニターは横長で2560なんて普通にあるからなあ。
昔は一画面に収まるように変数名も短縮して書いていたけど、
これぐらい広いと1行にいくつも書いても気にならないし、
かえって読みやすくなる。
まあ、みんながみんなこんな環境じゃないから良くはないんだろうけど。
予約可能人数? remainでいいよ その他の事は文脈で分かろう
capacityとかないわー
>>157 言語仕様で長い変数、メソッド名を推奨しているとこもあるわけで
capacityだと残りだけじゃなく 既に予約された部分まで含む って、予約可能人数って残りの事だよな? それとも全容量なのか?
>>163 とっくに全部目を通してるわけですけど…
ある、ってだけで誰が全部に当てはまると言った
長過ぎず、かといって理解不能なほど短すぎず、が理想だな
長過ぎるとダサい人としか思えないもんなー。 まぁよほどきれいな英語を使う人ならともかく、たかだか日本人英語だし。
↑英語コンプレックスでもあんのか?w
お前は後輩からもダサいって思われてるってこと
後輩のコードがネットで翻訳した感丸出しで困るわ。
教えてあげて
まあせいぜい20文字強くらいだな
>>149 Of略したらダメだと思う
Of書きたくないならReservedNumの方がマシ
でもReservedNumだと予約番号と取られかねないからReservedCountかな・・
>>171 ローカル変数なら20文字は長めだな
関数名ならまだしも
H.264の各種変数は 仕様書に書かれた通りの名前で扱うのが適当なので そうなるとそのくらいの長さになることはある
numof-をnum-にすることって、あまり良くない?
よくある
numをつけること自体あまり良くない
of付けるアホよりはマシって程度
countかcntつけてる
>>173 ReservedNum → 予約されたナンバー という意味になる。
このことは
>>173 も言ってる。
NumReserved → (後ろから前を修飾する英語の語順だから問題ないよ)
of theが省略されたと思えば
確かにまあ、numナントカばかり増えても分かりにくいか。 ナントカManagerやナントカDataよりはマシだと思うけども。 あと、index(idx)とcount(cnt)とnumber(num)の使い分けが微妙に分からん
>>183 文脈に応じて使い分けが変わるんじゃね
indexは整数、countは0を含む自然数、numberは実数
indexは配列の添え字、countは頻繁に+1/-1して数を数えるのに使う、numberは既にある個数を表す
indexは参照、countは個数、numberは番号
ありがとう。 1番目の、取りうる数字によって変わるという意見は面白いな。今度採用してみよう。
valueってのはありませんか?そうですか
>>185 その「1番目」はむしろトンデモだと思うけどねw
まあnumber以外は暗黙的に正の整数ってニュアンスはあると思うが、
型で言えば基本全部整数でしょ
.netフレームワークの配列だと indexは特定の要素を指定する変数、 countは配列の要素の件数を求めるメソッド名、って使われ方だね お使いのフレームワークの流儀に合わせておくと楽なのでお勧め
配列は Length で IList は Count ってのがねえ
>>189 正の整数って正確な定義はn≧0じゃなくてn>0なんだね。
勘違いしてた。
>>190 配列はほとんどの言語で要素がメモリ上に連続して配置される約束になってるけど、
リストはそうとは限らないからでしょ
別に連続してても Count でいいじゃんと 配列を IList にキャストすると Count になるし
>>193 確かにCountでもいいと思うけど、Lengthの方がより限定的な意味になる。
意味が限定的になったら何なんだって考え方もあるけど、そっちの方がより
しっくりくりくるって考え方もあるのでは
関数にするまでもないコードをそのままコピペできないから面倒くさい面はある
splitする予定の改行区切りテキストはどういうふうに名付けてる? URLリストの場合urls_textみたいにしてるけど
tmp(笑)
>>196 例えばデータベースのurlの欄に複数のurlが改行区切りで書かれていてそれを一時的に読み出すための変数名なら
単純に$urlで受けておいて、split結果を@urlに保存する。
>>197 正直url_joined_with_eolとかするくらいならそっちの方にしたい
>>198 Perlなら記号自身で単独と配列を区別できるから楽だよね
そうでないと複数形の変数名=配列みたいに制約が必要になるからこういうとき悩む
unsplit
>>196 そんな命名に困るような変な値、ローカルより広いスコープで持たずに済むのなら
それが一番。(そもそもどうして素直に配列じゃだめなんだろう)
持たざるを得ない理由があるのなら、「改行区切り」という概念に俺様頭字語を
宛がって、それを使うとか。
例えばurls_by_nlsvとか、ハンガリアンでnlsvUrlsとか。
やっぱり気持ち悪い物には気持ち悪い名前しか付けられないよな。
>>201 素直に配列じゃダメもなにも、例えばテキストファイルから一括で読んだ文字列を配列に分解する…みたいな、そういう話だろ?
テキストファイルは文字列並べたファイルであって素直に配列じゃないんだから、どうしようもないかと…
まあ俺なら関数分けの仕方を工夫するかな、んでtxtとかsrcみたいな名前にする
「テキストデータを分解する関数」であれば、何のテキストだよみたいな話にもならないし
>>202 何が「だろ?」か意味が分からないが、
君の言ってることは改行区切りの文字列を<ローカルより広いスコープの>変数で
持たなければならない理由になってない。
自分で勝手にローカルより広いスコープだと決めつけてるのに気づいてない
ローカル変数の名前に凝るのはバカの証と相場が決まってますよ
アウフヘーベンすると命名に困るような変数はそもそもデータの保持に問題があって 名付けるまでもなくさっさと専用の関数が処理してくれるようにしようということですね
責任範囲が広すぎるんだわな
十分にスコープが狭ければ、ch とかでも良かったりするしな…
極論だけど、分かればいい スコープ長いと適切な名前を付けるべき 短いならiでもかまわん って一文字変数スレみたいになるw
そういうのって受け取った時点で改行でsplitして配列に入れればいいんじゃないの? ファイルからでも引数かなんかで受け取った場合でも同じだと思う
「i」って変数を添字に使っちゃダメって社内ルールがある事は知ってる 賛成はしないが だからといって「ii」って名前付けるな、バカ前任者!
ルールを守った者に責任はない そんな不完全なルールしか制定できない池沼が悪い 常識で済むならルールは不要
>>211 フォントによってはiより視認性が上がる云々…を見たことあるw
俺は基本的にiを気にせず使ってるがj, k, lとかは使わんな。
ループの入れ子は避けるし、もしするなら変数にもう少し長めの名前付けるわ。
二次元配列ならxとかyを使えばいいか
うむ
何の説明もなしに「変数 i」と言われたら、大体のプログラマはループ用だと思うはずで、 コーディング規約の重要な目的の1つである「可読性」については、きちんと満たしているんだよな。 なのに、なー……
マウスのホイールと移動の量(どれだけ変化したか)を格納する構造体の名前 よろしくおねがいします
distance
219 :
217 :2013/05/24(金) 20:42:24.99
>>218 距離ですかなるほど
ありがとうございます
ホイールと移動の量を一つの変数に格納するのか・・・
すまん、見落としてた。 構造体か
222 :
217 :2013/05/24(金) 20:52:24.27
224 :
デフォルトの名無しさん :2013/05/24(金) 21:05:24.96
単位はmickyだっけ?
226 :
217 :2013/05/24(金) 22:05:55.80
何だその冗談と思ったらガチだった ミッキー構造体にするのもありかもしれない
ここは一つ、Mappyで
228 :
217 :2013/05/24(金) 22:33:08.86
>>227 もう何を表してる構造体かわからない
扉とかトランポリンかしら
ドラッグの処理などでマウスの絶対位置ではなく移動量が必要になることはよくあるけど、 それとホイールのカウントを一緒にもつ必要性がよく分からんね。 要するに、名前が付けられないのはそれが何を意味してるのかよく分からん値だからじゃ ないのかと。
ライントレーサ用センサモジュールを作ってる学生です。 ライン位置をセンサで読み込んで、 その値を、右を正として出力するか、左を正として出力するか設定する フラグの名前をどう付けるか悩んでます。 数学で言う、グラフの右を正とするみたいな言い回しだと思うんですが・・・ 皆さんならどうつけますか?
>>230 意外と難しいな。
Polarity = [LeftToRight | RightToLeft]
とか
もっとシンプルにboolを返すIsRightPositiveでもいいような気がするんだけど、
これはググってもヒットゼロだから言い回し的に何かおかしいのかも
232 :
217 :2013/05/25(土) 08:40:27.00
>>229 確かにそうですね
同時に取得できるからなんか一緒にしないとってなってました
解決しましたありがとうございます
>>231 右が正と仕様で定義して、isFlipped
XAxisDirection = 'right' っすな
かっこいい
237 :
230 :2013/05/25(土) 19:16:10.08
>>231 >>233 >>234 レスthx
シンプルにbool型を使いたいんで、is_axis_direction_rightとかにしようと思います。
個人の趣味でC言語による組み込み開発なんで、コーディング規約がなく、
命名規則もどれがいいか手探りの状態です。
変数名は経験をつまないとすぐ出て来ませんね。
ひとまず、この規約・命名規則使っとけみたいなのがあればいいんだけど
238 :
230 :2013/05/25(土) 19:26:59.64
あ、
>>1 に
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
てありましたね。すみません。
>>237 の後半は無視してください。
ヒントをくれた方、ありがとうございます。
規約規則はスレ違いだが、暗黙の了解としてGoogleのC++ガイドラインくらいは見ておいたらどうだろう
採用するかどうかは別として、だな。 半分くらいしか一致してないって人も多そうだ。
命名規則や設計の善し悪しについて議論することこそが、 価値あることだとなぜ気付かない。 ただでいろいろ議論してくれる連中がいるのに。
なんでもかんでも批判するやつが現れて気軽に案を出しににくくなるからじゃないかね知らんけど
なんぼでも批判してくれていいんだけどな。 しかもタダで批判してくれるってんだし。
>>241 次のスレで最初にそういう約束を書いておけばいい
人が集まるかどうかは知らんが
批判と同時に代案が出るならまだしも出ない場合はスレタイとは相性が良くないよな あと宗教戦争がこわい
右と左のフラグは文字列にするわ direction="L","R"の方が分かり易いし美しい
文字列定数の方がいいような気も…
一文字なら文字列じゃなくて文字でいいじゃん
二値なら0と1でいいじゃん
#define RIGHT 1 #define LEFT 0 こうか
>>250 defineキター
もうそれでいいんじゃね
RIGHTとLEFTだと文字数が違うのが気に食わんのだよないつも
width と height もね
DBのテーブル名なんだけど、メンバー登録とログインの履歴を記録するテーブルで auth_historyとauth_logで悩んでる 要はhistoryとlogっていう単語の使い分け方を教えてほしい
logは記録がメイン、historyは記録を遡って調べるのがメインって印象があるなあ。 UNIXコマンドのhistoryに引っ張られてるだけかもしれないが。
log から history を作る
logの配列がhistoryというわけか
258 :
256 :2013/05/28(火) 23:33:52.37
>>257 ごめん、log した情報をから、何を見せたいかという意図に基づいて(取捨選択して) history を作る
と言いたかった
>>254 この用途だったらauth_logにするかなあ、俺なら
なんかぼんやりと理解できたような テーブル自体はログであってそれをヒストリーとして使うかはアプリ側の問題って感じ? とりあえずテーブル名はlogで行こうかな ありがとうございます
261 :
259 :2013/05/28(火) 23:57:38.13
>>260 俺はlogは不変(どういう事情でも挿入も削除もされないもの)
historyは必要に応じて非表示、削除、追加修正があるものと捉えてる
アプリ側のインタフェース側だとhistoryでテーブルはlogってのがしっくりくるかな
historyは過去からの履歴。history of password changing logはそれを行った行為の記録。userA change password on 2013-05-29 01:00:00 lotgingとは言うがhistoriingとは言わない。
lotgingとは言わないんじゃ?
>>254 考えてみるとどっちもあまり違わない気が history vs. log
強いて言えば、logは自発的な行為も外生的(←なぜか変換できない)なイベントも含むが、
historyの場合は後者を含めない傾向はある気はする。
loggingの誤字くらい勘弁してやりたいところだが historyingも誤字ってるのでちょっとフォローできんわ
根本的に英語ができないのに辞書読んでわかったつもりになって説明するからボロが出る
commit logとは言うがcommit historyとは言わない change logとは言うがchange historyとは言わない これ、何かのトリビアになりませんかね?
言うよ?
"commit history" 約 1,120,000 件 (0.24 秒) "change history" 約 5,240,000 件 (0.32 秒) めちゃくちゃ言うやん
時系列の観点で使い分ければいいんじゃない? log は記録することが主体(結果的に時系列になっていることが期待できる) history は時系列の意識が log より強い
>>270 メンバー登録とログインの履歴を記録するテーブルというのは、
時系列の観点で log か history か分けられるもんなの?
historyは履歴 logは記録
ログインって言うくらいだからlogでいいだろ
>>273 ログインって和製英語だろ
英語ではSign in
海外のオープンソース(djangoとか)も内部でloginって使ってるよ
日本はパイルダーオン
>>274 UnixやLinuxでは
--
host_name login: _
--
ってなってるの知らない?
unixはログイン/ログアウト windowsはログオン/ログオフ
>>280 なんで同じこと思ったヤツが3人も居るんだよw
和製英語はlogined
logなら直感的に自動記録とわかる
コンピュータのシステムなら、logだろうがhistoryだろうが自動記録だろ
ブログは全然自動じゃないことを考えても、自動かどうかは関係ないと思いますが
logは記録のそのものを指し historyはあるモノの記録のある地点からそのあるモノの状態を遡った記録
>260あたりで既に完結してる感
そこから28も続いてたのか
290 :
デフォルトの名無しさん :2013/06/06(木) 03:22:14.21
創価学会の偽本尊にご注意
文字cがn個連続した文字列を作る関数 string ???(char c, int n) なかなかいい名前が出ない
repeat
なるほどリピートか
ソースの中から正規表現で画像URLを探し出すメソッド名 string MethodName(string src); いいのあったら教えてください。
FindImageUrl
ExtractImageURL GetImageURL FindImageURL SearchImageURL
298 :
デフォルトの名無しさん :2013/06/11(火) 22:39:37.98
複数返すならimage urlsにしておきたい。
ローカルディスクのファイルも同じ処理で調べられそうなら、 Url ではなく Uri にするのもアリかなあ。
関数名お願いします 文字列を引数に、文字列を前半後半で分けて配列を返すんですが、 devideString()は割り算を想起させますか? 他に分解っぽい名前が思いつかず相談します
splitAt(index)
>>302-303 単純なワード見落としてました
和英引くだけじゃダメっすね
ありがとうございます!
意味的にはsplitでいいと思うけど、実際の用法を参照すると、splitって名前は文字列をセパレーターで 分割する処理に対して宛がわれてることが多いと思うからどんなもんかね。 divideとかhalveとかいう言葉を使った方が変な誤解を避ける上ではよいかもしれない。
splitAt
first_half/last_half substring head tail
類義語を使って固定観念を崩すと後々紛らわしくなりそうだから splitの接尾辞にatとかhalfを推したい
substringFromHead
create_array(string org, int nsplit) // 単に文字数をnで等分していい場合 create_array(string org, char delim) // delimの位置を検出して前後を取り出す場合
ゲームの作成で、タイトルとかオプションとかを関数ごとに分けようと思います。 わかりやすく、下記みたいに頭に共通の文字を付けたいのだけど、何も思いつかない・・・。 ○○○Title ○○○Option ○○○の頭は大文字で2,3(,4)文字目は小文字で。 いい単語等あればよろしくです。
>>311 あなたのソース内の ○○○Title という名前の関数を見た者が、
そこから何を読み取ることを期待するのか、どういうことが頭に浮かんで欲しいのか、
そういう意図をはっきりさせないと、きっと良い単語は出てこないと思う。
○○○Option の方も然り。
>>311 DoMainLoopOfScreenOfTitle
DoMainLoopOfScreenOfOption
タイトルをどうする関数か オプションをどうする関数か
たぶん、タイトル画面やオプション画面などの「画面」単位に分割して、 それぞれを関数化したいって話だと思うよ。 もちろん、具体的にどう分割するか? 状態遷移をどう実装するか? っていう問題は別にあるけど。 自分はゲーム業界の人間ではないが、 Title()、GameTitle()、TitleScene()、TitleSequence()、Game::Title() あたりを見たことがある。 個人的には、名前空間 Game:: なり GameScene なりを付けるのが 色々と応用が効くから便利かなあと思っている。
あんまりいい設計には見えないんだけど
設計の良し悪しは議論しないスレじゃなかった?
だったな、すまん ただ設計思想が見えないと名前を提案する側もどうすりゃいいのか その場しのぎで思いついた名前を書くだけのスレって言うなら仕方ないけど
そのへんは質問者が説明してくれないならエスパーするしかない
>>321 無理にエスパーしなくても、説明されるまで黙って待てばいいんだよ
>>317 その辺は想像つくけど
結局それらを「どうする、何する」関数かって話
「生成」するとか「表示」するとか
動作の内容と結びつかない物の名前は関数名として非常にわかりにくい
関数名っていうからには何らかの動作があるんだろうと思ったわけ
>>315 あーそれあかんやつや。4ワード以上のCamelCaseは圧倒的に見辛い
325 :
317 :2013/08/02(金) 11:21:37.26
>>323 俺は、そういうのを全部ひっくるめた、各処理の呼び出し元となる関数だと思った。
そこから描画とか入力やらルーチンやらの処理を呼び出してく感じで。
で、「画面」の初期化処理の関数を用意するとして、そのときは
Game::Title::Init() とか TitleScene_Init() とか、title->Init() のように作っていけばスマートかなって目論見。
質問者は逃亡か
お前らのおかげで解決したんだろ
関数名です int _(FILE* fp, int offset, int len) ファイルストリームのoffsetの位置からlen byteを整数に変換して返す関数なのですが 何か良い感じの名前ないでしょうか
read integer
fread_int_at
334 :
デフォルトの名無しさん :2013/08/15(木) 05:48:09.39
bool値の取得にはisなんたらと名付けるけど setアクセサによって変更可能な値の場合は対義語のgetにしておくのがセオリーなんだろうか
エロゲのクラス名、変数名ってどんなかんじなんやろ
>>335 まったく面白くない答えで悪いが、普通のゲームと何ら変わらない。
例えば ADV だったら、普通のシーンもエロシーンも全てただの Scene だ。
それらがグラフ構造(コンテナ) SceneGraph の中で繋がっている。
背景やキャラクターについても同じで、どんなものだろうと BG や Character だ。
それらを Resource というクラスで管理している。
エロゲとそうではないゲームで分けるメリットがない。
EroResource EroItem, NormalItem SuperEroなんとか
意味がない
>>334 何が一番「分かりやすいか」だ。
あなたのプログラムソースの中で get 以外ではるかに分かりやすい名前があれば、
セオリーに拘らずに、そのより分かりやすい名前を使うべきだと思う。
ただ、並大抵の分かりやすさでは不足だと思うぞ。
セオリーというのは、長年培われてきた習慣だからね。
set の対は get だとたいていのプログラマは思い込んでいる。
それを前提にして API マニュアルの説明文もろくに読まない。
その習慣に逆らうわけだから、現場を十分に納得させる力がいる。
そうでなければ、素直に get を使っておくべきだ。
そうすれば、少なくとも現場でその関数の使い方で混乱することはない。
ここでいう現場というのはプログラマチームのことで、
もと一人で趣味でやっているのなら、その現場はあなた一人だ。
その場合は、好きにやってくれとしか言いようがない。
>>339 >セオリーというのは、長年培われてきた習慣だからね。
>set の対は get だとたいていのプログラマは思い込んでいる。
この思い込みって、ジャバラ文化に固有の風習/慣例のたぐいだろなぁ....
一般常識からすればsetの意味は集合だし、getの対はputだと思うけどね
>>334 そのメソッドが何を抽象化しようとしてるのかを明確にできればどうすればいいのかわかりやすくなる。
何かの判定関数を作りたいのであればisかもっと気の利いた名前があればそれでもいいし、
(java beansの)アクセサメソッドを設置したいのであればgetにするべきだ。
>>340 ジャバラ文化というのがどのような文化なのか知らんが、
ここで大事なのは一般常識で見てどうかではなく、
そのソースを読んだり使ったりするプログラマが見てどうか、だから。
プログラマの中では getter / setter という対が習慣として頭に入っいている者が多い。
入門書でも使っているしね。
アクセサで getter / putter の対を使っているのは、わたしの周りでは見たことない。
>>342 アクセサという概念を推すのはjavaなどの限られた言語だから
多分javaのこと言ってんだろうとエスパーはするけれど、
一応、元の質問ではjavaに限定してないからsetter/getterはjavaのローカルルールでしょ。
えっ?
せっかく隠した内部構造を透かせて見せるようなもんだからアクセッサは初心者には毒。 もっとも、C#のプロパティなんかはさらに甘い毒。
いちいち Get~ Set~ なんて面倒な程関数作られるよりは充分マシです>C#のプロパティ
アクセサは変数のやりとりに伴う 種々の面倒な手違いを防ぐためのもんでしょうに。 状態を持つ言語ならjavaだけじゃなく普通に使う。
>>345 何いってんだこいつ。
>>348 お前が一番スレチだということにいい加減気づけ。
てめえの卑しい欲求を満たすためにこのスレを利用するなバカ。
>>334 には変数へのアクセサとは一言も書いてない。
アクセサでないならgetter/setterにこだわる必要はない。
>>349 > お前が一番スレチだということにいい加減気づけ。
私のどのレスがスレチなのでしょうか。
卑しい欲求とは何のことでしょうか。
>>352 意味が分かるのはたぶん君だけだろうね。
>>345 が頓珍漢なことを言ってることは誰にでも分かると思うけど。
>>349 > てめえの卑しい欲求を満たすためにこのスレを利用するなバカ。
てめえの卑しい欲求を満たすためにこのスレを利用するなバカ。
>>命名規則や設計の善し悪しについて議論するのは基本的に禁止。 で、「基本的に」だから、完全に禁止してるわけじゃなくね?
卑しい欲求を満たしたいので、 エロゲのクラス命名法についてもっと語ってください。
>>356 話題ズレてんの自覚しててまだ続けようなんて相当に傲慢だね。
自分でスレ立てろっつの。
>>358 おまえが無理して入ってこなくていいんだよ。興味なきゃスルーで。
もし、そういうのが嫌で、厳格なルールに則ったスレが必要なら
自分でスレ立てろっつの。
>>356 基本的に禁止している事を例外的に認めるには、
質問者の疑問を解くのに繋がることでないとダメなのではないかと、私は思います。
たとえば、このように設計を考慮すればもっと適切な良い名前が付けられる、とか。
>>334 の 「get はセオリーか」という質問に対して、
少なくとも
>>345 と、それの相手をした
>>346 は質問に絡んでいないように見えます。
名前が話の主ではなく、アクセッサが主であるようなレスではないでしょうか。
私の個人的な考えです、気を悪くされたら申し訳ありません。
>>360 質問者だけのスレじゃねんだよ。質問者だけしかタメにならないんだったら、こんなとこで
回答なんかしねぇよ。そんなボランティアなんかやるかよ。
こっちも、質問者に回答するのが第一だけど、議論とかで
タメになると思ってるから、回答してるんだよ。
アクセサでないならアクセサと誤解するような命名は避けるべきではないだろうか
>>362 てめえの卑しい欲求を満たすためにこのスレを利用するなバカ。
今気づいたが、質問って 「ブール型変数」 に対するアクセサの名前なのね。
使用言語は分からんが、C++ でいうと、
class A {
private:
bool visibility;
public:
void setVisibility (bool v); // セッター
bool xxxx (); // ゲッター
};
このゲッターである xxxx 関数を
ブール値読み取りのセオリーにしたがって isVisible にするか、
セッター/ゲッターのセオリーにしたがって getVisibility にするか、
はたまた全く別の名前にするか。
もし質問がそういう意図であるなら、ごめん
>>339 の意見を撤回するわ。
is***、get*** どっちでもいいと思うが、それ以外は余程適切でないと混乱するとお思う。
ただし、ひとつのプロジェクトで is***、get*** が混在するのは良くないと思う。
どちらかに決めたら、それに統一した方がいいと思うぞ。
isというか visible(boolean)/visible(void)で 引数付きはsetter、なしはgetterでいいんじゃなかろうか。
>>368 その例で言うなら、
show()
hide()
isVisible()
の方が好み。
直交性のないものなのに同一の名前をもたせるのは問題だけど、 似た場所で使うのに名前が遠いメソッドであふれるから嫌なんだよな。 どっちも解決する方法があればなあ。
>>371 >直交性のないもの
間違えた、直交性のあるもの。
>>374 すまない、一般的な語すぎて出てこない。
それはどういうものなんだ?
376 :
334 :2013/08/15(木) 16:14:12.51
何やら情報不足だったようですいません
質問内容はまま
>>367 さんのご推察の通りです
特にセオリーなる風潮が見られないならば、getに統一したいと考えています
>>375 別に深い意味は無いよ。
特定の値を明示してセットするのではなくて、
今の状態に対してビット反転や足し算とmodなどを駆使して切り替えるようにしてみたらどうよって言ってみただけ。
>>376 そもそもisVisibleとgetVisibleが対立するという考えが正しくないような気が。
ありうるゲッター/セッターの組み合わせはこうじゃないのかと。
(1) getVisible / setVisible
(2) getIsVisible / setIsVislble
(3) visible / setVislble
(4) isVisible / setIsVisible
(5) bool isVisible() / void isVisible(bool value)
(1), (2)が普通で(3), (4)はあまり一般的ではないんじゃないかと思う。
(5)は自分しか見ないコード以外では使わない方が無難だと思う。
>>379 >(5) bool isVisible() / void isVisible(bool value)
わざとやってんの?
bool isVisible(void) はイイとして、 set/getという動詞を使うのなら、 たとえば void setVisibility(bool value) では? 些細な話かなw
あの、
>>367 で visible を例にしたのは私ですが、
とくに何も考えずに適当に visible を選んだだけですので、
この例をいつまでも引っ張ることもないかと・・・
>>372 にもセンスの無さを指摘されていますし
>>381 言ってる内容と違って、setVisible isVisibleを抜かして、
無理やり対称にしてるから。
>>382 俺は
>>368 を受けて書いただけで必ずしも自分の意見じゃないんだけどね。
でも
>>368 の言いたいことは分かる(つもり)。
C++/javaでもC#みたいにget/setなしで済ませたいと考える人がいて、
そういう場合にオーバーロードを利用して(5)みたいに書くらしいよ。
isVisibility(bool value)でthisを返すようにしたらjQuery
387 :
386 :2013/08/15(木) 17:02:39.89
isVibisleでした
>>385 > C++/javaでもC#みたいにget/setなしで済ませたいと考える人がいて、
そういう人達は、まず
>>370 みたいなことを考えるんじゃなかろうか。
>>388 bool値の属性に限定しても、属性の変更がセッター以外のメソッドでも表現できるケースはむしろ稀かと。
>>389 そうかな。
むしろ、bool値だからこそ別表現で表せることが多い気がするけど。
ただし、動作(副作用)が伴う場合に限るけど。
動作を冗長に書けばいいってもんじゃないしな。 setter自体強力な型持ってる言語ならそもそも不要だし。
392 :
334 :2013/08/15(木) 18:17:42.76
>>379 getIsのような動詞が重なるタイプって本当に一般的なんですかね
isはhas, canと並んで真偽値の取得に使われる接頭辞だと聞いてきましたが
使っているのはC++ですが自分の中の命名規則として英文法を重視していてJavaに近い気がします
メソッドの接頭辞は動詞, プロパティは形容詞か名詞 (形容詞はif it's XXXの名詞節が省略されていると考える)
補語は状態を表すなら形容詞, 分類を表すなら名詞
目的語は名詞オンリー
転じてJSのようにあくまでプロパティがオーバーロードによって関数的に振舞う場合は動詞抜きでOK
たとえば可視状態の読み書きに関する命名だとこれらが候補
○isVisible (可視的である)
×isVisibility (可視性である)
×getVisible (可視的の取得)
○getVisibility (可視性の取得)
×setVisible (可視的の設定)
○setVisibility (可視性の設定)
ぶっちゃけvisibilityは書くのが面倒なので「形容詞は名詞節」理論によって全て形容詞化してしまうか迷っているところ
>>392 setVisibility(true)にしたらどうなるんだよ?
394 :
334 :2013/08/15(木) 18:29:31.51
>>392 そんな難しく考えなくても、セッター/ゲッターはオブジェクトの属性名の頭に
set/getを付けて機械的に命名するものだと考えれば済むと思うんですが。
そのように考えず、いちいちセッター/ゲッター自体が英語的に違和感なく読めなければいけないと考えると
命名に困るというより、むしろほとんどのケースで命名なんか出来なくなると思うけど。
>>395 > むしろほとんどのケースで命名なんか出来なくなると思うけど
既存の変数にセッターゲッターを付けようとするとそうなるけど、
初めから変数名と合わせて考えれば、命名なんか出来なくなるというケースは、
たぶんあなたが思っているよりは少ないと思う。
ゲッター/セッターで取得/設定するのはあくまでオブジェクトの属性であって それを変数と呼ぶのは違うと思うけど、それはともかく、 get/setを頭につけた上で英語としてちゃんと読めるようにしようとすると、 get/setに後続する部分は名詞か名詞節にする必要性が生じるから、 どうしても表現の幅が制限される。 例えば、enabledっていう属性があるとして、これにget/setを付けて英語として 違和感なく読めるようにするには、どういう名前を付ければいいんですか? getEnability / setEnabilityではぎこちない。 getEnabledと書いて、これは例えば get whether enabled or notを省略したものだと 言い張ることも可能かもしれないが、ちょっと苦しい。
get enabledが自然
変に固定の命名に哲学押し付けるよりもその場に合った共通の基準でいいと思うよ。 Beans扱うとかならプログラマの可読性より静的解析優先だろうし、 中身が変化しやすいコードならそれこそ本当にセンス云々の話になると思うし。
400 :
334 :2013/08/15(木) 21:17:17.43
>>397 復唱になるけどその場合はget [if it's] enabledとできます
一般的な命名の表現力を殺すほど強い規則だとは思わないけどそんなに強引?
get [the value of] "enabled" get "enabled" [value]
>>397 > 例えば、enabledっていう属性があるとして、これにget/setを付けて英語として
それが、既存の変数にセッターゲッターを付けようとする、という事。
まぁ俺も変数名なんて言ったから申し訳なかった。
最初からget/setを使うつもりで変数名、属性名を考えるんだよ。
たとえばあなたが enabled に込めた役割を果たすような名前なら availability とか。
これなら、getAvailability、setAvailability で違和感が薄れる。
まぁ、微妙にニュアンスが違うと言われれば、返す言葉はないが。
ではセンスある命名よろしく
>>402 センス無いのはここ
> 最初からget/setを使うつもりで変数名、属性名を考えるんだよ。
ではセンスある命名法よろしく
>>406 最初からset/getを使うのを前提としない
get(Constant.VISIBILITY); set(Constant.VISIBILITY, Constant.VISIBLE); set(Constant.VISIBILITY, Constant.INVISIBLE); 抽象度を高めてみた。
Javaプログラマってほんとアクセッサ好きだよね ウンコ言語
自分に自信がありげな所がまた香ばしい
結局命名はできないと。
命名以前の問題 つまり、スレ違い
enableとavailableは全然違うだろ
もうアクセッサ禁止でいいよ。Java以外は。
Javaだけかよ お前の世界観狭いな
Javaのウンコプログラマは、機械的にセッターゲッター言ってればいいんだよ
Haskellでプログラムすればこんな馬鹿な問題は起きないんだがな
ocamlもだけど変な引数はコンパイル時にはじかれて受け取れないからな アクセサの一呼吸がいらないのは本当に楽
いや、俺はセッターゲッターの名前なんてものに悩まされないで済むという意味で言ったんだが
直接渡すって意味じゃないならどういう意味だ?
直接渡すわけではないって意味
なるほど 具体的な理解はできてないが文意は納得できた わざわざレスしてくれてありがとう
if (x.getEnabled()) ... なんて読みにくいじゃないか。 if (x.isEnabled()) ... のほうが明らかに読みやすい。 名前付けするときにはその名前が使われる箇所の可読性を考えてほしいな。
>>424 if で使うときはそれでいいよ。
でもさ、同じものを、引数として真偽値をとる関数を呼ぶのに使う場合はどうなのよ。
たとえば、createData (・・・, x.isEnabled(), ・・・)
なんか変じゃね?
createData (・・・, x.getEnabled(), ・・・)
とか
createData (・・・, x.getAvailability(), ・・・)
の方がまだマシじゃね。
使われる箇所の可読性を考えるとなると、同じ役割の別名関数を複数作ることにならね?
でなければ、if で使うか関数の引数で使うか、その他の所で使うか、
どこかのケースで妥協しないといけなくなるよ。
if (x.getEnabled()) はたまたま if で使うケースでの見やすさを諦めたのかも知れん。
>>425 > たとえば、createData (・・・, x.isEnabled(), ・・・)
>
> なんか変じゃね?
いや、別に。
何が変だと思うのかもう少し説明してもらえると伝わるかもね。
getEnabledはないだろ 英語の素養がるなら明らかに避けるべき
>>428 無知はお前だ
ガチガチな規則があるわけでもないなら避けるべき
>>426 違和感を改めて言葉で説明するはちょっと難しいな。
プログラミング言語の関数やプロシージャの実引数は、
その関数やプロシージャに「入力する」とか「挿入する」イメージがある。
戻り値は、出力とか、取り出すイメージ。
で、createData (・・・, x.getEnabled(), ・・・) だと、
get*** で取り出した値を createData の引数に入力するイメージとよく合うんだ。
取り出して入れるという一連の「処理」ね。
でも、createData (・・・, x.isEnabled(), ・・・) だと、
取り出すというイメージが乏しいじゃん。
なんというか、x is Enabled という言明で止まってしまう。
真偽値を取り出して、引数に入れるイメージとはちょっと合わない感じがする。
if (x.isEnabled()) なら別にいいんだよ。
x is Enabled という言明があって、if + 言明で、その言明が正しいなら節の中を処理する。
if 自体は関数でもプロシージャでもないからね。
432 :
431 :2013/08/17(土) 22:58:56.55
>>431 あ、あくまで命令形言語(手続き型言語)でのイメージの話ね。
関数型だと(共通点もあるが)また別のイメージがあるから。
>>431 共感はできないな。たぶん「取り出す」なんてイメージが無いから。
↓こんなの見ても嫌なの?嫌だとすれば変数名どうすんの?
bool x_is_enabled = x.isEnabled();
・・・
createData (・・・, x_is_enabled, ・・・)
>>433 bool x_is_enabled = x.isEnabled();
createData (・・・, x_is_enabled, ・・・)
これは、個人的には大変気持ちが悪いから、こう変える。
bool availability = x.getAvailability();
createData (・・・, availability, ・・・)
主語が不明になったうえに意味が変わってるじゃねーかやめろ。
>>435 なんで?
>>433 の例は全部変えなきゃ修復不可能なくらい個人的には気持ちが悪いんだよ。
この例の = って代入でしょ。
右辺から左辺へ情報が流れるわけじゃん。
パイプラインのパイプだよ。
右辺の流れが止まっている「x.isEnabled」から、
それを同じく流れが止まっている 「x_is_enabled」 にパイプを繋げても、
情報が流れている感じがしない。
この場合の左辺は本来は、get*** を使って、関数から情報を取り出して、
取り出した情報を = のパイプで左辺に流すと気持ちいい。
左辺の変数は、その情報が「何か」を表す名詞がいい。
x_is_enabled なんて文で受け取るなどもってのほか。
ただ getEnabled は、プログラマの間では問題なく通じるだろうが、
個人的にはあまり気持ちよくない。
なので、比較的近い意味の availability に変えた。
それに、getEnabled と availability って、
関数からどのような情報が出力されるかという事をプログラムの読み手が想像する上では、
意味はそれほど大きく離れていないからね。
437 :
436 :2013/08/17(土) 23:57:58.71
>>436 読みなおしたのに、紛らわしい誤字が混じってた。
> この場合の左辺は本来は、get*** を使って、関数から情報を取り出して、
> ・・・
訂正。
この場合の右辺は本来は、get*** を使って、関数から情報を取り出して、
取り出した情報を = のパイプで左辺に流すと気持ちいい。
左辺の変数は、その情報が「何か」を表す名詞がいい。
x_is_enabled なんて文で受け取るなどもってのほか。
438 :
436 :2013/08/18(日) 00:01:56.95
>>436 あわわ、これも訂正。
脳がうまく働いていないから、もう寝るわ。
> ・・・
> なので、比較的近い意味の availability に変えた。
ただ getEnabled は、プログラマの間では問題なく通じるだろうが、
個人的にはあまり気持ちよくない。
getAvailability に変えた。
> それに、getEnabled と availability って、
> ・・・
それに、getEnabled と getAvailability って、
関数からどのような情報が出力されるかという事をプログラムの読み手が想像する上では、
意味はそれほど大きく離れていないからね。
頭が固い人が多いね。
ゲッター/セッターのget/setは、ハンガリアン記法やインターフェイスの名前をIで始めるのと同類の
接頭辞の一種と考えるべき。
理由は
>>395 その他に書いたように、その方が命名が低コストで可能、あるいは
そもそもそうでなければ命名が困難な場合が多いから。
ハンガリアンと違ってget/setの2つしかないから、可読性が悪いとか違和感を感じるとかいう
批判は当たらない。(この程度は単純に慣れの問題)
百歩譲ってその批判を認めるとしても、(get | set) + [オブジェクトの属性の名前]で機械的に
名前を付けられるメリットの方がデメリットより大きい。
get/setがいらない 本当はプロパティでいい
>>439 > ハンガリアンと違ってget/setの2つしかないから、可読性が悪いとか違和感を感じるとかいう
> 批判は当たらない。(この程度は単純に慣れの問題)
違和感を感じるってのは批判してるのではないと思うが。
見た人がどう感じたかを素直に語ってるだけでしょ?
それでは駄目だ、こうしなさい、と言ってる訳じゃないじゃん。
なんでそれが批判になるの?
ここは君の感想を言う場ではありません
じゃあ、何言えばいいんだ? ここで語ってるやつらって、ほとんど全てと言っていいくらい自分の感想か、 一人よがりの理論じゃね。 俺はこう思う、いやこれはわかりにくいと思う、とかのオンパレードじゃん。
単なる感想文と根拠を付けて発言してるのじゃ全然意味違うだろガキ。
>>444 変数名を探しているという質問に対して、
その変数名をいくつか列挙するだけのヤツは根拠を示していないから単なる感想だ
OK?
>>424 の「その名前が使われる箇所の可読性を考える」
>>436 の「代入は右辺から左辺へ情報が流れるから、それに合わせる」
これらは根拠があるから単なる感想ではない
OK?
全然違うw
同じような状況でこういう名前を見た、マイクロソフトではこうやってる、 とか何でもいいからコメントあると、スレを眺めてる側からすると嬉しいなあ
MFCは論外としてもJDKも中途半端で一貫性がないね。 C#というか.NETにはプロパティのシステムがあるからそもそもこういう問題は発生しない。
get wild and tough
有効な設定か無効な設定か->available それを編集可能かどうか->enable
え?
分かりづらかったか。 有効期間がある複数の設定があったとき、ある設定が「有効かどうか」はavailableという変数を使う。 で、各項目を変更可能かどうかを設定するときは、enableという変数を使う。 有効な設定だけど編集不可な場合は、available but disable。 逆に、有効ではない設定だけど編集可能な場合もある。 まあ、何が言いたいかというと、availableとenableをごっちゃにするなってこと。
>>452 >まあ、何が言いたいかというと、availableとenableをごっちゃにするなってこと。
ごっちゃにするな、というのには同意なんだけど、
そもそもごっちゃになるものかな?
enableは「...させる」とか「...を可能にする」といった動詞で、
「編集可能にする」(というメソッド)なら enable_to_edit になる
で、もし一般的な「編集可能かどうか」という述語なら、is_editable であり、
(動詞の enableを使って) is_enabled_to_edit 等とするには違和感がある
(受動態の「....をさせられる」とか「可能にされる」という意味に読めるから....)
またアクセス権などで「編集を許可するかどうか」なら、
allow を使って does_allow_to_edit と書く(does_ は省略してもいい)
available はおおむね同意だけど、一般的な編集不可は uneditable で、
アクセス権上の明示的な禁止であれば does_deny_to_edit と書く(does_は省略可)
実際にはここまで英単語の意味にこだわるケースはほとんど経験が無いけど、
もし徹底的にこだわるならば、という意味で書いてみた
>>453 >>438 > ただ getEnabled は、プログラマの間では問題なく通じるだろうが、
> 個人的にはあまり気持ちよくない。
> getAvailability に変えた。
なんか、こういう人が一人だか複数人だかわからないけど、このスレに居るので。
いやそこは理解できるだろ。 get enabledってそのまま英語にしたら"有効にする"って意味だから。
getは使役動詞じゃありませんよ。 何言ってんの
get enabled を文字通り解釈すれば「有効になる」だ プログラマ的には「有効かどうかを取得する」だがな
やけにとんちんかんなレスが目につくと思ったら やっぱプログラマじゃない奴がいるのか 何のためにいるんだろう
プログラマになるため
プログラマじゃないってことにしたいんですね。
461 :
デフォルトの名無しさん :2013/08/19(月) 21:34:39.25
静的に生成してるならわかるが、 自分で付けるならisEnabledだろ。
静的に生成してるって何、どういうこと? 自分で付ける=動的に生成?
463 :
デフォルトの名無しさん :2013/08/19(月) 23:02:19.86
うむ。間違ったことを言った。 静的解析などを使って生成してるなら、だ。
すまん、静的解析などを使って生成というのがいまひとつピンとこないんだが たとえば何を静的解析すれば、変数や関数の名前が生成されるんだ?
465 :
デフォルトの名無しさん :2013/08/20(火) 00:07:00.61
アノテーションを検索して生成したり、 POJOのデータクラスから操作クラスを起こしたり。 スキャフォールディングなんかは静的解析とは違うが、 自動生成だから似たようなもんだ。
自動生成と静的解析は全く関係ないと思う っていうか、enableとavailabilityの違いはこだわるのに、 こういうところはどうでもいいの?
.NET の Enabled プロパティの内部表現は get_Enabled
IMSVidCtl::get_Enabled これ? ほんまや
>>466 全く関係なくはないだろう。
必ず自動生成する情報元があるんだから。
そうかカプセル化とは、変数を直接触らせない処理なんだ、 変数に対してアクセッサをつけるのが大事なんだ、 それがカプセル化なんだ、みたいな誤解。 いや、誤解じゃなくてそれで十分だしメリットはそこにこそあるという二番目の誤解。 一方、やりなれてる人はアクセッサありきのインタフェースなどには縛られない。
>>469 情報元を必ずしも「静的解析」しなくても変数名や関数名などは自動生成できる。
例えばIDEでよくあるウィザード、あれはユーザーから
チェックボックスなどを使って入力してくれた情報をもとに
ある程度まとまったコード片(スケルトンなど)を自動生成するが、
あれはIDEが入力情報を「静的解析」していると言えるのだろうか。
何かを静的解析することと、何かを自動生成することは、別の事柄だ。
静的解析の定義についてはよそでやってください
で?何なんだ?
「静的解析」の話題には二度とレスしないから、
同じくスレチな
>>470 にもガツンと正論を言ってやってくれよ
俺だけ言われるのは、なんか腑に落ちん
セルフサービスでいいよ 自分で言えば
言語はC#です テキストボックスを拡張して、Webサイトに増えてきた クリックすると消えて書き込めるようになる灰色の文字を表示出来るよう実装をしています が、灰色の文字用の一律の変数名(○○Text,○○Color)が思い付きません
英語サイト見て来たけど hint textとかgrey textなどと言ってた
>>478 HintText………なる歩道
ありがとうございます!
いやいやあれは普通water markって言うんですよw
>>480 俺が無知なだけだとは思うが、
全く別のものを想像してる可能性がある
>>480 頓珍漢だな……
HintTextで検索して普通にお題のような画像出てくるんだからそれは無いと思うぞ
そいつの言い方はアレだけどWatermarkで合ってるよ
>>482 watermarkは、water + markじゃなくて一語な。透かしって意味。
"html input watermark"でググると多数ヒットする。
入力し始めると消えるからwatermarkよりhint textの方が好きだな watermarkだとbackground picture/text的なものを連想してしまうんで
電子透かしとかそっち系だよな
watermarkは電子透かしの意味でも使うけど テキストボックスなんかに表示するやつの事でも間違いではない あとhint textでもいいけどテキストボックスの外に表示されてるヒントに使う事もある
「hint text」を表示する方法の一つがwatermark
テキストボックスの外に出す、ポップアップするヒントは Windowsだとツールチップって言うね
となると、HintText.style(watermark) みたいな感じがスマート?
492 :
デフォルトの名無しさん :2013/08/24(土) 11:08:32.56
あ?
494 :
デフォルトの名無しさん :2013/08/24(土) 17:15:32.56
>>494 本当にそう言うのかは知らないけど、
俺にはあれが place を hold しているようには見えない
placeholderだと桁数とか表示エリアを確保・明示するためって感じ
ああ、placeholderでもいいね
placeholderは場所取りだよ。 花見の時のブルーシートを敷いて若い社員が確保に行くだろ。 そのブルーシートの役割のこと
499 :
デフォルトの名無しさん :2013/08/24(土) 18:21:33.11
html5 では placeholder だね。
在庫管理のケース数、バラ数、総バラって英語でなんて言うんですか?
number of cases number of pieces total number of pieces
bool型の関数・変数で 「is + 形容詞」「can + 動詞」「has + 過去分詞」 「三単現(三人称単数現在)動詞」「三単現動詞 + 名詞」 って感じのをよく見かけるけど、 特定の機能を使うか使わないかを管理するbool型メンバ変数の名前を付ける場合 どういう規則で名前付ければいいんだろう?
use xxx
use xxx is xxx enabled
「xx機能を使う」って言葉は便利なので、色んな状況で使えてしまう。 例えば、描画機能を使う、通信機能を使う、確認ダイアログを使う、みたいな感じね。 なので、別の言い方に出来ないかをまず考える。 それがダメなら、あるいは機能のON/OFFを強く主張したいなら、 >507の言うように isEnabled にするかなあ。
>>506-508 Enabledは頭になかった。サンクス
でもやっぱり違う名前考えた方が良いのか。
確かにuseやenableばかりになったらカッコ悪いもんな…
俺ならwithXxx(true), withXxx(false)かな
Mapから別のMapへ、あるいはオブジェクトから別のオブジェクトに、 必要な値を「移し替える」メソッドの名前は何にするべきでしょうか? A.method(B) ←こんなの
>>512 「移し替える」の定義を詳しく説明してもらえないでしょうか。
int a = 2;
int b = a;
というような「コピー」とは何が違うのか、など。
こんなのって言われてもw
つまりコピーでいいってことだな。
>>512 「移し変える」ということはコピー元を消去するという意味を含むと考えていいのかな。
とりあえず「移譲」に相当する語句をはめてみればいいのではないかと。
transferとかhandoverとか。
ぶっちゃけmoveでもいい気がするが。
moveに1票。元が残るならcopyでもいいかな
移し替えると言うより、積み替えと言いますか、コピーですね。あるオブジェクトが持っている値のいくつかを 別のオブジェクトに持たせたいので。transferでしょうか。 何となく、そういった機会は多いと思うのですが、setやgetのような定番の規約はないのでしょうか? eatだと変でしょうか?
通信じゃないんだからtransferはないw なぜ素直にcopyで駄目なのか意味が分からない
>>518 元のオブジェクトに値が残るならCopyでいいと思うわ
残らずに移行するなら
B = A.Release()
とか?
一意的なオブジェクトならか
>>518 積み替えも移し変えも同じ。
値のいくつかってことは全部ではないという意味か。
どういう理由でその作業が必要なのかを名前にしたらいいんじゃね。
例えばinitとかsetupとか。
ふむ。transferは確かに紛らわしいですね。同じ理由でloadもダメでしょう。 copyといっても値の一部だけを貰うだけですし、copyというと全体を複製するイメージがありませんか? メソッドなので、BをAにコピーするでなく、Aをどっかにコピーするかのように見える。
>>522 コピー&ペーストとカット&ペーストは別物だから、どっちかはっきりしろ。
コピーですよ。
値のいくつか、つまり値のグループなわけだ。 そのグループ名のコピーでいいだろ。 例えば色ならcopyColors
>>522 余計な心配。
何をコピーするかは引数を見れば分かるんだから、名前に凝る必用は普通はないように思うけど
>>525 むしろA.setColors(B)だろ
>>525 だよな
任意で値を渡すのであれば
それぞれの値に対してCopyXX、MoveXXって用意すればいいだけだ
loadだな
moveだな
「継承させる」メソッド名に適当な英単語は何ですか? 継承する、ならすぐ分かるのですが、させるとだと和英辞典でも出てきません
perlならbless
いつもお世話になっております。 import/export あるいは upload/download をまとめた呼び方はないでしょうか。 ファイルを upload したり download したりする web ページがあって、そのURLを何とすべきか迷って相談しています。
そんなサービスすでに世間にゴマンとあるのに、何で新たに俺様な呼称を 考える必要があるの?
ファイル鯖? Uploader、Shared Storageとかのこと? 好きな名前つけたらええがな よし、名付け親になってやろう DropBoxなんてどうだ
exchange
share
>>538 >exchange
そうですね、これが無難かな。
ありがとうございます
>>537 >好きな名前つけたらええがな
このスレでそんなこと言われても・・・
設定値管理クラスの内容を設定用GUIに反映させるメソッドの名前は何と命名すればいいですか 逆にGUIの値をオブジェクトに反映させるメソッドの名前もお願いします
どっちもapply〜 かな。applyValuesとか。
load, save
こういう場合、直で「設定値用クラス←→GUIパーツ」とするより、 GUIパーツ側にはあくまで汎用的なsetWidthやらなんやらを用意しておいて、 設定値クラス側も単純なデータモデルとしておいて、 間に入るヘルパクラスがHelper.save(component src, savedata dst) Helper.load(savedata src, component dst) みたいなことにしておいたほうが、ある種楽だよな? な? 互いに相手を知らないのを基本に、ヘルパが唯一、設定値用クラスとGUIパーツを知っている状態。
そりゃそうだけど、要はヘルパクラスが設定値クラスでしょ。 設定値クラスが構造体なりモデルオブジェクトを持ってるのよ。 って俺は読んだけどw
548 :
デフォルトの名無しさん :2013/09/24(火) 23:44:12.01
Mediatorパターンですか
えっw
イベント書いてるんだけど 原形と過去形が同じ動詞ってどうすればいい? Open() → Opened Set() → Set //?
pre/postをつける
>>550 普通はSetの前に名詞が付くはずだからそれで何も問題がないのでは
didSet didOpen
onOpened onSet
Read Reset Cut
>>552 そんなものばかりじゃない
>>554 .NetだとOnOpenedもOpenedもあるのが普通
BeforeOpen/AfterOpen
>>556 いやそんなものばかりだから。
アホの子じゃあるまいし、Setみたいな汎用的な動詞、何がSetか分からない。
とりあえず、イベントドリヴン的な使い方をするときだけが問題なのかな。 変数名とか、返り値が重要な関数(って言うんだろうか?)では、特に問題にならない?
>>550 英語のできる俺が教えてやるreadAlreadyとかalreadyReadだ。
でもね文系じゃないんだしreadedなんて造語を作ってもいいんだよ。
settedなんて造語してかまわないと思う。
setされても変わらなかったらイベント発生しないとかで、wasChangedじゃないの。
settingCompleted
ゲームキャラクラスのメソッドで、引数の値だけHPを増減させて上限下限処理等するメソッドなんですが add_hp(val)みたいな感じだけどマイナスを入れれば減るからaddじゃなくて、 増減両方対応した良い感じの動詞ないでしょうか? 今の候補はchangeなんですが
マイナス値を足したら減るのは普通だから問題ないと思うが
add_hpにマイナスを入れて減らすのは 意図してない使い方をしているような感じがしてなんか変な気がするのは 自分だけなんですかね マイナスが切り捨てられても文句言えなそうというか
>>566 どんなんでも、引数の取りうる範囲とか説明が必要。
余談だけど、昔HP(Hit Point)が最初ゼロで、被弾してくと増えてって100になるとやられるってシューティングゲームがあった。被弾率と直訳すると確かに正しい。こっちの方がしっくりくる。 誰かがHealth Pointを知らなくて適当に言って広まっちゃったのかなぁ。
俺ルールでは引数にマイナス可能はplus_hpとする
こういうときだけはC#のプロパティが優れて見えるな。 giko.hp += x
ヴォルガード2か
572 :
デフォルトの名無しさん :2013/09/29(日) 14:04:11.12
>>568 昔の雑誌だとRPGのHit Pointsは「耐久値」と訳されることが結構あった。
「どれだけのダメージに耐えられるかの上限」という感じだな。
573 :
デフォルトの名無しさん :2013/09/29(日) 14:05:54.45
あ、キャラクターシートにも Hits Taken とあって、そこに蓄積していく形だったよ。
>>568 >>572 語源的には、「攻撃(ヒット)」という言葉が先にあって、それに耐えられる回数(ポイント)かな。
んー、ちょっと説明がおかしいな。言い直す。 何単位分の攻撃が当たったか(矢やミサイルなら何発当たったか等) = ヒットポイント(攻撃力) ……というタームがあって、 その何hp分の攻撃に耐えられるか?という値が、転じてHPと呼ばれるようになった、だな
こういう話と、プログラムの設計にまで踏み込んだ話。 同じ雑談でもどっちがより有益でスレの趣旨に沿うものか、よく考えて欲しいもんだね。 前にも書いたが、 > 命名規則や設計の善し悪しについて議論するのは基本的に禁止。 こんなルール(そもそも誰の合意にも基づいてないが)こそ荒れる原因。 ご都合主義の馬鹿に、てめえの下らない突っ込みを正当化する言い訳を与える効果しかない。
578 :
デフォルトの名無しさん :2013/09/29(日) 16:08:49.71
アプリやシステムでなく、プログラムの設計という斬新な手法。
そういう場が欲しけりゃ自分でスレ立てれば ここはそういう場じゃないんで ご愁傷様
>>580 そういうのをご都合主義って言うんだけどね。
頭が悪いって哀れだな。
>>576 導入が悪いw
その言い方じゃ反感しか買わないだろう。
設計にまで踏み込んだ話はしてはいけないといいつつ、
わりと普通にされているのは、よくスレを観察していると分かる。
結局、なにをどう禁止しようと、食いつけるネタであれば誰かが食いつく。
例えば window.Hide(true) というメソッドがあったときに、 引数の真偽を入れ替えて、 window.Show(true) にした方がいいよ! ……みたいな話はどうしても必要だしな
まちがい、window.Show(false)
window.SetVisible(true)
>>585 そういうしょうもない間違いをしないために、
window.Show()
window.Hide()
の方が優れてるね!
その場合 window.isShown() window.isHidden() も両方用意するんですか?
>>588 bool window.visible()
かな。
Javaでも.Netでもいいから何かのクラスライブラリ一通り使い慣れろよ 命名のセンスが身に付くぞ
@Deprecated public void show() 推奨されていません。 JDK Version 1.1 以降は、setVisible(boolean) に置き換えられました。 @Deprecated public void show(boolean b) 推奨されていません。 JDK Version 1.1 以降は、setVisible(boolean) に置き換えられました。 @Deprecated public void hide() 推奨されていません。 JDK Version 1.1 以降は、setVisible(boolean) に置き換えられました。
>>591 馬鹿っぽいな。
もちろん二重の意味で。
恥を忍んで聞くんだ、教えてくれないか。 その二重の意味とやらを…。
あるリストのアイテムが並び順を持っていて、その並び順の値を振りなおすメソッド の名前でいいのないですかね? 並び順はOrderNoってプロパティです。 で、UpdateOrderNo()ってメソッドはあってこれは、値の更新じゃなくてデータベースの 値を更新します。 (DBのテーブルを落とし込んだクラスで、UpdateXxxxx、DeleteXxxxx、LoadXxxxとかは DBの更新、削除、保存などになるため、値そのものの更新には使えません) "振り直し"の英語でカッチョいいのがあればそれが一番いいんですが。 お願いします。
reorder
Reなんて要らない。 並び替えと再並び替えにプログラム上の区別なんていらないでしょ。 OrderかOrderByで。 ついでにNoじゃなくてNumberってちゃんと略さずに書いて欲しい
Numに一票
その辺はどうでもいい 使う単語さえ決まればいいよ
UpdateListOrder
Renumberとかでもいいんでない?
メソッドで絶えず振り直さなければならないのなら
>>596 普段は自動でやっているけど、再度実行するならRe-付きとか
そういうのはprivateで、アクセスポイントはrefresh()とかでいいんじゃないの。他の更新処理も追加されるかもだし、呼ぶ側は何か更新した後に整合性を取るために呼ぶとかじゃ。 更新のコストが小さければ、setHogeとかの最後にクラス内部で毎回呼んであげれば、呼ぶ側の品質に影響されなくて気楽。
アクセスポイントって?
603 :
デフォルトの名無しさん :2013/10/03(木) 14:10:47.74
無線ルータだろ
>>602 外部から何てメソッドや関数を呼ぶかってこと。誤解を恐れずに言うならインタフェース。
レイヤモデルで他の層との接点もこう言ったりする。
ローカルな呼び方かも知れんけど。
エントリポイントみたいなもの?
俺はエントリポイントの言い間違いかと思ったけど
楽天ポイントとかの亜種じゃないかな
いずれにせよこのスレの住人として他人に通じない言葉使う神経がわからん
アクセスとポイントという単語が理解できない奴にわかるように話さなければいけないのか。難しいな。
この手の用語はもとの単語の意味とずれてること多いから、単語の意味あんま関係ない。 取り敢えずお前はなに書いても恥かくだけだろうから、当分 ROM ってなよ。
社内用語って実際多いよな。 IT業界以外でもそうなんだと思うけどさ。
>>610 名前を考えるスレで何を言ってるんだお前は。
>>611 会社独自とかも結構あるしな。
じじいが若い奴になんでこんなことがわからないんだよ...
(俺: わかるわけねーだろ、聞いたことないだから。ちゃんと説明してやれよ...)
一般的でない用語にすがりつくのは、 あるしゅ、自分の立場を守るためのの行為。
>>614 先輩・後輩の二人っきりしか社員がいないならともかく、普通は教えてくれる人が沢山いるので、ある先輩にとっては、そいつがある用語を誰かに聞いて知っているかどうかは不明。
なので、先輩がまず説明するのではなく、後輩が知らない用語を質問するというのが正しいプロトコル。
>>605 エントリポイントって言うと、mainとか全体の最初ってイメージある。構造化なら局所的に考えればそうかもね。ただオブジェクト指向とかで何度もやり取りするんだと、何か違うイメージ。
エントリーポイントはみんなわかるんじゃないのかな? 俺も良くわからないなりに、mainなんだろなと思ってる。 アクセスポイントと言われると… _. -─‐- / ⌒ \ / ⌒ (● ) \ ┏┓ / ( ● ) 、_) ヽ ┏┛ | (__ノ / | ・ ヽ  ̄ _ノ >  ̄ \
>>616 その用語がその会社でどう使われてるかわからんのに質問しろとか、アホがプロトコル設計するとぐだぐだになるいい見本だな。
募集要項にエスパー優遇とか書いておいた方がいいんじゃね? (w
オレオレ用語使っただけで先輩面すんなw
辞書まで引いて一生懸命適切な名前考えてつけてるのに 自分でコード見返して統一感のなさに絶望する毎日
なんだ俺か
いつか反面教師として報われる日がくるさ
>>621 一所懸命に考えるから、新しい統一感のないものを考えついちゃう気もする。
だからといって、考えなしでもうまく行かないんだけど。
特定のインターフェースを実装してるという意味での「このクラスはあのインターフェースを持つ」 インターフェースを実装してるわけではないが必要なメソッドやプロパティを持っているという意味で「このクラスはあのインターフェースを持つ」 これらを明確にわかるように区別できる言葉を知りたいのだけど良い日本語ありますか? あとプログラム上でそれを見分ける関数の名前も 自分の少ない知識だとどっちもhasXxxInterface、日本語でXxxインターフェースを持つになって困ってます
まんまImplementsXxxInterface
うそです。しっかり読んでなかったw
インターフェースが無いって事は、プライベートで実装してるってことか? どういう使い分けなのかな。
擬似コードで書くとこんな感じです interface Xxx { void method(); property string Prop; } class Yyy : Xxx { void meyhod() {} property string Prop; } class Zzz { public void meyhod() {} public property string Prop; } どちらも広義には同じインターフェースを持ってますが正確な表現ではないです
どちらも「規約に適合」で区別出来ないw
hasXxxInterface hasXxxCompatibleInterface
>>631 のCompatibleを拝借して
IsCompatibleWithXXX
633 :
710 :2013/10/12(土) 22:07:21.38
>>625 * インターフェースの実装を持つ
* インターフェースのみを持つ
・「継承によって」インターフェースが定義されている ・「継承によらず」インターフェースが定義されている
日本語: クラスコメントだったら インターフェース持ってる:xxインターフェースを実装する インターフェース持ってない: xxインターフェースと同じメソッドをプライベートで持つ or 説明なし プライベート実装の説明なんて書かないかなあ コード: XXXが名詞だったら インターフェース持ってる:HogehogeXxx インターフェース持ってない:Hogehoge プライベート実装にインターフェースと同じ名前のメソッドがあるだけなら 明らかに意味合いが違う、それは広義でもインターフェース持ってるとは言わない だからクラス名は、そのクラスがXxxインターフェースを持ってると誤解されないように、 インターフェース名は一切くっつけないのが正解な気がする。 質問者のリクエストは満たしてないかもしれんが 擬似コード見る限りだと名前付けの方針自体がおかしい気がするんだ。すまん
言語の仕様がわからんけど、どちらもpublicな同名メソッドとプロパティを持ってると。 違うのはクラスの役割だよね。 当然クラス名は違うものになるよね。 何を区別したいの?
>>625 結局何が聞きたいのかよく分からない。
っていうか命名と関係ないような気が。
まさか知らないと思わないけど、
>インターフェースを実装してるわけではないが必要なメソッドやプロパティを持っている
これってダックタイピングのことだよね?
あと、オブジェクトがある型と互換性があるかどうかを検査する機能は
ライブラリじゃなくて言語の機能じゃないのかなと
ごめん関数名かよく読んでなかた 関数なんかつくらんでいい、たいていの言語は演算子がある Java: a instanceof Xxx C#:: a is Xxx VB: a TypeOf Xxx
なるほど、プログラミング用語としてのインタフェースと、一般的な単語としてのインタフェースの違いって話なのか
>>637 >あと、オブジェクトがある型と互換性があるかどうかを検査する機能は
>ライブラリじゃなくて言語の機能じゃないのかなと
C++/Javaに代表される、現在メジャーな静的型付け言語における
「静的なオブジェクト指向言語」であれば正にその通りなんだけど、
他のケースでは事情が異なる
・Smalltalk/Ruby/JavaScript: 動的型付け言語における「動的なオブジェクト指向」
=> 言語ではなくライブラリの機能であり、
インターフェイス仕様による検査は存在しない
・Objective-C: 静的型付け言語における「動的なオブジェクト指向」
=> 言語およびライブラリの機能であり、
インターフェイス仕様による検査は任意
つまり基本は無検査だけど、仕様を明示的に宣言すれば静的に型検査される
そして、Objective-Cにはインターフェイスという概念に加えて「プロトコル」がある
これがデータ型としては不一致だけどインターフェイスの要求には従うことを意味し、
オブジェクト間は委譲(delegate)によって動的に結合される
前置きが長くなったけど、Objective-C的発想では:
>>625 ・特定のインターフェースを実装してる:hasXxxInterface
・必要なメソッドやプロパティを持っている:hasXxxProtocol
>>640 プロトコルはしっくり来たが
ネットワークのプロトコルと混同しそう
似た概念だし
「長期間キャッシュされるもの」を表す、簡潔な名前を教えてください。 現在の案: ・eternal ・permanent ・longterm できれば中学生ぐらいでも知ってそうな、もっと簡単な英語がいいんですが、思いつきません。
longlived old
secandary cache level 2 cache
646 :
710 :2013/10/18(金) 14:18:36.33
>>643 >・longterm
は、よくわからんけど、
>・eternal
>・permanent
辺りは、キャッシュの意図が伝わらないと思う。
素直に longCached とかでよくね?
もし変数名に日本語が許されたとしても、 「長期間キャッシュされるもの」これ意味が不明瞭すぎないか? このソースを読む人は、その変数のキャッシュされる期間とやらに気をつけなきゃいけないの?
preservedCache ⇔ temporalyCache
temporaryだったw
>>646 long cachedって英語的におかしくないか?
英語的におかしいと、第三者が見たときに、何がなにやらわからないぞ。
heavy cache hard cache super cache great cache
長時間キャッシュされる = 変更が少ない、安定しているキャッシュ と捉えて、stableを付けてみるのはどうか
LRUとか、そんな話なのかも
「キャッシュが変更される」というのにちょっと違和感がある 変更されるんじゃなくて、古いのは破棄されて新しいのがあらためてキャッシュされるんじゃ?
> もし変数名に日本語が許されたとしても、 > 「長期間キャッシュされるもの」これ意味が不明瞭すぎないか? え?とても明確だと思うけど。 > このソースを読む人は、その変数のキャッシュされる期間とやらに気をつけなきゃいけないの? 別に変数はキャッシュされないんだけど。 仮にキャッシュされるとしても、「長期間キャッシュされる」とだけ分かっていればよく、キャッシュされる具体的な期間は気にする必要はないです。
657 :
710 :2013/10/18(金) 17:07:58.00
>>647 誰かが書いてたけど L1 に対する L2 みたいな意味でしょ。
> このソースを読む人は、その変数のキャッシュされる期間とやらに気をつけなきゃいけないの?
理由がイミフ
あと、勘違いしてそうな人多いが、キャッシュじゃなくて、キャッシュに格納されるものの方だからね。
アイデア出してくれた人、ありがとうございます。 > longlived いいかも。 > secandary cache secondary は関係ない。 > longCached これでもいいですね。英語的に正しいかどうかは知らない。 > preservedCache 保存食か。いいですね。 > stable うーん、stable はちょっと違うんだよね。あくまで「長期間キャッシュされる」ことを表したい。 なかなかいいのはないですね。
quietCache
この徒労感。
macrobiotic (長寿の) die hard (なかなか死なない)
「いいかも」「いいですね」「いいですね」と 3 つあるのに、いいのはないですねとはどういうこと
長時間キャッシュが存在するってことは、短時間キャッシュ的な何かが存在するということだと思うけど、 どういう目的で使い分けるんだろう。
短期長期ってのが主観的なんだよな 何フレーム?何ナノ秒?何ミリ秒? 何秒何分何時間何日何年キャシュするのかな?
キャッシュそのものの名前ではないのか? データにtime_to_liveみたいなフィールドがあるのかな。
ぱっと思いついたのは long + life, expiration, term, period
668 :
デフォルトの名無しさん :2013/10/18(金) 18:08:36.36
durable cacheや
キャッシュかどうかを意識させずに作るほうが使いやすい
EternalBlizzardCache
tough guy cache
あえて「長時間」を強調しなきゃならない場面というのが思いつかない。 というより、生成や取得にコストや時間がかかるデータを後で使いまわすことが キャッシュと呼ばれるものの存在理由のはずだから、あえて強調する必用があるとすれば 短時間で破棄するキャッシュの方じゃないのか。 まあそんなものがあるのか知らんけど
ゲーム画面上の、得点とか体力バーとかあの部分ってどういう名前で呼ぶ? 戦闘機に倣うなら、視界に被せるHUDだと言えそう。 テレビの世界じゃ映像に被せるのはスーパーインポーズっていうんだっけ? スカッと納得できる名前たのまい。
indicator
からだかばーと読んでて何の事かわからんかった たいりょくばーね
HUD (head-up display)
Status Indicators
>>673 そもそも抽象化が間違ってる気が。
そういう部分が存在すると考えるより、HUDで言えばハーフミラーに相当するスクリーンがあって
(画像編集ソフトのレイヤーみたいなものだと考えてもいいけど)、その上に
いろんな表示器が乗ってると考えた方が分かりやすいと思うけど。
>>674 即レスとん!
可能な限りプリミティブで強い名前をつけてやりたいけど、
インジケータは名前が強すぎる>< さすがにもう他でちょこちょこ使っちゃってる。
インジケータと聞いてその部分だけを想像するのは今となっては難しい。
>>676 これまた絶妙やね…。うまいこと、その、それらを総称したい気持ちを汲んでくれてる。
javaのswingでのContentPane、GlassPane、LayeredPaneっていう階層分けを思い出した。
ゲーム、
>>673 、と二つの世界で考えずに、俺も初期にレイヤーという考え方導入したら色々捗ったのかも…。
>>677 HUDのいいのは三文字ってことですね。
ごちゃごちゃ言わんでも三文字で全部分かる。
>>681 つまり?
そのレイヤーの名前でよければ
>>676 と同じで。
あえて追加すればNotificationLayerとかInformationLayerとかGadgetとか。
Status Surface Status Window HuDが一般的だな
>>682 Gadgetこれすごくいいんじゃない?(直感)
少なくとも他にはどこにも使ってないし。
>>683 サーフェスと言いたいのは山々だけど、
d3dのサーフェスが強すぎて敬遠。
HUDはやっぱ強いね。
685 :
673 :2013/10/19(土) 00:21:20.99
みなさんどうもありがとうございました。 レイヤの考えを導入していけるのかどうかを含め、 ちょっと考え直して見たいと思います。
最近はゲーム系のニュースや勉強会でもHUDって言葉が結構出てくるな
ゲームでモンスターの初期データのテーブルを用意しておいて 戦闘時にそのテーブルからデータをコピーして使おうと思ってるんだけど 初期データと今戦ってるデータを呼び分けられる良い名前ない? 出来れば「初期データ」の部分を強調できるような名前がいい
master/xxxxxxx
毎回思うけど変数名で迷う人ってもともと日本語で表現するのもままならない人なんじゃないか? Originalとかmasterとか出てきそうなものだが…
>>687 そもそも生のデータ丸出しなのがおかしい。
コンストラクタでも初期化関数でもいいけど、そんなデータはメソッドの中にだけ
存在すれば十分だから名前なんかどうでもいい。
691 :
710 :2013/10/19(土) 20:43:54.42
692 :
710 :2013/10/19(土) 20:45:01.07
>>690 > 命名規則や設計の善し悪しについて議論するのは基本的に禁止。
693 :
687 :2013/10/19(土) 21:02:41.39
>>688 にしようと思います
他の方もありがとうございました
Java 研究室内コーディング規約 プロパティ名は日本語
分かってるやつからすれば、英語にこだわるのはバカのやることだからな
英語がデフォなのにいちいち日本語に訳するのは面倒だな
業界による 英訳でニュアンス情報が落ちる事があるから日本語は日本語のまま書くべき 常識だろ
クラス名・変数名で「英訳でニュアンス情報が落ちる事があるから日本語で書く」 なんてことが通るのはどこの業界の常識?
プロパティだけ…つまり、こうだね。 String サンプル; String getSample(){return サンプル;} 日本語でも捉え方によるので、コメントかプロジェクト内辞書は必須では。逆に名前だけで勝手に解釈されると困る。
「コーディング」とか「プロパティ」とかを日本語として認めてしまっていいなら、 日本語訳は、カタカナ英語でいいのではないだろうか
日本語を禁止する明らかなメリットがない 言語もコンパイラも許可してる 開発環境のサポートで文字コードは間違えない 英語より遥かに早くコードからビジネスロジックの意味を認識できる 英語訳で生じるニュアンス情報の欠落がない 翻訳困難な日本語をそのまま使える 仕様書やマニュアルそのままの単語でコーディングできる 後進国の外国人コーダをプロジェクトから排除できる 文字数が揃いやすいから気持ちいい 英語より短く記述できる
英訳というより和訳
日本語を禁止する明らかなメリットはないが、そもそも普通に英語をある程度身に付けていれば、 日本語変数のメリットとか英語クラス名がどうとか議論する必要もないことだと思う
704 :
デフォルトの名無しさん :2013/10/25(金) 11:08:42.67
日本語でいいよ puropatiとかやらかすアホはさすがにマズいが
Kuromate?
なでしこでも使ってろ
醤油と??油は別変数か。
日本語変数を使ってるとラノベのタイトルみたいな長い変数名が出てくるよね
こんの散々既出の耳タコネタだろ。 日本語変数は入力補完との相性が最悪だから使う奴は馬鹿ってことで結論が出てる。
全部ひらがなにしましょう!
Prologみたいになりそう
画像をセーブ、ロードするクラスの名前をお願いします。 このクラスは、設定によって保存先をファイルにだったりデータベースにだったり、変えることができます
stream
storage
PictureIO
resource manager
DataSrc DataDist
repository
>>713 Imageを継承したImageFileなり、ImageRowを作るか、
Imageから委譲されるDAOまたはStorageクラスを作る。
ImageLibrarian
>>713 その説明じゃ機能がよく分からないと思うんだよね。
例えば画像を出し入れするときに指定するのはファイル名なのかキーなのか
ImageStore にしました。 ありがとうございました
editerではなくeditorと書きますよね operaterではなくてoperator このorには何か意味がありますか?
普通の英単語だとerの方が多いのにこの業界ではorが多用されている気がしたからです。
また変なのが来たな…
>>729 ありがとうございます。
-orは何かを演じる者という具合でしょうか。だからoperatorは「演」算子と言うのかも。
かなり参考になりました。
あ?一言で言えば-orはラテン語由来で-erはガリア語由来ってこった。 operateの日本語訳は"算子"じゃねーだろうが
ガリアのがカッコいいからこれからはer使うわ
どこの世界にも必ず噛みついてくる変なのがいるんだよな。ここにも。
>>733 なるほど、今君がやってることがまさにそれだね。
っていういか馬鹿だろお前
うん
>>732 あーちなみにガリアってのは田舎もんってことだから。そういう意味で世間で使われる言葉に比べて
-orが多いんじゃ?っていう
>>727 の素朴な疑問はある程度正しい。
ガリアはガリア戦記のガリアだろw 要するに今のフランス辺りのことじゃないのか
場所じゃなくてガリア人の言葉に由来する、って意味。カエサルのガリア戦記ってのは未開人である ガリアを文明人であるローマが征服して文明人の端くれにしてやった、ってお話だから。
いらっしゃーい
何かの変化量を表す変数名ってどうしてますか? ゲームを作っていて、大きさ(width,height,size)、色(color)、角度(angle,rotate)など を変化させるために使いたいのです
delta これはプログラミングに限らず常識よ
>>742 一生懸命Variation,variable,variate,changeValueなんて末尾につけてました・・・
colorDelta,widthDeltaなどの方が短く、他の人が見てもわかりやすいものなのでしょうか
>>743 deltaは前につけるのが普通だと思うよ。
高校で数学赤点だった?
少なくとも高校の時点で数学に苦手意識がなかった人ならdeltaが何を意味するかは
誰でも分かると思う
>>744 colorならcolor関係だと分かるように後ろにつけた方がと思ったのですが、前なのですね
(高校で数学が一番の得意科目だったなんて言えない・・・!)
何故かデルタとかあまり使ってないというか、使ってもあまり気にしてなかっただけでした
数学とか関係ないと思うよ。 物理の方が高校レベルじゃ出てくるかも。 加速度と速度の関係を、まずは単位時間デルタTで考えるはず。
ああでも、colorならcolorXxxとかにしたい気持ちはわかる
確かに物理で少しデルタデルタしてたかもしれない…けど忘れかけてる これから変化量はdelta○○で変数名つけてみます! ありがとうございました!!
>>747 角度ならdeltaAngleとかの方がスッキリするのかな
こういうところの判断が微妙でまた悩ませてくれる
角度に関しては角速度(angular rate)でいいんじゃね。
普通に単語として存在する時もありましたね… 私みたいな人にはほぼ直訳みたいな方が伝わるんですよと言ってみる
数学的にやるなら「d」だけにするわ。dx, dy, dTheta, dWidth, dHeight, dSize, ..
引数やら一時変数で使う時はd、メンバとして使う時はdelta みたいな使い分けでやってみます 本当に助かりました
>>476 スレチだが、高校物理では微小変化量は使わない決まりだったと思う
数学では極限の項で学習するのになんで物理では応用しない?
といろんな方面から疑問視されてたはず
755 :
754 :2013/11/07(木) 07:05:41.11
日本の若者に物理を学ばれては困る勢力がいる それだけのことだ
おっしゃ、陰謀論きたw
>>754 実験しにくいし、普通の頭持ってたら数学の知識を物理に応用できるから
>>758 微積を使えば基本的な現象を素直に説明でき、式の意味も分かりやすく、
次のステップにも容易に繋げられるのに、高校物理の学習指導要領では
その場限りの公式を羅列してて、中学から大学への架け橋にはなり難い。
自由落下や放物線運動しかり、運動量と運動エネルギーの関係然り・・・
というような事が書かれた本を以前読んだ記憶がある。
「実験しにくいし、普通の頭持ってたら数学の知識を物理に応用できる」
という話は私は聞いたことがない。
ちょっとわけあって力学の本を10冊くらい読み比べたんだが、 跳びぬけて分かりやすいのがあるねえ。 それは、挿絵があったり、口調が柔らかかったりというんじゃない、 段階が細かいというのかなぁ。自然にスッと入ってくる。 それにくらべりゃ高校の物理なんてほぼ公式のぶつ切りよ。 センスあるやつはそれで多くを理解できるんだろうけど。
うるせえスレ違い死ねゴミ
>>759 > という話は私は聞いたことがない。
本とかしか信じない (=自分の頭で考えない) のか...
そう思うのはお前が馬鹿だから
764 :
759 :2013/11/07(木) 17:49:46.13
>>762 いや、そういう訳ではないが
759 本当に見聞きしたことがないから、ああ言っただけ
いつまでスレ違いの話題を続ける気?
>>760 微積なしに理解は出来ない
公式だけで問題が解けたとしても
それは問題の答えが見つけられるだけであり
物理を理解したことにはならない
俺の時代は高校物理でも普通に微分は使ってたけどね。 高校物理のレベルを下げる意味があると思えないから今だってたぶんそうでしょ。 そうでないと次元の概念も説明できないし。
委員会を見てみろよ売国奴ばかりだぜ 日本を弱らせるためにはなんでもやるよあいつら
被害妄想はネトウヨの始まり。
>>768 「学習指導要領 高校 物理 微分 積分」でググると、なんか色々出てくる
微分積分をさも大事な数学のエッセンスかのように語っちゃう風潮が嫌。 あと学問として最先端扱ってる人らはそりゃ数学を語っていいだろうが、 高校数学に毛が生えたようなもんの領域で持って数学を語る子の存在が嫌。
微積分なんてただの面積と勾配ではないか。
他の分野は知らんが、数学だと「ただの〜じゃん」って言われるものほど 基礎的で本質的で大事なもののような気がする
微積は記号や方法論がよく体系化された数学の成果みたいなもんだろ。 数学的な思考を養い、プログラムのあるべき姿を探すにはよいんだろ?
よいんだと思うよ
C#の拡張メソッドで、文字列が特定の文字から作成されていることを判定する名前って何がいい? ContainsOnly()、BuildFrom() は思いついたけど、他にもっといい案があれば 引数はこんな感じ public static bool ContainsOnly(this string target, param char[] values) public static bool ContainsOnly(this string target, Predicate<char> charDetector)
ConsistOf
>>778 意外と難しいな。
要はホワイトリストに照らしてチェックするわけだと思うけど、
ContainsOnlyでもいいと思うけど、これだと指定する文字のリストがホワイトリストではない
(リストの文字以外を含まず、かつリストの文字全てを含む場合のみ合格)仕様だと
誤解される恐れがある気がしないでもない。
というわけで
public static bool ConsistsOf(this string x, param char[] whiteList){...}
とか。
俺なら名前付けにくいようなもんは最初から作らない。 //char[] getDistinctChars(this string s) // char[]をnewするコスト平気なら //int getDistinctCharsBits(this string s) // 32ビットで十分なら long getDistinctCharsBits(this string s) // 64ビットで十分なら あとは好きなように比較してくんろ。 下の二つはaを0とかにしてフラグ立てる。整数扱いすると比較しやすいね。
782 :
781 :2013/11/09(土) 11:06:53.02
いや、どうもこれあんま良くもないなw ごめん。
if ("Ol23456789".All(char.IsDigit)) { }
だっさ
デリゲートって日本語にないの?
訳すなら委譲だけど
彼女はとてもデリゲートです。
お前らデリゲートゾーンどうしてる?
異常処理を委譲した以上
ゲームでplayerの反対は? player/cpu human/machine 一般的には何が採用されてるのかな?
player/non-player
早速ありがとう御座います! PC/NPCみたいに略してみてもいいかもしれませんね。
enemy opponent
とりあえずnon playerはないと思うわw 論理的に意味が通らない。 プログラムが操作するプレーヤーのことは80年代からCPUと呼ぶのが一般的だと思う。
characterを指すのか、それを操作するロジックを指すのか。
AI, artifact, creature auto, automation ていうか、playerの反対ってどういう意味?
atheist
COMってのもよく見る
>>793 今現在はopponentを使っています。
でも、三人以上の対戦の時使いにくいと思ってます。
>>794 CPUだと短くていいですね。NPCはネトゲではおなじみ?ですよね。
>>795 ここでは画面上のキャラクタ、およびそれに関係して表示させる名前とさせてください。
>>797 AIだけは絶対無いですねw 意味は
>>794 さんの解釈です。
>>798 無神論者ですか?一部のプレイヤーと被るおそれありですね。。
>>799 言われて見れば良く見た気がします。コンピュータ、っていう抽象化が一般的なレベルかもしれません。
CPUとなるとそれは、機械の部品の一つになるわけでちょっと専門的なレベルになっちゃてるのかも。
player character ←→ non-player character って表現は、ゲーム界隈では一般的だと思うけど、 単に non-player ってだけだとモニョる感じはあるなあ。 単にフラグとして使いたいなら、isPlayable とかどうだろうか。
802 :
801 :2013/11/19(火) 08:31:40.42
あー、自分がモニョる理由が何となく分かった。
プレイヤーはゲームトークンであるプレイヤーキャラクター(PC)を操作し、そのPCがゲーム世界に介入する。
同様に、コンピュータ(AI)がノンプレイヤーキャラクター(NPC)を操作し、NPCがゲーム世界に介入する。
つまりプレイヤーと対になるのはコンピュータやAIであり、PCと対になるのがNPCなんだよな。当たり前っちゃ当たり前だけど。
>>800 >NPCはネトゲではおなじみ
そーいやゲームによってNPCの定義の範囲って結構変わるんだよな。
RPGで、仲間に加わって戦闘にも参加するけど操作できないキャラ(DQ5のパパス等)だけを指す場合もあれば、
町の住人から自動販売機(=商人)まで指すような場合もあるという。
>>800 全てをcharacterにして、ユーザが操作てきるcharacterのみをPlayerCharacterにする。
オブジェクト指向をサポートしている言語でクラスにするなら、拡張が使える。
>>801-802 例えばスト2とかの場合、キャラクタだけで完結させてますよね。
プレイヤーか、コンピュータかという操作する側の区別表記ではなく。
場合によっちゃそれで十分かもしれません。
シリーズひとつもやったこないんで動画で見たんですが、
例えばスマブラ64だと1P, CP, 3P, CPなどというふうに、
操作する側の区別をタグのようにキャラクタの頭上に出してるようです。
同キャラ対戦ありだと操作する側の区別は必要になってきますね。
両方の例でも併記することは可能だったはずですが、
デザイナーがちゃんと最小限まで表記を削ってるようですね。
PLYAER/RYU - COM/KEN
1P/ルイージ, CP/ピカチュ, 3P/マリオ, CP/サムス
などとはせずに。
>>803 ボードゲームにも落ちゲーにもシミュレーションにもキャラクターなんて存在しない件。
それを言うのなら、
>>794 にもちょっと書いたけど、プレイヤーの中にプログラムによって操作される
プレイヤーと、UIを経由して外部から操作される(よく考えると操作するのは実は人間である必要はない)
プレイヤーが存在するんでしょ。
じゃあお聞きしますが、明らかに同じ機能を担ってるクラスの名前が ゲームの種類によって変っちゃってよいわけ? 少しは頭を使おうよ
念のために補足しておくと、画面上のキャラの特性を規定するクラスであるのなら、 それを操作するのが人間だろうがプログラムだろうが、同じものでよいでしょ。
809 :
800 :2013/11/19(火) 20:44:47.08
>>807 アッ!
揉めないうちに先に言うので
>>807 さんのしたい話題とズレてるかもしれませんが、
俺がスレ違いの質問をしてしまったことをはっきり白状しときます。
変数名でも、クラス名でもなく、あくまで画面上の表記を聞いたんス…。
いちおうそれだけはこの時点で言っときます。
じゃあ、顔アイコンオンリーでもいいわけだ。 魔界村だったらプレイヤーのクラスはアーサーで決め打ちしちゃいそう。
widthとheightの増分を deltaWidth、deltaHeight にするのは変ですか?
813 :
デフォルトの名無しさん :2013/11/21(木) 00:13:35.29
文脈によってはもっといいものがあるかもしれないが、意味は通じると思う。 stepとかdiffとかが適切な場合もあるかもしれない。
変じゃないが。 ただローカルだと長いからdw, dh とかにするかな。 クラスメンバならdeltaW, deltaHとかよく使う。
あとsigmaも使うで。deltaの合計って意味で。
ちょっとよくわからないから具体例で
ビュー上の座標計算だろ?
そうか、単純にwidth heightって言ったら母さんの体格かもしれんしな。 俺は座標計算に日頃よく使うから、何の疑問も起きなかったけどw
Size { int width; int height; }だとしたら、 Size size, delta; でいいやみたいな。
deltaと言えば微分の微小な差分みたいな感じがする。俺的にはdw,dh
>>820 > deltaと言えば微分の微小な差分みたいな感じがする。
これは理解できるがこ、だから dw,dh って、意味わからん。
width,heightに対してはdx,dyになるものじゃないのか 俺はグラフィック処理ではそう考えてる 横方向のみとかの1Dでの処理ではSizeとかLengthもあるけど 2Dでの大きさだとWidth,HeightやColoumns,Rows使うし 次の要素との差分はStepかStride
すでにdx, dyもあって区別したいときのdw, dhかな。
dx, dyはx, yに対しての微分だろうとマジレス
そもそもマジレスとわざわざ断るところが恥ずかしい
座標の計算が頻発しそうな雰囲気のときは思い切って文字数を下げる。
Wrapperの別の表現ないか
外科
Hokei
アダプタ コンバータ
それはラッパーと全然違うからw
そうですか
じゃあスキンで
アウターもいいかも。
manager
exoskeleton
なぜWrapperの別の表現が必要なのか Wrapperでいいじゃないか ゃっていることはWrap以外の何者でもないんだから Wrap以外のことが目的&役割で、あくまでWrapはその手段でしかないのなら、 その目的&役割を晒さないと、誰もアドバイスできんと思うぞ
要は内部機能にアクセスするための抽象化されたインターフェイスだよね。 ちゃうの?
>>833 いや、ラッパーてのは実際はアダプタかコンバータに分類されるように思えるが…。
ラッパーかどうかよりもどういう機能を提供するのかを名前にするべきだな
>>841 まずコンバータとは普通はデータの変換器のことでラッパーとはまるで違う。
アダプタは、オリジナルとは違うAPIを提供する意味ではラッパーと同じだが、その目的が違う。
ParapperWrapper
Condom
TheMarkOfSeirogan
略してTMOS
Saran Kure
Proxy Adapter Wrapper 違いは?
私は次のように考えている。 ・Wrapper 下位レベルのインターフェースを覆い、上位レベルに対して、抽象度の高いインターフェースを提供するもの。 だから、Wrapper の外と中には必ず抽象度に関する上位と下位の関係がある。 ・Adapter A からは「インターフェースが異なるために」利用できなかった B を A から利用するために、 A と B の間に置き、B のインターフェースを A から利用できるように変えるもの。 だから、両者の間には利用する側と利用される側という関係があり、 インターフェース(プログラミングならAPIなど)が変わる。 ・Proxy あるモノのインターフェースを覆い、付加価値や副作用を追加したインターフェースを提供する。 Wrapper や Adapter と違い、インターフェースは変えず、内部処理のみ変える。
WrapperとAdapterって幾何学的には同じグラフになるよね。 かなり似てね?
Adapterは単に二者の関係だけど、 Wrapperは標準的なAPIをサポートするものがいくつかある中で それに逸脱したやつを標準に合わせる感じ。
なるほどね。
俺の実践的には final で継承できないからしょうがなくWrapperを作成 目的のリスナーに対応しているAdapterを使用 使用目的に対して継承で特殊機能追加したものがProxy
>>849 Proxy: 代理としてリクエストを受け取る
Adapter: インターフェースを変更する
Wrapper: 機能を追加して使いやすくする
[a, b, c, d, ...] というリストがあります。 これから次のようにタプルを要素に持つリストを作る関数があります。 [(a, [b, c, d, ...]), (b, [a, c, d, ...]), (c, [a, b, d, ...]), ...] つまり、もともとのリストからひとつずつ要素を取り、 それとリストの残りでタプルを作る、そのようなものを要素に持つリストです。 (外側のリストや、中のリストは本当は順不同ですが、簡単のため説明では元の順を維持しています) もともとのリストの要素の型は何でもよく、ジェネリックな関数です。 このような関数の名前は何が良いでしょうか。 今のところ、headTails という名前にしていますが、イマイチわかりにくいです。 (自分は作者なんで意図は分かるのですが、初見の他人にとって、という意味です)
MakeCombination(1, size - 1)
>>856 次のあるひとつの処理のためだけで、意味あるものでないのなら、tanakaとか自分の名前つけておいたら。
listOfOneAndOthers makeListOf...
list of each one and others
Haskell? 手続型ならそんなヘンテコリストいきなり作ったりしないもんな
元々の関数名として void update(); というのを使っていたとします。 ところが、ある理由(update時に起きた特殊なイベントを取得する必要が生まれたなど)で このupdate()に戻り値を加え、 enum_event update(); となったとします。 この場合、関数の機能が「update」から「updateして結果生じたイベントを返す」に変化しているため、 enum_event updateAndGetEvent(); というように関数名と機能を一致させたくなるのですが、これはこれで長くて見づらい気がします。 こういうようなケースの場合、みなさんはどのように対処しているでしょうか?
>>862 Update()
GetCurrentEvent()
とかでいいんじゃないの?
Update()は従来のままで、GetCurrentEvent()は現在発生しているイベントを取得
イベント情報を取得する前に必ずUpdate()すればいい
現在発生しているイベントっていうのはおかしくないか 最後に発生したイベント GetLastEvent の方が updateAndGetEvent も見づらいほど長いと思わないけど、俺なら update のままで戻り値だけ追加する
イベント駆動的な意味のイベントなのか、 ゲーム用語のイベントなのか気になる木
>>864 GetLastEventやGetCurrentEventだとイベントの履歴を保持している印象を受けるな
むしろGetEventでいいのかもしんない
GetLastEventだとイベントが実行中なのか終わってるのか判断しにくいから GetCurrentEventも必要だね
思想としては、自分以外の人間が使うときに極力ヒューマンエラーを減らしたいと思っています。
enum_event update();
だと関数名からだけでは戻り値があることがわかりづらく、
Update();
GetCurrentEvent();
だとGetCurrentEvent()を呼び忘れたりupdate()より先に呼んでしまったりということが考えられます。
使用者がコメントやドキュメントを確実に読んで正確に理解してくれる前提ならどちらでもかまわないのですが。
関数名に"AndGetEvent"とつけておけば、さすがにupdateと同時にeventを取得していることを
わかってくれるだろう、というのが元々の考えでしたが、自分で使っててどうもすっきりしませんでした。
updateとイベントの取得とを分ける方向で考えてみます。
>>865 ゲーム的なイベントです。前に進んだ結果どうなるのか、木にぶつかるのか、何か見つかるのか、といったような。
1回のupdateでイベントは1回しか発生しないのだろうか
あと、updateしないとイベントは一切発生しないのだろうか
updateやめてcheckにしようず
>>868 ゲーム的な話ということで
プレイヤーのキー入力によりイベントの発生を判断するのであれば、キー入力の際にUpdateすればいいし
一定の間隔でイベント発生を判断しているのなら、そのループ内の最後にUpdateの呼び出しをしておけば
GetCurrentEventの場所はループ内であればどこでもいいと思うけど
今後の拡張を考えて分けておくのが正解だと思うわ
メソッド分けるとスレッドセーフとかが怪しくならないか? 大丈夫な用途ならいいかもしれないが。 あと戻り値忘れる人は別メソッドの呼び出しもしないんじゃ…。
>>868 考えすぎ。機能がupdateなら返り値があろうがなかろうがupdateでいい。
そもそもupdateだから返り値を持たない筈だ、なんて先入観を持つプログラマがいたら
その人のその感覚の方が間違ってる。
百歩譲ってそういうプログラマの存在を前提とするとしても、今時みんなIDE使うでしょ。
だったら何の問題もない。
876 :
デフォルトの名無しさん :2013/11/28(木) 20:32:53.28
update_event()
updateAndGetEvent アトミック性が必要ならば、実に愚直で分かりやすいじゃないか。 Javaとかだと、 AtomicInteger.getAndIncrement() とかあったりするし
getEventAfterUpdate()
関数名しか見ないなんて事しなけりゃいいだけ
閃いた。 readme()
881 :
856 :2013/11/29(金) 07:26:02.58
>>858 他のところでも使うので、分かりやすい名前を考えています。
>>861 Haskell です。
アイデアを提案していただいた事はうれしいのですが、
どれも少々冗長ぎみに感じました。
もう少し考えてみます。
ありがとうございました。
>>880 くそー、ちょっと笑っちまった
でも、それやりだしたら、
readme11( )
readme12( )
readme13( )
readme14( )
とかなって、昔の Coboler が作ったソースみたくなりそう (w
コードで申し訳ないんだが、↓みたいな処理の名前ってどうすべき? 内容としては、taskの正常終了時のみ completionFunc をかまして結果を作成、それ以外は taskの状態を引き継いだ新しいTaskを返す public static Task<TOut> WrapPipeline<TIn, TOut>(this Task<TIn> task, Func<TIn, TOut> completionFunc) { var tcs = new TaskCompletionSource<TOut>(); switch( task.Status ){ case TaskStatus.Canceled: tcs.TrySetCanceled(); break; case TaskStatus.Faulted: tcs.TrySetException(task.Exception.InnerExceptions); break; case TaskStatus.RanToCompletion: TOut result; try{ result = completionFunc(task.Result); } catch(Exception ex){ tcs.TrySetException(ex); break; } tcs.TrySetResult(result); break; } return tcs.Task; }
返り値がTaskである必要性がないようが気が
Packet<TOut> filterPacket(Packet<TIn> in, Filter<TIn, TOut> filter)
convertTask
GetNextTask
>>884 Task じゃないとキャンセル・エラー情報を引き継げない
使い方も書いとくべきだった↓
AsyncMethdo()
.ContinueWith(t => t.WrapPipeline(result => {
// AsyncMethod 成功時の処理
})).ContinuewWith
…
.ContinueWith(t => {
// エラー処理がまとめてできる
});
>>883 やってることがwrapではねーなっていうのはわかる。どっちかっつーと状態遷移のための仕組みに見える。
>>887 に一票
しかしそんな処理必要なんだろうか
TaskContinuationOptions を指定して完了・キャンセル・エラーを分離することもできるけど、複数に分かれて煩雑になるじゃん・・繋げて書けないし
ChainFuncとかJoinFuncとかPipeFuncとか。 AddやAppendだと入出力が繋がってるニュアンスが出ない? 正確に全部の機能をもれなく名前に盛り込もうとするとやたら長くなりそうだから 適当なところで諦めた方が良さそう。 あと"Func"の部分の概念をあらわす適切な言葉が存在しないのがつらい。 ProcedureとかProcessとかPostProcessではおかしいし。
常にそのパターンで使うのなら ContinueWith ごとラップした方が便利だし名前を付けやすいと思う AsyncMethod() .Chain(result => { ... }) .Chain(result => { ... }) .ContinueWith(t => { 最後 });
bool object.isAvailable();が "the object is available"という英文に添った形になっているのはわかるんですが、 getterとかsetterってどうなんでしょう。 bool object.getAvailability();は "the object get availavility"ではなく、"get the object's availability"や"get availavility from the object"ですよね。 isとの統一性を考えるとgetじゃなくてshowやrevealにすべきなんじゃないでしょうか。 それとも私の考え方が間違ってるんでしょうか。
またその話題か
we get availability じゃないの?勘だけど。
>>894 object.availabilityでいいんじゃない。
get me objects availability
>>894 isXXXという命名パターンはC言語の頃から見られる記法であり、object is XXXを示しているわけではない。
だからといってそれが絶対正しいわけではないし、
貴方が今の考えにしたがってゲッターセッターも統一させたいと思うのは自由だ。
Hey Bob! Kiss my ass! と同じオブジェクトさん、プロパティを取ってよ、と呼びかけてるの
x=trueに対してxのsetterが作動すべきでありy=xに対してxのgetterが作動すべき これができないヘボ言語はやむをえずgetXやsetXを直に弄ることになる。 isXってのはgetXのことに他ならない。getXとisXが同じ用途で覇権を競っているならばgetXの方が正しいだろう。
setterを用意しないならisXのほうが正しいだろうね
それはない
isとgetの区別が付かないとかネタでしょ
setX, getX, isX はオブジェクト指向が一般化するはるか以前からある。 オブジェクト指向になってもその慣用は変わらなかった。 この慣用とは違う動詞を使うのはリーダビリティ下げるよ。
isXとgetXの違いなどヘボ言語における混乱にすぎないということ。
hasXのこともたまには思い出してあげてください。
908 :
デフォルトの名無しさん :2013/12/06(金) 13:33:01.93
>>901 そういうのって自然言語処理とか使ってケースごとに対応を変えるだけでいいんでない
例えばBoolean型のフィールドの場合にはisXで
他の方の場合にはgetXでという具合に対応するだけで問題なさそうだけどな
C#です ProgressBarをコンストラクタで受けて、各メソッドで状態を管理するクラスを考えています 以下のようなクラス名を考えましたがいまいちな気がします いいクラス名を教えて下さい ManageProgressBar ControlProgressBar
ProgressBarController
Progress
ProgressBarManager
>>913 いやいや、クラス名にmanagerとかcontroller使うのはバッドノウハウの典型例だろ。
ProgressBarを管理するのはProgressBar自身であって、これ自体は進捗状況を表示するためのアイテムなわけ。
そして貴方はProgressBarを管理したいんじゃなくて、
とある進捗状況を与えられたProgressBarを通じて表示したいだけだよね。
>>914 ProgressBarをコンストラクタで受け取るクラスなんだから、複数のProgressBarを管理したいってことでしょ。
で、この設計が妥当かどうかという話なら、それはスレ違い。
918 :
909 :2013/12/13(金) 17:42:33.85
やりたいことは以下の通りです 管理するプログレスバーは一個 表示、非表示を切り替えるメソッドを持ちたい 最小値、最大値を設定するメソッドを持ちたい 値をカウントアップするメソッドを持ちたい フォームでこのクラスのインスタンスを生成し、 ロジッククラスに渡して上記メソッドでプログレスバーを管理したいと考えてました
919 :
909 :2013/12/13(金) 17:45:27.38
一回決めて頂いたのにすいません やりたいことを最初から詳細に書いておくべきでした やりたいことは前レスの通りです、よろしくお願いします
MyProgressBar
>>918 まさしくProgressBarそのものじゃん。
922 :
909 :2013/12/13(金) 18:27:24.39
言われてみればその通りかもしれません ただ画面コントロールをロジッククラスに渡すのはよくないかと思いクラスにしようと思いました ラッパーになるんでしょうかね
ああ、frameWorkにprogressBarがすでにあるのか。 じゃあラッパーだよね。controllerとかmanagerではないな。
ProgressBarState
Peogress爺
特定の条件によって、画面の項目を有効または無効にするような処理をなんと呼べばいいのでしょうか? 例えば、性別を切り替えたときに入力できる項目を切り替えるような処理。 入力制御や入力規則でググると、テキストボックスに数字のみ入力するというような 単体のコンポーネントに対する処理がヒットしてしまいます。 条件によって有効になる項目もあれば無効になる項目もあるので、 enableXXXXX, lockXXXX のようなメソッド名以外を考えています。 このような制御をなんと呼ぶのかご存知の方がいましたら教えてください。
updateEnablity
update gui update components update component states update availability update editability
>>927 おれなら enableXXXXXGroup
あるいは enableXXXXX (XXX_GROUP)
enable を使わないとなると、ごめん、自然な英語は思い浮かばないな
プロパティのGetterだけを定義したインターフェースIXXXがあります。 これに対して、プロパティのSetterだけを定義したインターフェースを導入して、可変にしたいのですが、 何て名前がいいでしょうか?? とりあえず、適当に思いついたのはIMutableXXXぐらいです。 よろしくお願いします。
普通、IXXXに対してsetIXXXじゃないの? と思ったらインターフェースの名前か。 IXXXSettersとかは?
IVariableとか 自分ならSetterのみを定義したインターフェイスは作らないかな
IXXXMutator IXXXEditor
IReadOnlyAAA IAAA : IReadInlyAAA
IReadable/IWriteable
>>931 です。
元のGettersだけのインターフェースの名前はReadOnlyとかで修飾したくありません。
このインターフェースはメソッドに渡すパラメータを定義したインターフェースなのでGettersだけなのです。
実際は、このインターフェースを実装したクラスを自分で定義すれば、パラメータを設定するのに、
別に追加の可変にするインタフェースなんて必要ありませんが、
実装を省略できるように、追加のSettersのインタフェースを用意して、
これとGettersのインタフェースを実装したクラスをこちらで用意して、このインタフェースを返そうという事です。
ちなみに、外部に公開するのはインタフェースだけなので。
まぁ、追加のインターフェースを元のIXXXから継承させるにせよ、させないにせよ。 IYYYYXXXの形式のやっぱIMutableXXXとかIVariableXXXとかあたりが いいのかなと思いつつ。
視点が読み書き可能かに偏っているが、メソッドに渡したいパラメータのセットであるなら、 そのパラメータの名前をあてた方がスマートだと思う。 例えばSTGの当たり判定のメソッドのパラメータにIRectangleを渡す感じで。
>>939 まさしくそんな感じで、インタフェース名にパラメータの名前(要は名詞、IRectangleみたいに)をつけてます。
でも、Gettersのメソッドしか定義してません。
で、
>>937 で書いたように、使う側で実装を省略できるように
ヘルパ的なパラメータを設定するためのインターフェースを用意したいのです。
IXXXEx
IXXXConst
IMutableって嫌がらせ過ぎる名前だなw っていうか、素直にReadOnlyつければ済む話を何で頑なに拒むのかちょっと理解できないな
俺なら、Stringに対するStringBuilderみたいにBuilderパターンにするかな。
比較方法 CompareMethod が長すぎるので CompMeth CmpMth もう少し良いのありませんか?
メソッドを比較するの? それとも比較するメソッドなの?
Comparator
Comparer
949 :
945 :2013/12/24(火) 03:10:48.42
VB.NETのCompareMethod 列挙体の値を入れる変数です。
cm
currentCompareMethod
VB.NETならVisual Studio環境だろうから、 インテリセンスが効くから別に名前は長くても問題ないはず。 むしろ変に省略系にしてしまって、後の自分や他の人が見て 意味不明なものにならないようにすべき。
>>945 今時その程度の名前で長いと思うならプログラマ辞めた方が吉。
>>953 ORACLEとかやってる人なんじゃなのかなー
あのDBは変数名・テーブル名に30バイトの制限あるじゃん
955 :
デフォルトの名無しさん :2013/12/24(火) 21:42:15.07
ないない
30バイトもあるなら、CompareMethod で長いなんて言わんだろ
ごめん、全然関係ない所読んでた そうだね、プログラム書いてると普通にクラス名長いのあるよね
メソッドのローカル変数のようにスコープが短い場合はcmかな
最近書いたある抽象クラスの名前 RelationshipBetweenParentAndChildren どや?
960 :
デフォルトの名無しさん :2013/12/27(金) 23:38:38.23
family
javaで業務アプリを作ろうとしてるんですが、各画面のクラス名どうしてますか? 規則に従ったIDにしようかなと思ってます。 200画面くらいあるシステムでだと、どうなってますか
役割に応じた名前をつけてあげてください・・・
200画面が完全に独立したもので無ければ、 画面を分類して、名前はその分類名から始まるように付けるとか。
>>959 200画面もあったら、適切な名前付けづらいだろうし、ID + 名前かな〜
966 :
デフォルトの名無しさん :2013/12/28(土) 01:29:27.45
天然無能な・・・
仕様書の画面ごとに名前あるだろ。 画面ってswingかな。
>>961 200画面必要な業務ってのが想像つかないけど、それが事実でまともな人が設計してるのなら
自然と階層構造になってるか、それでなければ
>>967 の言うように個別に名前を与えれるような
分類になってるはず。
前者なら階層どおりアンダースコアで区切るとかして名前を付ければいい。
長くて読みづらくても無意味な数字よりましだと思う。
>>959 Relation<Parent, Children> がいけるんだがなC++だと
970 :
961 :2013/12/29(日) 10:59:53.04
みなさんレスありがとう flash + .netでのシステムが、100画面くらいで運用しています。 ほとんどバッチ処理を起動するだけの画面なんですが、処理が微妙に違っているだけの画面とかあります。 出庫入力1、出庫入力2、出庫入力3みたいな感じで だから、新しくシステムを作る時(javaで)に、どのようにクラス名をつけようか困っているわけです
特効薬はない
>>970 それ、入力画面クラスがあって、そのモードを変えてるだけじゃないの?
俺ならそうするけどw
>>972 違うよ
あまりにも仕様変更が多すぎるから、画面まるまるコピペしてる
SEがダメすぎだから
在庫で使う、ケース数、バラ数、総バラ数って 英語だと単語何になりますか?
最適化を施したある関数Fがあって、その引数と戻り値の関係が正しいかどうかをテストしたい。 そのために、最適化を施してなく計算処理は遅いのだが、 誰が見ても正しいと思えるような、慎重に実装した技術的には稚拙な、 Fと同じ引数と戻り値の関係を持つ関数Gを作り、大量の引数に両関数を適用して比較したい。 このようなテスト用の関数Gの名前は、何するのがいいんだろう。 たとえば F に対して test_G とすると、G をテストするようなイメージが湧く。 テストするのは G そのものではなくて、F と G が関数として同値かどうか。
Reference Implementation
978 :
18 :2014/01/01(水) 12:22:59.34
>>976 どうせ一時的に必要になるだけなんだろうから名前なんか何でもよいのでは?
int void PowerOf2(int n)
int void PowerOf2_Unoptimized(int n)
とか
int void PowerOf2(int n, bool optimizes){
if (optimizes) return PowerOf2(n);
....
return xx;
}
とか
980 :
976 :2014/01/01(水) 13:34:00.63
みなさん、アドバイスありがとうございました。
Reference Implementation を略して RI か ri を使わせていただきます。
(RI_F や ri_F あたり)
>>979 一時的ではありません。
何を使ってどうテストしたのか、記録として残しておくものです。
なので何でもよいわけではなく、比較する元のものである、
という目的が後で見てすぐに汲み取れないといけません。
Reference Implementation は今回の目的にぴったりです。
幸い、これを RI と略しているのはよく見かて違和感ないので、
これを採用させていただきました。
で、1年後に自分のソース見て「このRIってどういう意味なんだ(ムキー」ってなるの巻。
982 :
976 :2014/01/01(水) 13:42:12.90
>>981 そんないい加減な管理ではないので、ご心配なく。
煽りはスルーせれ
別に煽るつもりないけど、管理しなけりゃならない時点で名前としては破綻してるんじゃないのと思うけど。
>>984 > 別に煽るつもりないけど、管理しなけりゃならない時点で名前としては破綻してるんじゃないのと思うけど。
いいえ。
こんな少ない情報で、そんな結論を出せるあなたはエスパーじゃないかと思うのだけど。
980のように納得する答えを出せた人(>977)) が、実社会で価値のある人間だよ。
アウトプットを出せる人間と出せない人間の違いは、まさにコレ。
>>985 > アウトプットを出せる人間と出せない人間の違いは、まさにコレ。
あ、はっきり書くね。
アウトプットを出せる人間 = >977
アウトプットを出せない人間 = >981, >984
ムキーッ!!
何が言いたいのか分からないが幼稚だね。
>>985 こういう思考回路の人が伝説になってる、「ID番号付きの関数をバインダで管理」
なんて地獄絵図の世界を作るんだろうな。
コード上の名前と別に管理が必要な時点で名前として破綻している、
というのは今時のプログラマとしては常識的な見解だと思うが。
まるでジョナサン流の強がりだな
だれ?
カモメの
板違い・スレ違いかも知れんが、助けてくれ 自分用にデータベースを使って家計簿みたいな日々の収支を記録するアプリを作ってるんだが、 テーブルのフィールド名で困ってる 収支の日付はDateで、収支の品目はItemでいいとして、収支の金額は普通なんて言うの? Price、Value、Ammount、Money あたりなの? プログラムで扱いやすいように、日本語は無し、英語という縛りで
いんかむ
994 :
992 :2014/01/04(土) 14:45:18.34
>>993 せっかくのアドバイスに本当にごめん、言い忘れていた
今回は収入と支出に分けず、収支を一つのフィールドで表す方法をとってるんだ
(支出は正の整数で、収入は負の整数)
収支を1つで表すの? 分けたほうがいいんじゃない 収入=Income 支出=ExpensesとかCostsとか
income and outlayとかか InOutでいんじゃね?
負の値を使うなら、名称はそれが正の場合の呼び方でいいでしょ。 つまり収支じゃなくて収入でいい。 加速度を加減速度とは言わないし、経済成長率を経済成長縮小率なんて言わんでしょ。
998 :
992 :2014/01/04(土) 15:35:04.01
それもそうか、じゃあ支出の英語ということで spenfing にするよ
みんな、ありがと
>>995 データベースの中では分ける意味がない
ある品目が支出であり、かつ収入であるなんてことはあり得ないのだから
このデータを画面に分かりやすく表示する際には当然分けるけど
999 :
992 :2014/01/04(土) 15:35:51.73
またミスった 誤 spenfing 正 spending
>>998 そういうものなのか
それぞれの合計とか出したりするなら
分けた方がいいと思ったんだけど
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。