クラス名・変数名に迷ったら書き込むスレ。Part28 [無断転載禁止]©2ch.net

**ネミ子** · 2017/05/07(日) 18:01:52.03

クラス名、変数名のつけ方に悩んだら書き込むスレです。

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

前スレ
クラス名・変数名に迷ったら書き込むスレ。Part27
http://echo.2ch.net/test/read.cgi/tech/1476572490/

**デフォルトの名無しさん** · 2020/05/28(木) 16:00:40.72

>>927
ちょっと抽象的かなと

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

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

13/31の場合は、実処理は月を先に処理するので0/31となって終わります
これはまあ、日だけデータがあってもどうしようもないのであってないようなものです
年や月が正常ならば日を正確に処理するようにしています

**デフォルトの名無しさん** · 2020/05/28(木) 16:27:30.79

>>929
よく分からないなあ。
不正な値は未知の値と見なして「未知な値」を表す値に変換して正規化するってこと？
NormalizeInvalidAsUnknown

それなら13/31は0/0に変換すべきじゃないの？
年が不明で月日だけ分かるケースはあるかもしれないが、
常識的には月が不明なら日付も不明とすべきじゃないのかな

**デフォルトの名無しさん** · 2020/05/28(木) 16:50:57.83

不完全なっておかしい？
incomplete

**デフォルトの名無しさん** · 2020/05/28(木) 17:29:01.58

>>930
> 不正な値は未知の値と見なして「未知な値」を表す値に変換して正規化するってこと？

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

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

これは確かに無意味なので0/0の方がいいので、そのようにします

**デフォルトの名無しさん** · 2020/05/28(木) 17:43:29.94

parse date string

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

設計的には妥当な入力は日付型として扱った方が堅牢
無効な値を残しておきたいなら生年月日の入力値と生年月日を別に持てばいい

**927** · 2020/05/28(木) 19:59:07.19

>>929
まあ、日付オブジェクトの(拡張)メソッドくらいのつもりだったからな。
じゃあ、グローバル関数のつもりで。

invalidate unacceptable parts of date

**デフォルトの名無しさん** · 2020/05/28(木) 22:41:35.95

zerofillInvalidDateChar

**926** · 2020/05/29(金) 21:18:54.54

皆さんありがとうございました
mask invalid～辺りで行きます

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

一般店舗でのデータなので、客が誕生日を書いてくれないことが多くこのような仕様になっています

**デフォルトの名無しさん** · 2020/08/04(火) 06:50:25.70

メソッドならzeroizateInvalid
関数ならzeroizateInvalidDate

**デフォルトの名無しさん** · 2021/02/05(金) 13:55:29.79

バックエンドから戻ってきたフォームのエラーフラグをフォームに反映させるクラス、または関数の名前

**デフォルトの名無しさん** · 2021/02/05(金) 14:11:24.01

class Reflector
class FormReflector extend Reflector
class FormErrorReflector extend FormReflector

**デフォルトの名無しさん** · 2021/02/05(金) 15:01:52.21

>>939
ありがとう！2番目採用したいと思います

**デフォルトの名無しさん** · 2021/02/05(金) 16:03:20.59

英語的にはそのreflectの使い方は誤用じゃないかな
設計的にもupdateView(response)やdisplayErrors(errors)で対処できるような構造にしたほうがいい気がする

**デフォルトの名無しさん** · 2021/02/05(金) 16:37:34.95

このスレまだあったんだね

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

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

IndicateErrorstとかNotifyErrorsとかの方がいいように思っちゃうけど
まあ細かい話が分からんので何ともいえんね。

**デフォルトの名無しさん** · 2021/02/05(金) 16:54:53.60

FormReflectorをValidatorにmixinとかするとスマートかなっておもた

**デフォルトの名無しさん** · 2021/02/15(月) 01:37:18.93

Taskってマルチスレッドで並列実行的な意味合いが大きいの？
単純に処理を数珠つなぎに登録して別の箇所で実行していく
Task/TaskList的なものはなんて名前つけるのが一般的なの？

**デフォルトの名無しさん** · 2021/02/15(月) 03:16:42.65

コマンドパターンに近そうなのでCommandかな
単に関数のリストならfunc_listやfn_listみたいなのにするかも

**デフォルトの名無しさん** · 2021/02/15(月) 03:34:49.14

>>944
https://e-words.jp/w/%E3%82%BF%E3%82%B9%E3%82%AF.html
によればtask≒threadみたいなニュアンスがあるらしい。
文脈次第のような気もするけど。

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

こっちの実装によっては個々のアイテムの呼称については
必ずしも明確にしなくても良いような気もする。
まあ、コメントやドキュメントを書くときに名称がないと困るかもしれんけど

**デフォルトの名無しさん** · 2021/02/15(月) 04:01:07.94

script 台本

**デフォルトの名無しさん** · 2021/02/15(月) 04:13:17.44

タスクはTaskでええやろ。
マルチスレッドかどうかは実装の話やし。

で、そういうリストはQueueやないか？

**デフォルトの名無しさん** · 2021/02/15(月) 21:10:20.48

TRONではスレッドのことタスクって言うんだったっけ

**デフォルトの名無しさん** · 2021/02/20(土) 14:44:39.38

リバースアセンブラでopcodeとoperandをひとまとめにしたデータクラスってどう命名するのがいいですかね？
Operationだとプログラミング中で使うのに含意が広すぎる気がするんですよね
現状ではInstructionを略してInstにしてるんだけど

**デフォルトの名無しさん** · 2021/02/20(土) 15:43:08.73

>>950
instructionでもoperationでもどっちでもいいと思うけどCPUのアーキテクチャー
関係の用語としてはinstructionの方が一般的みたいな印象はあるね。

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

あえてこの2つ以外を選択する理由はないようが気がする。

**デフォルトの名無しさん** · 2021/02/20(土) 16:18:17.41

op_infoとかop_dataとか？

**デフォルトの名無しさん** · 2021/02/20(土) 16:31:25.39

asm,rev_asm

**デフォルトの名無しさん** · 2021/02/20(土) 17:13:35.31

PythonのdisassemblerではInstructionって名前が使われてる
https://docs.python.org/3/library/dis.html#dis.Instruction

**デフォルトの名無しさん** · 2021/02/20(土) 17:51:24.35

>>951
>>954
ふむ、やっぱInstructionが無難ですかね
とりあえずそれで進めてみます

**デフォルトの名無しさん** · 2021/04/24(土) 21:02:28.99

誘導されてきました

フォルダを参照して
処理用の関数に渡すための色々なデータ(ID
とかパスとか拡張子とか) を収集してひとつの変数に配列として格納した
この変数の名前はなんてつけたらいいでしょうか？

temp? database? container?

**デフォルトの名無しさん** · 2021/04/24(土) 21:18:35.00

info

**デフォルトの名無しさん** · 2021/04/24(土) 21:24:10.39

命名以前の問題がある気がするんだけど気のせいかなw

**デフォルトの名無しさん** · 2021/04/24(土) 22:25:30.30

config、settings
配列って連想配列のことだよね

**デフォルトの名無しさん** · 2021/04/24(土) 22:33:52.72

>>958
スレ違い

**デフォルトの名無しさん** · 2021/04/24(土) 22:43:44.49

>>960
名前を与えられるだけの条件を満たしてないというのも立派な回答。
そういう交通整理こそスレ違いだから
しかしどこにでも他人にケチをつけたいだけのバカいるなほんと

**デフォルトの名無しさん** · 2021/04/24(土) 23:00:23.27

>>956
for ent in xxx_entries

**デフォルトの名無しさん** · 2021/04/24(土) 23:28:36.98

>>961
いや>>1は見ようよ
そのルールが気に食わないと思うならこちらに書き込まないのが大人の対応

**デフォルトの名無しさん** · 2021/04/24(土) 23:52:57.68

>>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みたいな事前処理の結果だと分かる名前にするかもしれない

**デフォルトの名無しさん** · 2021/04/24(土) 23:58:58.76

>>961
スレ違いじゃなくて、理解力も想像力も足りないバカだったか。。。

**デフォルトの名無しさん** · 2021/04/25(日) 00:00:45.26

>>961
>名前を与えられるだけの条件を満たしてないというのも立派な回答。
これには同意するんだけど
命名以前の問題があると感じたんならそれがどの辺なのかを指摘して
良い命名ができる手助けをしてあげたらいいんじゃないかな

あー、>>2にある設計・命名スレに誘導すればよかったのか

**デフォルトの名無しさん** · 2021/04/25(日) 00:48:37.24

>>2にあるスレは死んでるっぽいので
命名の相談時に設計のアドバイスや指摘を禁止しないスレ立てといた

【命名スレ1】命名に悩んだらココへ (設計助言あり)
https://mevius.5ch.net/test/read.cgi/tech/1619279151/

**デフォルトの名無しさん** · 2021/04/25(日) 02:38:18.46

また死ぬ

**デフォルトの名無しさん** · 2021/04/25(日) 03:15:27.21

世の中ほんと馬鹿が多いよね。

プログラミングは実学であり命名なんて「分かりやすいコードを書く」という
上位目的達成のための一手段に過ぎない。

上位目的が間違ってるならその手段を考えるのは無駄だ。
少なくとも>>956の仕様はクソだ。

こんなクソ仕様の変数にどんな名前を付けたって意味はない。
どうせ名前からそれが何を意味するかをくみ取ることなんて不可能なのだから。

>>965みたいなバカは「水虫の足の切断方法を教えてくれ」という質問者に足の切断方法を
説明するんだろうね（笑）

俺なら皮膚科の医者に行けバカという。

**デフォルトの名無しさん** · 2021/04/25(日) 03:26:05.72

んー、このスレではそのような話題は何度も出てるよ
あえてこのスレでは設計に関する話題は除外することになってるので、別スレでどうぞ

なんで除外してるのかは>>2が死んでることからも察してもらうか、過去スレを舐めるように追ってください

**デフォルトの名無しさん** · 2021/04/25(日) 03:35:50.60

>>970
こいつも重症だな
設計の話なんか誰もしてない。
問題自体が間違っているなら回答することに意味がないと言ってるんだけど

**デフォルトの名無しさん** · 2021/04/25(日) 03:44:56.19

さて次は上から目線でどんな馬鹿を言うか楽しみだねw

こういう連中は単に頭が悪いだけじゃなくて自分が単に「他人のやることにケチを付けたい」
という下劣な動機に突き動かされていることが自覚できない性格異常者。

ついでに言わせてもらえれば、スレのレンプレにグダグダとルールを書き込むのは有害無益。
こういう卑しい連中に他人に絡む口実を与えるだけのことでスレの「平和」には一切寄与した
試しがないからね。

**デフォルトの名無しさん** · 2021/04/25(日) 04:01:27.17

ん？
命名自体意味がないって言いたいのかな？

**デフォルトの名無しさん** · 2021/04/25(日) 04:12:27.28

>>972
「他人のやることにケチを付けたい」て、自己紹介すんな！ｗ

**デフォルトの名無しさん** · 2021/04/25(日) 05:37:50.62

かまってちゃんはNGして無視で

**デフォルトの名無しさん** · 2021/04/25(日) 10:07:18.53

>>971
意味がないと思うならスルー
>>972は自己投影にしか見えない

**デフォルトの名無しさん** · 2021/04/25(日) 11:05:41.53

え？無料で変数名の相談に乗ってくれた上に
無料で設計のアドバイスももらえるんですか！

**デフォルトの名無しさん** · 2021/04/25(日) 12:32:05.94

もらえるよ！

参考になるかどうかは知らんけど…

**デフォルトの名無しさん** · 2021/04/25(日) 13:33:01.25

相談者そっちのけやけどな！ｗ

どうせだいたいが「アドバイス」というよりは、言いたいことを言ってるだけの決めつけばかり。

**デフォルトの名無しさん** · 2021/04/26(月) 01:24:45.55

>>956
素直に file_data とかでよい気がする
temp は本当に一時利用の目的でなければ避けた方がよい
やるとしても file_data_temp とかかな

配列って言ってるけど構造体参照への配列とかだよね

**デフォルトの名無しさん** · 2021/04/26(月) 02:10:55.19

file_dataだとファイルを読み込んだ生データに見えちゃう
必要なのはパス情報なんじゃないの？
path_parts_list
みたいなのを処理関数に渡して、そっちで読み込んだりするのかとオモタが

**デフォルトの名無しさん** · 2021/04/26(月) 02:19:00.69

childItemList

**デフォルトの名無しさん** · 2021/04/26(月) 02:29:12.92

ファイルパスや拡張子はたぶん一例で、IDみたいな情報も含んでるらしいぞ
当人が思い付いた候補もそれっぽい
パスに特化した名前よりも設定全般を表す変数名が妥当だと思う

**デフォルトの名無しさん** · 2021/04/26(月) 02:32:01.56

お題がかなり抽象的だからいっそparamsでもいいシチュエーションな気もしてきた

**デフォルトの名無しさん** · 2021/04/26(月) 07:33:33.25

>>981
まあ data がファイルの中身に見えるのはそうかなと思う
配列名を file_info にしたうえで、中身をしまう先は file_info[],content とかにするかな

**デフォルトの名無しさん** · 2021/04/26(月) 12:31:03.80

>>983
>設定全般
設定の話だっけ？

**デフォルトの名無しさん** · 2021/04/26(月) 13:04:04.27

いわゆるいれもんやろ。

**ネミ子** · 2021/04/26(月) 14:57:01.40

次スレ立てミスりました(つ∀｀)ﾀﾊｰ
4年ぶりとか久しぶりすぎ・・・
連続するためかわたしはもう立てられないようですので、どなたかお願いいたします。
クラス名・変数名に迷ったら書き込むスレ。Part29
クラス名、変数名のつけ方に悩んだら書き込むスレです。

命名規則や設計の善し悪しについて議論するのは基本的に禁止。
命名するのに足りない情報は適当に想像して楽しんでﾏﾀｰﾘ返してあげてください。
設計などの話が主題になるならば他のスレでどうぞ。

前スレ
クラス名・変数名に迷ったら書き込むスレ。Part28
http://mevius.5ch.net/test/read.cgi/tech/1494147712/

**デフォルトの名無しさん** · 2021/04/26(月) 18:00:16.89

次スレ

クラス名・変数名に迷ったら書き込むスレ。Part29
http://mevius.5ch.net/test/read.cgi/tech/1619427133/

**デフォルトの名無しさん** · 2021/09/28(火) 03:43:35.62

(UTC+9) とかの "+9" に固有名称ありますか？
無い場合どういったものが適当でしょうか？
diffUTCtime とか TimeZoneAdjustableValue みたいな？

**デフォルトの名無しさん** · 2021/09/28(火) 07:42:17.66

UTC offset
timezone offset
time offset
offset hours
この辺でいいんじゃないかな

**デフォルトの名無しさん** · 2021/09/28(火) 07:45:10.82

UTC offsetかUTC time offsetだね

**デフォルトの名無しさん** · 2021/09/28(火) 09:39:29.80

ちなみにman dateには「numeric time zone」とある。

**デフォルトの名無しさん** · 2021/09/28(火) 22:36:46.20

>>991-993
timezone そのものを指すものでもあるし num_TimeZone や TimeZone で良いのかも
他には
UTC time offset
timezone offset
短い変数名だと iTZ_h 辺りかな
ありがとうございました

**デフォルトの名無しさん** · 2022/01/02(日) 01:35:29.19

ｔ

**デフォルトの名無しさん** · 2022/01/02(日) 01:35:50.17

ｂ

**デフォルトの名無しさん** · 2022/01/02(日) 01:35:56.05

ｇ

**デフォルトの名無しさん** · 2022/01/02(日) 01:36:22.69

ｖ

**デフォルトの名無しさん** · 2022/01/02(日) 01:36:30.15

ｃ

**デフォルトの名無しさん** · 2022/01/02(日) 15:45:55.12

ｘ

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1700日 21時間 44分 3秒