X
クラス名・変数名に迷ったら書き込むスレ。Part28 [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001ネミ子
垢版 |
2017/05/07(日) 18:01:52.03ID:akuyRduv
クラス名、変数名のつけ方に悩んだら書き込むスレです。

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

前スレ
クラス名・変数名に迷ったら書き込むスレ。Part27
http://echo.2ch.net/test/read.cgi/tech/1476572490/
0851デフォルトの名無しさん
垢版 |
2019/11/25(月) 00:14:30.07ID:wA2TWbSp
本来は親子でないものに「parent」とかつけたら、そのほうがややこしくてたまらんわ。
0852デフォルトの名無しさん
垢版 |
2019/11/25(月) 00:38:12.82ID:rt9A3Dcl
グラフ理論とか知ったら発狂しそうだね
なんでこれがpathなんだとか、どこがheadなんだとか
0853デフォルトの名無しさん
垢版 |
2019/11/25(月) 02:14:23.37ID:KQ7B6BKU
>>848
最初の元ネタはTwitter
最近になって841が蒸し返したのはメールの親子関係をツリーと呼ぶ是非の話
Twitter APIはInReplyTo
メールはReplyToヘッダがRFCで定められてる
スレの趣旨は変数名として何が妥当か
流れを理解せずに勘違いで罵ってるアホはお前だよ
0854デフォルトの名無しさん
垢版 |
2019/11/25(月) 02:41:05.02ID:7zhksLgm
>>850
何を言ってるのか意味が分かんないねw
それ、which is が省略されてるんじゃないの？w

それ以前にtoがどっちに掛かるのか自明でない、という反論として成立していない
0858デフォルトの名無しさん
垢版 |
2019/11/25(月) 12:50:56.59ID:TgbLWIbn
お前らの対立軸はマクロで見るかミクロで物事を見るかの違いだな。

メールやツイートの返信関係は、マクロで見るとツリーではない。というのも、返信と全く関係ない独立したメールがあるからこれらを考慮して全体として見るとツリーにはなってない。

実際に返信関係あるメールだけのミクロで見ればツリーになるけど。
0860デフォルトの名無しさん
垢版 |
2019/11/25(月) 13:01:16.04ID:TgbLWIbn
ディレクトリ構造の場合は必ずルート以外は親いるから、まさしくツリーになるけど。

メールやツイートの場合は返信と関係ない独立したメールのインスタンスが存在するから、返信関係はツリーであるとは言わん。

もちろん、実際返信関係が成り立っってるミクロな部分だけ見ればツリーだけど。
0861デフォルトの名無しさん
垢版 |
2019/11/25(月) 13:50:21.50ID:Rjr9199e
>>853
Twitterの話→ディレクトリ構造を例に親子関係論展開→Twitterは親子関係じゃない→
ディレクトリ構造を再度提示してこいつが親子なのにTwitterが親子じゃないのはおかしい→

本筋はこれだ
この流れにメールを例に出した横槍が入ってるだけで、この横槍にまた亀レス横槍が入ってる構造に
お前がRFCを持ちだして「本筋」にFAを突きつけてるアホ丸出しの構造だ

この親子関係ｗｗくらい理解してから発言しとけ
まあこんな奴が居るからレス安価（メール）は親子関係じゃ分かりにくいよってなるわけだが
0865デフォルトの名無しさん
垢版 |
2019/11/25(月) 23:36:15.23ID:wmfv73Ue
ディレクトリ構造がツリーの親子だって？
よしハードリンクの話をしようぜ
ジャンクションでループを作ろう
0866デフォルトの名無しさん
垢版 |
2019/11/26(火) 06:51:02.39ID:6EvauiRd
実際の親子でも近親相姦とかあるわけでそんな例外的な話でドヤるのはどうかと思うなw
0867デフォルトの名無しさん
垢版 |
2019/11/26(火) 08:53:57.19ID:i6eVGflj
クソくだらない話が延々と続いてるのでちょうどいいかなと
それとも有意義な議論だったのかこの状況
0868デフォルトの名無しさん
垢版 |
2019/11/26(火) 12:38:11.97ID:iBb2XGni
結局バカの壁は厳然として存在する、という事実が再確認されたまでだよ
世の中には具象の中に抽象的な構造を見出す類の思考がどうやっても出来ない人が存在する、というねw
0870デフォルトの名無しさん
垢版 |
2019/11/26(火) 18:40:00.61ID:5FF2MzCH
ツリー構造という具象でしか見れてないことにすら気付かないツリーボーイww
0872デフォルトの名無しさん
垢版 |
2019/11/26(火) 19:47:38.62ID:dYmckS6u
>>868
いやまったく。
具象と抽象の具合を図るのが命名の妙であり、このスレの目的。

なんでもかんでも抽象化すればいいってもんではない。
たまたまツリーに見えたとしても、本質的にツリーとして表現するべきかどうかを考えんとな。
0873デフォルトの名無しさん
垢版 |
2019/11/26(火) 22:55:56.97ID:RP1bqzn6
何度も同じ話を繰り返すのも壁の向こう側の人の特徴>>813

壁の向こう側の人は、

　- 自分を包含するディレクトリを親と呼ばないのか、と問われても答えずに流す

　- in reply toは「〇〇に対する返信」だが、「に対する返信」という変数名では○○に何が入るのか不明確
だと指摘されても反論せずに流す

要するに他人と議論する以前に自分自身を欺いている。
自分に自信がないから、間違いを認めるのが怖いんだろう。
0874デフォルトの名無しさん
垢版 |
2019/11/26(火) 23:02:59.13ID:RP1bqzn6
○○に何が入るのか、じゃなくて変数に何が入るのか、だね訂正します
0875デフォルトの名無しさん
垢版 |
2019/11/26(火) 23:59:30.95ID:5FF2MzCH
>何度も同じ話を繰り返すのも壁の向こう側の人の特徴>>813
>要するに他人と議論する以前に自分自身を欺いている。
>自分に自信がないから、間違いを認めるのが怖いんだろう。

みんながお前に対して思ってることそのままでワロタww
0877デフォルトの名無しさん
垢版 |
2019/11/27(水) 01:00:35.28ID:ymKEnJ4Y
>InReplyToっていうメンバー変数を持つクラスのインスタンスがあるとして、
>InReplyToのtoがInReplyTo自身に掛かるのか、それともそれを内包する
>インスタンスの方に掛かるのか、自明じゃないように感じるよね

↑コレを↓コレに都合よく変換してあるあたり「自分に自信がないから、間違いを認めるのが怖いんだろう。」

>- in reply toは「〇〇に対する返信」だが、「に対する返信」という変数名では○○に何が入るのか不明確
0881デフォルトの名無しさん
垢版 |
2019/12/22(日) 06:42:09.17ID:BhZ7lWAO
迷ったらhoge
0882デフォルトの名無しさん
垢版 |
2019/12/22(日) 10:15:02.45ID:qcLf379+
いや、fooとどちらがいいか議論が必要ではないだろうか…？
fooならbar、bazと続くが、hogeはどうだ
piyoなのかhugaなのか
実に悩ましい
0885デフォルトの名無しさん
垢版 |
2019/12/28(土) 19:31:32.73ID:U0yz7pVo
Load（？？？？） <-> Save（保存・記録）
Read（読み込み） <-> Write（書き込み）

Loadも読み込みでOK？
0886デフォルトの名無しさん
垢版 |
2019/12/28(土) 21:03:10.86ID:06FVqHz0
>>885
むしろreadは読み込まない。
読み込むとはつまり読込先が存在するということ
"read data to an array"とは普通書かないのでは？
0890デフォルトの名無しさん
垢版 |
2019/12/28(土) 21:57:03.80ID:U0yz7pVo
「load read 違い」でググってみた

Load->読み込む・読んで込める・読んでから変数にセットするまでを「込んでる」
Read->読む・読むことにだけフォーカスしている・読んだ後はタッチしてない、知らん

こんな感じでいいのだろうか
確かに意識してなかったけどソースコードはそんな組み方になってたので勝手に納得してみました
皆さんありがとう
0894デフォルトの名無しさん
垢版 |
2020/01/01(水) 02:03:06.51ID:4oQ1Kxot
readもloadも同じく低速媒体から高速媒体に移動するイメージでしょ
readはシリアルやストリームから一定量または全量読み進める感じ
媒体を読む(read)行為そのものに意識があり対象データが何かは必ずしも問わない
loadはオブジェクトやプログラム等の有意のデータ単位を読んで所定位置に載せる感じ
読み込まれる情報に意識があり何がどこに読み込まれるのかだいたい分かってる

loadのコアイメージは読むことではなく、積み荷を載せること
弾丸を弾倉にリロードする感じ
0895デフォルトの名無しさん
垢版 |
2020/01/01(水) 03:14:02.92ID:YaU7J6nt
fp=Load("第一章"）
Read(fp, data)
printf(data)　　→　何でもないようなことが幸せだったと思う
0896デフォルトの名無しさん
垢版 |
2020/01/01(水) 03:48:19.30ID:t62Wc1II
それはroadや
って元旦にみんな何しとんねんw
0899デフォルトの名無しさん
垢版 |
2020/01/12(日) 23:07:00.28ID:hbtwGtoY
クラス名変数名より一歩前の話です

会計時の支払い方法で現金・クレジットカードが選べる簡易レジシステムなんですが、
最近流行り（？）のバーコード（QR）コード決済を追加してくれという流れになり、その表題を「キャッシュレス」
と指示されたのですが、クレカもそうやん・・・と思うのでバーコード（QR）という名前でもいいと思うのですが、
この第三枠目にはバーコード（QR）決済のみならず現金・クレジット以外という意味も含まれる可能性があるようです

なおさらここはキャッシュレスじゃないだろ・・・と思うのですが、どういう名前が最適かご指南ください
0900デフォルトの名無しさん
垢版 |
2020/01/12(日) 23:38:10.18ID:crjmdSkp
電子マネー：ElectricMoney
電子決済：ElectricPayment, EPOS
クレカ以外のキャッシュレス：CashlessButCredit

でもキャッシュレスでいいって言ってるんだからいいじゃんキャッシュレスで。
ああ、クレカ以外のキャッシュレスを狭義のキャッシュレスって言ってるんだなって分かるでしょ
0901デフォルトの名無しさん
垢版 |
2020/01/13(月) 00:56:38.11ID:mmkLwImI
>>899
「QRコード」は登録商標やぞ。
細かいことを気にするなら、そもそも候補に入れるな。ｗ
一般名なら二次元バーコードかマトリックスコードか。

将来にも通じる名前というなら、「other」「etc」とかにせざるを得ないやろ。

しかし、>>900の言うように、こだわらずに指示に従っとくのも一理。
そいつのせいにしとけばいいんだよ。
コメントに明記しといたれ。ｗ
0903デフォルトの名無しさん
垢版 |
2020/01/13(月) 16:13:53.18ID:UjYrXoaW
>>899
nonCash
0904デフォルトの名無しさん
垢版 |
2020/01/13(月) 16:18:02.53ID:UjYrXoaW
>>899
そのくくりそのものが典型的な仕様崩壊パターン。

一つ追加して、また一つ追加して複数のものになって名前が崩壊する。

英語ならOthersとするしかない。
0905デフォルトの名無しさん
垢版 |
2020/01/13(月) 16:23:12.93ID:WUoSHY6Y
エバーノートのパチモンでネバーノートを作りたい。
0906デフォルトの名無しさん
垢版 |
2020/01/13(月) 19:04:38.38ID:KUNSdwO3
ElectricPaymentに一票
Othersもいいけど、電子決済以外の支払い方法が増えたらまた新しい名前を追加することになると見た
0907デフォルトの名無しさん
垢版 |
2020/01/14(火) 01:42:05.14ID:QzFNJ/om
皆さんありがとうございます

>>900
キャッシュレスでも通じる感じですか・・・自分の頭が固いのかもですねｗ

>>901
確かにQRはダメですね
自分の流儀で行けば二次元バーコードですが、マトリックスコードもいいですね
キャッシュレス指示してる人がキャッシュレス連呼止まらないので、
コメントで愚痴を各方向に向かいつつありますが・・

>>904,905
後から増える懸念がとてもあります
ブランド種別や締め日などのワードがちらっと顔を覗かせていますが、
そこまでやるとやり過ぎ論で今のところ防がれています
0908デフォルトの名無しさん
垢版 |
2020/02/24(月) 10:52:27.86ID:TgLwmft3
例えば、メーラーアプリがあるとします
既読管理ができるとして、メール一覧画面において既読のメールを未読と区別するため未読より全体を暗く?表示したりしますがこの名前をお願いします

まず、日本語名からお願いします
暗く?以外にふさわしい表現ありますでしょうか
0909デフォルトの名無しさん
垢版 |
2020/02/24(月) 12:22:27.23ID:cnp9Tx4f
強調表示 = highlighting

視覚効果の選択肢は知らない
メーラーならオリジナルの方法にこだわるより既存の物に右へ倣えした方がいいと思うけど、
メーラーじゃないんだよね
0911デフォルトの名無しさん
垢版 |
2020/02/24(月) 14:17:18.95ID:iQYTd9Fe
>>908
名前を付けようとしてる対象が適切でないように思う

個別のスタイルを適用できる要素として既読メールや未読メールがあって
それらに既定のスタイルやユーザーがカスタマイズしたスタイルを適用してるだけなので
この場合の暗くするという処理(というか設定によっては暗くなる状態)に名前はついてないしつけるべきでもない

例えばcssなら.UnreadMessageBodyや.ReadMessageBodyみたいなclassを定義して
それぞれにcolor, font-size, background-colorなんかを指定するだけ
0912デフォルトの名無しさん
垢版 |
2020/02/24(月) 19:31:21.70ID:v3p46mmV
対処済
低優先
低重要

とか？
区別したい趣旨や目的が不明瞭なら、これくらい抽象的な名前かな？
0913デフォルトの名無しさん
垢版 |
2020/02/24(月) 19:49:44.96ID:TgLwmft3
うーん。アイテムはメールで例を出しましたが、ツイートであったり5chならレスであったりメールと似たようなものです。それの「既読・未読」管理します

で、その暗く?するという視覚効果を適用するかしないかをオプションでユーザーに選択できるようにしたくて
0914デフォルトの名無しさん
垢版 |
2020/02/24(月) 19:54:31.19ID:TgLwmft3
>>909
「既読を〰�ｷる」じゃなく、その逆の発想の「未読を強調表示する」も考えましたがどいなんでしょうね

もうちょっと考えてみます
0916デフォルトの名無しさん
垢版 |
2020/02/24(月) 21:04:45.30ID:iQYTd9Fe
>>914
(例)macOSのMail.appの設定にあるチェックボックス
- Display unread messages with bold font
- 未読メッセージをボールドフォントで表示

ユーザーにスタイルの選択肢は与えず
あくまで「既読を暗くする」って感覚にこだわりたいなら
上の例で「強調表示する」ではなく「ボールドフォントで表示する」になってるように
「暗くする」とはどういうことなのかをもう少し詳細度を落として考えたほうが良い
0918デフォルトの名無しさん
垢版 |
2020/02/24(月) 22:05:36.25ID:TgLwmft3
>>916
暗くするって、具体的にはビューの上に不透明度?Opacityを設定したビューを重ねて合成表示すると全体的に輝度が下がって暗くなる
そんな実装です

>>917
あー。なんかdimってありましたね。どっかで見た記憶があるが思い出せない
0921デフォルトの名無しさん
垢版 |
2020/02/24(月) 22:33:44.92ID:TgLwmft3
つか、連投すみません。
>>916
未読をボールドフォントで表示する方法もありましたね。アイデアありがとうございます。そっちの方が見やすいかもしれません。試してみます。
0922デフォルトの名無しさん
垢版 |
2020/04/21(火) 21:47:10.01ID:S98JwHkY
○○ファイルを削除する関数の名前に統一性もなくDeleteやRemoveを使ってたのが発覚
ここはまあDeleteに統一かなと思ったけど、気にしすぎかな？
0923デフォルトの名無しさん
垢版 |
2020/04/21(火) 22:16:03.42ID:tPnrPq2V
統一しようぜ
核となるニュアンスは取り除く(re-move)だからファイル消去にremoveはかなり微妙
0924デフォルトの名無しさん
垢版 |
2020/04/21(火) 22:29:43.63ID:9fcQjJm8
removeが微妙かどうかはコンテキスト次第

同じモジュール内にもかかわらず
同じ意図で異なる名前を使ってるなら統一したほうがベター
0925デフォルトの名無しさん
垢版 |
2020/04/21(火) 23:58:14.52ID:S98JwHkY
>>923-924
やはりまずは統一ですね

ところで、linuxがrmだったりdosはファイルがdel、ディレクトリがrmdir、
win32apiもファイルがDeleteFile、ディレクトリがRemoveDirectoryだったりするのはなぜでしょう？
0926デフォルトの名無しさん
垢版 |
2020/05/28(木) 14:48:04.26ID:EFbtIqYt
渡された日付がおかしな日付だったらおかしな部分を0にして返す関数名をお願いします

例えばうるう年ではないのに2/29が渡されたり、4/31というようなあり得ない日付は、
2/0、4/0として返すようにします
13/1みたいなのだと、0/1として返します

ここでは0にしていますが、おかしいものはxxxに統一しておくことで後々一々日付範囲チェック
しなくてもxxxなら異常値として処理できるように意図しています
0928デフォルトの名無しさん
垢版 |
2020/05/28(木) 15:45:21.36ID:TOqrHko/
13/31の日付はどう判定すべきなんだろうw

しかし、変なら変だと素直に教えてくれりゃいいのに、
わざわざ別の変な値に変換して返す関数ってずいぶんと意地悪な仕様だなw
0929デフォルトの名無しさん
垢版 |
2020/05/28(木) 16:00:40.72ID:EFbtIqYt
>>927
ちょっと抽象的かなと

>>928
顧客情報に誕生日欄があり、UI側では異常な数値は設定できないようになっており
誕生日が不明な部分（何年のみ、何月生まれのみという事だけ分かるなど）
というケースもあり得る感じになっています
分かっている部分はデータが入っており、未設定・不明部分は0としてデータセットします

問題は、CSVから顧客情報をインポートする場合に2/31のような異常な日付データが入ってくることがあり、
これをインポート時に処理しておきたいということです

13/31の場合は、実処理は月を先に処理するので0/31となって終わります
これはまあ、日だけデータがあってもどうしようもないのであってないようなものです
年や月が正常ならば日を正確に処理するようにしています
0930デフォルトの名無しさん
垢版 |
2020/05/28(木) 16:27:30.79ID:TOqrHko/
>>929
よく分からないなあ。
不正な値は未知の値と見なして「未知な値」を表す値に変換して正規化するってこと？
NormalizeInvalidAsUnknown

それなら13/31は0/0に変換すべきじゃないの？
年が不明で月日だけ分かるケースはあるかもしれないが、
常識的には月が不明なら日付も不明とすべきじゃないのかな
0932デフォルトの名無しさん
垢版 |
2020/05/28(木) 17:29:01.58ID:EFbtIqYt
>>930
> 不正な値は未知の値と見なして「未知な値」を表す値に変換して正規化するってこと？

そういうことです
データそのものは色々な使い方をするので、その色々な処理で一々不正な日付かも知れない
というチェックを入れるよりは、最初から未定義として設定しておこうかと

> それなら13/31は0/0に変換すべきじゃないの？

これは確かに無意味なので0/0の方がいいので、そのようにします
0933デフォルトの名無しさん
垢版 |
2020/05/28(木) 17:43:29.94ID:Xow4Xb3r
parse date string

mask invalid date string
annotate invalid date string
format invalid date string
set zero to invalid date string

設計的には妥当な入力は日付型として扱った方が堅牢
無効な値を残しておきたいなら生年月日の入力値と生年月日を別に持てばいい
0934927
垢版 |
2020/05/28(木) 19:59:07.19ID:d4ggzNnr
>>929
まあ、日付オブジェクトの(拡張)メソッドくらいのつもりだったからな。
じゃあ、グローバル関数のつもりで。

invalidate unacceptable parts of date
0936926
垢版 |
2020/05/29(金) 21:18:54.54ID:/MYYXMLs
皆さんありがとうございました
mask invalid〜辺りで行きます

> 設計的には妥当な入力は日付型として扱った方が堅牢

一般店舗でのデータなので、客が誕生日を書いてくれないことが多くこのような仕様になっています
0938デフォルトの名無しさん
垢版 |
2021/02/05(金) 13:55:29.79ID:In3kItp2
バックエンドから戻ってきたフォームのエラーフラグをフォームに反映させるクラス、または関数の名前
0939デフォルトの名無しさん
垢版 |
2021/02/05(金) 14:11:24.01ID:sQbQrry7
class Reflector
class FormReflector extend Reflector
class FormErrorReflector extend FormReflector
0941デフォルトの名無しさん
垢版 |
2021/02/05(金) 16:03:20.59ID:ywW/HyXt
英語的にはそのreflectの使い方は誤用じゃないかな
設計的にもupdateView(response)やdisplayErrors(errors)で対処できるような構造にしたほうがいい気がする
0942デフォルトの名無しさん
垢版 |
2021/02/05(金) 16:37:34.95ID:5eI5Jyf0
このスレまだあったんだね

まあ質問者さんがいいならいいんでないの？
そもそも質問内容もあいまいだし。

submitされた後で複数の入力項目のエラーをまとめて
UIに反映するタイプのアプリなのかな？

IndicateErrorstとかNotifyErrorsとかの方がいいように思っちゃうけど
まあ細かい話が分からんので何ともいえんね。
0943デフォルトの名無しさん
垢版 |
2021/02/05(金) 16:54:53.60ID:sQbQrry7
FormReflectorをValidatorにmixinとかするとスマートかなっておもた
0944デフォルトの名無しさん
垢版 |
2021/02/15(月) 01:37:18.93ID:Upko3Ndr
Taskってマルチスレッドで並列実行的な意味合いが大きいの？
単純に処理を数珠つなぎに登録して別の箇所で実行していく
Task/TaskList的なものはなんて名前つけるのが一般的なの？
0945デフォルトの名無しさん
垢版 |
2021/02/15(月) 03:16:42.65ID:Yv9X0Du7
コマンドパターンに近そうなのでCommandかな
単に関数のリストならfunc_listやfn_listみたいなのにするかも
0946デフォルトの名無しさん
垢版 |
2021/02/15(月) 03:34:49.14ID:2abjFk2X
>>944
https://e-words.jp/w/%E3%82%BF%E3%82%B9%E3%82%AF.html
によればtask≒threadみたいなニュアンスがあるらしい。
文脈次第のような気もするけど。

Commandは良さげに聞こえるね。あとはActionとか？
「TaskList的なもの」はSequenceってとこ？

こっちの実装によっては個々のアイテムの呼称については
必ずしも明確にしなくても良いような気もする。
まあ、コメントやドキュメントを書くときに名称がないと困るかもしれんけど
0948デフォルトの名無しさん
垢版 |
2021/02/15(月) 04:13:17.44ID:2VFC6Owo
タスクはTaskでええやろ。
マルチスレッドかどうかは実装の話やし。

で、そういうリストはQueueやないか？
0950デフォルトの名無しさん
垢版 |
2021/02/20(土) 14:44:39.38ID:PUihGoQs
リバースアセンブラでopcodeとoperandをひとまとめにしたデータクラスってどう命名するのがいいですかね？
Operationだとプログラミング中で使うのに含意が広すぎる気がするんですよね
現状ではInstructionを略してInstにしてるんだけど
0951デフォルトの名無しさん
垢版 |
2021/02/20(土) 15:43:08.73ID:eYAtaCBL
>>950
instructionでもoperationでもどっちでもいいと思うけどCPUのアーキテクチャー
関係の用語としてはinstructionの方が一般的みたいな印象はあるね。

opcode = operation codeなんだからoperationの方が素直な気もする反面
確かにより一般的なinstructionの方が変な誤解がないような気もする。

あえてこの2つ以外を選択する理由はないようが気がする。
レス数が950を超えています。1000を超えると書き込みができなくなります。
ニューススポーツなんでも実況