クラス名・変数名に迷ったら書き込むスレ。Part28 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
クラス名、変数名のつけ方に悩んだら書き込むスレです。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
前スレ
クラス名・変数名に迷ったら書き込むスレ。Part27
http://echo.2ch.net/test/read.cgi/tech/1476572490/ 無関係スレ
設計・命名スレ
http://echo.2ch.net/test/read.cgi/tech/1477368563/
設計から喧々諤々されたい殿方は別スレがございますので、そちらをご利用ください。 データベース的なものを想像して欲しい。
あるデータ群(オブジェクトの配列)を画面出力するとき、出力イベントをフックして
・「表示/非表示」を切り替える(単純にreturn falseだけで済むような処理ではない)
・「見た目」を切り替える(色変更や予め用意した画像に変更など)
の2つが必要なとき、それぞれどんな単語を使えばいい?
紛らわしくなく、かつ統一感のある関数名にしたい。
上記2つは呼び出すタイミングが微妙に異なるため、一括にはしにくい。
また、出力を切り替えると言っても、実際には個々のオブジェクトに含まれている値やメンバ変数を読み込み、
その設定を適用させるといった内容になる。 ありがとう、それでいく
出社前にスレ確認できてよかった 通信やファイルへ書込を伴う処理で
一旦変数に代入(書き込み予約)してから、任意のタイミングで確定させて処理したい
確定処理ってupdate? apply? commit? finalize? save?
それとこの場合の代入ってsetでいい? stageとcommitかな
でもwriteやsendといった実際の物理的な動作をイメージさせる名前を差し置いてまで強調するようなことだとは俺は思わないけどな
抽象的な名前は基本的に糞 ReserveFoo()とかが並ぶのか
代入の接頭詞はset、みたいなイメージあると代入にしろ確定にしろ結構離れる感じね
>>10
一応、write()と同じくらいのレベルでsave()を想定してた >>7
その言語でよく使われているORマッパーとか参考にすると
他の人にも理解してもらえそう setかどうかはmodelかviewかによるかな
modelならset >>7
BufferedFile f;
f.write(data);
f.flush();
BufferedConnection c;
c.write(data); // or c.send(data)
c.flush(); Series を列挙する型と、それを格納する変数。
C# だと
enum Series {
A,
B
}
Series Series;
とできなくはないけど、別にしたい。
たいていは列挙の方を複数、変数を単数にするんだけど、複数と単数で変化がないものはどうしたもんか。 >>15
靴に足を合わせた方がいいと思うよ
型名と変数名が同じだと気持ち悪いという感覚が時代遅れだから、
名前を小細工するより自分の感覚を修正した方がいいんじゃないかしら >>15
型名は大文字から、変数名は小文字から始めればよい 1年後に1画面に入らないくらいまで広がっててsってなんだっけー んー、時代遅れか。
C# の例は挙げたけど、できない言語の場合にどうしようかってのもあったんだがな。
大文字小文字の場合も。
これといった案はなさそうだね。
いろいろ意見ありがとう。 >>21
> できない言語の場合にどうしようかってのもあったんだがな。
> 大文字小文字の場合も。
enum SeruesOption {A, B}
SeriesOption series = A 最初の質問で「できなくはないけど」と言いつつ
「できない言語の場合」って追記するの、ちょっとずるくない? >>23
やり取りを円滑にするために最初に忘れず言おうな、とは思う。
が、ズルくはないだろ。
それで質問者が何か得したわけでもないし、
君が何か論破された訳でもないんだから。 まあできない言語なら >>16 みたいな回答はないから初めから書いとけ
って言うのは正しいと思う
でももう終わった話だしいちいち蒸し返す意味ない 言語に関わらず共通のスタイルを使うという発想自体がそもそもの大間違い
郷に入れば郷に従え
C#では型名とプロパティ名に同じ名前を付けることが推奨されていてenumにXXEnumみたいなのは禁止されている
他の言語には違ったルールがある、それに従うだけ
その良し悪しを判断するのはお前でもこのスレでもない あとC#ならenumの型名にs付けていいのはビットフラグの場合だけだ 型の名前は型自身じゃなくてインスタンスの性質を表しているべきだって
発想かもしれんけど、拡張メソッドの入れ物の静的クラスにExtensionsなんてのもあったりして
ちょっと統一感ないね >>29
インスタンスの性質は分かるけど、型自身の名前って例えばどんなの?
Extensions だって性質を表してるんじゃない?
詳しく表してるとは言い難いけど。 The name of a type should express the charactor of not a type itself, but the instance 確かに、やや低レベルな名前って気はするかな
具体的にどうすればいいかは分からんけど 現時点ではスレチだけど、いずれ設定周りの名称に出没しそうなのでご容赦ください。
スタンドアロンのシステムが既に稼働していますが、一部機能をクラウド化して併用する計画があります。
クラウド化してもスタンドアロンの方もそのまま運用を続けます。
いわゆる半クラウド?とでも言うのでしょうか、このようなシステムの場合、
何と呼べばいいでしょうか? >>34
ありがとうございます。
色々調べましたが、ハイブリッドクラウドとは
パブリッククラウドとプライベートクラウドなどの複数のインフラ周りを
組み合わせた場合に呼ぶようです。
サーバーデータの保全や負荷分散という説明も見ると、
今回のケースに該当するのかというと、う〜ん。。。 単項検証: SingleFieldValidation
相関検証: MultiFieldsValidation
データベースで行と行を比較する検証や表を超えて検証する場合はなんと言いますか?
日本語と英語の両方ともわからない >>36
相関 correlated
行 row または record
表 table ちょっと物事を単純化して話しますが
オブジェクトの有効期間を変数として持たせたいんです
リストの中にぶっこんでいって
リストを触る奴がその値によってリストから削除したりをさせたい
このとき、有効期限をどう表現しますか?
色々考えた結果
long lifetime = now + duration;
と初期化しておいて
if (obj.lifetime < now) list.remove(obj);
というふにしました
もっと名前、初期化、運用に他のやり方があったかなと心配しています
名前は単にtime_to_removeでもよかったかなと思ってます >>38
有効期限が本当にそのオブジェクトが管理すべき情報なのか、それともそのオブジェクトを使う側が
管理すべき情報なのか、それだけじゃ分からんけど、前者だとして
CreationTime(作られた時)
LifeSpan(寿命)
TimeToLive(余命 CreationTime + LIfeSpan - now)
IsAlive(TimeToLive > 0)
こんだけの情報を持たせた方が扱いやすいかも >>39 ありがとうございます見てみます
>>40 expireは既に別のとこで使っておりまして
>>41 もう少し正確にお話すると
class WithLifetime<T> {
public final T org;
public final long lifetime;
WithLifetime(T org, long duration) {
this.org = org;this.lifetime = System.currentTimeMillis() + duration;
}
}
こういうのを
list.add(new WithLifetime<Foo>(foo, TimeUnit.HOURS.toMillis(5)));
こう使ってますね
あくまでlistありきで
list中の生存期間を、listを使う側の都合で勝手に決めてるという
List<Foo> listのままで、Map<Foo, Long> lifetimeみたいなのを併用
っていうのも最初は考えたりもしたんですが、それでいくと
list0, map0, list1, map1, list2, map2みたいな煩雑さがチラついてきますんで
この形式にしました >>42
そのlistを拡張した方がいいんじゃないの
管理対象のobjectは何も知らない方がいい
listを使う側も同期とか以外は知らなくていいくらいに
そしたら汎用でも使える >>43
ありがとうございます
とても有力な手だと思います
ただ、みなさんも覚えがあるかもしれませんが
こういうコンテナラッパーを気軽に書いても
意外とスッキリしていかねえな、ということです
1) 最初から十分なインタフェースをそろえるのはめんどい(主に指の疲労)
2) だから最初はsize, add, removeくらいで始めるのだが
あとで結局また加筆していくことになる
3) コンテナクラスの理想は中身を知らないこと
でもこういう作りにするとそこに想定が入ることになる
だからと言ってすぐ困りはしないが、そのことに小さい不満が残る
removeExpired()みたいなこともさせたいが、何か不満が残る
それに引数を与えてやりたいが、ここでその引数の名前が難しすぎる
何をどういう基準でremoveしてるかを表現しきるメソッド名も難しい
最後までぐだぐだ申しましてすみません
不満ばかりできりが無いのでこれにて閉じさせてくだしあ >>44
remove_if(predicate) >>45
もしくはその知恵がないかやりたくない理由があるんだろ
>>44の文章見るとなにか異様にこだわりあるみたいだし 俺は同じような状況でexpires_onにしたことがある Optionsみたいに複数形ってクラス名には不適切?
OptionBagか
OptionsBagにすべき? >>49
別に複数形でもいいと思うけど、規約か何かで使えないなら
「諸設定」っぽニュアンスがあるようなないような気がするconfigurationにするとか OptionSetとかOptionListでいいんでない >>52
言語によってはデータ型としてSetやListが用意されていて、その場合はそれらの性質を持っていないのに
そういう名前を付けるのは望ましくない。 listはともかく、setはちょっときついだろ。
意味が多すぎる。 逆でしょw
>>49が言ってるようなクラスは普通に考えたら
雑多な(型も意味もバラバラの)optionの寄せ集めなんだろうから
あえて何かつけるならsetの方がニュアンス的に近い >>49
そんな再利用性のないもんをクラスにすんな(直球)
汎用的なクラスをつくっといて、
変数名でもって特殊化して運用セヨ Optionの単数形でも別にいいと思うけどね
各オプションには具体名があるだろうし
責務によってはOptionManager/OptionHandler/OptionContainerみたいなer系も有り
オプションバッグ、オプションセット、オプションリストとかは普段からそういう名前で呼んでも問題ないかどうかに依る
あとは汎用コレクションクラスを使ってList<Option>みたいな選択肢も >>58
> List<Option>みたいな選択肢も
だいたい後悔するんじゃね?
ただし、拡張メソッドがあるC#ならなんとか。 javaはPropertiesクラスがあるから複数でもいい気が ある値と、それに掛け合わされる係数fooがあります。
元の値が500、fooが30だとすると、500の30%アップで650といった具合です。
このとき以下の関数名をお願いします。
(a)そのまま30を返す
(b)0.3を返す(30%→0.3なので)
(c)130を返す(元の値を130%する)
(d)1.3を返す(元の値に1.3をかける)
関数を1つにまとめて、フラグなり呼び出し元で計算するなりしろよ思わないでもないですが、
名前変更以外の修正を伴うので避けたいところ。
ちなみに既存のコードはGetFoo1()、GetFoo2()…という命名になっているので
ちょっとキレそうです。 >61に追記です。
圧倒的に使用頻度が高いのは(a)の「そのままの値を返す」でした。
ほかは同じくらい、 >>61
> (c)130を返す(元の値を130%する)
> (d)1.3を返す(元の値に1.3をかける)
申し訳ないが意味わからん >>61
(a) deltaInPercent
(b) delta
(c) multiplier
(d) multiplierInPercent
スレ違いだしたぶん余計なお世話だと思うけど、可能なら「係数」自体を
クラス化した方がいいんだろうね 税率、税抜き価格、税込価格、税額みたいに
文脈に応じた名前を付けたほうがいい気がするけど
“〇〇係数”みたいな名前がついてるんじゃないの? >>61
(a) なし
(b) increase rate
(c) なし
(d) increase multiplier
パーセント版はいらんやろ。その場で100倍すればいいじゃん。
どうしてもというなら、末尾に_percentとかつければ。命名としては歪かもしらんけど、わかりやすかろう。 >>68
だから増分だってw
ほかにもっといい表現があるならよろしく deltaは差分(足し算の増分)のイメージが強いなあ
x = 500
rate = foo/100 = 0.3 だとして、
delta = rate * x = 150
って感じ お買い物に例えないと算数理解できないデキの悪い小学生じゃないんだからw
正規化された増(減)分って考え方は普通だと思うよw
もともとパーセンテージ自体がそうなんだし deltaは差分だよな
係数って意味でdeltaって呼んでるケースーある? 考えかたはふつうかもしれないが、それをdeltaとは言わん、という話。 ついでにincrease rateも増加率・伸び率・上昇率みたいな意味だよ
増やすための割合じゃなく、増えた割合って意味が強いから
あんまり適切じゃない気がする
〇〇rateって名前にするのはいいと思うけど
その〇〇として適切な用語は>>61の情報だけじゃ分からん 500 ⇒ 650 にするなら
係数: 1.3
係数(%): 130
増分係数: 0.3
増分係数(%): 30
なので
(a) GetPercentOfIncrementalRate
(b) GetIncrementalRate
(c) GetPercentOfRate
(d) GetRate >>74
日本語でもだいたいそうだろ。
値の履歴について言うことが多いというだけで、べつにおかしくないんじゃね。 >>73
だからそんなことはないって
だから、お買い物のたとえないと算数が理解できない小学生かw
金額だろうが物理量だろうが、正規化された抽象的な無名数であろうが、
増分は増分ですってw 係数の質問者です。みんなありがとう。
リファクタリングしてたのはゲームプログラムでして、
攻撃力アップ、獲得経験値アップ、消費MPダウン、3Dモデルの表示サイズ等で使われてる。
日本語で総称すると何になるんだろう? ……ステータス強化?
百分率くらい自分で計算しろよと言うのは、そのとおりだと思う。自分も強く思う。
関数ポインタ的な使い方をしてる箇所が幾つかあるので関数化されてたほうが都合がいいだろうってのと、
一括置換でいけるだろうとはいえ処理の変更扱いになってしまうので手続き上ちょっと面倒くさい。
とりあえず、
GetFooRateInPercent
GetFooRate
GetFooMultiplierInPercent
GetFooMultiplier
で提案してみます >>78
俺ならrateとmultiplierって何が違うんだ同じじゃないのかと思っちゃうねw 頭の悪い奴に言ってもしょうがないから質問者にだけ言うけど、
rateとmultiplierはどちらもほぼ同じ意味だから再考した方がいいよ。
もちろん見直す必要があるのはrateの方。
これははっきり言って意味不明だ。
これで通じるのは「税率」のように本体からの上乗せ部分に注目している場合だけで、
水の質量を基準値の何倍にするかって言う場合に「質量乗数」は何倍にするかっていう
倍率だろうなと推測できるが、「質量率」って聞いて[基準値からの増加分]/[基準値]
のことだと分かる人は誰もいないはずだ >>78
そういうのだったんか
それならincrease rateでもおかしくないな
バフ・デバフともいうけど日本語の総称はステータス効果かな
自分ならEffectのうち乗算型のやつに.rateや.percentのプロパティつけとく
名前とは関係ないけど
0.3や30%を返すのと1.3と130%を返すのが同居してるのは
個々のeffectを適用する計算の責務がEffect側にあるのか
使う側にあるのか明確じゃない気がしてちょっと気持ち悪いかも >>81のいうようにrateが曖昧だというのは同意するが、
それに変わるものがdeltaだとやはり違和感がある
相対誤差みたいな気持ちで相対増分(relative delta)とかはどう? >>84
absolute deltaって言っても意味不明だからrelative deltaも意味不明だと思うよw
俺は単にdeltaで問題ないと思うが、どうしても気に入らないなら「上乗せ分」か「変位」かね
辞書みても上乗せ分はぴったりの語が見当たらないから、displacementか
でもdisplacementは1次元の移動量のイメージが強い気がするな あとは俺は冗長だと思うけど「正規化された差分」かね
normalized delta >>84
そもそも増分自体が相対的な感じだし w
30%アップ分をdeltaとか言う奴は今までに見たことないし恐らくこれからもないことを祈るわ rateは特に曖昧じゃないだろ
税率(tax rate)、成長率(growth rate)、割引率(discount rate)、
どれもrateの前にある名詞の率(rate)を指してる
質問者の例で言えば攻撃力アップ率は30%であって130%ではない
この場合の率(30%)に対して130%を表現する言葉が
日本語にも英語にも無いのが困るところ >>87
だから、では何と言えばいいでしょう。
何回も言うケけど、そう感じるのは君の思考回路が数学脳じゃないからだよ。
deltaって聞いて物理量の増減分しか連想できないのは算数の問題を
お買い物に置き換えないと理解できない小学生と同じ。 >>88
>>89はアンカーミス
正しくは>>81参照。
君は「質量率」って聞いて[基準値からの増加分]/[基準値]のことだと分かるの? >>91
「質量率」って言葉知らないからわからないんだよ
君の言ってることが正しいのかどうかもわからないし
その言葉の定義が書いてるサイトでも教えてくれるかな? >>92
このスレは一般的でない概念に名前を与えるスレなんだけどw
何訳のわかんないこと言ってるの?
論点はrateという単語から
[基準値からの増加分]/[基準値]
これを想像できるかどうか。
できるわけないでしょ。
>>81でrateが意味不明だと言ってるのはrateという言葉の意味が曖昧だと言っているのではなく、
>>78の
GetFooRateInPercent
GetFooRate
これを意味不明だと言っている まあとにかく、話の文脈追わずに短絡的に反応されても困惑するだけ >>88
倍率とかmultiplierとかで通じるでしょ。 あーー、「質量率」って自分で作った名前だったのか
分かってあげられなくてごめんね。。。。。
〇〇率 = 部分/全体(基準) は 部分の名前を〇〇に入れて使うのが一般的
税率、成長率、割引率、どれも同じパターン
質量率だけだと何が部分で何が全体なのかわからない
rateという言葉の曖昧さが問題じゃなくてネーミングの問題 >>97
そう言われるとそうだね。
ただ、単に倍率(multiplier)で済むときはいいんだけど
例えば税率や割引率に対応するのは何倍率と呼べばいいの?
消費税率 -> 消費税倍率?
攻撃力上昇率 -> 攻撃力上昇倍率? >>98
>税率
これは増減する量に関わる比率じゃない
>成長率、割引率
確かに経済成長率、人口増加率、前年同月比のように、経済や統計の指標では
[増減分]/[元の量]を〜率と言うことがあるが、これは、例えば減少局面では数値がマイナスになるようにしたい、
というような指標として分かりやすくするためだと思われる。
指標ではなく直接計算に用いるような実務的な比率の場合は、[変化後の値]/[元の値]を〜率という場合が多い。
e.g.. 増幅率、拡大率
俺は少なくとも質問者のケースでは後者だと思うが、それはどうでもいい。
何度も言うが、論点は
GetFooRate
これを見て[Fooの増加分]/[Fooの元の値]を意味していると分かるかということ。
分かかるわけないでしょ。
だから、文脈を無視して短絡的な反応をしない。 ただ、81-82で書いているように、Fooの増加分にFoo(例えば商品価格)とは別のbar(例えば消費税)
という概念があてがわれているのであれば、
GetBarRate
これはあり。 >>100
なるほどね
その2つはrateとratioの違いのように思えるけど
まあそういう捉え方をする人もいるということは理解した
俺は根底のロジックは、着目部分/全体(基準)でどちらも一緒だと捉えてるから平行線だわな
FooRateのときは、Foo/全体(基準)でFooに着目してるのであってFooの増加分に着目してるのではない
拡大率は拡大サイズ/元サイズ、ただこれは部分全体の関係じゃなく比率の考え方から来てるので
英語でもrateという言葉は基本使われない >>102
平行線って意味がわからないよ。これは簡単な問題。
だから
FooRate
これを見て[Fooの増加分]/[Fooの元の値]のことだと分かるのかどうかはっきりしてくれ。
>>78ではそう意味で使われてるし、ここはそういうことを追及するスレのはずなんですが。
>拡大率は〜英語でもrateという言葉は基本使われない
"magnification rate"で普通に検索に引っかかるよw
余談だけど、rateとratioの違いだというのも全然違う
http://worldts.com/english-writing/eigo-ronbun31/index.html
によれば、どちらも同じ比率だが、ratioの場合は分母が自明の場合に使われる
(文章に分子を表す言葉しか現れない)ということらしい。 >>103
あれ、変だな。訂正
× ratioの場合は
○ rateの場合は >>103
質問者は結論を出したようなので、もうどうでもいいが、わかるかどうかについてはもっとどうでもいい。
用語定義や文脈などでわかれば充分なので。
たとえば実際、消費税率はconsumption tax rateというが、これについてもとの値がとか増加分がとかいうバカはいまい。
あんたは言っていいよ。w >>103
>これを見て[Fooの増加分]/[Fooの元の値]のことだと分かるのかどうかはっきりしてくれ。
分かるも何も、君の「質量率」以外にそういう使い方してるやついないから
攻撃力上昇率と攻撃力上昇倍率をrateとmultiplierで区別してるだけ
ここでのFooは攻撃力上昇であって攻撃力ではない
君の定義だと、攻撃力率になるけど誰もそんなこと言ってないよ
>"magnification rate"で普通に検索に引っかかるよw
それ間違えてる例だからww
調べるならちゃんと調べよう
もう面倒くさいから上の説明で理解できんならあとは好きにやってくれ >>105
何を言ってるのか意味不明
>>106
そういうのみっともないよ。
よっしゃ今日はこのぐらいにしといたるわ、ってか。
日本語でも同じこと
攻撃力上昇率
攻撃力上昇倍率
この2つを見て
攻撃力上昇率 = [攻撃力の増分]/[元の攻撃力]
攻撃力上昇倍率 = [増加後の攻撃力]/[元の攻撃力]
だと分かる人間がいるのか。いるわけないでしょ。
率も倍率もどちらも本質的に同じだからだ。
君の世界では競争率と競争倍率は違う意味なのか? しかし、すごいね
「rateとmultiplierでは何が違うのか読み取れない」>>79
「FooRateのrateは意味不明だ」>>81
っていう当たり前の事実にこれだけの説明が必要か?
っていうか、これだけ説明されてもたぶんまだよく理解してないんじゃないの?w incrementValue_percent とかでもいいんだけど、
一番多用するメソッドにつける名前としてはちょっと長いのよねぇ まあそうなんだけど
倍率の方をmultiplierなりrateなりにして、
もう一方を、少し遠めの言葉から選んでみたつもり。
絶対値みたいな言葉もあるし、
あとは自分みたいな英語さっぱり勢でも困らない単語ということで。 パーセントの値は計算時じゃなく表示時に使いたいんだろうから
数字のフォーマッティングをするクラスに任せたほうがいいかと
atk_increase = new Effect()
atk_increase.rate.to_percent() >>113
>>78
処理自体を関数にしたいんだとよ。
戦闘ルーチンをシステマチックに組み上げるためなんだろう。 >>114
もしそれが避けられないならEnum的なもので
decimalかpercentを引数として渡すようにするかな
atk_increase.rate(:persent)
でも表示用に数字をフォーマットする処理は
別途書いてるんだろうから二度手間だと思うわ 設計の話はNGって水を差すいつもの人が出てこない時は
その人自身がそれをやってる時だったりするのかなw
まあ俺ならRatioクラスを作るね。 命名がうまくできないのは設計がうまくいってない結果の場合もかなりあるのに
それを無視して設計の話はNGで命名だけってのは意味がないよね >>118
一般論としてはそう思うけど今回は微妙だね
まあ、どっちにしろこんな過疎スレでくだらないことに目くじら立てる奴の方が
確実にどうかしてるけどねw だからそういう奴のためのスレがあるっつってんだろ。
どうぞ正論に同意されている方々でやってください。無能なんですか?
設計・命名スレ
http://echo.2ch.net/test/read.cgi/tech/1477368563/
設計から喧々諤々されたい殿方は別スレがございますので、そちらをご利用ください。 >>115
質問者の現実のコードを想像できてないだろう。
そんな状態で、設計を非難し改めさせようとはおこがましいとは思わんかね? 仕方ない事だけどNormalizedってよく使うのに長すぎ
どっか偉い団体が頻出単語は標準的な省略形を定めてくれればいいのに ファイルの拡張子ごとに処理するクラスがあるんですが、そのクラスの静的メソッドとして、
処理できる拡張子かどうかを判定する静的メソッドを追加したいのですが
その名前をお願いします。 「処理する」の内容とあと言語のクラスメソッドの文法に依るけど、例えば
Class.canHandle(".xxx") >>127
なるほど。処理するの内容が何気に重要でしたね。すみません。
言語はC#で、アーカイブファイルを開くクラスですね。zipとか、それが拡張子ごとにある感じです。
そうすると「開く」??かなぁ・・? CanHandle、いいと思うけどな
あとはIsKnown(Extension)とか
静的メソッドだと
if (Hoge.CanHandle(ext))
...
else if (Hage.CanHandle(ext))
...
else if (Foo.CanHandle(ext))
...
ってなるのは必定で何だか泥臭いなとは思うけど、そこはスレ的に突っ込んじゃダメかね >>129
クラスクラスのインスタンスからクラスメソッド呼べないような言語あるの?
結局、サポートするコンテントタイプのリストを返すメソッドが欲しくなると思うけど オレなら、単純にisAcceptかなぁー
関係ないけど、静的関数を足すよりfactoryのクラス作って静的なインスタンス返すほうがいいとおもうんだ。
ステートフルパターンな感じに。。。 ありがとうございます。
Handle,Acceptのどちらかにしようと思います。 5chの板のスレ一覧のクラス(例えばThreadList)と各スレのクラス(Thread)があって、
・スレ一覧を更新するメソッド(各スレのログはダウンロードしない)
・スレッドを差分ダウンロードして新着レスを得る(最新状態に更新する)メソッド
にそれぞれ何という名前を付けますか?どっちもupdate()にしてるんですけど、同じ名前なのにやってることがだいぶ違ってなんかいまいちに感じます その専ブラがどのプラットホーム向けでいつリリースされるのかのほうが気になる。 >>134
updateはユーザーから見た動作であって実際のオブジェクトの動作はdownloadじゃないのかな?
知らんけど
と言う訳で
Download
DownloadUpdatedOnly ⇔ DownloadFull >>134
後者はrefreshとかどうか
ブラウザでページ更新して最新を取得するっていうときによく使われてる気がする >>136-137
参考になりました、ありがとうございます
ペーペーなので他にもユーザ目線の命名が多そう…見直します
>>135
すみませんただの練習用なんです><5chブラウザ腐るほどあるだろうし… get とfetchってどう使い分けたら良いですか? >>139
ググれ。
英語がらみでいっぱい見つかるから。 fetchなんて仰々しい言葉プログラミングではあんまり使わないと思うw ただ取るんじゃなくて「行って取ってくる」のが fetch だとググって知った。
ワンコがフリスビーとってくわえて戻ってくる感じ。
FreeBSD だと wget のかわりに fetch っていうコマンドを使うし
プログラミングではDBとのやりとりの時に使うことがあるね。
どうやって使い分けるのかっていうとうーん・・・ まあ、比較的高価だったり重かったり間に通信が入ったりする処理であることを
意識させる必要がある時ぐらいかね。
CPUがコアの外側のメモリから命令を拾ってくるのをフェッチっていうのも
そういうニュアンスなんだろうたぶん あるDLLをロードしたとき、そのDLL内部で使う情報を色々初期設定するために
InitializeDllって関数を作ったとき、それに対する終了処理としてつかう関数名は、
FinalizeDll?TerminationDll?どっちの名前を採用しますか?
もしくはもっと別の名前? >>145
finalizeに一票。
terminateは、後始末というよりも、本当に終了させる感が強すぎない? >>145
どっちでもいいでしょw
どぢらでも意味は分かるし誤解のしようもない。
ついでに変なサフィックスもいらない
Initialize/Finalizeで十分では?
名前異空間が使えなくてバッティングを避ける目的ならHOGE_Initialize
みたいにプリフィクスでやるのが普通じゃない? 補足しますと、元々DLLがロード・アンロードされるときに呼ばれるDllMainに渡される引数
DLL_PROCESS_ATTACHとDLL_PROCESS_DETACHで初期化処理終了処理を
突っ込んでたんですが、調子に乗って色々やり過ぎて不具合起こしたので
改めて明示的にEXE側から呼び出す初期化終了関数を作ったのでした。
(MSDNにも注意点として書かれれた)
そこで名称に疑問符が。
>>146
同感なのですが、後々DLLのアンロード時(アプリ終了時)に実行することを考えると
terminateもアリなのか?と思ってしまいました。
>>147
Initializeのイメージと被る感じがします・・・
>>148
まあどっちでもいいかもですがw
サフィックスはもうちょっとちゃんと考えますね。
finalizeで行こうと思います。
皆さんありがとうございました。 >>149
>後々DLLのアンロード時(アプリ終了時)に実行することを考えると
それは使う側の都合じゃね?
>>146でいいと思うよ goodsとかnewsと言った単数にしない単語をモデル名に使いたいとき、皆様はどのようになさるのでしょうか。productやarticle, postと言った別の単語で置き換えるのでしょうか。
置き換えると意味的に微妙に違和感が出るケースでしたので質問させていただきました。
参考
goodsが使われるケースがないか探している中で、ZOZOTOWNのAPIがgoodsを使っているのを見つけました。モデル名はどうしているのでしょうね...。 >>151
面白そうだからググってみたけど、その手の単語ってそうは多くないみたいね
http://www1.odn.ne.jp/xenom/gohou.box/gohou1.html
それを集約するオブジェクトがあって複数形が使えた方が都合がいいなら複数形がある別の可算名詞に
置き換える、そうじゃなきゃそのまま使う
まあ、柔軟に対応でいいんじゃないでしょうか >>152
どうもありがとうございます。柔軟に対応します。 ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 指定したプロセスのメモリ使用量を表示する場合名前は何にしますか?
具体的にはタスクマネージャのプロセスタブにあるメモリ (プライベート ワーキング セット)の値をX秒毎に取得してその値を表示するプログラムです
SurveillanceProcessMemory?
CheckProcessMemory?
ViewProcessMemory?
WatchProcessMemory?
etc・・・ 何の名前?
表示を更新するUIのメソッド名?
それともアプリ自体の名前? その時点の情報表示 ViewProcessMemory
情報を監視(垂れ流し表示) WatchProcessMemory
なイメージ
checkは抽象的でよく分からない 見ることではなく、見せるものであれば、「Show」とか。 Monitorじゃねって混乱させたり、
Memoryの中見るんじゃなくて使用量見るんならMemoryUsageとかMemoryUseだよねとつっこんでみたり。 そもそもexeの名前なんだから
俺のメモリー.exe
とかでいいだろ 先頭が数字で半ば固有名詞扱いになってるものを識別子にしたい場合のお約束ってなんかある?
3D Y/C分離とか3次元ノイズリダクションとか
セットアップレベルの0IREとか7.5IREとかを読みやすさを損なわずに列挙体メンバにしたい 月並みなことしか言えんけど...
■ 先頭が数字の名前の対処法
(1) 先頭にアンダーバーか適当なプリフィクスを付ける
_3DYCSeparation
m3DNoiseReduction
(2) アラビア数字の代わりに英単語で
ThreeDimensionsYcSepartion
■ 小数点
電気屋は小数点をSI接頭辞やRで置き換えるんだった気が...
_7R5Ire
4.7kΩ = _4k7Ohm
自分は小数点をpで置き換えたことがある
_7p5Ire 公開する名前をアンダーバー始まりにするのは認めないぞ。
絶対の絶対だ。 誘導されて来ました
ネット上のAPIを叩いて、情報を取ってくるメソッドの名前って
どんな感じにつけたらいい?
例えば、どこかのサーバーにアクセスして天気予報データをJSONで
取ってくるケースだと、どういう名前にしたらいいか教えてください 天気予報といえばこのURLだしフォーマットもJSON以外ありえないという前提なら、
FetchWeatherでいいだろ。
もっと大げさに指定したいならFetchWeatherDataFromUrlInJsonとか。 >>165-166
やっぱこういうのは fetch >>139-144 がしっくりくるね >>166
>>167
ニュアンス的にはfetchがあってそう
サンキュー つか、メソッド名はクラス設計とも関係してて、
主語のクラス名も明確にしてくれないとどのメソッド名(動詞)が一番しっくりくるか変わるし。
俺は、例えば、天気予報情報を提供するREST API経由のXXXサービスがあるとすると、
クラスとしてXXXWeatherClientクラスみたいの用意して、
メソッド名にGetWeatherInfoでGetで十分だわ。
クラス名がどこから取得するか物語ってる事になるし。ローカルキャッシュされたものを取得するなら
適当に、LocalCacheWeatherClientとか。
だから、俺はこんな設計に大抵するからGetで十分だな。 抽象化してもしなくてもいいが、例えば
interface IWeatherClient
GetWeatherInfoAsync():
用意して、
class XXXWeatherClient : IWeatheerClient
class YYYWeatherClient : IWeatherClient
class LocalCacheWeatherClient : IWeatherClient
だから、クラス名の方がどっから取ってくるか物語るのでメソッド名は汎用的・抽象的なGetで十分かな。
こういう設計する場合は。 API呼ぶの1か所だけだし、抽象化もいらねぇしとかなら
class WeatherUtillity
static FetchWeatherInfoAsync
でstaticメソッドあたりにしてこれなら名前はFetchでいいかなとは思うけど。 getの話はさんざんされてるけど、言語の慣用によっては、
属性のゲッター的軽い処理と見誤られることがあるので注意すべき。 まぁ、長々書いたけど、
Twitter APIとかDropbox APIとかいろんなREST APIのラッパーライブラリ
を見ると、Fetchを使ってるのはほぼ見ないかな。ほとんどGetだと思う。 まあ、混在がない(FetchXxxだけでGetXxxがない)かつ、
全部をGetXxxにしてもそれが何を意味するか文脈的に自明なら全部Getでも問題ないねたぶん
でもpublicなメソッドは全部FetchXxxでも非publicなGetXxxメソッドが
存在するような場合は、使う人は良くても書いたり保守するのは混乱するかもね そんなん気にしてるのおまえらだけやぞw
しかも他人は絶対使わんやんおまえらのコードw REST APIの仕様であれば、Getばかりなのはそういうものなので、あたりまえ。
今回の質問者にふさわしいとは限らない。
プログラム全体と天気予報情報の関係によるだろ。
ほかのところはふつうにプロパティ参照みたいになってるのに、天気予報情報だけがサーバーに取得しにいくとかなら、それだけを特別にfetchと名付けるのは妥当。
つーか、質問者はもうfetchがいいって言ってるんだっつーの。w weather.api() か weatherAPI() だな ついでに型名とか軽量単位あたりも接頭辞で表すようにしてみるか fetch()、sketch()、oneTouch()メソッドを持つHentaiクラス 文字型としてはchar32_tのみ、文字列型としてはUTF-8 stringを使う体系の名前
なんか格好いいのないですか >>184
回答じゃなくてすまんが、
それ、文字列中の文字を一つずつ処理したいときどうすんの? >>185
文字列をコードポイント単位で切り出して処理します StringUTF8_CharUCS4
かっこよくはないけど、字面のわかりやすさ重視で。
ほかのところ(Enum型名とか)でだいたいわかるのであれば、String_Char.UTF8_UCS4とかでも。 体系って言ってるんだからクラス名とかじゃないんでしょ
そもそもクラス名なら、内部でどういう符号化してるかなんて普通はどうでもいいはずw >>188 >>190
アバウトでごめん
例えばD言語のforeachだとUTF-8が入ったchar[]をdchar(char32_t)単位でループできるんだけど
そういうルールに従っていることを示せる、名前空間やプレフィクス等に使える名前みたいな…… ずばりUCSにしてしまおうかとも考えましたがUnicode一般と区別がつかないですし
>>189で提案していただいたUTF_UCSみたいなのは"UTF"がそもそもそういう意味なので
格好悪いなあ、と 振る舞わせたいことが決まってるならForeachableStrとか?
>>190も言ってるように「何で実装されてるか」を名前にするのはあんまり筋がよくない気がする >>193
クラス名ではなく、イテレート検索置換set/mapその他文字列関数やそれを用いる処理群に付ける名前で
既存のchar/string、wchar_t/wstring等のペアと区別するためのもの、と思っていただければ 正直そっちの世界よく知らんけど、単純に文字・文字列の順でそれぞれを
表すプリフィクスをくっつけちゃうとか。つまり、Uu8 >>195
簡潔で良いですね。格好は……悩んでても仕方ないのでそうします
ありがとうございます 多重起動できる数を制限するのはなんて言う?
1つしか許さない場合もあれば2つまでは可能な場合もある
LimitMultiBoot、RestrictMultiBoot、他 そもそも数なら数ってわかる名前にしろよw
基本がアカンのに凝るとこ間違っとるでw >>199
多重起動できる数を制限するのに
Instancesで違和感無い?
>>200
間違ってない例お願い >>198
クラスなの?メソッドなの?変数なの?
そういう情報なしに命名なんかできるか。 >>201
実行ファイルを起動してできるプロセス = Instance
だったらMaxProcessesでもよさそうだけど、それだとまるで別のバイナリも含めた
実行可能なプロセスの数のような感じになっちゃう
そもそも質問文が曖昧に感じるけど、
プログラムが起動を許す自分の実体の最大値を表す数ならMaxInstancesでいいと思う >>202
多重起動できる数を制限する変数っておかしくない?
変数が何かするわけでもないし
>>203
プロセスもInstanceなんだありがとう
MaxInstancesだと「数」が格納されてそう
改めて言うと
自プロセスが多重起動できる数を「制限する」関数だから
動詞からはじめたい >>204
制限する個数を入れておく変数なら十分あり得るだろ
ていうか、MaxHogeっていうのはそういう変数や定数の名前にしかならんよ >>204
じゃあLimitInstanceCountとか?
だけど、
if (getCurrentInstanceCount() >= MaxInstances) プログラム終了;
の方が分かりやすいと思うけどw >>205
変数を訊きたいなら「多重起動できる数はなんて言う?」になるのでは?
> 多重起動できる数を制限するのはなんて言う?
既に元の質問でこうなんだから変数はありえないとわかるし
そもそも例も動詞から始まってるんだから関数だとわかると思ったけど
それとも動詞から始まる変数もありなん? >>206
あぁごめん
そっちも変数だと思ってたのね
かみ合わないなと思ったらそういう事か
Limitにするよありがとう invokeの意味はcallに近いからメソッドの呼び出しには相応しいけどプロセス起動には違和感ある
bootだとOSが起動しそう
start、launchあたりでいいんじゃないかな
プロセスであることに特段の意識を向けないならrunもイイと思う callというより、summonだよ。
すごいやつを召喚する感じ。
commandの起動にはinvokeが一番ぴったりだよ。 ぴったりなのはsummonやんけw何言っとんやコイツw
バカの考え恐るべしw ソースにsummonとか出てきたら笑ってまうやろな。w
ファンタジーなのか、中二なのかと。 SummonWizard とか SummonDaemon したい デーモン"クロン"を召喚
スーパーユーザの名において命ずる
時の守護者よ預言を現実と為せ auto daemon = Necromancy.Summon(); >>219
auto slave = necromancer.summon(new demon()); 核となる動詞の目的語と付随する前置詞の目的語の区別がつかないんよ>他人のコード でも、自動詞と他動詞が並んだときに、すべて前置詞なしで統一したい気持ちもわかる。
確認もめんどくさいしね。。。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
RUCPE Lookfor みたいに1語としてしまう方法もあるかな
自分も含めて英語が苦手な人間だと、確認が大変なのは同意する とある制御用プログラムの話です
例えるならスクリーンショットのように、ある瞬間の現場の状態を記録する処理をCaptureと命名しています
今回悩んでいるのはその逆で、記録されたキャプチャデータから可能な限り現場を再現する処理の命名に悩んでいます
何か名案ありますか? >>228
restore?
decapture?
まあ、話が抽象的過ぎw
再現する対象によるんじゃないかと
絵画ならreadrawだろうしボードゲームならreplayだろうし構造物を再建するならrebuildだろうし
そもそも再現というニュアンスが本当に必要かもよくわからん
キャプチャーされたデータだろうとゼロベースで作ったデータだろうとdrawはdrawだろうって考え方もありうるかと >>229
工作機械の制御プログラムなので構造物が近いです
rebuildにしようと思います
ありがとうございました captureだと一般的すぎるのでsnapshotをご提案。 もし工作機械というのが削る系なら、rebuildには超違和感。。。
組み立て系なら超納得だけど。 "restore a snapshot" は割と使われる表現みたいね
あとはimport/export とかも思いついたけど、
captureよりはもうちょっと上の処理のイメージになっちゃうかな 純粋なデータを保存するわけではなく、実物の加工品(加工途中?)をスキャンして再現を試みる…と言う話みたいだから、save/loadやexport/importは違和感があるかなあ
それだと100%同じものが復元されるイメージがある snapshotみたいな名詞らしい語を処理名(関数名)にするのには躊躇いを感じる
動詞用法あるけど基本はtake a snapshotだしこれチェキるみたいなくだけた表現だよな
SnapshotクラスやStateHistoryクラスのreplayやrestoreメソッドなら好き 毎日データを作成して保存しているのですが、x日間保存・残しておくという仕様です。(現状5日)
このx日をdefineで名前を付けておきたいのですが、この名前をお願いします。 なるほど、TTLというのがありましたね。
それで行きます。
どうもありがとうございました。 expireを使うならDAYS_TO_EXPIRYだな スレ立てるまでもない質問のスレ見てて、ここでもたまに同じ話になるが
このスレタイや>1だと、クラス名と変数名以外の質問はできないと勘違いしちゃう人も多いのかね SQLのテーブル名やら実行ファイル名なんかも
過去にはありましたけどね メソッド名・関数名は変数名の一種でしょ(高階関数脳) >>254
草
スレタイを『クラス名・変数名「とか」に迷ったら〜』ってすればええんちゃう このスレの前身スレである「ネーミング倶楽部」の復活来る!? 昔は、板名を見ずに検索で飛んできて
頓珍漢な質問する人って結構いたなあと思いだした メソッド名について相談です。
c#ですが、
public static Func<SqlConnection> CreatSqlConnection{xxxx}(string connectionString)
みたいな、「インスタンスを作るメソッド」を作るメソッドの場合、{xxxx}には何をいれたら良いでしょうか?
また、もっとより良い名前があれば教えてください。 素直にこうすれば無理名前考えずに済むんじゃないのかなと...
public static SqlConnection CreateSqlConnection(string connectionString){ ... }
....
Func<SqlConnection > creator = CreateSqlConnection; ごめんこうか...
Func<SqlConnection > creator = () => CreateSqlConnection("debu"); getSqlConnectionSupplier
頭と末尾の動詞はニュアンスに応じてお好みで
変数名をフルスペルで書いたときこうなる感じ
Func<SqlConnection> sqlConnectionSupplier = getSqlConnectionSupplier("debu");
関数型の変数についての良い命名ガイドラインって無いのかな
SupplierはJava8から拝借した >>260 261
ありがとうございます。
例に出したものに限らず、
「インスタンスを作るメソッド」を作る(返す)メソッド郡を作っているので、何かしら定型的なものがあればと思っています。
>>262
ありがとうございます。
creator,maker等は思い付いたのですが、supplierってのもあるのですね。
勉強になります。 >>263
「Func<T>を返すメソッド」自体が抽象的で分かりづらい。
どうしてもGetFuncToCreateSqlConnectionみたいに長くなると思う
例外は
static class SqlConnectionHelper
{
public static Func<SqlConnection> GetCreator(string connectionString) { ... }
...
}
みたいにメソッドが置かれた文脈が十分に明示的な場合だけ
しつこくて申し訳ないけど、そもそも本当に「Func<T>を返すメソッド」に
固執する必要があるのか再考した方が俺はいいんじゃないかと思うけどなあ。
ラムダ式で簡単にTを返すメソッドからFunc<T>を作れるんだから >>264
抽象的でわかりにくいとおまえが思うのは、おまえが質問者の状況を想像できてないから。
質問者がいいと言っているのだから、それでいいのだ。 >>263
create factory predicate
○なにかをつくるなにかはやはりfactoryだろう。FactoryパターンとかFactoryメソッドとかいうしね。
○個人的に、Action/Funcには総称してpredicateと名付けることにしている。 >>265
それでいいと思うならスレの趣旨にそったレスをしろ馬鹿者 >>266
いやpredicateは全然違うからw 昔、関数ポを返すのを書いたときは
GetFooFunctionだったかGetBarMethodだったか、そんな感じにしたなあ
今考えるとちょっと野暮ったい 仮に運よく>>264みたいに簡潔なメソッド名が使えるとしても、
var creator = SqlConnectionHelper.GetCreator("Hage");
こう書けるだけ。
これが、
Func<SqlConnection > creator = () => CreateSqlConnection("debu");
より簡潔でより読みやすいと言えるか、かなり微妙だと思うけどね。
むしろ後者の方が可読的と思うけどなあ >>264
提案ありがとう。
都度都度ラムダで作れるのはそうだけどConnectionは1つの例で、(disposeの有無に関わらず)他にもラップしたいのはいくつかあるんですよ。
今は「インスタンスを作るメソッド」を作る(返す)メソッドってテーマで色々やってるんで。
他皆様もありがとうございます。 殺伐としたスレにPredicateが!
public delegate string IntToStringAction(int i); predicateって1つ以上の引数を取ってbool型を返す関数(関数オブジェクト)じゃねーの?
関数名が断定する名称でさ、例えば、Equal(A, B) → bool それであってるよ
https://msdn.microsoft.com/ja-jp/library/bfcke1bz(v=vs.110).aspx
専ら条件式を記述するときに使う代物で、一般に「何かを受け取って真か偽か判定する」関数をpredicateと呼ぶ
>>266みたいに何でもかんでもpredicateと名付けるのは論外
覚えたての言葉を使いたがるガキかと >>273
案をありがとう。
これだと、C#にすでにはActionって名前のデリゲートがあるから、そっちに意味を取られないかね?
これは各々の認識の話になるけれども。
だったらサフィックスをFuncにしろよって話だけど、
なんかね、、、カッコ悪いしね >>276
C#にはPredicateというさらに別の意味のデリゲートもあって、Predicateと言いつつActionという名前が付いたFuncですよね!いい加減にしてください!
と言われたいだけのネタだったんだ… お詫びに案を挙げますね
//取得
Func<SqlConnection> createSqlConnection = x.GetCreatingSqlConnection("debu");
// 実行
createSqlConnection(); >>274
C#とかJavaでそういうデリケート/インターフェイスが定義されてるとしても、「predicate」の本来の意味は「述部」だから。
C#の場合は、comparerとかの名前を先にインターフェイスとして使ってしまってるから、ヤケクソ的にpredicateを使ったのでは?w
単体では意味が広すぎると思う。 >>275
たまたま知ってるひとつの意味にこだわるとか、まさにバカガキ。 classの本来の意味が「部類・種類」だからと言ってenumに付けてまわったら紛らわしいことこの上ないじゃん
JavaやC#といったメジャーな言語で定義されてるもんを勝手に使うのは良くない
しかも今回はActionやFuncが登場する言語での話だし
たまたま知ってたじゃなくて>>280が無知なだけ >>279
少なくともプログラミングの世界のpredicateの普通の用法はこれw
https://en.wikipedia.org/wiki/Predicate_(mathematical_logic)
仮に君の言う「述部」とやらの意味だったとして、
そんな意味の用語がプログラミングの世界で必要とされる余地が果たして存在するかねw >>279
命名ってのは英和辞書で引いてみて意味があってりゃいいってもんじゃねえだろ。
例えば「モノを作るなにか」でもcreaterやfactory、maker、manufacturerなどなど似たような単語はいっぱいあるが、その中でも最も適切な単語を選ぶのが命名だ。
「述語=predicate」と言うたまたま知ってた1つの単語に固執してるのは君だろう
初めて英単語を覚えた中学生じゃあるまいし まあ業界用語はテキトーに決められてる奴もあるから元の意味ガーとか言ってもしょうがないわな
ネットワーク用語のpromiscuousなんて元の意味は人前でつかうのを憚られるし w >>281
言語要素といっしょくたにする意味がわからん。
名前空間のどこかにある名前とかぶってはイカンとか現実的じゃないし。
>>282
それは「プログラミングの世界」じゃなくて、数理論理学や一階述語論理における用法。
>>283
じゃあ「述語」に相当する英語は? >>286
>言語要素といっしょくたにする意味がわからん。
言語要素よりは、そりゃ回避優先度は高いだろうが
次元としては同じじゃないかなあ すまん、>288の日本語がおかしい
誤:回避優先度は高いだろうが
正:回避優先度は低いだろうが >>286
一連の処理の総称を言いたいならmethodやfuncと名付けるのが一般的だわな
ガキンチョはちょっと周りと違う言葉を使おうとしてトンチンカンなチョイスをするから困る そもそも質問者がC#を使ってるのに、そのC#で多用するPredicateを別の意味で再定義しようとしてる時点でアホやろ
そんなアホ新人がいたら試用期間で切るわ predicateの名詞用法のうち最も代表的なものは「述語」だから広義に用いても間違いという訳ではないんだけど、英英辞典を引くと動詞の「断定する」や「命題の述部」というニュアンスも色濃く現れてきて無視できない
https://www.dictionary.com/browse/predicate
語源としてもその辺から由来し、広義の述語へと転じた経緯がある模様
特にプログラミングや論理学の分野でどう用いられているかを見れば答えは自ずと決まる C#(特にLINQ)を触り始めたばかりの初心者だとPredicateとラムダ式を混同してることが多いからその類じゃないかね?
Predicateを引数にとる各種メソッド群も、一定の規則を守ったラムダ式ならコンパイラが自動的に解釈・変換してくれるもんだから勘違いしがち >>294
何を言いたいのかよくわからん
この際、おまえがしてた、若しくは現在進行形でしている勘違いを
洗いざらい吐き出しちまえよ >>295
「FuncにもActionにも何でもかんでもPredicateと名付けてしまうのはこれら全てがラムダ式と同一のものだと勘違いしてるんじゃないの?」ってこと
俺じゃなくて今春の新米PGにいたんだわ >>296
ラムダ式と同一のものというのがよく分からんが
ラムダ式ならLambdaでええやん
それがなぜPredicateになるんや? >>297
同じ意味をもつ別名ぐらいに考えてたらしい
そこで謎の選択をした理由はそんなの本人にしかわからんがな
カッコいいとでも思ったんじゃね? この人はPredicateとDelegateを混同してるのではないだろうか >>266が発狂してスレ伸ばしてるのこれ?
>>300
かもねえ >>300
最後の3文字しかあってないじゃないかwww
そんなバカがいるわけが…いや、そんな、まさか、ねえ? >>300
いいだしっぺ本人だが、混同はしていないつもり。
C#ではdelegateは言語機能だけど、あくまでpredicateは一般名詞。数理論理なんかを記述してるわけではないし。
lambdaは抽象的な機能とか無名関数とかをあらわす印象。
>>293
英語は同じ単語を別の用途に使い回すことはよくあるからね。
あんまり気にしない。w >>303
このスレでも何度も書いたことだが、
英語という言語は日本語のように新しい概念に対して語彙を増やして対応する言語じゃない。
同じ言葉を文脈によってまったく別の意味に使い分ける傾向が強い言語だ。
だから、
>あくまでpredicateは一般名詞
これナンセンス。
だから何度も言ってるだろう。
プログラミングの分野では(数学と同じく)boolで評価する関数のことをpredicateを言うの。
いい加減恥を知った方がいいよ。 >>303
言語機能か一般名詞かの違いしかないと思ってるんならそれは混同してるってことだよ だいたいコードの中の普通の日本語でいう述語なんか出てこないだろうってw
お前はコードの中に、
(空は)青い
(地球ま)回る
とか書くのかとw
ダイクストラ先生の時代からコードってのはデータと手続きで出来てるんだよw
それは宣言型の言語だろうが同じこと なんやまたどえらいアホが現れたなあw結構結構wwww >>303
キミ、「述語」って言葉の意味すらよく分かってないんじゃない? 混同というのはID:nnyWdGJKに対して言ったんだけどな
余計な飛び火をさせてしまった >>305
英語にも外来語は多いよね
新しい概念に対して語彙を増やさないというのが何を指してるのか詳しく知りたい
漢字がない分、同音異義語が多いという話なら分かる >>308
if (sky is blue) earth.evolute()
プログラミングで述語は書くと思うよ あらゆるメソッド名、クラス名にSentenceと名付けてしまうかのような暴挙 あらゆるメソッド名、クラス名にSentenceと名付けたらコンパイル通らんやんwwww
アホしかおらんのかここはwwww その理屈で言えば>>266もコンパイル通らんやろ… >>316
スコープ内で一意なら普通にコンパイル通るわw
おまえプログラミングしたことあるんかwwwww >>317
その理屈で言えばSentenceも通るやろ
マジレスするとプレフィックスないしサフィックスの話やろ >>318
どの理屈やねんwwww
言い訳すんなアホw つーか何度も言ってるが、C#で多用されるLINQの引数型としてPredicateはあちらこちらで使われるんだから
それに別の意味を持たせて再定義してる時点で脳味噌スッカスカだろと >>319
スコープ内でSentenceが一意ならコンパイルが通ることも知らんのかいな(呆れ)
プログラミングしたことあるか? delegate(委任、委譲)とpredicate(断定)の区別すら出来ない子がいるとは…一般名詞とか言語仕様以前の問題だろう
中学生ぐらいで英語力が止まってるのか? >>312
何を指すも英語はそんな文脈に依存して意味が変わる単語だらけ
atomic, bit, function
日本語は英語より文脈に依存する表現を好まない傾向が強い
分割不可能性みたいに明示的な漢語を作り出すか、ビットのようにカタカナ表記にするか
(日本語でビットといえば普通文脈に関係なくそのビットしかない)関数のように音訳する 電動ドライバーのビットはあるかw
でも日本語が同じ言葉より語彙を増やすことを好む言語なのはちょっと考えれば
大方同意するよね
スレ違いなのでこれで終わりで × 同じ言葉より語彙を増やすことを好む
〇 同じ言葉を使いまわすより語彙を増やすことを好む傾向が強い valueをgetするメソッド名に悩んでるのですが、一般的にはどんな名前になるんですかね? >>320
いうほど使わないが。
Func<T,bool>としか書かないからな。 >>326, >>327
変数のようにその値が意味する名称にする(例えば、string.length)、あるいはgetValueのように動詞始まりで書く
個人的には、状態を取得する関数は他の関数(手続き、メソッド)と完全に区別しているから、名詞にするよ
状態を表すbool型を返す場合は、trueを想定した命題にする特殊なルールがある(例えば、iterator.hasNext)
ValueGetterって名称の場合、関数は動詞始まりが一般的だから、(get)ValueGetterのように省略していると解釈され
意地悪を言っちゃうと、Valueを取得するGetterオブジェクトを返すって意味に取られかねない >329は解答として満点に近いと思うのでこれに賛成しておこう >>324
ありがとう把握した
個人的にはやまと言葉は1単語の広がりがとても広く
漢語はその豊富な表意文字と音素の恩恵から狭めって認識だわ
それと外来語学習者のバイアスがあって
学習者はコアとなる概念をそのまま理解できずに
母語の単語に置き換えて把握するから
例えば英語話者は日本語の核という言葉が
atomic, core, nucleus, kernelの4つに当てはまることを見て
使い回しの多い言語デスネーと感じる傾向があると思う
スレチなんで俺もこのくらいにしておきます >>326
言語とクラス名にも依るけど、その感じだとJavaかな
JavaならThreadLocalやOptionalのような変数のコンテナクラスにはget()というメソッド名が与えられてるから、それに倣うと自然な感じになると思う 20年前ならともかく、
getだけでJava前提にするのは厳しいかなと思いますがw モダンな言語は大概プロパティがサポートされているから、getterメソッドを使う慣習があって、小文字で書くそこそこシェアのある言語ってことでJavaかなーと思ったんだけどな
Rubyも候補に入るのかな >>328
コンパイラが暗黙的にキャストしてくれるからって、それに頼り切って本来の引数型を見てみぬふりしちゃいかんだろう >>334
プロパティあっても、アクセサ的なメソッドを作ることは珍しくないかなと >>334
C#でもありえーるでしょ。
リフレクション前提とか。
プロパティはメソッドと別扱いだから。 >>339
小文字でと書いたのは、C#のようにメソッド名先頭を大文字とするのが主流の言語は
推測の第一候補にはならなかったっていう意味ね
もし>>332でJavaと推測・仮定したことがナンセンスだというツッコミを入れるなら
他の言語である可能性がゼロでないことを示しても論拠として弱い
Javaではない蓋然性の方が高いだろという主旨でないと 今週のぱいじょ132話
https://paiza.jp/paijo
『大事な変数名』だってよ よーしパパ、ハンガリアンでバリバリコード書いちゃうぞ! 変数名はだいじだな
ハンガリアン(に汚染されていたことの発覚)はおおごとだな カッコさんもこれほど存在感のない使われ方するとは思ってもみなかったやろなw ハンガリアン悪くない
悪いのは型名をプレフィクスに使う事 ハンガリアン悪くない
private変数の
m_
とか推奨 >>352
何が言いたいのかよく分からない
英語にケチつけてるなら、それ相応の板へどうぞとしか 訳し方ひとつじゃないだろ
プログラマーのメンタルに悪い こうですね、理解ります
DEAD_LINE
死の線
モノの死にやすい部分
直死の魔眼により視ることができ、切られたものは死ぬ >>354
一般的な日本人がそのまま読んでも意味が通じる
実に最適な選択だろ 納期=死線
ちがう絶対ちがう遅れたっていいんだ誰も死なないんだ 最適解について考えるなら俺も due date を推したい
時刻もあり得る deadline と違って日付であることが明確
deadline は守るべき締め切りというニュアンスが乗りすぎてフラットでない感もある
ただアッパーケースで書いてるし、ザ・期日というべき値ならDUE_DATEよりDEAD_LINEのニュアンスが相応しい文脈なのかもと思ったり
due date という英語は難しいから避けた方がいい、なんて環境ならレベルが低すぎるからとっととおさらばしたい いや納期だったか
じゃあ delivery date だな delivery dateだと、その日だけって感じにならん?
due dateならそれより前でも可ってわかるけど 英辞郎で「納期」で検索した感じ、ニュアンス的には納品側の用語としてはdeadline、
発注側の用語としてはdue dateが適切のように感じるね
個人的にはそこまでこだわる必要はなく、普通にdeadlineでよいと思う 俺のメンタルに悪いっつってんだろgじゃkじゃあjsふぁ 日本語には「〜です」って言葉をよく使うんだけど
生きづらそうだね それは直接的な意味ではないし回避するために毎回文章を考えるのが面倒なので仕方ないdeath 自社スタンドアロンアプリでデータをCSVにエクスポートする機能があるので、
ExportXXX()みたいな関数名が付けられていたんだけど、
この機能を使い回して自社WEBサービス版でも一部利用しようということに
なったものの、こっちで使うときもExportでいいのかどうか
くだらないことに引っかかってる次第。
スタンドアロン←→WEBの間にユーザーは一切関与せず、どちらもまとめて
一つのシステムという扱いなので、Exportでは外に出して自由に使える
イメージが強くて違和感が。
気にしすぎですかね? もはや気にしてもしょうがない
出来ているものの名前は変えなくていい
とはいえ違和感が強いならExportというネーミングが最初から微妙だった可能性を省みてもいいかも
システム外部へのエクスポートはCSV出力のひとつの役割で
当初はその側面しか見てなかったけど
本質を表してはいなかった可能性がある
例えば別案はWriteXXXToCSV 何言ってるのか分からないねw
Exportっていうのは普通に考えれば「データを他所のアプリに対してexport」ってニュアンスなので、
もしCSVをそのアプリ自身でも読むのならちょっと違うとは思う。 >>367
スタンドアロンというのが意味が違うんですかね。
Windowsにインストールしてるソフトがあり、それのことを書いてました。
旧来のそのソフトにWEBサービス版が加わり、そっちとデータの
やりとりが必要となったという流れです。
>>368
仰るとおりです。当初は外部に出してしまって好きに使ってもらう
ことしか考えてなかったのですが、WEB版にデータを渡すのに
一々新規でそのプログラムを作らないで、Export部分を使い回した方が
工数削減出来るだろうし、その後の保守も手間を省けるというところです。
ただ、この場合システム内部で完結するのでExportとは言わないかなあと。
既に開発スタートしてて、既存のExport部とは関係ないデータを吐き出すのに
MakeXXXXCSVみたいなのを作ってから、後でExport処理も使い回す際に
ネーミングに疑問が出てきました次第で。
>>369
WEB版にはExport機能はありません。
スタンドアロン運用で不便な点のみWEB版として追加してます。
>>370
すみません。
ニュアンスとしては同感でして、そこから今回の質問の流れとなりました。
とりあえずは、やはりExportのままだと本来の意味からするとちょっと
違う感じですよね。
もうちょっと考えてみます。どうもありがとうございました。 >>366
エクスポートは取り出した結果を外部に公開するイメージだから、スタンドアロンとかwebとかは関係ないと思う。 >>372
そう、関係ないですよ。一行で書けば、
既にあるExport機能を内部で完結する形で流用するので関数名がExportだと意味が違ってくるけど変えた方がいいかな考えすぎ?
という主旨です。
開発内部からみれば一応二つのシステム間でExport,Importしてるのは間違いないですが。 最初から通信などの内部処理用として用意するならserializeとかにすると思うけど、
既存の処理を使い回すならexportでも別にいいかなあって印象
自分で自由に出来るなら、出力部分のコードをserialize側に移して
export側ではserializeを呼び出すようにしちゃってもいいんだろうけど 「システム・ハンガリアン記法」を嫌う人がいるようだけど、個人的には実際に長年使ってみて、
コーディング効率が上がっていると感じる。
ネット上でよく見かける反論に、「システム・ハンガリアン記法は、(代入などで型が異なれば)コンパイラ
がエラーを出してくれるのだから不要」というものがある。
しかし、システム・ハンガリアン記法を使っていれば、たとえば、代入のコードをコーディングしたい最中に
周囲の変数の変数名を見て、エラーが起きない組み合わせを探すと、実は、非常にわずかな組み合わせ
しか無いことが多い。
そして、そのわずかな組み合わせの中に必ず正しいコードがあるので、人間の作業は、
そのわずかな組み合わせの中から選ぶだけでよくなるので、思考の節約になってくれる。
もし、システム・ハンガリアンを使っていなければ、この思考の節約が働かないので、
本格的に考えないといけないことがあり、余計に時間がかかってしまうことがある。
正しいコードが次のようなものだったとする:
pXxxx = pYyyy + ofsAaa;
周囲には、pXxx, pYyy, ofsAaa 位しか変数がないとすれば、頭を使わなくても、可能な組み合わせは、
上記のコードを含む少数のパターンしかないことがすぐに分かる。
そのうちから正しいコードを「選ぶ」事と、意味で考えることを二重に行うことで、早く正解のコードを
書くことが出来るようになる。
ところが、システム・ハンガリアン記法を使っていなければ、意味で考えることしか出来なくなり、
思考パターンを減らすことが出来ない。また、コンパイルしてみないと「検算」もも出来ない。 さらに、文字列などを使っている時、
CString strText;
const char *pszText = (const char *)strText; // operator char *() 演算子による型変換
int lenText = strText.GetLength();
などと、同じ Text という名前の文字列に対して、CString 文字列や、それを高速アクセスするための
文字列へのポインタ、文字列の長さ、の各々に対する変数名を機械的に付けられるのは重宝している。
さらに、よくあるのは、メンバ変数と全く同じ意味のローカル変数や仮引数がある状況。
この場合、毎回、新しい生を考え出すのは大変なので、メンバ変数には必ず先頭に m_ を
つけていると便利。今の場合、
m_strText = strText;
m_lenText = lenText;
のように美しくバランスするのがとても好きだ。
これだと、エラーが正しいコードであることがとても分かりやすい。
また、「m_」の接頭辞は、次のようなコンストラクタでも重宝する:
CPerson::CPerson( const CString &strName ) {
m_strName = strName;
}
さらに、引数が同じ文字列でも、0終端文字列の場合は、
CPerson::CPerson( const char *pszName ) {
m_strName = pszName;
}
とすればよいだけなので、とても美しい。 唐突にどうしたのw
真面目に言ってるのかネタのつもりかのか知らんけど、畢竟
「書きっぱなしで他人も自分も後でメンテしない」
コードならどんな表記法使おうが何の問題もないのよ。
ハンガリアンが批判されるのは、この条件を満たさない(世の中のコードの9割はそうだと思うけど)
場合に問題が起こるから
もちろんハンガリアンがダメって言ったって教条主義的に全部捨てる必要はない。
メンバ変数のプリフィクスなんか誰も文句言わないよ
こんな20年前に決着が付いてる話を今頃して何が楽しいの ワイはアプリもシステムも混在するハンガリアン
とりあえず事故は皆無
アプリケーションで使うのは、大体座標系かな
x,y,cx,cyとか、コイツらをシステムの方でやっちゃうと変数名が長くなるだけ
ならまだいいんだけど、計算がちと複雑化してくるとあああああってなる 個人的にはこうだな
・ポインタ変数にpを接頭するのは分かりやすい
・メンバ変数にm_も悪くない
・型を接頭するのはやめて lenTextがintLenTextじゃないのは気になった
デフォルト扱い? 型の接頭がいいと思うのは関数内で型変換するときくらい ポインタと型変換とメンバ変数に共通することを一般化して考えると、同じ情報を異なる形式で2つ持ちたいときにハンガリアンは活きる >>381
今時pXxxはないわ
普通にPtrToXxxかXxxPtrでいい
PtrToReadPtr
これなら何を意味してるかだいたいわかるが
ppRead
こんなのは勘弁してもらいたい C++相談室 part137
https://mevius.5ch.net/test/read.cgi/tech/1535353320/962
962 デフォルトの名無しさん (ワッチョイ 6ee3-BkfR) [sage] 2018/10/05(金) 18:51:17.31 ID:4ThlZrTR0 [3/7]
>>947
最初の従業員のデータについては、
EmployeeInfo
二番目の dictionary の方は、
g_dictCompanyEmploeeInfo_s pFooとbarPtr/PtrToBazの間に
そこまで大きな差があるとも思えないんだが
>>381
個人的には、メンバ変数の m_ はバッドノウハウに見える >>388
pは適当すぎたか
PointerToCompanyNameよりは
ptrCompanyNameのほうが好み程度のことが言いたかった >>389
どっちもプリフィクスなの変わらなくない?って聞きたかったんだけど >>390
別にサフィックスでもいいんじゃない?
そこは気にしてなかったわ 変なプレフィックスを使うことに忌避感情はあるけどptrというやや古典的な略語を使うことについてマイナスイメージはないということか >>391-392
よく分からんが、pFoo を否定したのは>385だぞ >>385
何故、ハンガリアン記法が支持され、否定されてきたか
PtrToReadやPointerToReadなんて記法は、そのオブジェクトのデザインとしての命名ではなく
ハンガリアン記法と同じくプログラマの都合のような命名でしょ
文章的にそれをやってしまうと、ハンガリアン記法よりも余計にウザったい命名規則になると思うがな
そのPointer(Ptr)って名前は、システムとしてのポインタ(型)なのか
デザインとしてのポインタ(指し示すもの)なのか、って分かりづらくなる >>395
何を言ってるのか意味が分からないよ
システムとかデザインとか何のこっちゃw
世の中いろんなプログラマがいるが、PtrToReadなんて命名をする奴は誰もいないだろうw
よく見てみ
ReadPtrって書いてあるでしょうw
これは例えばキューみたいなものを実装する時に次のデータの読み出し位置をポイントするポインタ(読み出しポインタ)だ
だからPtrToReadPtr は「読み出しポインタへのポインタ」だw >>396
>PtrToReadなんて命名をする奴は誰もいないだろう
「普通にPtrToXxxかXxxPtrでいい」って>>385に書いてあるじゃん
>だからPtrToReadPtr は「読み出しポインタへのポインタ」だw
意気揚々と説明しなくても、そんなことは分かってるよ
>システムとかデザインとか何のこっちゃw
意味分からんか?
本来デザインとしての名称にシステムとしての名称が加味される状態だろ(strFoo、iBarなどのシステムハンガリアンみたいに)
PtrToXXXでもXXXPtrでもそれと同じな上に変に文章的な書き方をしたことでデザイン上の名称なのか区別がつき難い
fooPointerって変数があった時、それがポインタ型を表すのか、デザインとして指し示すモノって意味でつけたのか、分からないだろ
そんなのなら、まだpFooのような無機質な記号の方がまだマシだよ
こんなの、Bool型を返すプロパティを命題にするとか、プロパティ名は名詞にするとかと同じように特殊ルールなんだからさ
>>397
システムハンガリアンだよ >>398
よっしゃ、今日はこれぐらいにしといたるワ、まで読んだ
しかし、前置詞のtoと不定詞のtoに区別が付かないって真面目にいう人初めて見たよw >>399
その区別の話をしていないよ
文章の書き方が悪かったら申し訳ないけど、何でそんなふうに捉えるんだ? よしじゃあMemoryAddressPointerToReadにしよう ドラゴンボール的なものを想像して欲しいんだけど
かめはめ波を撃つとして
(1)手首を合わせて腰の横に持っていく
(2)エネルギーを貯める「かめはめ〜」
(3)手首を前に突き出す、エネルギー放出開始。「波!」
(4)敵に命中
(5)「行けぇ!!」とか「うおおおお!」とか叫びながら攻撃力アップさせる
(6)耐えきれなくなった敵が吹っ飛ぶ
というシークエンスに分割するとき、それぞれどういう単語を選んだら良いだろうか。
とりあえず
(1)PreliminaryAction (2)ChargingEnergy (3)MainAction (4)Impact (6)BlowingAway
まではそれっぽいのを探したが、(5)が全然分からん。そもそも適切な日本語も分からん。 >>405
BoostActionとかでいいと思うけど個人的にはMainActionがイミフ >>406
なるほどboost。
(1)が予備動作だったので、対になる主動作かなあって >>405
prepare
charge
fire / discharge
hit
empower / inject power
blow away
一部微妙? それならfireとboostに一票
6段階あるシーケンスで主処理って命名は危うい
目的は相手にダメージを与えることだからむしろboostが主ともいえる
解釈に差が生まれる語は避けるが吉
アクションと状態が一緒くたになってるからアドバイスが名詞と動詞で割れてる
状態遷移図でいう丸印と矢印ね あんまりアニメみないが、あのシーンは単に揉み合ってるんじゃなくて攻撃力をアップさせてるのかw
その発想は俺にはなかった
あの世界ではそんなことが可能なのか >>405
(5) はreinforce とかどうか
こういうのは軍隊用語引っ張ってくるとそれっぽいのが見つかりそう
Reinforcements は「増援部隊」の意味 しかし>>405は何なんだろう
ゲームのキャラクターの内部状態ではないようだし、映像のカット割りともちょっと違うような
仮に映像のカット名前なら(5)は接触中(KamehameHaContacting)とかかなあ
余談だけど、ちょっと気になってググってみたら、映像業界ではカット(本来はショットというらしい)の集まりを
シーン、シーンの集まりをシーケンスと言うらしい。
https://ja.wikipedia.org/wiki/シーン
どっちにしても、断片のことをシーケンスというのは言葉の使い方としてちょっと変でしょうw fireいいな。適度に短いし
あとreinforceは俺の厨二心へ実に刺さるチョイスだ
>409後半
言われてみればそうかも
>>410
どうなんだろうな。プリキュアとかでもあるし
>>412
ゲームの方
ただ格闘ゲーム的なものではなくて、かめはめ派的な攻撃のシーンの流れそのものを
分割処理しようとしてたので、カット割りっぽくも見えたのかも
シーケンスという用語云々については分からん 揉み合って攻撃力が上がるアニメといえばヴァルキリードライヴ マーメイド >>412
シーケンスは意味が多くて、文脈依存。
つながってるものなら、なんでもシーケンス。
C#のIEnumerableとかも。 >>412
映像業界のカットはフィルム映画の名残で厳密にはシーンを表してはいないでしょ
フィルムをハサミで切るからカットだよ
>というシークエンスに分割するとき
「かめはめ波」という1つの塊を動作という解釈で断片の集まり(シーケンス)として捉えてって言っているように見えるけど?
この場合、連続的に分割する時って意味でしょ >>416
全体的に何を言ってるのかさっぱり意味分からんけどw
>映像業界のカットはフィルム映画の名残で厳密にはシーンを表してはいない
だれもそんなこと言ってませんw
自分で言ってるようにシーケンスとういのは断片を集めて一列につなげたもの。
だからシーケンス「を」分割するならわかるがシーケンス「に」分割なんて意味が分からない 名前にこだわるスレではあるものの、助詞1文字違いの言葉のあやにいちいち草生やすのもいやらしいな >>417
シーケンスって一定のルールに従って何かが順番に並んでいるモノでしょ
つまり、かめはめ波って1つのモノ「を」動作単位のシーケンス「に」分割したんだよ
例えば、配列もシーケンスでしょ
確保されたメモリの塊(シーケンスではない)を型というルールで分割して配列(シーケンスである)にしている
何で分からないかなあ ついでに言うとさあ、上でC#のシーケンスという用語が出てくるけど、
このシーケンスという言葉にはむしろ「かならずしも配列のようにメモリー上に要素を持つとは
限らない」からシーケンスと呼ばれる。
例えば単に乱数求めて都度吐き出すだけでもシーケンス。
用法的にはシーケンス制御のシーケンスと同じ かめはめ波という動作をもっと細かい動作のシーケンスに分割(シーケンスとして表現)
言ってること理解できるし全く問題なし。 結構面白いと思うけどね。
ゲームプログラミングなんかで実際ぶち当たりそうな場面だし。 >>423
マジでこういう思考回路の人間がいるから世の中面白いねw
こんな人が何でこういうスレに興味を持つのか疑問だが
こういう人はきっと「関数を処理に分割する」んだろうw
普通の人は「処理を関数に分割する」んだが >>425
ヒント。
細かい動作『の』シーケンスに分割
と
細かい動作『を』シーケンスに分割<-君が>>425で出した例
全然違うから。 >>425
君はこのニュアンスの違いを理解してないだけw >>425は分割するの目的語を見誤ってるw
細かい動作『の』シーケンスは
細かい動作のシーケンスになるようにかめはめ波(省略)を分割する
って意味だから。 >>425
お馬鹿さん日本語しっかりしてくださいww
『分割する』の目的語は省略されてるんですよw >>429
粗みじんに切る
とか
千々に乱れる
の「に」だと言いたいんだと思うし、そういう反論は予想してたが、
それだとしてもちょと無理あるよ
元々の話は>>405がたぶんシーケンスって言葉のニュアンスを誤解してだだけの話。
別に誰もそれをことさら馬鹿にしてやしないし、無理して擁護することないと思うけど 「分割」の目的語は「かめはめ波という動作」で「もっと細かい動作のシーケンスに」は「もっと細かい動作のシーケンスになるように」の「なるように」を
長いので省略
「分割」の目的語を見誤やまなければ全然問題ない。君は>>425の例を出したように完全に見誤ってた。
>馬鹿にしてやしないし、
>マジでこういう思考回路の人間がいるから世の中面白いねw
>こんな人が何でこういうスレに興味を持つのか疑問だが
これで十分馬鹿にした言い方だろw >>433
質問者の誤用(たぶんね)を馬鹿にしてないとは書いたが、
君を馬鹿にしてないとは言ってないよw
まあ、もういいでしょ >>425のおまえが最初に馬鹿にし出したから、同じ事されても文句言うなよ。
短い1行の文の目的語すら把握できない日本語できないおバカさんww >>434
おまえが原因のくせに何がもういいだろだよ。カスww
日本語できない馬鹿が混じると話へんな方にいくからロムってろボケww >>432
ID:G3jvy5HTは>>412かな?誤用でも誤解でも何でも無いよ
君が指摘する「断片はシーケンスである」とは誰も言っていないんだよ
1つの物体に対して「何かの一連の集まりである」という解釈で観測している
件の場合は「かめはめ波」という1つのモノを「動作」という単位でシーケンスに分割して観ている
こういう抽象的な思考ってプログラムで要求されると思うんだけども大丈夫? >>437
何度も言うけど、そういうのは「短いカットに分割する」って言うんだよ。
あるいは、「短いカットをつないだシーケンスとして映像を構成する」なら日本語として正しい。
シーケンスに分割なんて表現はありえない。
それは分割統治されたメソッドや変数の集合として構成されるクラスを書くときに
「クラスに分割する」なんて言わないのと同じだ >>438
だから、君の言ってることも正しいが君が唯一間違ってるのは、片方だけがあってるんじゃなくて表現として両方問題なし。
君は表現力が乏しくて片方しか想像できなかったら、ファビョリ続けてる。 俺はシーケンスに分割なんて表現はお初やな
シーケンシャルな処理やデータって基本的に順次データの完成品みたいなもんであって、
こいつを編集分割とかするんなら、それこそシーンやカットをピックアップコピーペーストカット(削除)ソート〜
ということはあっても、シーケンスに分割って考え方は出てこない
シーケンス(な処理やデータ)を再構成するってなら分かる だから,「Aに分割」っていったとき、
1.「Aという最小単位に分割」
2.「Aという集まりなるように分割」と言葉厳密に分けると2通りある。
>>440とほざいてるアホは1.しか想像できてない。 おっ、言葉遊びの論破合戦やったんやな
失敬失敬
どうぞ続けてくれ >>438
「1つの物体を分割してシーケンスにする」って表現でも分からない?
「シーケンスに1つの物体を分割する」の「に」は「へ」に置き換えてもいい
「シーケンスに分割」って思うからおかしくなるんだよ
>それは分割統治されたメソッドや変数の集合として構成されるクラスを書くときに
>「クラスに分割する」なんて言わないのと同じだ
そりゃ、こっちはクラス視点で話をしているからな
君はそのメソッドや変数などの構成物視点で話をしてる
>>441も言ってるけど、両方の視点を理解した上でこっちは言っているのよ >>443
だな。「シーケンスに分割」を「シーケンスという最小単位に分割」と捉えると、
分割した結果の断片が最小単位であるシーケンスだから、
>「断片のことをシーケンスというのは言葉の使い方としてちょっと変でしょうw 」とか言ってる。
となるのは事実。
でも、他の捉え方もできて、
「シーケンスに分割」を「結果がシーケンスなるように細かく分割」また、>>443の「1つの物体を分割してシーケンスにする」と捉えると
意味通じるし、何も問題なし。
1通りの解釈しかできなくて、それが意味が通じなかったから、「誤用」とかいってファビョってるだけ。
>>405はだから、誤用なんかしてない。
まぁ、数学じゃねぇから生き物のような言葉に100%正しいとかはないけど。 まあ、毎度おなじみバカの壁だね
>>438にも書いた通り、壁の向こう側の人たちはクラスを書くことを「クラスに分割する」と表現するんだろうw
壁の向こう側の人口が少ないことを祈るばかり
日本のIT産業の平和のためにも しかし、この彼>>443にしてもそうだけど、
>>438でクラスを書くことをクラスに分割すると表現するのかと問われて何も自問自答しなかったのかw >>445
相手とのやり取りで理解を示すために思考もせず
自分の意見が正しい、他は間違いって凝り固まっている君の方がその壁の向こう側じゃね?
こっちはそっちの言っていること「も」理解した上で言っているんだよ
何で視点の違いが分からないんだろう
よくそれでオブジェクト指向やってんね 「物体を分割して細かい何かのシーケンスにする」するのを「物体を細かい何かのシーケンスに分割する」って言っても意味が通じるのに、
この馬鹿重症すぎる。 迷ったけどちょっとだけ捕捉
上に書いた「(玉ねぎを)粗みじんに切る」という表現が成立するのは
たぶん粗みじんが切るという動詞の修飾として、切り方の説明として成立しているからだと思う。
ではシーケンスに分割する、と言った時、シーケンスは分割方法の説明になっているだろうか?
なってないね。
なぜならシーケンスというのは断片が一列に(文字通りシーケンシャルに)つながった状態
を表す抽象名詞だからだ。 >>446
>クラスを書くことをクラスに分割すると表現するのかと問われて何も自問自答しなかったのかw
君はそれが変だと分かっていても、どういうことだ?と思考していないんだよ
ただレコーダのように変だ変だって繰り返しているだけ
よくそれでプログラミングやってんね
君の解釈とは違うから、別の解釈であることをずっと説明しているじゃん
まず、そこに聞く耳を持とうよ >>448
この彼の書いたものを見ると、そもそもシーケンスという概念がよく分かってないんだろうなとは思う。
>>447
この彼は自分を疑うことを知らない。
自分の批判を自分自身に向けることを知らない。
話にならないね >>453
じゃあ君もそのバカの仲間入りってことだね 俺は詳しい文法までは知らんが、おまえも詳しく知らないならちょっと突っ込んだ文法的な説明は無駄すぎてやめたほうがいい。
お互い説得力なさすぎ。 >>452
え〜?こっちはそっちの言い分を理解した上で説明してきたんだけど>>447をちゃんと読んだよね
ちゃんと意思疎通できているよね、不安になってきたわ >>454
なんでや???生憎バカの理屈は理解できんのやwwww ほんと、これに尽きる。
>「物体を分割して細かい何かのシーケンスにする」するのを「物体を細かい何かのシーケンスに分割する」って言っても意味が通じるのに、
>この馬鹿重症すぎる。
もう、今日のまとめはこれで。 >>460
おまえもバカやからw
何調子にのっとるんやバカwwww >>459
敬ww語ww使wwえwwバwwカwww
バカにするつもりでバカに絡んでバカにされた先輩、チワっすwww そもそもカメハメ波の送出過程とプログラムとがどう関係あんのか
小時間問い詰めたい・・・。 小一時間のことを小時間というのは言葉の使い方としてちょっと変でしょう?(便乗) >>464
その「シーケンスを個別アクションに分割」して表示したいんじゃね >>464
ゲーム中で、状態やモーションの状態遷移系を考えるなら、ふつうに関係あるぞ。 普通の人はリングを連結して鎖を作り、鎖をリングに分割する
壁の向こう側の人間は「鎖に分割する」
普通の人は車両を連結して列車を作り、列車を車両に分割する
壁の向こう側の人間は「列車に分割する」
普通の人はプロジェクトを作業工程に分割する
壁の向こう側の人は「プロジェクトに分割する」
普通のプログラマはクラスの機能をメソッドに分割する
壁の向こう側のプログラマは「クラスに分割する」 …いや、てにをはを間違えるとおかしなことになるぞ!
というのを分かりやす〜く例示してくれてるだけだろ 悔しかったからってしつこすぎだろw
いつまで続ける気だよ >>470
てにをはを間違えるとおかしな奴に絡まれるぞ!の間違いでは? >>473
本当は、てにをはが問題ではないんだけどね
誰も指摘しなかったな こんなに続くこと自体が双方おかしい
決着も相互理解も得られないことは解ってるくせに
信条もイデオロギーも絡まない、とるに足らない揚げ足とりと反論でここまで続くのは病的
残業のしすぎか?辛くなったら休めよ 頭いい俺は完全にわかった。
今回のポイントは「文脈」と「省略」。
今回は「文脈」を考慮して、色々単語を「省略」したら、誤解した人と意味をくみ取った人に分かれた。
で、誤解した一方の>>468は誤解したからなのか文脈もない省略もない基本的な文法にこだわって、
「AをBに分割する」のAとBを機械的に色々な単語に置き換えて、
>壁の向こう側の人間は「鎖に分割する」
と他の例を「勝手」に出してるけど、「もう一方の側は誰もそんな事いってない」。
この例は「文脈」も「省略」も全く考慮していない。
もう一方は今回の例の「シーケンス」と単語と「文脈」などを考慮つまり省略されたであろう単語を考慮して、
「シーケンスに分割」と言っても「意味が分かるよ」としかいってない。 つまり、
>>468はあくまでも「文脈」も他の単語の「省略」もないただのAをBに分割するの文法レベルの話で正しいだの間違ってるだの
の話に終始し、
もう一方は、文脈を考慮して意図をくみ取ったから、解釈の仕方を説明する事に終始してる。
どうだ?? だから、>>468は
>壁の向こう側の人は「プロジェクトに分割する」
>壁の向こう側の人間は「列車に分割する」
と言ってるが、勝手に妄想ででっち上げて、反論できないから俺正しいじゃんと思ってるだけ。
もう一方は今回の「シーケンス」という具体例と「文脈」で「省略されたであろう単語」を考慮して「意味がわかるよ」としか言ってない。
こうやってちゃんと>>468の主張に反論すれば>>468は黙るだろう。 黙らないに一票。
黙ったとしたら、単純に時間が空いたから。
いや、最近、そういうヤツをこのスレでよく見かけるんだよ。w
偏執狂的「理論」を垂れ流したあと、突然いなくなるという。 一言。
頭のいい人は簡潔を好む。だらだら要領を得ないことを書くことを好まない。
しかし、省略と来たかw
だったら省略する前の原文ぐらい書けばいいのに。 俺は基本的に人間に関しては悲観主義者で、壁の向こう側の人間を信用しないので
論理が通用するはずの壁のこちら側の人に対してだけ言う。
壁の向こう側の彼らは単純にシーケンスという言葉の意味を理解してないだけだ。
言葉を正確に使う意思と能力も足りないのかもしれない。
そして何より、自分を批判的に見る能力がない。
自分を批判的に見るためには自己信頼が必要だが、それがないんだろう。
こっち側の人間なら同じ「に」の使い方で意味が通るシーケンス以外の言葉を探して
自分の主張の正当性を示すぐらいしそうなものだが、それすらしようとしない グダグダ自分語りを始めちゃったよ
もうスレ違い(別の意味も含めて) >>482
>>478はつまり論点が基本ずれてるってこと。
これは君の主張の正当性が相手の主張の否定につながらないってこと。
例えると、この計算式の答えに君が答えながら、相手は別の計算式を答えてる感じ。答の値がちがくても式2つあるんだからどっちも正しい場合もある。
論点が同じ時だけ自分と意見がちがければ相手の意見を否定することになる 繰り返しになるけど、期待はまったくしてないけどねw
君にはたぶん無理だ >こっち側の人間なら同じ「に」の使い方で意味が通るシーケンス以外の>言葉を探して
>自分の主張の正当性を示すぐらいしそうなものだが、それすらしようとしない
だから基本論点が違う。『に』の正しい文法的に厳密に正しい使い方を問題にしてるのは君の論点で、もう一方は、省略されようが誤用されようがどうでもいい。 どうせ言ってもわかりゃしないと思うが。
繰り返しになるが、「シーケンスに分割する」という表現が成立するためには
シーケンスという言葉が分割の仕方に対する説明になっている必要がある。
別の言い方をすれば、他の選択肢が存在する必要がある。
シーケンスに、ではない別の何かに分割する方法がね。
粗みじんに切る、短冊に切る、サイコロに切る、といった具合に。
そんなものはない。
なぜならそもそもシーケンスというのは分割のありようを描写する言葉ではないからだ。
元の質問者のお題に戻れば、シーケンスという言葉はそもそも「かめはめ派のシーン」の言い換えに過ぎない。
それを短いカットをつないだシーケンスとして実現する別の方法なんか存在しないからだ 訂正
× それを短いカットをつないだシーケンスとして実現する別の方法なんか存在しないからだ
〇 それを短いカットをつないだシーケンスとして実現する以外の別の方法なんか存在しないからだ まともな教育を受けてたら
シーケンスを分割する
で通じるからな
まず低学歴知恵遅れはシーケンスの意味がわかってない
ここからも低学歴知恵遅れとは意思疎通が不可能なことが分かる 間違えてる言葉づかいでも通じるんだからこまけえことは気にすんな
はダメだな
それを読む側にはエラー補正を強いられてることも書く側は気にしろってことだ 理解力ねぇのか??
シーケンスを分割するが文法的に間違ってて
シーケンスに分割するが文法的にあっててるなんて基本的には言ってないんだよ。逆もしかり。
どっちが誤用してようと、他に単語省略されてようと、仮に文法間違ってても補正して『意味がわかる』って言ってるしだけ。
だから論点がずれてるっていってるの でもそんな揚げ足とりで毎回紛糾しててもしょうがないからね。まぁ今まさに紛糾してるが これで論点がずれてることの恐ろしさを理解できたかね?
もう一方の主張が>>488、>>490の意見が間違ってるなんて言ってない、合ってるとも言うのも目的じゃない。だって基本論点ずれてるんだから な、いまだにシーケンスの意味が分かってない
で、著しく頭悪い低学歴知恵遅れが顔真っ赤にして長文連投してるワケ
コレが低学歴知恵遅れ >>496のこっちのお馬鹿さんはわかって無さそうだが、>>488の方は理解できたんじゃないかな? バカはまずバカの自覚がないからな
だからバカは治らない
バカは根治不可能
ホントなバカの自覚がないバカは救いようがない 低学歴知恵遅れの自己評価の高さは異常だからな
それは底辺であるほど顕著に見受けられる傾向といえる とりあえず己の能力では連投しまくらないと説明できないことについて
相手の理解が足りないだのと馬鹿にするのは違うだろうな
前提条件をはっきりさせりゃ一行で済む内容なのに
相手を馬鹿にすることに命を燃やしてID真っ赤にしてるだけという >>492
君に何を言っても無駄だと思うが....
そもそも話は>>412から始まっている。
意味がわかると言ってるだけで文法的に正しいなどとは言ってない、だって?
それならそもそも俺に突っかかる理由は最初から何もないはずだ。
俺は何を言ってるのか分からない、などとは言ってないのだから。
言葉の使い方がちょっと変だ、つまり文法的におかしいと言っているだけだ。
論点がずれてる?誰の事だよ。大丈夫かほんと
君に限らないが、壁の向こう側の人種は自分の中に
一貫した主張や論理を持つわけでなく、相手の主張に場当たり的に噛みつくからこうなる しかし、壁の向こう側の人たちはあれかね、バグ出して叱られても
「ロジックが正しくなくても意図は分かるはずだ」って言い訳するのかねw しかし、誰か一人ぐらい>>488に対して
「いや選択肢はある。それは>>405が書いたシーケンス以外の別のシーケンスだ」
って反論するのを期待してだけど誰もいなかったw
ではそろそろさようなら >>501
だから君と重みが違うんだろ。ガチガチの文法の命の男ににもっと、軽いのりの文法とか深く考えずに、意味がわかるからいいんじゃねみたいなノリで。
流れ見直すと、文法が正しいか正しくないしかしかの話に終始してる男にもう一方はどっちかというと、解釈の仕方がメインでこう捉えれば?が話の流れにしか見えない。一方が文法の詳しい話しても、もう一方はめんぐせそうに避けてるし。
多少流れにぶれあるけど、骨格はそう。 だから元から論点が違う、もっと砕けた言い方すると、興味ある部分、重要視してる部分が違い元から土俵違って、一人相撲がメインだったのに、隣で張り手しただけなのに自分に飛んできたと勘違いして、お互いヒートアップ。 同じことしか繰り返してねぇけど、まぁ、俺の意見はそういうこと。 >>501
うん。だから、そこは謝る部分はある。
誤用してようが、誤用してまいが、「いいたい事分かるしというレベル」で別に「誤用」してないという軽い気持ちで最初に突っ込んだのは事実。
俺の発端はこれ。
だから、>>432や>>449で文法深く突っ込んできてもどうでもよかったから、>>455で逃げたのも事実。
こっちからも文法の話絡めてるけど、それは、相手の興味のレベルまで頑張って下げようとして、答えてる部分もあるから、今思うと
無理やりすぐにひねり出して一貫性ないのがある部分も事実。
それはお互い様の部分もある。君は文法の正しさしか興味なかったら、こっちの話は興味まったくなくて、一切、合わせようとしなかった。 だから、言い訳すると、相手の興味のレベルに合わせることは大変なんだって。
君は文法の正しさしか興味なかったのが一貫してるのは事実で、
>こっちは、誤用してまいが、「いいたい事分かるしというレベル」で別に「誤用」してないという軽い気持ちで最初に突っ込んだのは事実。
と書いたように、元から興味のある部分が違ってから、途中からずれちゃった。だからは、俺は誤用してようが誤用しいまが
それを補正してどう解釈すればいいかみたいな話だけしか興味なかった。。
だから、お互いの興味のある部分、論点が途中からずれてた。
悪かったよw >>501
最後に君が一番知りたい話で締めくくらせてもらうと、「シーケンスに分割」は誤用だな。
俺の中じゃ一番初めに「Aというシーケンスに分割」でシーケンスはAの並びだからつまりこの場合、「Aに分割」って言いたいんだろうなって、
本当の文法の正確性を全く考慮しないこんな感じの論点で言いたい事わかるから「誤用」じゃないって速攻で決まってて。
文法のこと内心は本当はどうでもよかったら、君の数々の「文法の正当性」発言を何この主張?意味わからねぇー。めんどくせぇー。で
しっかり考える時間もなかったし、考えたくもなかった。
で、やっと、君の興味のレベルに下りて考えたら君の言いたかった事と途中で論点がずれてるのに気づかない自分とかにも気づいた。
悪かったwすまん。 >>415
アテナに出てきたら2Pだもんなあ。
意味が多すぎる。 メンバ変数hogeに対して
null(デフォルト)、定数FOO、BAR、BAZ… の値が指定できる
・hogeに引数で指定した任意の値を代入:SetHoge(arg)
・hogeをデフォルトに戻す:InitHoge()
が既にあるとして
・hogeに決め打ちでfooを代入(引数なし)
・hogeに別処理で選ばれた値を代入(引数なし)
を加えるならどうする?
SetHogeToFoo()とApplyHoge()とか? hogeって変数の存在が表に出すぎじゃね?
もっと裏の意図がわかる名前がよかったりしない? >>513
set_hoge_FOO
set_hoge_BAR
これくらい割り切れば。
英語をこねるよりもわかりやすいやろ。 >>514
出来るやつは幾つかそうしたんだけど
ちょっと思いつかないやつがあってなあ
>>515
そうかもしれない 定数FOOを決めうちでセットさせたいときは素直にsetHoge(FOO)でしょう
静的型付け言語ならFOOをタイプセーフな定数として宣言すると収まりがいい
いちいちsetHogeFoo()等をとりうる値全てに用意するのはナシ
値FOOにだけ専用メソッドが欲しいと感じるなら特定の関係性があることを示唆しているはずで
その関係に相応しい動詞や名詞を探すとしっくりくるかも >>517に同意
hogeを保持するオブジェクトにおけるその決め打ちとは何ぞや?って考えてみたら良いんじゃね
あとInitHoge()みたいなのは正直いらないというか、表に出すようなものじゃない レイヤを曖昧にしたままで名付けようたするから
回答側も無意識に想定しとるレイヤで自由気ままに答えるわなそらw 名前付けはプログラムの10%くらいは占める大事な要素なんです。 >>517には同意
>>518
> あとInitHoge()みたいなのは正直いらないというか、表に出すようなものじゃない
意味わからん
既定値に戻したいことってそれなりにあると思うが
まあ俺ならSetDefaultHoge( )とかResetHoge( )とかにするけど 亀
>>517他
FOOだけならいいけど、実際には
SetHoge(VeryLong.VeryLongLong.VeryVeryLongLong.BAR) だったり
SetHoge(ARG_BAZ1,ARG_BAZ2,ARG_BAZ3) でワンセットだったりするんだよな
前者のパターンはともかく(いくらでも短縮する方法があるので)
後者に関しては、専用の関数を作っちゃうのが楽かな?って発想だった >>522
複数の値を取るものは引数同士の結び付きと、親との関係性による
SetHoge(春、夏、秋、冬)ならSetHoge(四季)が自然
四季という組み合わせ方がそのクラスの機能の一部として隠蔽されているのはおかしいので専用メソッドは変
Set(しょうゆ、みりん、酒)ならSetHogeFor割り下()もアリかなと思う
レシピを型として用意した方が綺麗だとは思うけど、調理人Interfaceの固有知識と捉えても差し支えなさそうなので なるほど、ありがとう
あと、その語のチョイスに至った言語センスを分けてくれw 永続するデータの変化点を時刻と共に持ち、変化点をまとめてデータの移り変わりを表現したいと思っています。
この場合、変化点に望ましい名前は何がありますでしょうか?
timeSectionなどでしょうか?
何か良いものがあれば教えて下さい。 その前に変化点って日本語が何を意味してるのか全然分かりません。
構造体の中で値が変化したメンバー(の名前)とかそういう意味? 値の変化だとたんにchangeってこともあるし
状態の変化だとtransitionがよかったり。 >>525
素直にChangingPointで良いかと 時系列で持つデータは名前にそのニュアンスを入れないという選択もある
データベースの履歴テーブルとかそう
イチイチChangePointだのTimeSegmentだの付けてるとくどい
集合をhistoryと呼ぶのは慣例的によく使うけど、その個々のエントリーに対してhistoryと呼んでしまったら微妙
versions, revisions, snapshotsあたりもアリかな 点(タイミング)に焦点合わせてるみたいだけど
「データの移り変わりを表現」なんだから流れとして見てログとかじゃダメなん? >>529
素直も糞も、だから変化点でもChangingPointでも何でもいいけど、それって何なんだとw
率直にいって質問者が何を言ってるのかさっぱり分からんけど、
よくこんな意味不明な質問にみんな解答できるよなw 悩ましいネタだからもう少し具体的に書いてくれた方がいい答えが付くのにとは思う
プライバシーを晒したくないなら似た何かに置き換えてくれてもいいし
せめて変化点が4M管理の話なのか実測データのプロットなのか何かの改編履歴なのか…
命名ってデリケートで、一般化して質問されると回答も抽象度が増してズレることが結構ある マジで
> データの変化点を時刻と共に持ち
で何をしたいのかがわからん奴は黙ってて欲しいわ
4M管理とか頓珍漢すぎるし >>535
そういう御託はいいから、本気でそう思うなら変化点とやらが何を意味してるのか説明してみ。
まあ無理しなくていいよ。
この手の輩は物事を深く考えてないだけ。 引っ込みつかなくなってるのか?
Time | Data
00:00| 001
00:01| 001
00:02| 002
00:03| 003
00:04| 003
00:05| 002
00:06| 002
00:07| 002
00:08| 001
00:09| 001
みたいなデータを
Time | Data
00:00| 001
00:02| 002
00:03| 003
00:05| 002
00:08| 001
のようにして管理したいってことだろ 何が引っ込みなんだろうねえ
意味がわからないよ
求められてるのは変化点が何を意味してるかなんですが。
それ、時刻と一緒にデータそのもののスナップショットを保存してるだけじゃないのアホか >>538
> それ、時刻と一緒にデータそのもののスナップショットを保存してるだけ
わざわざ
> データの変化点を時刻と共に持ち
って書いてあるのに… >>540
頭悪そうだけど、>>537で「時刻と共に持」っているのはデータのスナップショット。
マジで大丈夫かおたく はいはい、理解力が壊滅的に無い奴に何言っても無駄だわな w まあこのお馬鹿さん以外の人に言うけど、最初から言ってるように変化点が何を意味してるのか、
それを厳密に定義するとどういうことなのか、深く追求せずに曖昧なままイーメージ的にとらえると
彼みたいな訳の分からん話になる。 ID:ToRrrvnY
あほなのかな。
わからんならだまってればいいのに。
めんどくさ。 >>545
馬鹿はお前だよ
お前が質問者の求めているものの意味が分かるなら黙って解答すればいい。
それもしないで他人に喧嘩うってるじゃねえよ馬鹿が (a) 変化点 = 変更された時刻 + 変更後のデータ
仮にこういう定義なら>>525の「変化点をまとめてデータの移り変わりを表現したい」
と整合性がある。
>>525の質問が謎なのは、その前段が、
>永続するデータの変化点を時刻と共に持ち
ってなってること。
つまり変化点は時刻を含まず、(a)の定義はありえない いや、最初は単純に、
(b) 変化点 = 変更後のデータ
のことを言ってるのかとも思ったが、それだと質問者自身がこれをtimeSection
と仮に命名してることと整合性がない > お前が質問者の求めているものの意味が分かるなら黙って解答すればいい。
> それもしないで他人に喧嘩うってるじゃねえよ馬鹿が
既に>>527-531辺りで回答されてるのに何言ってるんだよww
> それもしないで他人に喧嘩うってるじゃねえよ馬鹿が
こんなわかりやすいブーメラン久々に見たわ 俺はネトウヨじゃないけど、ほとんど韓国人の理屈だなそれw 525です。
色々な解答ありがとうございます。
具体的にと出たので後出しで申し訳ないのですが、どのような物を想定しているかを書かせていただきます。
547さんのa)そのままなのですが、DBを利用し、
変更された時刻と変更後のデータをテーブルに保持します。
上記テーブルから「変更された時刻」から「直後の変更された時刻」までを期間として持つビューを作成し、実際に利用する際はこのビューを利用します。
今回は、a)のテーブルにどのような名前(の要素)を付けたら良いかと思い質問させていただきました。
timeSectionは思い付く単語を並べただけですので無視してください。 やっぱりごくありふれた歴アリのテーブル構造だよな
ならcustomerテーブルやelectric_currentテーブルみたいな簡潔な名前ではダメなん? >>553
心配しなくても誤解してるのは1名だけww
普通はあの書き方で充分わかる >>552
くどくて済まんけど、要するにsnapshotだよねそれ。
差分とかじゃなくて変更後のベタなデータなんでしょ? >>547
aだってよ?w
おまえいがいはそうぞうがついてたが。
これからは、わからんかったらだまってるようにな! >>556
snapshotは違う気がするな。
スナップショットはあんまり連続させないし、ふつうは対象が変化自体ではないからか。
上にも似たようなのがあったけど、ValueChangeくらいでいいんじゃないの? >>557
>そうぞうがついてた
頭悪いね。
問題にしているのは質問文から「変化点」の意味を正確に読み取れるかどうか。
質問者自身が認めているようにそれは明らかにNoだ。
俺が想像したのと大体同じ、だから俺の勝ち、これガキの論理。
>>558
https://wa3.i-3-i.info/word14388.html あとどうでもいいけど、>>552を読む限り質問者さんの言う変更点って
>>548に書いた(b)なんじゃないの? >>559
もういちどいってあげるけど、ひとりいがいはよみとれてたよ?
しつもんしゃのけんそんをこんきょにするなんて、あほのうえに、ずうずうしいぞ。 525です。
皆様色々なご解答ありがとうございました。単語の意味などを調べつつ適切な物を選びたいと思います。
自分の質問が悪かったのですが、
変化点=変更後のデータ
欲しかったもの=変更時の時刻と変更後のデータを表す命名(の要素)
となります。誤解を招く質問で申し訳ありませんでした。 >>554さん
実際のデータ(の表現)はviewで、変化した時点のデータのみをテーブルで保持したいので、提案いただいたものはviewにつけたいと思っています。
>>556さん
リンクも見させていただきましたが、snapshotとは少し違うかと感じてしまいました。
自分が抱いているイメージとしては、
金太郎飴(ストリーム)と切断面(時刻と変更後のデータ)になります。
今回は切断面の名称だったので。
長々と失礼しました。 んーよー分からんw
ゲームのコントローラーの入力状態の履歴みたいなイメージなんだろうか。
それならsnapshotは違うというのもちょっとわからんでもないけど...
しかし、状態変化直後の状態の写し(スナップショット)の記録に違いはないと思うんだけどな 質問のポイントは、金太郎飴な等間隔時系列データ(VIEW)と、変化点だけに圧縮した時系列データ(TABLE)の2つのオブジェクトをDBに作るから、それぞれを識別できるように名付けたいということだな
しかも集合と要素のどちらも呼び分けたいという思いがあると 要素には別々の名前をつける意味はないと思う
そのTABLEはVIEWの部分集合に他ならないから、集合だけに個別の名前を与えるのが妥当
集合の名前については、繰り返しになってしまうけど、永続化するときに変化点だけに圧縮するのは最も一般的な時系列データの持ち方だから、俺なら等間隔に展開した冗長な(奇異な)VIEWの側に説明的な名前をつけて欲しいわ
前か後ろにequal_intervalを付けるとか
そもそもその奇異なVIEWの存在意義が
気になる
速度もメモリ量も性能悪そう
ツリー構造の索引を持つデータとしてメモリ内に読み出しておいて、任意時点のデータを取るメソッドを付けて、必要ならflyweightパターンにしたい
もちろん事情があるならそのままでいい 525です
>>565さん
自分がスナップショットの意味を取り違えていると思いますので、意味を調べ直してきます。
>>566さん
今想定しているのは時間は等間隔ではありません。状態やデータが変化した時のみ保持し、不規則なデータの移り変わりを表現したいと考えています。
>>567さん
今のところは、主体をview、変化点(と言ってしまいますが)は要素として考えています。
この考え方は自分の知識が弱いこともあると思いますので、改めて考え直してみます。
金太郎飴の例が悪かったですね。
今後は伝わりやすい例を考慮してから質問させていただきます。 Change Update
Log History
ここらへん組み合わせればいいんでないの >>567
まだ言ってるのかよ…
> そもそもその奇異なVIEWの存在意義が気になる
> 速度もメモリ量も性能悪そう
>> 命名規則や設計の善し悪しについて議論するのは基本的に禁止。 >>521
今更だけど
オブジェクトそのもの(あるいは一部)を初期化するメンバ関数は基本的にPublicになることはないかなって話
例えば、init()、update()、final()ってメンバ関数があったとして
init()→update()→final()の一連の流れをオブジェクト利用者に約束事として強要しちゃうわけよ
final()で一旦終えた後に、init()せずにupdate()しちゃったらオブジェクト内部がおかしな状態になるかも知れない
じゃあ、final()の中でinit()しちゃえばいいよねってなるけど、final()(init実行)→init()って無駄なことをされてしまう
そうするとinit()が邪魔になり、コンストラクタ内でinit()を呼んで、利用者に好きなだけupdate()させて
final()(init含む)で結果を受け取ってもらった方が分かりやすいよね
利用者が「この処理やーめた」って出来るようにオブジェクトそのものを初期状態へ戻すreset()のメンバ関数を
増やすのなら分かるけど、利用者からしたらいちいち処理の最初に呼び出すinit()は要らんよね
同様に一部のメンバ変数へのSetter(再代入、初期化)は極力排除するべきだと思うよ
オブジェクト内部で処理される絶えず変化するメンバ変数なんて外部からSetするようなものじゃないし
逆に処理に利用される外部から能動的に値を変えない限り定数状態になっているようなメンバ変数なら
オブジェクト構築時に初期化するようにして、それらの値を変えたいなら新しくオブジェクトを構築したら良いと思うよ >>571
> じゃあ、final()の中でinit()しちゃえばいいよねってなるけど
なりません
コンストラクタ/デストラクタを持ってる言語なら init() はコンストラクタで、final() はデストラクタで呼び出せば良い
再利用したいなら削除して再度生成すべき
コンストラクタ/デストラクタを持ってない言語ならinit()→update()→final()を強要するんだからfinal()した後で再利用したいならinit()から強要すべき
中途半端にfinal()の中でinit()なんて呼び出すべきじゃない
そもそも再利用しないならそのinit()は無駄だし >>568
いや、「スナップショット」についてのその感覚は正しいと思う。
再確認するのはいいけど、言われたことにあんまりこだわらないようにね。
って、もう来ないかな?
オレとしてはいろいろ出ていたchange系の名前がよさそうだと思ってたけど、気に入らない理由を聞きたかった。 語感の問題なんだろうけど、スナップショットは任意のある時点って感じで、変化時点って意味は含まなさそう。 >>572
>final()はデストラクタで呼び出せば良い
ああごめん、それらのメンバはオブジェクトを構築破棄する意味合いが強いものじゃなく
そのオブジェクトの目的を処理する意味でのinit()とfinal()
例えば、ハッシュ関数、データを繰り返しupdate()してその処理を終わらせるfinal()
final()はハッシュ値を返すみたいな
>コンストラクタ/デストラクタを持ってない言語なら~
そりゃそうだ
>そもそも再利用しないならそのinit()は無駄だし
その対比として再利用するreset()メンバ関数を例に出したんだけどね
init()は少なくともコンストラクタとreset()の中でコールされるよ
で、オブジェクトの初期化と処理の初期化を1つにして
もし処理を初期化するinit()メンバ関数を設けるなら、publicにはしないよって話だよ >>574
スナップショットって「ここで記録を残したい!」って、それを取り扱う側の任意が強いよね
変化したポイントを必ずしも残したいとは限らないからちょっと違うイメージだな >>576
それは確実に違うw
https://wa3.i-3-i.info/word14388.html
↑の人が簡潔に書いてるように、「何か」のある瞬間の丸ごとの写し、という含意しかない
人が意志を持って作ろうが、一定の間隔で機械的に作成されるものであろうが、それは関係がない 完全に蛇足だけど、VirtualBoxみたいに
完全な写しではなくてもある瞬間の状態が再現可能なデータのことを
スナップショットと呼ぶケースもあるとは思う >>574
変化直後の値であることを名前で明示する必要があるかは微妙だと思う
だって例えば一定間隔でサンプリングされたデータだったらいちいちそんな名前付けんでしょう。 >>525はデータ自体の持ち方より変化した時のみ記録すると言う事を言いたい
って言うのは1名を除いてみんなわかってる話
なのでスナップショットの議論をしてもあまり意味がないと思う >>575
> そのオブジェクトの目的を処理する意味でのinit()とfinal()
> 例えば、ハッシュ関数、データを繰り返しupdate()してその処理を終わらせるfinal()
> final()はハッシュ値を返すみたいな
それならそんな変な名前をつけるべきじゃない
普通にget_result()とかでいいだろ
> init()は少なくともコンストラクタとreset()の中でコールされるよ
>>521が言ってるのはreset()の話な
> まあ俺ならSetDefaultHoge( )とかResetHoge( )とかにするけど
って書いてるあるから普通理解できると思うが >>577
あるにきまってんだろ。
それに、「スナップショット」は、IT用語のスナップショットの意味も強すぎる。 >>580
だから、そんな必要はないだろうと言ってる。
タイムスタンプとデータの写しが保存されていれば、常識的にそれは変化の先頭を
記録したものだと分かる。
それは繰り返しになるが、データの羅列(とサンプリング間隔)を見たら
いちいち一定間隔でサンプリングしたデータだなんて言わなくても分かるのと同じ
そんなことよりそれがナニであるかの方が余程重要な情報だ。
まあ仮にどうしても必要でも、例えばsnapshotOnChangedとかすればいいだけの話だけど
>>582
ないから。
あるというならそう言ってる人の記事の一つでも出してみ。
君が勝手に狭義に思い込んでるだけ。 しかし、すぐに喧嘩ごしで物を言ってくる馬鹿がいるな。
しかも言ってる内容がほんとしょうもない >>583
「スナップショット」は普通に使う言葉なんだが。w
狭義といえばそうだが実際にそうだから。
喧嘩腰に相手される理由を自省しろ。 >>581
そのレスを否定も何もしていないよ
同じことを言っているだけなんだけど、initやinitializeって名称のメンバ関数を表に出すことはなく
初期化は利用者が能動的に使う名称にした方が良いねって説明しただけだよ
で、後半にメンバ変数を個別に初期化するような処理を持たせるにも条件が有るよねって書いたのよ >>583
全体的にほぼ同意
タイムスタンプのフィールド名がただの時刻じゃなく有効期間開始時刻みたいなニュアンスでキーになっているテーブルならもう誤解する人いないレベル
妥協案としてのsnapshotOnChangedもいいな
changeが原形で出てくるとどうも動詞っぽくて座りが悪し >>583
> タイムスタンプとデータの写しが保存されていれば、常識的にそれは変化の先頭を記録したものだと分かる。
等間隔でタイムスタンプとデータを記録することなんて普通にある
> そんなことよりそれがナニであるかの方が余程重要な情報だ。
だからそんなことを思ってるのはお前だけ emploee_with_mail_addressとか
emploee_with_optimistic_lockingみたいなテーブル名が冗長なのと同じ理由で
emploee_snapshot_on_changedなんて説明的な名前になるのだとしたら
本来こっちがemployeeだよなあとは思う ここまで読んだが、スナップショットの定義論争する意味ある?
使ってもいいし使わなくてはならないこともないレベル >>586
> 初期化は利用者が能動的に使う名称にした方が良いねって説明しただけだよ
だから
>> まあ俺ならSetDefaultHoge( )とかResetHoge( )とかにするけど
って書いてあるのに、バカなの? >>590
> ここまで読んだが、スナップショットの定義論争する意味ある?
ない
最初にスナップショットって言い出した>>538が一人でしつこく食い下がってるだけ >>591
書いてあるから何なの?
そのレスの人は自分はそうするって書いているだけで何故かを書いていないでしょ
それをこっちは説明しただけじゃん、何で突っかかってくるの?
まあ、その例に対しても>>571の後半でこっちの意見が書いてあるけどね
この場合はそのレスの人とは意見が異なるよ そう言えば普通に理解できる人じゃなかったんだな…
1ヶ月以上も前のレスに粘着するような人だと言うことを忘れてたよ w 常に差分だけを記録するって
あんまり得策とは言えないからな… 変数名はよく迷うんだけど、
最近、本当に迷っているのは変数名自体じゃなくて、
日本語の英訳だと気付いた。
ググっても、いまいちしっくりこないんだよな。
状況的にこの訳でいいの?って。 たしかに迷ったら書き込むスレだが、そんな日記かポエムはいらん >>597
>>596はええ事ゆうとるやん
おまえのがいらんわw 絶対自分しか読まないなら、そうするけどな。
Dim ななこSOS As Long とか。 Const くりいむレモン As String = "亜美" マス目の中央に十字に線引いて、左上、左下、右上、右下と「田」の字型に4分割していることをイメージさせたい時、
どう短い英単語で表現したらわかりやすいでしょうか? >>611
イメージ的にはライフルのスコープのあれ?
reticleと言うらしい
後は素直に4分割でquarteringぐらいか キューブ4とかスクウェア4とか、そんなんしか思い浮かばん。 >>611
その形が重要なの?目的っぽい名前にはできないの? >>612-616
調べたところ象限という表現が近いと思います(多分
いちばんパッと見て馴染みやすそうなquadrantにしようかと思います
ありがとうございました >>617
形と言うか
中央を基準に左上・左下・右上・右下の4つに分類したいと言った感じでしょうか >>618
象限っていうのは普通は四つに分けた一つのことなんですよw
第〇象限って高1で習ったでしょ。
数学の言葉を使うなら╋は直交座標とかデカルト座標とか言う
でも冗長だと思う SWOT分析みたいな分割図の区画を描くようなイメージなら象限とquadrantでいいんじゃない 象限て久しぶりに思い出したわ
たまには為になるなおまえらもw 2×2であることが自明なんだったらgridでもよさげ そろそろ positioning map でググれ ポジショニングマップって…
さすがに的ハズレすぎだろ quadrantで画像検索するとそれっぽいのが出てくるからこれでイメージ合ってりゃquadrantでいいんじゃね
各領域の呼び方も決まってるぽいし
https://www.google.com/search?q=quadrant 同時に処理できる最大数(制限値)を示す、短い変数名をお願いします >>633
結局さ、「処理」っていうのが抽象的過ぎるから命名に困るんだと思うけどねたぶん。 短くしたいなら漠然とした一般的な部分は削除候補になるので
max_parallel 外部からこの処理やってねって頼まれる場合なら
AcceptLimit? >>636
parallelはちょっと読みすぎやろ。 え?proc_maxも最大プロセス数みたいな感じじゃないの
バッチ処理やバッファリングのサイズ上限みたいなイメージってこと?
むしろRunLimitあたり「魔法のランプは3回まで」みたいな回数限度で、同時であるニュアンスが落ちすぎだと思ってたわ
まあいくつか挙がった内から近いものがあれば選べばいいとは思うが ボタンをn回押すと実行されるイベントがあります。
(回数nは別途指定します)
n回押されたとき、その時刻を設定ファイルに記録するのですが
そこに使うキーとなる文字列をお願いします
foo: 1970-01-01T09:00:00
みたいな感じです >>642
> foo: 1970-01-01T09:00:00
> みたいな感じです
それでなんの問題があるんだ?
あとスレ違いだし ありがとう
特定回数という意味はあえて入れないということかしら >>645
ボタンn回押すのが何かのコマンドか何かであるなら、それを名前に使った方がいいね。
そういうのじゃなく、本当に純粋にボタンがn回押されたタイミングを記録したいだけだとすると
なかなか適切なのが思いつかんなあ >>646
具体的なイベントもコールバックで指定されるんで
なにかが起こるとしか言えない感じ >>647
そういう漠然としたものに名前を与えろっていうのも無理筋な気がするw
まあOnEveryNthClickとか? あーなるほど
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()みたいなメソッド追加すればいいんじゃね? そうですか、型は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という命名は拙い >>806
なるほど、では君はファイルシステムで上位のディレクトリのことを親って言わないんだねきっと。
どういう問題領域のどういう対象であろうと、それが木構造にみなせる以上、親は親だ。
普通はそう考えると思うけど 「金槌しか道具を持っていない人は、何もかも釘であるかのように取り扱う」by マズロー >>809
ふつうじゃねえよ。異常。
独立したものの参照関係がツリーのように見えているだけで、本質的には親子関係が成立するツリーじゃないぞ。 >>811
それは君がツリーっていう言葉の語感に影響されているだけ。
だからUIみたいに「見える化」されているものだけを指すと勘違いしてるんだろう。
抽象的な思考が苦手なタイプによくある勘違いだ。
木構造は単に論理的な関係を表現しているだけだ。
っていうか自分でツイートとそれに対するリプの関係を図示してみろって。
それ、ツリーそのものだろアホか。
っていうかだから、直上のディレクトリを親と言うのか言わないのか、答えてみろって。
頭悪いにも程があるよほんと >>810
こいつも何か言ってるつもりなんだろうけど馬鹿だよねw
悪いけど「バカの一つ覚え」なのはそっちの方だ。
何もそれを表現するより具体的な表現や用語があるのなら
木構造だの親だの、そんな抽象的な言葉を使つ必要なんかない。
ディレクトリの例もそうだが、それがないから「親」と呼べばいいじゃないかと言ってる。
なのにこの手の御仁は「もっと具体的な言葉を使うべきだ!!!」というバカの一つ覚え。
笑えるね 本件はツリーだけど親子関係ではない
ディレクトリではなくメールボックスをツリー表示したようなものだから、
返信メールを子とは言わないしレス元のメールを親とは言わないけどツリーではあると
と横からレス >>814
論理的な関係を表現していると言ってるそばからこれだ。
何を言ってるのか意味が分からないよ。 あ・・・この人は・・・
君以外全員馬鹿ってことでいいよ
円満解決だ いやいや、全てにおいてあなたの大勝利で結構ですよ
その他の犬共に侮蔑の言葉を投げつけてくださいワンワン しかし、ツイートとリプの関係を図示するってそんな難しいか?w
10歳ぐらいの子供でも図示なんかしなくても頭の中で描けると思うけど。
それ以前に親が変だと思うならもっとふさわしい表現を出せばいいのに。
ここそういうスレでしょ。
少なくともin reply toじゃ「に対する返信」で、意味不明は言い過ぎとしても
分かりやすいとは言えないよね。 見た感じメインは罵倒みたいだし議論する気には見えないな
おっとワンワンワンワンww >>813
具体的な表現がないって、InReplyToとRepliesというまさに具体的な回答が出てるだろ
その回答を論理的に否定しないと皆は納得しない
お前がなんで不満なのかはわかるよ
英語ネイティブであるAPI設計者の名付けに対して
> IN_REPLAY_TO_TWEET_IDなんて意味不明だから
なんて赤っ恥なツッコミをしてしまったから引っ込みがつかなくなったんだろ?
でももういいだろ
間違えることもある
そこからどう行動するかが大事なんじゃないのか >>819
言えないよね、っていうのは感覚だよね
女子っぽく同意を求めてもそれなと答えてくれるのは仲のいい子だけ
最終的に感覚に頼るしかないなら、自分の感覚と他人の感覚を同じように尊重することだ
しかし周囲が全員、低い英語力のコーダーしかいない環境ではChildrenの方が通りがいいケースはあるだろうな ID:ZDqxsHuV 必死過ぎて見てて恥ずかしくなる >>815
そうそう、1対Nになる論理的な関係はすべて木構造ですよねw
論理的な関係で言えばデスヨね
「論理的」とは何か「関係」とは何か
それすら理解できてないバカには何を言っても無駄ですよw
図示してツリーになるやつは全部Parent/Childrenですもんね
抽象的思考が苦手なバカwはこんな簡単なことも理解できないんですかね?
「バカの一つ覚え」とはよく言ったもんですねw 他人をバカにするなら
少しは書き込みを見直した方が良いかと >>806
構造まで名前に入れるのはプログラムの世界では良くあることだよ >>815
君が論理的にっていいながらディレクトリ構造を持ちだして親子親子言ってるから、
メールボックスのツリー構造を例に出してこれは親子とは言わないよなってツッコんだら
意味が分からないとかもっとふさわしい条件とか、君こそ馬鹿の一つ覚えの
主張しかせず全くツッコミ内容に触れずに相手を馬鹿にすることに全力賭けてるもんだから、
ワンワンとしか言えないなって話になる 有向グラフなのか無向グラフなのか
順序関係なのか半順序関係なのか
この辺で親子という表現を使うかどうかが決まる この件が親子関係になるんなら、この一連のレスバにも親子関係があることになるが
ちょっと意味が分かりませんね >>830
決まらん。
ひょっとして、ツリーバカと同一人物? 各ノード
親は高々1人
子はゼロ人以上
ループはない
グラフでいうと
親から子への有向単純グラフ
全ての点は、それに向かう辺が1個以下
閉路は含まない
連結の条件は不要かな >>825-826
ちょ、皮肉殺しのマジレスやめてー 自分が分かってない事を分かってないってほんと怖いね 皮肉って言葉の意味わかってんのかコイツ
自分が議論に窮した時に使う言い訳じゃねえんだぞ >>829
メールボックスのツリー構造も親子というと思うけど
なぜディレクトリは親子で、メールボックスは親子ではないの?
構造はどちらも同じだろ >>841
俺の親はお前なの?
俺が>>829にも安価付けてレスしたら兄弟にもなるの?
ディレクトリ構造とは全く違うわな >>842
安価もツリーと見なしたら、親子関係にあるとも言えるでしょ
見方によって変わるものを、一面だけ見て決めつけるのも違うと思うんだがな 「お前を俺の親と見なしたら、親子関係にあるとも言えるでしょ」w メール
送信者→親
受信者→子
受信者が送信者に返信
元の送信者→親であり子になる
受信者も→親であり子になる
だからおかしくね?って話だと思ってた 別にコードを書くにおいてメールを親子関係としてネーミングするのは自由にしたらいいと思うけど、
送信者X→相手A,B,C
A返信→X
B返信→X,A,C
この組み合わせが変わったりして続くとか普通にあるから、親子関係に当てはめられても人間から見て分かりやすいか?って話
元レスのtwitterの件も同じカテゴリ
もちろん親子関係が成立するメールもあるけど、必ずしもそうならないって話
なのでディレクトリとは明確に違う(ハードリンク云々はおいといて) まだこの話してるのか
いやメールのスレッドが親子じゃないという例は微妙かなと思ったよ
でも蒸し返してもいいことないぞ
結局スレの趣旨的にはメールの返信元にあたる変数をParentと名付けるのが妥当かどうかという話になる
どう考えてもReplyToだろ
RFCで定められたスタンダードにはかなわんということでFA
もうこの話は勘弁 元の話はTwitterやぞ
何がRFCやねんアホか 何の用語に採用されてようと意味が通じれば別にいいんだけど、
in reply to ってたぶん副詞句なんだよね。
まあそういう不細工さには目をつぶるとしても、
InReplyToっていうメンバー変数を持つクラスのインスタンスがあるとして、
InReplyToのtoがInReplyTo自身に掛かるのか、それともそれを内包する
インスタンスの方に掛かるのか、自明じゃないように感じるよね
parentならこういう曖昧さの問題は存在しない >>849
前置詞句は使い方次第で副詞句にも形容詞句にもなる
中学校で習わなかった?
A tweet in reply to the tweet
Tweetクラス/構造体のInReplyToで保持してるTweet IDがどれを指してるのか誤解のしようがない 本来は親子でないものに「parent」とかつけたら、そのほうがややこしくてたまらんわ。 グラフ理論とか知ったら発狂しそうだね
なんでこれがpathなんだとか、どこがheadなんだとか >>848
最初の元ネタはTwitter
最近になって841が蒸し返したのはメールの親子関係をツリーと呼ぶ是非の話
Twitter APIはInReplyTo
メールはReplyToヘッダがRFCで定められてる
スレの趣旨は変数名として何が妥当か
流れを理解せずに勘違いで罵ってるアホはお前だよ >>850
何を言ってるのか意味が分かんないねw
それ、which is が省略されてるんじゃないの?w
それ以前にtoがどっちに掛かるのか自明でない、という反論として成立していない >>852
抽象と具象の違いってわかる?
わっかんねえんだろうなあ。 お前らの対立軸はマクロで見るかミクロで物事を見るかの違いだな。
メールやツイートの返信関係は、マクロで見るとツリーではない。というのも、返信と全く関係ない独立したメールがあるからこれらを考慮して全体として見るとツリーにはなってない。
実際に返信関係あるメールだけのミクロで見ればツリーになるけど。 プログラマーって中1レベルの英語も理解できないんだねw ディレクトリ構造の場合は必ずルート以外は親いるから、まさしくツリーになるけど。
メールやツイートの場合は返信と関係ない独立したメールのインスタンスが存在するから、返信関係はツリーであるとは言わん。
もちろん、実際返信関係が成り立っってるミクロな部分だけ見ればツリーだけど。 >>853
Twitterの話→ディレクトリ構造を例に親子関係論展開→Twitterは親子関係じゃない→
ディレクトリ構造を再度提示してこいつが親子なのにTwitterが親子じゃないのはおかしい→
本筋はこれだ
この流れにメールを例に出した横槍が入ってるだけで、この横槍にまた亀レス横槍が入ってる構造に
お前がRFCを持ちだして「本筋」にFAを突きつけてるアホ丸出しの構造だ
この親子関係wwくらい理解してから発言しとけ
まあこんな奴が居るからレス安価(メール)は親子関係じゃ分かりにくいよってなるわけだが >>860
それってWindowsみたいにドライブ毎にルートがあるような感じじゃないの? >>863
何を言いたいのか意味不明なんだけど…
どこからムリヤリとか出てきたんだ? ディレクトリ構造がツリーの親子だって?
よしハードリンクの話をしようぜ
ジャンクションでループを作ろう 実際の親子でも近親相姦とかあるわけでそんな例外的な話でドヤるのはどうかと思うなw クソくだらない話が延々と続いてるのでちょうどいいかなと
それとも有意義な議論だったのかこの状況 結局バカの壁は厳然として存在する、という事実が再確認されたまでだよ
世の中には具象の中に抽象的な構造を見出す類の思考がどうやっても出来ない人が存在する、というねw ツリー構造という具象でしか見れてないことにすら気付かないツリーボーイww >>868
いやまったく。
具象と抽象の具合を図るのが命名の妙であり、このスレの目的。
なんでもかんでも抽象化すればいいってもんではない。
たまたまツリーに見えたとしても、本質的にツリーとして表現するべきかどうかを考えんとな。 何度も同じ話を繰り返すのも壁の向こう側の人の特徴>>813
壁の向こう側の人は、
- 自分を包含するディレクトリを親と呼ばないのか、と問われても答えずに流す
- in reply toは「〇〇に対する返信」だが、「に対する返信」という変数名では○○に何が入るのか不明確
だと指摘されても反論せずに流す
要するに他人と議論する以前に自分自身を欺いている。
自分に自信がないから、間違いを認めるのが怖いんだろう。 ○○に何が入るのか、じゃなくて変数に何が入るのか、だね訂正します >何度も同じ話を繰り返すのも壁の向こう側の人の特徴>>813
>要するに他人と議論する以前に自分自身を欺いている。
>自分に自信がないから、間違いを認めるのが怖いんだろう。
みんながお前に対して思ってることそのままでワロタww tweetが「ふつうにツリー構造」とか言っちゃった>>802君いきしてるぅ?? >InReplyToっていうメンバー変数を持つクラスのインスタンスがあるとして、
>InReplyToのtoがInReplyTo自身に掛かるのか、それともそれを内包する
>インスタンスの方に掛かるのか、自明じゃないように感じるよね
↑コレを↓コレに都合よく変換してあるあたり「自分に自信がないから、間違いを認めるのが怖いんだろう。」
>- in reply toは「〇〇に対する返信」だが、「に対する返信」という変数名では○○に何が入るのか不明確 表示がツリーのようにされるだけ。
データの構造は別。 いや、fooとどちらがいいか議論が必要ではないだろうか…?
fooならbar、bazと続くが、hogeはどうだ
piyoなのかhugaなのか
実に悩ましい 私の頭を見ながらhogehoge言ったことを後悔させてやる Load(????) <-> Save(保存・記録)
Read(読み込み) <-> Write(書き込み)
Loadも読み込みでOK? >>885
むしろreadは読み込まない。
読み込むとはつまり読込先が存在するということ
"read data to an array"とは普通書かないのでは? >>885
カタカナで「ロード」「セーブ」でええやん?
もうリッパに日本語やろ。 「load read 違い」でググってみた
Load->読み込む・読んで込める・読んでから変数にセットするまでを「込んでる」
Read->読む・読むことにだけフォーカスしている・読んだ後はタッチしてない、知らん
こんな感じでいいのだろうか
確かに意識してなかったけどソースコードはそんな組み方になってたので勝手に納得してみました
皆さんありがとう ていうか>>886さんの言ってることを今さら理解できました
すみませんでした x = ReadHoge()
LoadHoge(out x)
こういうことか? LoadはよりCPUに近い場所に移動させるイメージだな readもloadも同じく低速媒体から高速媒体に移動するイメージでしょ
readはシリアルやストリームから一定量または全量読み進める感じ
媒体を読む(read)行為そのものに意識があり対象データが何かは必ずしも問わない
loadはオブジェクトやプログラム等の有意のデータ単位を読んで所定位置に載せる感じ
読み込まれる情報に意識があり何がどこに読み込まれるのかだいたい分かってる
loadのコアイメージは読むことではなく、積み荷を載せること
弾丸を弾倉にリロードする感じ fp=Load("第一章")
Read(fp, data)
printf(data) → 何でもないようなことが幸せだったと思う クラス名変数名より一歩前の話です
会計時の支払い方法で現金・クレジットカードが選べる簡易レジシステムなんですが、
最近流行り(?)のバーコード(QR)コード決済を追加してくれという流れになり、その表題を「キャッシュレス」
と指示されたのですが、クレカもそうやん・・・と思うのでバーコード(QR)という名前でもいいと思うのですが、
この第三枠目にはバーコード(QR)決済のみならず現金・クレジット以外という意味も含まれる可能性があるようです
なおさらここはキャッシュレスじゃないだろ・・・と思うのですが、どういう名前が最適かご指南ください 電子マネー:ElectricMoney
電子決済:ElectricPayment, EPOS
クレカ以外のキャッシュレス:CashlessButCredit
でもキャッシュレスでいいって言ってるんだからいいじゃんキャッシュレスで。
ああ、クレカ以外のキャッシュレスを狭義のキャッシュレスって言ってるんだなって分かるでしょ >>899
「QRコード」は登録商標やぞ。
細かいことを気にするなら、そもそも候補に入れるな。w
一般名なら二次元バーコードかマトリックスコードか。
将来にも通じる名前というなら、「other」「etc」とかにせざるを得ないやろ。
しかし、>>900の言うように、こだわらずに指示に従っとくのも一理。
そいつのせいにしとけばいいんだよ。
コメントに明記しといたれ。w >>899
そのくくりそのものが典型的な仕様崩壊パターン。
一つ追加して、また一つ追加して複数のものになって名前が崩壊する。
英語ならOthersとするしかない。 ElectricPaymentに一票
Othersもいいけど、電子決済以外の支払い方法が増えたらまた新しい名前を追加することになると見た 皆さんありがとうございます
>>900
キャッシュレスでも通じる感じですか・・・自分の頭が固いのかもですねw
>>901
確かにQRはダメですね
自分の流儀で行けば二次元バーコードですが、マトリックスコードもいいですね
キャッシュレス指示してる人がキャッシュレス連呼止まらないので、
コメントで愚痴を各方向に向かいつつありますが・・
>>904,905
後から増える懸念がとてもあります
ブランド種別や締め日などのワードがちらっと顔を覗かせていますが、
そこまでやるとやり過ぎ論で今のところ防がれています 例えば、メーラーアプリがあるとします
既読管理ができるとして、メール一覧画面において既読のメールを未読と区別するため未読より全体を暗く?表示したりしますがこの名前をお願いします
まず、日本語名からお願いします
暗く?以外にふさわしい表現ありますでしょうか 強調表示 = highlighting
視覚効果の選択肢は知らない
メーラーならオリジナルの方法にこだわるより既存の物に右へ倣えした方がいいと思うけど、
メーラーじゃないんだよね read の過去分詞が read で区別がつかなくて困るとかか? >>908
名前を付けようとしてる対象が適切でないように思う
個別のスタイルを適用できる要素として既読メールや未読メールがあって
それらに既定のスタイルやユーザーがカスタマイズしたスタイルを適用してるだけなので
この場合の暗くするという処理(というか設定によっては暗くなる状態)に名前はついてないしつけるべきでもない
例えばcssなら.UnreadMessageBodyや.ReadMessageBodyみたいなclassを定義して
それぞれにcolor, font-size, background-colorなんかを指定するだけ 対処済
低優先
低重要
とか?
区別したい趣旨や目的が不明瞭なら、これくらい抽象的な名前かな? うーん。アイテムはメールで例を出しましたが、ツイートであったり5chならレスであったりメールと似たようなものです。それの「既読・未読」管理します
で、その暗く?するという視覚効果を適用するかしないかをオプションでユーザーに選択できるようにしたくて >>909
「既読を〰�キる」じゃなく、その逆の発想の「未読を強調表示する」も考えましたがどいなんでしょうね
もうちょっと考えてみます >>913-914
だから未読/既読を管理すればいいなら例えばIsUnreadとか逆にIsAlreadyReadとかでいいんじゃね? >>914
(例)macOSのMail.appの設定にあるチェックボックス
- Display unread messages with bold font
- 未読メッセージをボールドフォントで表示
ユーザーにスタイルの選択肢は与えず
あくまで「既読を暗くする」って感覚にこだわりたいなら
上の例で「強調表示する」ではなく「ボールドフォントで表示する」になってるように
「暗くする」とはどういうことなのかをもう少し詳細度を落として考えたほうが良い >>916
暗くするって、具体的にはビューの上に不透明度?Opacityを設定したビューを重ねて合成表示すると全体的に輝度が下がって暗くなる
そんな実装です
>>917
あー。なんかdimってありましたね。どっかで見た記憶があるが思い出せない dimよさそうですね。
dim background for? read mails
日本語があれやな.. つか、連投すみません。
>>916
未読をボールドフォントで表示する方法もありましたね。アイデアありがとうございます。そっちの方が見やすいかもしれません。試してみます。 ○○ファイルを削除する関数の名前に統一性もなくDeleteやRemoveを使ってたのが発覚
ここはまあDeleteに統一かなと思ったけど、気にしすぎかな? 統一しようぜ
核となるニュアンスは取り除く(re-move)だからファイル消去にremoveはかなり微妙 removeが微妙かどうかはコンテキスト次第
同じモジュール内にもかかわらず
同じ意図で異なる名前を使ってるなら統一したほうがベター >>923-924
やはりまずは統一ですね
ところで、linuxがrmだったりdosはファイルがdel、ディレクトリがrmdir、
win32apiもファイルがDeleteFile、ディレクトリがRemoveDirectoryだったりするのはなぜでしょう? 渡された日付がおかしな日付だったらおかしな部分を0にして返す関数名をお願いします
例えばうるう年ではないのに2/29が渡されたり、4/31というようなあり得ない日付は、
2/0、4/0として返すようにします
13/1みたいなのだと、0/1として返します
ここでは0にしていますが、おかしいものはxxxに統一しておくことで後々一々日付範囲チェック
しなくてもxxxなら異常値として処理できるように意図しています 13/31の日付はどう判定すべきなんだろうw
しかし、変なら変だと素直に教えてくれりゃいいのに、
わざわざ別の変な値に変換して返す関数ってずいぶんと意地悪な仕様だなw >>927
ちょっと抽象的かなと
>>928
顧客情報に誕生日欄があり、UI側では異常な数値は設定できないようになっており
誕生日が不明な部分(何年のみ、何月生まれのみという事だけ分かるなど)
というケースもあり得る感じになっています
分かっている部分はデータが入っており、未設定・不明部分は0としてデータセットします
問題は、CSVから顧客情報をインポートする場合に2/31のような異常な日付データが入ってくることがあり、
これをインポート時に処理しておきたいということです
13/31の場合は、実処理は月を先に処理するので0/31となって終わります
これはまあ、日だけデータがあってもどうしようもないのであってないようなものです
年や月が正常ならば日を正確に処理するようにしています >>929
よく分からないなあ。
不正な値は未知の値と見なして「未知な値」を表す値に変換して正規化するってこと?
NormalizeInvalidAsUnknown
それなら13/31は0/0に変換すべきじゃないの?
年が不明で月日だけ分かるケースはあるかもしれないが、
常識的には月が不明なら日付も不明とすべきじゃないのかな >>930
> 不正な値は未知の値と見なして「未知な値」を表す値に変換して正規化するってこと?
そういうことです
データそのものは色々な使い方をするので、その色々な処理で一々不正な日付かも知れない
というチェックを入れるよりは、最初から未定義として設定しておこうかと
> それなら13/31は0/0に変換すべきじゃないの?
これは確かに無意味なので0/0の方がいいので、そのようにします parse date string
mask invalid date string
annotate invalid date string
format invalid date string
set zero to invalid date string
設計的には妥当な入力は日付型として扱った方が堅牢
無効な値を残しておきたいなら生年月日の入力値と生年月日を別に持てばいい >>929
まあ、日付オブジェクトの(拡張)メソッドくらいのつもりだったからな。
じゃあ、グローバル関数のつもりで。
invalidate unacceptable parts of date 皆さんありがとうございました
mask invalid〜辺りで行きます
> 設計的には妥当な入力は日付型として扱った方が堅牢
一般店舗でのデータなので、客が誕生日を書いてくれないことが多くこのような仕様になっています メソッドならzeroizateInvalid
関数ならzeroizateInvalidDate バックエンドから戻ってきたフォームのエラーフラグをフォームに反映させるクラス、または関数の名前 class Reflector
class FormReflector extend Reflector
class FormErrorReflector extend FormReflector >>939
ありがとう!2番目採用したいと思います 英語的にはそのreflectの使い方は誤用じゃないかな
設計的にもupdateView(response)やdisplayErrors(errors)で対処できるような構造にしたほうがいい気がする このスレまだあったんだね
まあ質問者さんがいいならいいんでないの?
そもそも質問内容もあいまいだし。
submitされた後で複数の入力項目のエラーをまとめて
UIに反映するタイプのアプリなのかな?
IndicateErrorstとかNotifyErrorsとかの方がいいように思っちゃうけど
まあ細かい話が分からんので何ともいえんね。 FormReflectorをValidatorにmixinとかするとスマートかなっておもた Taskってマルチスレッドで並列実行的な意味合いが大きいの?
単純に処理を数珠つなぎに登録して別の箇所で実行していく
Task/TaskList的なものはなんて名前つけるのが一般的なの? コマンドパターンに近そうなのでCommandかな
単に関数のリストならfunc_listやfn_listみたいなのにするかも >>944
https://e-words.jp/w/%E3%82%BF%E3%82%B9%E3%82%AF.html
によればtask≒threadみたいなニュアンスがあるらしい。
文脈次第のような気もするけど。
Commandは良さげに聞こえるね。あとはActionとか?
「TaskList的なもの」はSequenceってとこ?
こっちの実装によっては個々のアイテムの呼称については
必ずしも明確にしなくても良いような気もする。
まあ、コメントやドキュメントを書くときに名称がないと困るかもしれんけど タスクはTaskでええやろ。
マルチスレッドかどうかは実装の話やし。
で、そういうリストはQueueやないか? TRONではスレッドのことタスクって言うんだったっけ リバースアセンブラでopcodeとoperandをひとまとめにしたデータクラスってどう命名するのがいいですかね?
Operationだとプログラミング中で使うのに含意が広すぎる気がするんですよね
現状ではInstructionを略してInstにしてるんだけど >>950
instructionでもoperationでもどっちでもいいと思うけどCPUのアーキテクチャー
関係の用語としてはinstructionの方が一般的みたいな印象はあるね。
opcode = operation codeなんだからoperationの方が素直な気もする反面
確かにより一般的なinstructionの方が変な誤解がないような気もする。
あえてこの2つ以外を選択する理由はないようが気がする。 >>951
>>954
ふむ、やっぱInstructionが無難ですかね
とりあえずそれで進めてみます 誘導されてきました
フォルダを参照して
処理用の関数に渡すための色々なデータ(ID
とかパスとか拡張子とか) を収集してひとつの変数に配列として格納した
この変数の名前はなんてつけたらいいでしょうか?
temp? database? container? 命名以前の問題がある気がするんだけど気のせいかなw config、settings
配列って連想配列のことだよね >>960
名前を与えられるだけの条件を満たしてないというのも立派な回答。
そういう交通整理こそスレ違いだから
しかしどこにでも他人にケチをつけたいだけのバカいるなほんと >>956
for ent in xxx_entries >>961
いや>>1は見ようよ
そのルールが気に食わないと思うならこちらに書き込まないのが大人の対応 >>956
[{id: 1, file_path: path/to/x.jpg, ext: jpg}, {id: 2, file_path: path/to/y.jpg, ext: jpg}, …]
JSONで書くと↑こういうイメージの配列だとするならtargetとかtarget_filesとかにするかな
あとは渡す先の関数の処理内容だったり
その変数自体がプログラム全体の構造の中で持つ意味だったり
他の関数名や変数名との兼ね合いだったりで調整する
指定されたフォルダをスキャンして収集した結果データなんだぞってことを強調したいなら
scan_resultsみたいな事前処理の結果だと分かる名前にするかもしれない >>961
スレ違いじゃなくて、理解力も想像力も足りないバカだったか。。。 >>961
>名前を与えられるだけの条件を満たしてないというのも立派な回答。
これには同意するんだけど
命名以前の問題があると感じたんならそれがどの辺なのかを指摘して
良い命名ができる手助けをしてあげたらいいんじゃないかな
あー、>>2にある設計・命名スレに誘導すればよかったのか >>2にあるスレは死んでるっぽいので
命名の相談時に設計のアドバイスや指摘を禁止しないスレ立てといた
【命名スレ1】命名に悩んだらココへ (設計助言あり)
https://mevius.5ch.net/test/read.cgi/tech/1619279151/ 世の中ほんと馬鹿が多いよね。
プログラミングは実学であり命名なんて「分かりやすいコードを書く」という
上位目的達成のための一手段に過ぎない。
上位目的が間違ってるならその手段を考えるのは無駄だ。
少なくとも>>956の仕様はクソだ。
こんなクソ仕様の変数にどんな名前を付けたって意味はない。
どうせ名前からそれが何を意味するかをくみ取ることなんて不可能なのだから。
>>965みたいなバカは「水虫の足の切断方法を教えてくれ」という質問者に足の切断方法を
説明するんだろうね(笑)
俺なら皮膚科の医者に行けバカという。 んー、このスレではそのような話題は何度も出てるよ
あえてこのスレでは設計に関する話題は除外することになってるので、別スレでどうぞ
なんで除外してるのかは>>2が死んでることからも察してもらうか、過去スレを舐めるように追ってください >>970
こいつも重症だな
設計の話なんか誰もしてない。
問題自体が間違っているなら回答することに意味がないと言ってるんだけど さて次は上から目線でどんな馬鹿を言うか楽しみだねw
こういう連中は単に頭が悪いだけじゃなくて自分が単に「他人のやることにケチを付けたい」
という下劣な動機に突き動かされていることが自覚できない性格異常者。
ついでに言わせてもらえれば、スレのレンプレにグダグダとルールを書き込むのは有害無益。
こういう卑しい連中に他人に絡む口実を与えるだけのことでスレの「平和」には一切寄与した
試しがないからね。 >>972
「他人のやることにケチを付けたい」て、自己紹介すんな!w >>971
意味がないと思うならスルー
>>972は自己投影にしか見えない え?無料で変数名の相談に乗ってくれた上に
無料で設計のアドバイスももらえるんですか! 相談者そっちのけやけどな!w
どうせだいたいが「アドバイス」というよりは、言いたいことを言ってるだけの決めつけばかり。 >>956
素直に file_data とかでよい気がする
temp は本当に一時利用の目的でなければ避けた方がよい
やるとしても file_data_temp とかかな
配列って言ってるけど構造体参照への配列とかだよね file_dataだとファイルを読み込んだ生データに見えちゃう
必要なのはパス情報なんじゃないの?
path_parts_list
みたいなのを処理関数に渡して、そっちで読み込んだりするのかとオモタが ファイルパスや拡張子はたぶん一例で、IDみたいな情報も含んでるらしいぞ
当人が思い付いた候補もそれっぽい
パスに特化した名前よりも設定全般を表す変数名が妥当だと思う お題がかなり抽象的だからいっそparamsでもいいシチュエーションな気もしてきた >>981
まあ data がファイルの中身に見えるのはそうかなと思う
配列名を file_info にしたうえで、中身をしまう先は file_info[],content とかにするかな 次スレ立てミスりました(つ∀`)タハー
4年ぶりとか久しぶりすぎ・・・
連続するためかわたしはもう立てられないようですので、どなたかお願いいたします。
クラス名・変数名に迷ったら書き込むスレ。Part29
クラス名、変数名のつけ方に悩んだら書き込むスレです。
命名規則や設計の善し悪しについて議論するのは基本的に禁止。
命名するのに足りない情報は適当に想像して楽しんでマターリ返してあげてください。
設計などの話が主題になるならば他のスレでどうぞ。
前スレ
クラス名・変数名に迷ったら書き込むスレ。Part28
http://mevius.5ch.net/test/read.cgi/tech/1494147712/ (UTC+9) とかの "+9" に固有名称ありますか?
無い場合どういったものが適当でしょうか?
diffUTCtime とか TimeZoneAdjustableValue みたいな? UTC offset
timezone offset
time offset
offset hours
この辺でいいんじゃないかな UTC offsetかUTC time offsetだね ちなみにman dateには「numeric time zone」とある。 >>991-993
timezone そのものを指すものでもあるし num_TimeZone や TimeZone で良いのかも
他には
UTC time offset
timezone offset
短い変数名だと iTZ_h 辺りかな
ありがとうございました このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 1700日 21時間 44分 3秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。