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

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

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

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

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

**デフォルトの名無しさん** · 2019/12/22(日) 17:52:02.51

私の頭を見ながらhogehoge言ったことを後悔させてやる

**デフォルトの名無しさん** · 2019/12/28(土) 19:31:32.73

Load（？？？？） <-> Save（保存・記録）
Read（読み込み） <-> Write（書き込み）

Loadも読み込みでOK？

**デフォルトの名無しさん** · 2019/12/28(土) 21:03:10.86

>>885
むしろreadは読み込まない。
読み込むとはつまり読込先が存在するということ
"read data to an array"とは普通書かないのでは？

**デフォルトの名無しさん** · 2019/12/28(土) 21:18:17.06

>>885
カタカナで「ロード」「セーブ」でええやん？
もうリッパに日本語やろ。

**デフォルトの名無しさん** · 2019/12/28(土) 21:43:00.44

読み出し？

**デフォルトの名無しさん** · 2019/12/28(土) 21:45:40.23

>>886
read data into ~

**デフォルトの名無しさん** · 2019/12/28(土) 21:57:03.80

「load read 違い」でググってみた

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

こんな感じでいいのだろうか
確かに意識してなかったけどソースコードはそんな組み方になってたので勝手に納得してみました
皆さんありがとう

**デフォルトの名無しさん** · 2019/12/28(土) 21:58:36.23

ていうか>>886さんの言ってることを今さら理解できました
すみませんでした

**デフォルトの名無しさん** · 2019/12/28(土) 22:06:26.14

x = ReadHoge()

LoadHoge(out x)

こういうことか？

**デフォルトの名無しさん** · 2019/12/31(火) 22:56:12.54

LoadはよりCPUに近い場所に移動させるイメージだな

**デフォルトの名無しさん** · 2020/01/01(水) 02:03:06.51

readもloadも同じく低速媒体から高速媒体に移動するイメージでしょ
readはシリアルやストリームから一定量または全量読み進める感じ
媒体を読む(read)行為そのものに意識があり対象データが何かは必ずしも問わない
loadはオブジェクトやプログラム等の有意のデータ単位を読んで所定位置に載せる感じ
読み込まれる情報に意識があり何がどこに読み込まれるのかだいたい分かってる

loadのコアイメージは読むことではなく、積み荷を載せること
弾丸を弾倉にリロードする感じ

**デフォルトの名無しさん** · 2020/01/01(水) 03:14:02.92

fp=Load("第一章"）
Read(fp, data)
printf(data)　　→　何でもないようなことが幸せだったと思う

**デフォルトの名無しさん** · 2020/01/01(水) 03:48:19.30

それはroadや
って元旦にみんな何しとんねんw

**デフォルトの名無しさん** · 2020/01/01(水) 04:30:15.32

し・・・仕事しとるんやで・・・・・デバッグ中

**デフォルトの名無しさん** · 2020/01/02(木) 00:15:37.46

・

**デフォルトの名無しさん** · 2020/01/12(日) 23:07:00.28

クラス名変数名より一歩前の話です

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

なおさらここはキャッシュレスじゃないだろ・・・と思うのですが、どういう名前が最適かご指南ください

**デフォルトの名無しさん** · 2020/01/12(日) 23:38:10.18

電子マネー：ElectricMoney
電子決済：ElectricPayment, EPOS
クレカ以外のキャッシュレス：CashlessButCredit

でもキャッシュレスでいいって言ってるんだからいいじゃんキャッシュレスで。
ああ、クレカ以外のキャッシュレスを狭義のキャッシュレスって言ってるんだなって分かるでしょ

**デフォルトの名無しさん** · 2020/01/13(月) 00:56:38.11

>>899
「QRコード」は登録商標やぞ。
細かいことを気にするなら、そもそも候補に入れるな。ｗ
一般名なら二次元バーコードかマトリックスコードか。

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

しかし、>>900の言うように、こだわらずに指示に従っとくのも一理。
そいつのせいにしとけばいいんだよ。
コメントに明記しといたれ。ｗ

**デフォルトの名無しさん** · 2020/01/13(月) 02:52:15.06

>>181
ハンガリアン記法を再燃させるな

**デフォルトの名無しさん** · 2020/01/13(月) 16:13:53.18

>>899
nonCash

**デフォルトの名無しさん** · 2020/01/13(月) 16:18:02.53

>>899
そのくくりそのものが典型的な仕様崩壊パターン。

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

英語ならOthersとするしかない。

**デフォルトの名無しさん** · 2020/01/13(月) 16:23:12.93

エバーノートのパチモンでネバーノートを作りたい。

**デフォルトの名無しさん** · 2020/01/13(月) 19:04:38.38

ElectricPaymentに一票
Othersもいいけど、電子決済以外の支払い方法が増えたらまた新しい名前を追加することになると見た

**デフォルトの名無しさん** · 2020/01/14(火) 01:42:05.14

皆さんありがとうございます

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

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

>>904,905
後から増える懸念がとてもあります
ブランド種別や締め日などのワードがちらっと顔を覗かせていますが、
そこまでやるとやり過ぎ論で今のところ防がれています

**デフォルトの名無しさん** · 2020/02/24(月) 10:52:27.86

例えば、メーラーアプリがあるとします
既読管理ができるとして、メール一覧画面において既読のメールを未読と区別するため未読より全体を暗く?表示したりしますがこの名前をお願いします

まず、日本語名からお願いします
暗く?以外にふさわしい表現ありますでしょうか

**デフォルトの名無しさん** · 2020/02/24(月) 12:22:27.23

強調表示 = highlighting

視覚効果の選択肢は知らない
メーラーならオリジナルの方法にこだわるより既存の物に右へ倣えした方がいいと思うけど、
メーラーじゃないんだよね

**デフォルトの名無しさん** · 2020/02/24(月) 12:46:32.33

read の過去分詞が read で区別がつかなくて困るとかか?

**デフォルトの名無しさん** · 2020/02/24(月) 14:17:18.95

>>908
名前を付けようとしてる対象が適切でないように思う

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

例えばcssなら.UnreadMessageBodyや.ReadMessageBodyみたいなclassを定義して
それぞれにcolor, font-size, background-colorなんかを指定するだけ

**デフォルトの名無しさん** · 2020/02/24(月) 19:31:21.70

対処済
低優先
低重要

とか？
区別したい趣旨や目的が不明瞭なら、これくらい抽象的な名前かな？

**デフォルトの名無しさん** · 2020/02/24(月) 19:49:44.96

うーん。アイテムはメールで例を出しましたが、ツイートであったり5chならレスであったりメールと似たようなものです。それの「既読・未読」管理します

で、その暗く?するという視覚効果を適用するかしないかをオプションでユーザーに選択できるようにしたくて

**デフォルトの名無しさん** · 2020/02/24(月) 19:54:31.19

>>909
「既読を〰�ｷる」じゃなく、その逆の発想の「未読を強調表示する」も考えましたがどいなんでしょうね

もうちょっと考えてみます

**デフォルトの名無しさん** · 2020/02/24(月) 20:19:01.61

>>913-914
だから未読/既読を管理すればいいなら例えばIsUnreadとか逆にIsAlreadyReadとかでいいんじゃね？

**デフォルトの名無しさん** · 2020/02/24(月) 21:04:45.30

>>914
(例)macOSのMail.appの設定にあるチェックボックス
- Display unread messages with bold font
- 未読メッセージをボールドフォントで表示

ユーザーにスタイルの選択肢は与えず
あくまで「既読を暗くする」って感覚にこだわりたいなら
上の例で「強調表示する」ではなく「ボールドフォントで表示する」になってるように
「暗くする」とはどういうことなのかをもう少し詳細度を落として考えたほうが良い

**デフォルトの名無しさん** · 2020/02/24(月) 21:55:47.75

dimっていう用語はよく使われるよ

**デフォルトの名無しさん** · 2020/02/24(月) 22:05:36.25

>>916
暗くするって、具体的にはビューの上に不透明度?Opacityを設定したビューを重ねて合成表示すると全体的に輝度が下がって暗くなる
そんな実装です

>>917
あー。なんかdimってありましたね。どっかで見た記憶があるが思い出せない

**デフォルトの名無しさん** · 2020/02/24(月) 22:08:24.40

https://tech.recruit-mp.co.jp/mobile/remember_canvas2/#h-2
合成モードでdarkenとかありますね。
似たような効果なのかしりませんが

**デフォルトの名無しさん** · 2020/02/24(月) 22:16:39.81

dimよさそうですね。
dim background for? read mails
日本語があれやな..

**デフォルトの名無しさん** · 2020/02/24(月) 22:33:44.92

つか、連投すみません。
>>916
未読をボールドフォントで表示する方法もありましたね。アイデアありがとうございます。そっちの方が見やすいかもしれません。試してみます。

**デフォルトの名無しさん** · 2020/04/21(火) 21:47:10.01

○○ファイルを削除する関数の名前に統一性もなくDeleteやRemoveを使ってたのが発覚
ここはまあDeleteに統一かなと思ったけど、気にしすぎかな？

**デフォルトの名無しさん** · 2020/04/21(火) 22:16:03.42

統一しようぜ
核となるニュアンスは取り除く(re-move)だからファイル消去にremoveはかなり微妙

**デフォルトの名無しさん** · 2020/04/21(火) 22:29:43.63

removeが微妙かどうかはコンテキスト次第

同じモジュール内にもかかわらず
同じ意図で異なる名前を使ってるなら統一したほうがベター

**デフォルトの名無しさん** · 2020/04/21(火) 23:58:14.52

>>923-924
やはりまずは統一ですね

ところで、linuxがrmだったりdosはファイルがdel、ディレクトリがrmdir、
win32apiもファイルがDeleteFile、ディレクトリがRemoveDirectoryだったりするのはなぜでしょう？

**デフォルトの名無しさん** · 2020/05/28(木) 14:48:04.26

渡された日付がおかしな日付だったらおかしな部分を0にして返す関数名をお願いします

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

ここでは0にしていますが、おかしいものはxxxに統一しておくことで後々一々日付範囲チェック
しなくてもxxxなら異常値として処理できるように意図しています

**デフォルトの名無しさん** · 2020/05/28(木) 15:23:59.56

>>926
invalidate value

**デフォルトの名無しさん** · 2020/05/28(木) 15:45:21.36

13/31の日付はどう判定すべきなんだろうw

しかし、変なら変だと素直に教えてくれりゃいいのに、
わざわざ別の変な値に変換して返す関数ってずいぶんと意地悪な仕様だなw

**デフォルトの名無しさん** · 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みたいな情報も含んでるらしいぞ
当人が思い付いた候補もそれっぽい
パスに特化した名前よりも設定全般を表す変数名が妥当だと思う