クラス名・変数名に迷ったら書き込むスレ。Part28 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
クラス名、変数名のつけ方に悩んだら書き込むスレです。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
前スレ
クラス名・変数名に迷ったら書き込むスレ。Part27
http://echo.2ch.net/test/read.cgi/tech/1476572490/ 特定の問題を解く上で便利なデータ構造があるなら、それが695の説明ほぼそのままの抽象度の高いものであってもいいだろ
自然物や既知の概念に縛られる必要はない
データの特性が明かされている以上、定数7の例示は過度の単純化をしていて相応しいとは思えない
抽象性の高いままに案を提示してくれている人々に対して「意味ない」とは俺は思わん 695です
このデータ構造は、OneHot〇〇って命名するのが適切そうなのでそうします
ありがとうございます
>> 698
そのケースはあります >>708
だから特定の問題領域で何と呼ばれるか、そんなの何の意味もない
彼の問題領域でそれが何を意味しているか、それが重要。
当たり前でしょ
そもそも配列がベクトルか、行列の列や行を表しているのか、数列か、
あるいは数学的な意味は持たないただの集合か、状況によって
配列そのものがまったく違った意味を持つ
もちろん抽象度が高い配列の特定の状態(例えば全部の要素が規定値とか)が
汎用的な意味を持つ場合もあるだろうし持たない場合もあるだろうが、
普通に考えればこんなのか後者に決まってる
>>709
抽象度が高いのが悪いとか誰も言ってないの。
重要なのは何を意味しているのかだと何度言わせるの
大丈夫かマジで >>708 で終了だろ
何をグダグダ言ってるんだよw >>711
名前の提案ができないのなら、黙ってればいいんだよ。
できない言い訳をするスレじゃないから。 抽象的と言うか
外から見た役割で命名しろというのは大前提も大前提だろ
ただ、その内部処理を書いてるときとか
実装べったりな命名やら、類似処理で使える汎用的なプリフィクス/サフィックスやらが欲しいときも当然あるさ 質問者は
OneHotXXX
↑こういうのの「OneHot」という言葉が欲しかったんでしょうに。 そんなのなら素直にValidってやった方いい
意味不明より抽象的な方がミスリードの心配がなく情報量も多いから >>716
いきなりどうした?
既に質問者(と思われる人)は
> このデータ構造は、OneHot〇〇って命名するのが適切そうなのでそうします
> ありがとうございます
ってレスしてるよ Analysisが長いのでAnalにしようと思います pencilが長いのでpenisにしようと思います insertまでできるんだったらmagnumを使おうと思います 商品であれば取扱開始日と終了日まで、アカウントであれば有効化日と無効化日を表す変数名で悩んでます。
今はとりあえずstartdateとenddateにしてるんですが、どんな名前にするのがいいでしょうか?
validateddateとinvalidateddateのほうがいいですか? >>723
regist_date、cancel_dateとか Active, Disable?
取扱開始日と有効化日、終了日と無効化日を同じ変数名で?
それなら商品の方が微妙になるか >>723
いつでもそうできるわけじゃないだろうけど、開始日/終了日を一組にしてしまえば、
DealingSpan.First
DealingSpan.Last
とかできるはず。 下手に微妙な名前をつけるよりstartdate, enddateで一般化したほうがいろいろ具合がいいという側面もある
個人的にはbegindateの方が好き
型が日付なのか日時なのかわからない名前は嫌 次に読んだ時に、何が初まるの? とはないだろうか? >>723
終わりのほうはexpired一択。
始まりはなんだろ?対応させるならsubscribedかな?
ただの開始と終了じゃなく、なんか有効期間的な範囲だったら。 >>732
現時点で過去とは限らないのでそういうのはどうかと思うよw 難しいな
他動詞なら過去分詞を受動態として無造作に使えるけど、自動詞では、時制が過去かどうかはともかく、完了相が前に出るということだろうか
expire dateでは文法的におかしいし、expiringも進行相だし、素直にexpiryかexpiration dateしかないのか >>733
>>734のいう感じで、過去分詞のつもり。
原則、命名で過去形なんか使わん。
自動他動は気にしなかったけど、そこはどっちでもよくない?
英語は言うほど詳しくないんだけども。w いやexpiredは形容詞だと思うけど、どっちにしろ
現時点までのある時点で「期限切れ」になってないものに使うのは変だと思う。 >>734
英語として正しいことが目的じゃなくて、わかりやすい変数名でしょ
文法的に正しくても、一般的でない単語や言い回しだと読む人が混乱するんじゃね?
まあ、誰が読むのかって定義は必要かも知れんが
つまり、YukoukaDate,MukoukaDateにしろ 開き直るならyukoukabi、mukoukabiもありだと思うよ
ただし和英混合ありなしとヘボン式なのか何なのかは厳格に
それで一貫してるシステムは割と開発しやすかった 過去分詞の形容詞的用法って懐かしいよな
ちなみに未来完了形でwill have expiredという活用になることもある
いずれにしても話者の視点からは「失効した日」という意味になるから
おかしいと思うのは同感だ おまえらexpireで盛り上がりすぎ。
質問者いつ出てくるんだよ。 思い…出した!
obsolete dateだわ
対義語はeffective date
我ながら見事な回答と言うしかないが、日本人エンジニアからはインテリぶってると思われる諸刃の剣
素人にはおすすめできない >>739
知ってるよ。
っていうか辞書引いてそれ言ってるのか
>>740の言う通りというか、いやちょっと違って、
もともと形容詞的な用法から派生したんだと思うが、今では独立した形容詞と見なされている単語だよ
expiredを過去分詞として使っているとしても(もちろん受動じゃなくて完了の意味で)
どっちにしろ現時点で過去になってない期日を表す言葉としては不適切だ
もう質問者さんどうでもいいみたいだけど、
こういう面倒な問題をスキップするためにも、>>729に書いたみたいに
可能なら期間を表す型を定義しちゃったほうがシンプルだね URIが与えられて、そのURIが表すリソースの種別を判定するのですが、
例えば、Aリソース、Bリソース、Cリソースなど。
各種別ごとに下のようにメソッド用意するのもあれなんで、
bool isAResourceUri(Uri uri);
bool isBResourceUri(Uri uri);
bool isCResourceUri(Uri uri);
一つにまとめて
解析結果を表すクラス parseUri(Uri uri); //
みたいな感じにしたいです。解析結果を表すクラスのクラス名をお願いします。
parseUriの名前も変えた方がいいならお願いします。 parseはあかん
ResourceTypeOf(URI uri); >>746
与えられるのが文字列ならparseでいいけど既にUri型になってるならparseは違和感ある
UriクラスにgetResourceType()みたいなメソッド追加すればいいんじゃね? そうですか、型はUriですね。もちろん、文字列にして内部でUriにしてもいいですが。
で、そのUriのパスのフォームからリソースタイプを判定するのですが。
Uriはビルトインクラスなので、メソッド追加できません。拡張メソッドみたいのもありませんし。 後、解析結果なんですが1つのリソースタイプだけじゃなく複数の情報が返されるのです。
たから、現状クラス名がUriParsedResultとかにしてて..
後parse以外にanalyzeとか思いつきましたがなんか大袈裟というか 最初のbool isAResourceUri
で、返される情報は1つだけみたいな誤解を与えてしまいましたすみません web全然知らんけど、要するに実際にファイルをwebから拾って中身を見て解析するわけじゃなく、
単純にパスの拡張子を見るだけってこと?
そうならそこを強調しないとまずいよねたぶん。知らんけど。
適当な名前空間に収まってる前提で
ResourceType PathParser.GetType(Uri uri) そうですね。実際にWebから中身拾ってくるわけじゃありません。例えば
http://hoge.com/users/[userId]
このUriならuserを表すuri
http://hoge.com/tweets/[tweetId]
このUriならtweetをあらわす
これを解析してどのリソースを表すかと、例えばuserを表すuriなら抜き出したuserIdも返す感じです >>750
> Uriはビルトインクラスなので、メソッド追加できません。
言語がわからんけど(Javaのfinal classとかC#のsealed classとかで)派生できないようにされてるの? >>754
これ、そもそもURIはリソースを指しているんじゃなくて、
アプリケーション(?)の種類とそのパラメータを表してるんじゃないの?
その意味じゃ全然URIじゃないねw ResourceUri ResourceUri.of(Uri uri)
ResourceUriはtypeやidなどを持つ getURIInfo
これなら、いろいろふんわりやから気にならんやろ。w >>759
RESTのUriはあんな感じですよね。
>>760
ふんわりしてていいかもですね。 A, ファイルをバイナリとして開いて検索
B, 起動中のプロセスのメモリを検索
検索部分は共通した処理だから同じクラスでやりたい
この場合はクラス名何がいいかな?
MemorySearchとかだとBだけになるし
BinarySearchだとメモリもバイナリでいいの?ってならないかな? >>763
class BinarySearch {
public BinarySearch(String FileName){ … }
public BinarySearch(Pid ProcessId){ … }
…
}
みたいな感じでいいんじゃね? Binary searchは「二分探索」って意味になるからそれは避けたほうがよいと思う >>763
検索対象のデータはストリームみたいに抽象化するんだろうから、
「何から」検索するかではなく「何を」検索するかに注目して
名前を付けた方がいいんじゃない?
だとするとざっくり検索って言われてもな感じ。
これだとFinderとかSeekerとかぐらいしか言いようがないよね Seeker
Searcher
SearchEngine ありがとう
A, バイナリエディタの検索部分
B, メモリエディタの検索部分
検索部分だけのプロジェクトを作ってAとBに使い回すなら
両方で違和感の無い名前がいいよなってのが経緯
「何を」と言われると
A, 修正箇所
B, 値の変動に応じて絞り込み検索してアドレスを特定
こうなるから同じにせずに分けた方がいいのかなと思えてきた
でもやってる事は同じだから共通化させたいけどこういう時は分けるもんなんかな? >>770
よほど特殊な機能を持ってるなら別だけど単なる検索機能だけならコード量もたいしたことないだろうから俺なら別々にしておくと思う 共通部分をis-aなりhas-aなりで共通化することに問題はないと思う 簡単な名前でいいならBinaryDataSearcher
Dataみたいな語は情報量が少ないから削られがちだけど、この位置のDataを無造作に省略すると修飾先が変わっておかしなことになる
もう少し真面目に考えると、バイナリかテキストかという初歩的な分類用語よりも、エンディアンとか解釈した結果のバイトストリームを扱ってるならそういう名前の方が適切
ほかには多少語弊が生じるけど、お好みでProcessとかProgramとかExecutableあたりの語を使ってもいいかも >>770
要するに、
(1) ストリームの中から
(2) 指定されたバイト列に完全一致する場所を探す
ってことね。部分一致とか、パターンマッチと、CRC的な符号が一致するとか、そういうのじゃないわけだ。
じゃあ「バイト列の探し屋」か?
ByteSequenceFinderとかByteArraySeeker みたいな感じ? Cで言えばstrstrのバイナリ版GNU拡張のmemmemだよね。
ファイルが対象だとしてもmmapすれば同じだし。 そこまで抽象化するなら検索アルゴリズムの実装になるから検索アルゴリズムの名前でいいんじゃ ありがとう
そう、完全一致だけで部分とかパターンとかは無し
この流れをヒントにして考えてみるよ
ありがとう テキスト検索で、検索ボックスに入力する文字列と検索対象の文字列(本文)はどう名付けるのが無難ですか? >>779
前者はkeyword?
後者は置かれる文脈次第だろうね。シンプルにtextで通じるならそれでいいと思う
他の候補は
target, targetText, scannedText, searchee
ググってみたがsearcheeって言葉は正式な英語じゃない(当たり前か)
でも意味は分かると思う box, search という単語を変数名に入れた方がいいと思う
同じような変数が何種類か出てくることになると思うので 検索文字列はsearchStringがよく使われる印象
boxみたいにUIの形状に基づく変数名は本当にそれが妥当なのかよく考えてから付けたい UI要素につける名前なのか
UIから受け取った検索文字列と検索対象文字列を一時的に格納するローカル変数につける名前なのか
それを渡す検索メソッドの引数につける名前なのか
コンテキストによって適切な名前は変わってくるから
それを共有しないと時間の無駄 普通に考えれば>>779の人が検索ボックスと言ってるのは
その方が話が早いからでUI要素の名前を聞いてるわけではないと思うよ
英語のkeywordに相当する日本語って意外とないから。
検索文字列とか言っても見つけ出したい文字列じゃなくてスキャンされる方の
文字列を指してると誤解される可能性がある。 例えば、Twitterのツイートがあります。ツイートが他のツイートへの返信の場合、
どのツイートへの返信かを表すIN_REPLAY_TO_TWEET_IDみたいのがあります。
で、この逆の関係を表現したいのです。
あるツイートがあって、このツイートへ返信してるツイートのIDsを表す場合
なんて名前がいいでしょうか? この手のってコード書いてると訳分からんようになるんだよなー 連投すまん
上2レスをまとめて書いたらNGワードで蹴られたから分けてみたら通った
ERROR: Rock54: Warning:NG〜ってやつ
何じゃそら 788のにそのまんま返してしまったけど、replyだったねw >>789で終わってたw
逆にこれ以外に何があるんだw
ついでに、IN_REPLAY_TO_TWEET_IDなんて意味不明だから
素直にparentとかした方がいいんじゃないの? in reply to tweet id は返信先のツイートのIDって意味じゃないですかね?確かTwitterAPI のJSONはこういう名前のフィールド持ってたから外人の人が命名しただろうから、盲目的に信じてたが、おかしいのか? Tweetクラスに、InReplyToプロパティとRepliesプロパティ追加しとげばいいか。どっちがどっちになりそうだけど仕方ないのか in_reply_to_tweet_idってのはTwitter APIの仕様だから変えるのはいささか難しいだろうな
リプライオブジェクトを格納するrepliesと、リプライIDだけを格納するreplyIDsを名前で区別したい場合はある
名前に対称性を持たせるならreply_tweet_ids つか今見ると俺がreplayだったのか。すまん、typoしてました >>795のparentというアイデアを借りて、
単にParentとChildren。これじゃ何の親子関係か分かりづらい?のでReplyParentとReplyChildrenじゃくどい?
で最後InReplyToとReplies
皆さんはどれがお好みでしょうか? 特定のツイートとリプライは1対Nの参照関係だけど親子関係ではないし
ドメイン用語にParentやChildは無いのでそういうのは入れないほうがベター
InReplyToとRepliesがいい 循環てw
明日書かれるツイートに今日返信できるのかwww ついでに言うと、論理的には木構造は循環する可能性を必ずしも排除しないはず。
ツイートは循環なんかしないけどね >>802
ツイートとツイートの関係(=relationship)の話と
それをプログラムで扱う際にどういうデータ構造で表現するのかという話はレイヤーが違う
親子関係じゃないということとツリー構造で扱うということは両立しうる話
特定のデータ構造で扱うことを前提とした命名をすべき状況で
ツリー構造に依存した名前にしたければそうすればいい ツリー構造であるかどうかを議論してもしょうがないと思うぞ
ツリーの関係性を有するデータの名前に漏れなくChildrenをつけるべきか?
これは常には成立しないよな
ツリー以前に、単なる1:Nの親子関係を有するデータにも同じことがいえる
雇用関係ならEmployerとEmployeesが妥当であって、EmploymentParentとEmploymentChildrenという命名は拙い ■ このスレッドは過去ログ倉庫に格納されています