X
クラス名・変数名に迷ったら書き込むスレ。Part28 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
0001ネミ子
垢版 |
2017/05/07(日) 18:01:52.03ID:akuyRduv
クラス名、変数名のつけ方に悩んだら書き込むスレです。

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

前スレ
クラス名・変数名に迷ったら書き込むスレ。Part27
http://echo.2ch.net/test/read.cgi/tech/1476572490/
0750デフォルトの名無しさん
垢版 |
2019/09/06(金) 19:08:30.01ID:uS/8ghDY
そうですか、型はUriですね。もちろん、文字列にして内部でUriにしてもいいですが。
で、そのUriのパスのフォームからリソースタイプを判定するのですが。
Uriはビルトインクラスなので、メソッド追加できません。拡張メソッドみたいのもありませんし。
0751デフォルトの名無しさん
垢版 |
2019/09/06(金) 19:13:06.97ID:uS/8ghDY
後、解析結果なんですが1つのリソースタイプだけじゃなく複数の情報が返されるのです。
たから、現状クラス名がUriParsedResultとかにしてて..

後parse以外にanalyzeとか思いつきましたがなんか大袈裟というか
0752デフォルトの名無しさん
垢版 |
2019/09/06(金) 19:15:06.10ID:uS/8ghDY
最初のbool isAResourceUri
で、返される情報は１つだけみたいな誤解を与えてしまいましたすみません
0753デフォルトの名無しさん
垢版 |
2019/09/06(金) 19:59:09.78ID:aE1H8E8O
web全然知らんけど、要するに実際にファイルをwebから拾って中身を見て解析するわけじゃなく、
単純にパスの拡張子を見るだけってこと？

そうならそこを強調しないとまずいよねたぶん。知らんけど。
適当な名前空間に収まってる前提で
ResourceType PathParser.GetType(Uri uri)
0754デフォルトの名無しさん
垢版 |
2019/09/06(金) 20:24:08.80ID:uS/8ghDY
そうですね。実際にWebから中身拾ってくるわけじゃありません。例えば
http://hoge.com/users/[userId]
このUriならuserを表すuri
http://hoge.com/tweets/[tweetId]
このUriならtweetをあらわす

これを解析してどのリソースを表すかと、例えばuserを表すuriなら抜き出したuserIdも返す感じです
0755デフォルトの名無しさん
垢版 |
2019/09/06(金) 23:54:53.62ID:w2Tc9TX1
>>750
> Uriはビルトインクラスなので、メソッド追加できません。
言語がわからんけど（Javaのfinal classとかC#のsealed classとかで）派生できないようにされてるの？
0756デフォルトの名無しさん
垢版 |
2019/09/07(土) 00:34:21.80ID:lng4b11W
>>754
これ、そもそもURIはリソースを指しているんじゃなくて、
アプリケーション（？）の種類とそのパラメータを表してるんじゃないの？

その意味じゃ全然URIじゃないねw
0763デフォルトの名無しさん
垢版 |
2019/09/14(土) 19:11:22.43ID:TUFMAlcF
A, ファイルをバイナリとして開いて検索
B, 起動中のプロセスのメモリを検索

検索部分は共通した処理だから同じクラスでやりたい
この場合はクラス名何がいいかな？
MemorySearchとかだとBだけになるし
BinarySearchだとメモリもバイナリでいいの？ってならないかな？
0764デフォルトの名無しさん
垢版 |
2019/09/14(土) 20:18:51.13ID:nEO5MM+y
>>763
class BinarySearch {
public BinarySearch(String FileName){ … }
public BinarySearch(Pid ProcessId){ … }
…
}
みたいな感じでいいんじゃね？
0765デフォルトの名無しさん
垢版 |
2019/09/14(土) 20:53:18.08ID:ynHb/SwE
Binary searchは「二分探索」って意味になるからそれは避けたほうがよいと思う
0766デフォルトの名無しさん
垢版 |
2019/09/14(土) 21:20:28.76ID:hosEl+Of
>>763
検索対象のデータはストリームみたいに抽象化するんだろうから、
「何から」検索するかではなく「何を」検索するかに注目して
名前を付けた方がいいんじゃない？

だとするとざっくり検索って言われてもな感じ。
これだとFinderとかSeekerとかぐらいしか言いようがないよね
0770デフォルトの名無しさん
垢版 |
2019/09/15(日) 10:33:36.53ID:WyNEQ0+k
ありがとう

A, バイナリエディタの検索部分
B, メモリエディタの検索部分
検索部分だけのプロジェクトを作ってAとBに使い回すなら
両方で違和感の無い名前がいいよなってのが経緯

「何を」と言われると
　A, 修正箇所
　B, 値の変動に応じて絞り込み検索してアドレスを特定
こうなるから同じにせずに分けた方がいいのかなと思えてきた
でもやってる事は同じだから共通化させたいけどこういう時は分けるもんなんかな？
0771デフォルトの名無しさん
垢版 |
2019/09/15(日) 11:24:36.57ID:VKeDSGtj
>>770
よほど特殊な機能を持ってるなら別だけど単なる検索機能だけならコード量もたいしたことないだろうから俺なら別々にしておくと思う
0773デフォルトの名無しさん
垢版 |
2019/09/15(日) 12:48:53.00ID:lkQ+SOXM
簡単な名前でいいならBinaryDataSearcher
Dataみたいな語は情報量が少ないから削られがちだけど、この位置のDataを無造作に省略すると修飾先が変わっておかしなことになる
もう少し真面目に考えると、バイナリかテキストかという初歩的な分類用語よりも、エンディアンとか解釈した結果のバイトストリームを扱ってるならそういう名前の方が適切
ほかには多少語弊が生じるけど、お好みでProcessとかProgramとかExecutableあたりの語を使ってもいいかも
0774デフォルトの名無しさん
垢版 |
2019/09/15(日) 13:13:26.96ID:WGDoaeaE
>>770
要するに、

(1) ストリームの中から
(2) 指定されたバイト列に完全一致する場所を探す

ってことね。部分一致とか、パターンマッチと、CRC的な符号が一致するとか、そういうのじゃないわけだ。

じゃあ「バイト列の探し屋」か？
ByteSequenceFinderとかByteArraySeeker みたいな感じ？
0775デフォルトの名無しさん
垢版 |
2019/09/15(日) 14:39:03.93ID:1CTIlTlw
Cで言えばstrstrのバイナリ版GNU拡張のmemmemだよね。
ファイルが対象だとしてもmmapすれば同じだし。
0776デフォルトの名無しさん
垢版 |
2019/09/15(日) 15:50:14.45ID:WGDoaeaE
もっと単純BytesFinderでもよかったか
0777デフォルトの名無しさん
垢版 |
2019/09/15(日) 16:44:36.00ID:PqHAhyXf
そこまで抽象化するなら検索アルゴリズムの実装になるから検索アルゴリズムの名前でいいんじゃ
0778デフォルトの名無しさん
垢版 |
2019/09/16(月) 08:48:03.32ID:f/9IJK5V
ありがとう

そう、完全一致だけで部分とかパターンとかは無し
この流れをヒントにして考えてみるよ

ありがとう
0779デフォルトの名無しさん
垢版 |
2019/10/21(月) 11:26:02.37ID:cJ8/Rgj7
テキスト検索で、検索ボックスに入力する文字列と検索対象の文字列(本文)はどう名付けるのが無難ですか？
0780デフォルトの名無しさん
垢版 |
2019/10/21(月) 12:13:57.58ID:VNGEIVP2
>>779
前者はkeyword？
後者は置かれる文脈次第だろうね。シンプルにtextで通じるならそれでいいと思う

他の候補は
target, targetText, scannedText, searchee

ググってみたがsearcheeって言葉は正式な英語じゃない（当たり前か）
でも意味は分かると思う
0781デフォルトの名無しさん
垢版 |
2019/10/21(月) 13:48:15.35ID:qqa/WroJ
box, search という単語を変数名に入れた方がいいと思う
同じような変数が何種類か出てくることになると思うので
0783デフォルトの名無しさん
垢版 |
2019/10/21(月) 15:02:23.84ID:coWSyVCC
検索文字列はsearchStringがよく使われる印象
boxみたいにUIの形状に基づく変数名は本当にそれが妥当なのかよく考えてから付けたい
0785デフォルトの名無しさん
垢版 |
2019/10/21(月) 17:44:13.34ID:cifrZUYa
UI要素につける名前なのか
UIから受け取った検索文字列と検索対象文字列を一時的に格納するローカル変数につける名前なのか
それを渡す検索メソッドの引数につける名前なのか

コンテキストによって適切な名前は変わってくるから
それを共有しないと時間の無駄
0787デフォルトの名無しさん
垢版 |
2019/10/21(月) 21:00:10.44ID:VNGEIVP2
普通に考えれば>>779の人が検索ボックスと言ってるのは
その方が話が早いからでUI要素の名前を聞いてるわけではないと思うよ

英語のkeywordに相当する日本語って意外とないから。
検索文字列とか言っても見つけ出したい文字列じゃなくてスキャンされる方の
文字列を指してると誤解される可能性がある。
0788デフォルトの名無しさん
垢版 |
2019/11/13(水) 09:16:45.77ID:JAuzgMXK
例えば、Twitterのツイートがあります。ツイートが他のツイートへの返信の場合、
どのツイートへの返信かを表すIN_REPLAY_TO_TWEET_IDみたいのがあります。
で、この逆の関係を表現したいのです。
あるツイートがあって、このツイートへ返信してるツイートのIDsを表す場合
なんて名前がいいでしょうか？
0792デフォルトの名無しさん
垢版 |
2019/11/13(水) 11:20:16.90ID:ZW56FeJ7
連投すまん
上2レスをまとめて書いたらNGワードで蹴られたから分けてみたら通った
ERROR: Rock54: Warning:NG〜ってやつ
何じゃそら
0795デフォルトの名無しさん
垢版 |
2019/11/13(水) 15:07:27.24ID:dfS9RQP/
>>789で終わってたw
逆にこれ以外に何があるんだw

ついでに、IN_REPLAY_TO_TWEET_IDなんて意味不明だから
素直にparentとかした方がいいんじゃないの？
0796デフォルトの名無しさん
垢版 |
2019/11/13(水) 17:41:41.87ID:JAuzgMXK
in reply to tweet id は返信先のツイートのIDって意味じゃないですかね？確かTwitterAPI のJSONはこういう名前のフィールド持ってたから外人の人が命名しただろうから、盲目的に信じてたが、おかしいのか？
0797デフォルトの名無しさん
垢版 |
2019/11/13(水) 17:45:10.84ID:JAuzgMXK
Tweetクラスに、InReplyToプロパティとRepliesプロパティ追加しとげばいいか。どっちがどっちになりそうだけど仕方ないのか
0798デフォルトの名無しさん
垢版 |
2019/11/13(水) 17:47:41.19ID:Imemf4ry
in_reply_to_tweet_idってのはTwitter APIの仕様だから変えるのはいささか難しいだろうな
リプライオブジェクトを格納するrepliesと、リプライIDだけを格納するreplyIDsを名前で区別したい場合はある
名前に対称性を持たせるならreply_tweet_ids
0800デフォルトの名無しさん
垢版 |
2019/11/13(水) 18:03:10.32ID:JAuzgMXK
>>795のparentというアイデアを借りて、
単にParentとChildren。これじゃ何の親子関係か分かりづらい?のでReplyParentとReplyChildrenじゃくどい？

で最後InReplyToとReplies

皆さんはどれがお好みでしょうか？
0801デフォルトの名無しさん
垢版 |
2019/11/14(木) 00:23:50.76ID:Nc6xtndT
特定のツイートとリプライは1対Nの参照関係だけど親子関係ではないし
ドメイン用語にParentやChildは無いのでそういうのは入れないほうがベター
InReplyToとRepliesがいい
0802デフォルトの名無しさん
垢版 |
2019/11/14(木) 00:29:00.53ID:HNBp407z
いやいやいやw
フツーにツリー構造だからw
0804デフォルトの名無しさん
垢版 |
2019/11/14(木) 11:24:59.93ID:xkNbqoiZ
循環てw
明日書かれるツイートに今日返信できるのかwww
0805デフォルトの名無しさん
垢版 |
2019/11/14(木) 11:28:27.61ID:xkNbqoiZ
ついでに言うと、論理的には木構造は循環する可能性を必ずしも排除しないはず。
ツイートは循環なんかしないけどね
0806デフォルトの名無しさん
垢版 |
2019/11/14(木) 13:15:57.33ID:Nc6xtndT
>>802
ツイートとツイートの関係(=relationship)の話と
それをプログラムで扱う際にどういうデータ構造で表現するのかという話はレイヤーが違う
親子関係じゃないということとツリー構造で扱うということは両立しうる話

特定のデータ構造で扱うことを前提とした命名をすべき状況で
ツリー構造に依存した名前にしたければそうすればいい
0808デフォルトの名無しさん
垢版 |
2019/11/14(木) 18:48:28.45ID:VHDeJvx8
ツリー構造であるかどうかを議論してもしょうがないと思うぞ
ツリーの関係性を有するデータの名前に漏れなくChildrenをつけるべきか？
これは常には成立しないよな

ツリー以前に、単なる1:Nの親子関係を有するデータにも同じことがいえる
雇用関係ならEmployerとEmployeesが妥当であって、EmploymentParentとEmploymentChildrenという命名は拙い
0809デフォルトの名無しさん
垢版 |
2019/11/14(木) 22:24:40.93ID:DMlczWCC
>>806
なるほど、では君はファイルシステムで上位のディレクトリのことを親って言わないんだねきっと。
どういう問題領域のどういう対象であろうと、それが木構造にみなせる以上、親は親だ。
普通はそう考えると思うけど
0810デフォルトの名無しさん
垢版 |
2019/11/15(金) 00:27:23.00ID:SWgp43Jk
「金槌しか道具を持っていない人は、何もかも釘であるかのように取り扱う」by マズロー
0811デフォルトの名無しさん
垢版 |
2019/11/15(金) 00:33:09.85ID:WAwhq9DE
>>809
ふつうじゃねえよ。異常。
独立したものの参照関係がツリーのように見えているだけで、本質的には親子関係が成立するツリーじゃないぞ。
0812デフォルトの名無しさん
垢版 |
2019/11/15(金) 00:49:32.81ID:ZDqxsHuV
>>811
それは君がツリーっていう言葉の語感に影響されているだけ。
だからUIみたいに「見える化」されているものだけを指すと勘違いしてるんだろう。
抽象的な思考が苦手なタイプによくある勘違いだ。

木構造は単に論理的な関係を表現しているだけだ。
っていうか自分でツイートとそれに対するリプの関係を図示してみろって。
それ、ツリーそのものだろアホか。

っていうかだから、直上のディレクトリを親と言うのか言わないのか、答えてみろって。
頭悪いにも程があるよほんと
0813デフォルトの名無しさん
垢版 |
2019/11/15(金) 00:58:36.52ID:ZDqxsHuV
>>810
こいつも何か言ってるつもりなんだろうけど馬鹿だよねw
悪いけど「バカの一つ覚え」なのはそっちの方だ。

何もそれを表現するより具体的な表現や用語があるのなら
木構造だの親だの、そんな抽象的な言葉を使つ必要なんかない。

ディレクトリの例もそうだが、それがないから「親」と呼べばいいじゃないかと言ってる。
なのにこの手の御仁は「もっと具体的な言葉を使うべきだ！！！」というバカの一つ覚え。
笑えるね
0814デフォルトの名無しさん
垢版 |
2019/11/15(金) 00:59:46.30ID:E8ESC8td
本件はツリーだけど親子関係ではない
ディレクトリではなくメールボックスをツリー表示したようなものだから、
返信メールを子とは言わないしレス元のメールを親とは言わないけどツリーではあると


と横からレス
0815デフォルトの名無しさん
垢版 |
2019/11/15(金) 01:03:57.08ID:ZDqxsHuV
>>814
論理的な関係を表現していると言ってるそばからこれだ。
何を言ってるのか意味が分からないよ。
0817デフォルトの名無しさん
垢版 |
2019/11/15(金) 01:10:06.03ID:ZDqxsHuV
はいはい得意の精神勝利法ね。
0818デフォルトの名無しさん
垢版 |
2019/11/15(金) 01:18:47.48ID:E8ESC8td
いやいや、全てにおいてあなたの大勝利で結構ですよ
その他の犬共に侮蔑の言葉を投げつけてくださいﾜﾝﾜﾝ
0819デフォルトの名無しさん
垢版 |
2019/11/15(金) 01:20:02.90ID:ZDqxsHuV
しかし、ツイートとリプの関係を図示するってそんな難しいか？w
10歳ぐらいの子供でも図示なんかしなくても頭の中で描けると思うけど。

それ以前に親が変だと思うならもっとふさわしい表現を出せばいいのに。
ここそういうスレでしょ。

少なくともin reply toじゃ「に対する返信」で、意味不明は言い過ぎとしても
分かりやすいとは言えないよね。
0820デフォルトの名無しさん
垢版 |
2019/11/15(金) 01:25:04.80ID:SY/YBOOW
見た感じメインは罵倒みたいだし議論する気には見えないな
おっとﾜﾝﾜﾝﾜﾝﾜﾝww
0821デフォルトの名無しさん
垢版 |
2019/11/15(金) 09:05:44.13ID:MDhJ3LYt
>>813
具体的な表現がないって、InReplyToとRepliesというまさに具体的な回答が出てるだろ
その回答を論理的に否定しないと皆は納得しない
お前がなんで不満なのかはわかるよ
英語ネイティブであるAPI設計者の名付けに対して
> IN_REPLAY_TO_TWEET_IDなんて意味不明だから
なんて赤っ恥なツッコミをしてしまったから引っ込みがつかなくなったんだろ？
でももういいだろ
間違えることもある
そこからどう行動するかが大事なんじゃないのか
0822デフォルトの名無しさん
垢版 |
2019/11/15(金) 09:21:07.06ID:MDhJ3LYt
>>819
言えないよね、っていうのは感覚だよね
女子っぽく同意を求めてもそれなと答えてくれるのは仲のいい子だけ
最終的に感覚に頼るしかないなら、自分の感覚と他人の感覚を同じように尊重することだ

しかし周囲が全員、低い英語力のコーダーしかいない環境ではChildrenの方が通りがいいケースはあるだろうな
0824デフォルトの名無しさん
垢版 |
2019/11/15(金) 13:26:17.06ID:SWgp43Jk
>>815
そうそう、1対Nになる論理的な関係はすべて木構造ですよねw
論理的な関係で言えばデスヨね

「論理的」とは何か「関係」とは何か
それすら理解できてないバカには何を言っても無駄ですよw

図示してツリーになるやつは全部Parent/Childrenですもんね
抽象的思考が苦手なバカwはこんな簡単なことも理解できないんですかね？

「バカの一つ覚え」とはよく言ったもんですねw
0829デフォルトの名無しさん
垢版 |
2019/11/15(金) 14:26:50.12ID:E8ESC8td
>>815
君が論理的にっていいながらディレクトリ構造を持ちだして親子親子言ってるから、
メールボックスのツリー構造を例に出してこれは親子とは言わないよなってツッコんだら
意味が分からないとかもっとふさわしい条件とか、君こそ馬鹿の一つ覚えの
主張しかせず全くツッコミ内容に触れずに相手を馬鹿にすることに全力賭けてるもんだから、
ﾜﾝﾜﾝとしか言えないなって話になる
0830デフォルトの名無しさん
垢版 |
2019/11/15(金) 19:57:05.56ID:3X1+zKuD
有向グラフなのか無向グラフなのか
順序関係なのか半順序関係なのか
この辺で親子という表現を使うかどうかが決まる
0831デフォルトの名無しさん
垢版 |
2019/11/15(金) 20:09:51.51ID:SY/YBOOW
この件が親子関係になるんなら、この一連のレスバにも親子関係があることになるが
ちょっと意味が分かりませんね
0833デフォルトの名無しさん
垢版 |
2019/11/15(金) 21:14:16.66ID:/dDy1LQy
各ノード
親は高々１人
子はゼロ人以上
ループはない

グラフでいうと
親から子への有向単純グラフ
全ての点は、それに向かう辺が1個以下
閉路は含まない

連結の条件は不要かな
0838デフォルトの名無しさん
垢版 |
2019/11/16(土) 13:01:11.14ID:7BT2jGOo
皮肉って言葉の意味わかってんのかコイツ
自分が議論に窮した時に使う言い訳じゃねえんだぞ
0841デフォルトの名無しさん
垢版 |
2019/11/22(金) 12:27:14.39ID:Da5ctjWB
>>829
メールボックスのツリー構造も親子というと思うけど

なぜディレクトリは親子で、メールボックスは親子ではないの？
構造はどちらも同じだろ
0842デフォルトの名無しさん
垢版 |
2019/11/22(金) 13:26:05.71ID:vT5VBrvl
>>841
俺の親はお前なの？
俺が>>829にも安価付けてレスしたら兄弟にもなるの？
ディレクトリ構造とは全く違うわな
0843デフォルトの名無しさん
垢版 |
2019/11/22(金) 14:43:50.50ID:o7w4L720
>>842
安価もツリーと見なしたら、親子関係にあるとも言えるでしょ
見方によって変わるものを、一面だけ見て決めつけるのも違うと思うんだがな
0845デフォルトの名無しさん
垢版 |
2019/11/23(土) 08:14:27.92ID:lHF5Ppzy
メール
　送信者→親
　受信者→子
　　受信者が送信者に返信
　　　元の送信者→親であり子になる
　　　受信者も→親であり子になる

だからおかしくね？って話だと思ってた
0846デフォルトの名無しさん
垢版 |
2019/11/24(日) 01:47:32.93ID:1sgprDiI
別にコードを書くにおいてメールを親子関係としてネーミングするのは自由にしたらいいと思うけど、

送信者X→相手A,B,C
A返信→X
B返信→X,A,C

この組み合わせが変わったりして続くとか普通にあるから、親子関係に当てはめられても人間から見て分かりやすいか？って話
元レスのtwitterの件も同じカテゴリ
もちろん親子関係が成立するメールもあるけど、必ずしもそうならないって話

なのでディレクトリとは明確に違う（ハードリンク云々はおいといて）
0847デフォルトの名無しさん
垢版 |
2019/11/24(日) 02:22:47.27ID:Ak7CJVWZ
まだこの話してるのか
いやメールのスレッドが親子じゃないという例は微妙かなと思ったよ
でも蒸し返してもいいことないぞ
結局スレの趣旨的にはメールの返信元にあたる変数をParentと名付けるのが妥当かどうかという話になる
どう考えてもReplyToだろ
RFCで定められたスタンダードにはかなわんということでFA
もうこの話は勘弁
0849デフォルトの名無しさん
垢版 |
2019/11/24(日) 23:02:32.23ID:wqMWqGYC
何の用語に採用されてようと意味が通じれば別にいいんだけど、
in reply to ってたぶん副詞句なんだよね。

まあそういう不細工さには目をつぶるとしても、
InReplyToっていうメンバー変数を持つクラスのインスタンスがあるとして、
InReplyToのtoがInReplyTo自身に掛かるのか、それともそれを内包する
インスタンスの方に掛かるのか、自明じゃないように感じるよね

parentならこういう曖昧さの問題は存在しない
0850デフォルトの名無しさん
垢版 |
2019/11/24(日) 23:22:59.50ID:ajYX9vGJ
>>849
前置詞句は使い方次第で副詞句にも形容詞句にもなる
中学校で習わなかった？

A tweet in reply to the tweet
Tweetクラス/構造体のInReplyToで保持してるTweet IDがどれを指してるのか誤解のしようがない
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況