クラス名・変数名に迷ったら書き込むスレ。Part28 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
クラス名、変数名のつけ方に悩んだら書き込むスレです。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
前スレ
クラス名・変数名に迷ったら書き込むスレ。Part27
http://echo.2ch.net/test/read.cgi/tech/1476572490/ あーなるほど
n回ってのをそのまま名前にしちゃうという手があったか
いちいち特定回数みたいな日本語に直して考えてたわ Goldfish.AzureGoldfishIsMany() //アジュール色の金魚が多いときに真
のように、形容詞 + クラス名と同じ名詞 + is + 形容詞 という命名の関数があったとして
クラスと関数でGoldfishがダブってるわけだけどどうしてる?
たとえば関数名のほうを消して Goldfish.AzureIsMany() にできるか?みたいな AzureColorIsManyじゃダメなん?
あと多いってのがアバウトじゃね?いいの? このダブってしまうケースに合うとしばらく思考停止してしまう このケースだからそう思うのかもしれないけど、
IsManyを判定できる関数がこのクラスに居るのが違和感
Goldfishの集まりを持っているクラスが他にあって(水槽とか)
FishTank.ContainsManyAzureGoldfishes()
みたいな感じで定義したい
Goldfishクラスには
Goldfish.IsAzure()
関数があればよいはず
まあ単に X.IsAandB() みたいな命名でよいケースもあるような気もする
>>650
「多い」の実装がどうであるかは呼び出し側は気にしたくないんだろう多分 金魚が「Goldfish」なことに違和感。w
直訳?
誰や、んな訳語をつくったんは! >>650
まあ既に指摘されてるけど、集まりを評価する関数を要素のクラスに持たせるのが
そもそも変だねw
何か事情があるにしても、HasManyAzureとかIsRateOfAzureHighでいいんじゃないか。
むしろいちいちGoldfishと断る意味が分からん >>653
なるほど、同じ文意になる文章がないかと考えてみるのは良さそう
>>651>>655
形容詞(この場合はAzure)に対してmanyと言って良いのか悩んだんだ
多いのはあくまでも金魚の方だから >>656
azureは他の色と同様名詞の用法もあるみたいだよ
辞書的には不可算名詞みたいだけど、たぶん他の色と同じように場合によってはs付けても大丈夫だと思う Dataを継承して値の変更を検出できるようにしたDataのクラス名 >>658
変更検出の方法に基づいて考えたい気がする。
変更時に通知が出るなら >659 とかでいいけど、原本を控えておいて比較によって検出するような形だとまた違ってきそう。 >>660
検出するのがオブジェクト自身なら、その方法をクラス名に含めないほうがええやろ。
実装の詳細はできるだけ隠すべき。
>>661
それは、Dataオブジェクトの外側の何かやろ。 変更を検知する方法を外部に提供するのか
自分で検出して自分でなにかするのかによって違うわな DetectableなDataをChangeするになってしまわないか? そもそも値の違いを検出できるクラスを作ること自体が設計としてまずいんじゃねえの そこの議論は一応スレチなので…
Angular詳しくないけどこういう枠組みはあるもよう
https://qiita.com/lacolaco/items/523d96ddbfe55c4e6949
で、実質は Change-Detectable な Data かも知れないけど、
周りからは DataChangeDetector とでも呼ばれるべきという考え方はあるかもしれない もう素直に DataWithChangeDetect でよくね? それならDataWithChangeDetectionかな
スレチで我慢してたけどDataとChangeDetectorを同じクラスにするのは微妙だから、名前にWithとか入って微妙感が出るのは自然な成り行きと思う
>>665
changeには名詞と動詞があるからそうも読めるけど、change detectionという一般名詞があるから誤読されにくい
クラス名が現れるべき文脈でメソッド名と間違われることなんて実際少ないから、混同への配慮よりも俺なら英語として自然であることを選ぶ 質問者もやる気なさそうだから真面目に考えるだけ無駄だと思うよw
だいたい、こんな命名をそのクラスが必要になる背景も、
「検出」の具体的な意味も示さずにやれとか言う時点で何をかでしょ 普通の実装ならDetectableを継承したDataになるはず 普通ではないね
むしろ勘違いオブジェクト指向っぽいw
その多態、本当に必要か?
いらないでしょw 全ての品番と型式が対になったリスト
型はC#のDataTableです >>673
品番はキーだろうから普通にModelsとかModelNumberとかでいいんじゃね >>672
モデルビュー的なことをするならそんなにおかしくもない。
「多態」が目的じゃないから。 >>675
どう考えても多態そのものだと思うけど、
それはともかく特殊な条件付けたら何でも正当化できるよw
もとの質問にそんな条件なんか付いてないのは自明でしょ >>671-672はイチャモンつけたいだけだからスルーでいいよ
そのために
> 命名規則や設計の善し悪しについて議論するのは基本的に禁止。
の注記あるんだし >>677
これもういうの何度目?
この手の馬鹿は自分もそのお仲間である自覚が皆無のおめでたい馬鹿 ついでに言えば、こんな過疎ってるスレ(もう今ではこの板の大半のスレがそうだが)で
「スレ違いガー」なんてそれこそ言い掛かりでほとんど無意味。
お前こそ他人にイチャモン付けたいだけだろ馬鹿w
今時2chにいるなんてもういい歳こいてるんだろうから、もうちょっと合理的かつ柔軟に考えたらどうなのかね
派生的な話題を許容しても誰も困らないだろう。 混乱の元
そんなに気に入らないならまずは次スレを立てる時にテンプレから外しな 新参か?
実際に設計の善し悪し含めた話OKの命名スレが立っても、そのスレは全く活用できなかったという
実績が確実に残ってるのよね
そこんとこ分からない程度のオツムなら、設計の善し悪しなんか話すオツムなんか当然ないんだからやめとけ そりゃ名前聞きたいだけなのに生半可な知識の奴に設計ガーとか言われても困るだけ
バカな言い合いで賑わうぐらいなら過疎ってた方がまだマシだよ >>682
意味が分からない。
自分で自分が何をっているのか理解しているのか
>>683
こういう馬鹿、言ってる傍から自分で自分の言ってることに矛盾してる自覚もないのな。 他人をバカにしたいだけのヤツは、天に召されていただきたいものだ。 >>672みたいなレスは
- 誰かの参考になる可能性がある
- 2chの現状を考えれば誰の迷惑にもならない
のに対して>>677みたいのは
- 誰の役にもたなない
- それどころか一部の人間の気分とスレッドの雰囲気を悪くする
どちらが悪質で罪深いか言うまでもない。
毎度のことだけど、2chに限らずネットではこの程度のことに考えも及ばないバカに限って
本人は自分が正しいと思い込んでる
なぜならこういう馬鹿は内省的になるのが怖くて仕方がなく、
内省的な自分を抑圧する手段の一つとして他人に言い掛かりをつけている自分に無自覚だからだ そんでこれが一番重要なことだが、このスレのテンプレにもあるような
ローカルルールは、結局その手の馬鹿に体のいい言い訳を与えているだけ。
「他人を批判したい」という卑しいだけの動機を抑圧して「正しいこと」に変える欺瞞のね こーゆーのずっと繰り返してpart28なのよ
んでご希望の設計込みのスレ立てて分離したけど、そっちに居着かないのよ
言い出しっぺもね
どうしても納得いかないならもう一回スレ立てたら?
このスレのルールを変えようとすることだけが目的の馬鹿がまた来たなあとしか思わんね
どうせまた消えるに1億ペリカ >>687
> - 誰かの参考になる可能性がある
ない。
他人のやりかたを「勘違いオブジェクト指向」呼ばわりするようなクソ発言が参考になんかなるか。
> - 2chの現状を考えれば誰の迷惑にもならない
実際に迷惑なんだよ! >>687
> 本人は自分が正しいと思い込んでる
ブーメランすぎるw >>682
(どうせ使われないだろうけど)って皮肉がわからん新参か? >どうせ使われないだろうけど
スレ内ヒット>>692
>どうせ
スレ内ヒット>>488>>689>692
>使われない
スレ内ヒット>>102>>103>>692
>だろうけど
スレ内ヒット>>375>>574>>692
どの言葉も話の流れにヒットしないんで>>692が創造主になってるんだが
皮肉の元が真面目に分からん 混乱の元
そんなに気に入らないならまずは次スレを立てる時にテンプレから外しな(どうせ使われないだろうけど) 1つだけ有効な値が入っていてそれ以外は0になる配列ってなんて命名すればいいだろうか?
例えば、
{0, 0, 1, 0, 0, 0, 0} これはOK
{0, 0, 0, 0, 0, 0, 1} これもOK
{0, 0, 0, 1, 1, 0, 0} これはNG それがナニを意味するか、それを名前に入れないと意味ないのでは?
それがナニを意味するかはあんた以外誰も分からないのでは? >>695
array_valid_only1
それっぽい単語を並べるしかないのでは? 既に有効が1つある状態で別の場所が有効になるケースはあるの?
{0, 0, 1, 0, 0, 0, 0} これが
{0, 1, 0, 0, 0, 0, 0} これになるケース
それとも最初はゼロフィルで1度有効の場所が決まれば不変? 「1つだけ有効な値がある配列」ではなく
「ある処理に対して有効な配列」という方向での命名はどう? >>695
論理回路がらみでone-hotっていう用語があるよ。ググって。 意味ないってそんなの
定数1に名前を付けろと言ってるのと同じだから
だから、1がナニを意味するのか分かんなきゃ名前なんか付けようがないだろうにw 具体的な用途がないと型に名前を付けられないというのも乱暴な話だな
QueueやTupleのような単純なデータ構造だってそれが役に立つなら型と名前が与えられるべき
そういう場合、用途は変数名が表せば充分 この人、QueueやTupleって名前が何の意味も表してないと思ってるのかな 表してるに決まってるだろ
逆に聞くが質問者がいう配列は何も表してないと思うのか? だから何でそうなるのw
何かを表しているはずだと思ってるからそれを言ってくださいと言ってるんでしょw
もう大丈夫かマジw だからね、「一週間の日数を表す定数の名前を付けてくれ」って質問はありだけど、
何を意味してるのか伏せたまま「定数7に名前を付けてくれ」って質問に意味があるとか
思うわけ?
あるわけないじゃんww 少なくとも、あれは、one-hot encoding という立派な名前のついた状態表現方法。
ただの数字と一緒にするのは無知。 特定の問題を解く上で便利なデータ構造があるなら、それが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()みたいなメソッド追加すればいいんじゃね? ■ このスレッドは過去ログ倉庫に格納されています