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

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

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

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

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

**デフォルトの名無しさん** · 2019/11/15(金) 13:41:49.03

>>824
少なくとも｢全て｣ではないな

**デフォルトの名無しさん** · 2019/11/15(金) 13:42:55.92

他人をバカにするなら
少しは書き込みを見直した方が良いかと

**デフォルトの名無しさん** · 2019/11/15(金) 13:45:07.28

>>806
構造まで名前に入れるのはプログラムの世界では良くあることだよ

**デフォルトの名無しさん** · 2019/11/15(金) 13:46:00.43

元の書き込みを見てないので適切かどうかは別として

**デフォルトの名無しさん** · 2019/11/15(金) 14:26:50.12

>>815
君が論理的にっていいながらディレクトリ構造を持ちだして親子親子言ってるから、
メールボックスのツリー構造を例に出してこれは親子とは言わないよなってツッコんだら
意味が分からないとかもっとふさわしい条件とか、君こそ馬鹿の一つ覚えの
主張しかせず全くツッコミ内容に触れずに相手を馬鹿にすることに全力賭けてるもんだから、
ﾜﾝﾜﾝとしか言えないなって話になる

**デフォルトの名無しさん** · 2019/11/15(金) 19:57:05.56

有向グラフなのか無向グラフなのか
順序関係なのか半順序関係なのか
この辺で親子という表現を使うかどうかが決まる

**デフォルトの名無しさん** · 2019/11/15(金) 20:09:51.51

この件が親子関係になるんなら、この一連のレスバにも親子関係があることになるが
ちょっと意味が分かりませんね

**デフォルトの名無しさん** · 2019/11/15(金) 20:50:28.62

>>830
決まらん。
ひょっとして、ツリーバカと同一人物？

**デフォルトの名無しさん** · 2019/11/15(金) 21:14:16.66

各ノード
親は高々１人
子はゼロ人以上
ループはない

グラフでいうと
親から子への有向単純グラフ
全ての点は、それに向かう辺が1個以下
閉路は含まない

連結の条件は不要かな

**デフォルトの名無しさん** · 2019/11/15(金) 22:28:51.89

>>825-826
ちょ、皮肉殺しのマジレスやめてー

**デフォルトの名無しさん** · 2019/11/16(土) 09:43:16.55

皮肉だったのか
そこしか見てなかったので

**デフォルトの名無しさん** · 2019/11/16(土) 11:14:00.05

皮肉としても底質

**デフォルトの名無しさん** · 2019/11/16(土) 12:58:45.04

自分が分かってない事を分かってないってほんと怖いね

**デフォルトの名無しさん** · 2019/11/16(土) 13:01:11.14

皮肉って言葉の意味わかってんのかコイツ
自分が議論に窮した時に使う言い訳じゃねえんだぞ

**デフォルトの名無しさん** · 2019/11/17(日) 10:42:22.71

ツリーボーイ必死やなw

**デフォルトの名無しさん** · 2019/11/17(日) 11:38:40.03

釣りーボーイか

**デフォルトの名無しさん** · 2019/11/22(金) 12:27:14.39

>>829
メールボックスのツリー構造も親子というと思うけど

なぜディレクトリは親子で、メールボックスは親子ではないの？
構造はどちらも同じだろ

**デフォルトの名無しさん** · 2019/11/22(金) 13:26:05.71

>>841
俺の親はお前なの？
俺が>>829にも安価付けてレスしたら兄弟にもなるの？
ディレクトリ構造とは全く違うわな

**デフォルトの名無しさん** · 2019/11/22(金) 14:43:50.50

>>842
安価もツリーと見なしたら、親子関係にあるとも言えるでしょ
見方によって変わるものを、一面だけ見て決めつけるのも違うと思うんだがな

**デフォルトの名無しさん** · 2019/11/22(金) 18:10:38.25

「お前を俺の親と見なしたら、親子関係にあるとも言えるでしょ」w

**デフォルトの名無しさん** · 2019/11/23(土) 08:14:27.92

メール
　送信者→親
　受信者→子
　　受信者が送信者に返信
　　　元の送信者→親であり子になる
　　　受信者も→親であり子になる

だからおかしくね？って話だと思ってた

**デフォルトの名無しさん** · 2019/11/24(日) 01:47:32.93

別にコードを書くにおいてメールを親子関係としてネーミングするのは自由にしたらいいと思うけど、

送信者X→相手A,B,C
A返信→X
B返信→X,A,C

この組み合わせが変わったりして続くとか普通にあるから、親子関係に当てはめられても人間から見て分かりやすいか？って話
元レスのtwitterの件も同じカテゴリ
もちろん親子関係が成立するメールもあるけど、必ずしもそうならないって話

なのでディレクトリとは明確に違う（ハードリンク云々はおいといて）

**デフォルトの名無しさん** · 2019/11/24(日) 02:22:47.27

まだこの話してるのか
いやメールのスレッドが親子じゃないという例は微妙かなと思ったよ
でも蒸し返してもいいことないぞ
結局スレの趣旨的にはメールの返信元にあたる変数をParentと名付けるのが妥当かどうかという話になる
どう考えてもReplyToだろ
RFCで定められたスタンダードにはかなわんということでFA
もうこの話は勘弁

**デフォルトの名無しさん** · 2019/11/24(日) 22:32:00.69

元の話はTwitterやぞ
何がRFCやねんアホか

**デフォルトの名無しさん** · 2019/11/24(日) 23:02:32.23

何の用語に採用されてようと意味が通じれば別にいいんだけど、
in reply to ってたぶん副詞句なんだよね。

まあそういう不細工さには目をつぶるとしても、
InReplyToっていうメンバー変数を持つクラスのインスタンスがあるとして、
InReplyToのtoがInReplyTo自身に掛かるのか、それともそれを内包する
インスタンスの方に掛かるのか、自明じゃないように感じるよね

parentならこういう曖昧さの問題は存在しない

**デフォルトの名無しさん** · 2019/11/24(日) 23:22:59.50

>>849
前置詞句は使い方次第で副詞句にも形容詞句にもなる
中学校で習わなかった？

A tweet in reply to the tweet
Tweetクラス/構造体のInReplyToで保持してるTweet IDがどれを指してるのか誤解のしようがない

**デフォルトの名無しさん** · 2019/11/25(月) 00:14:30.07

本来は親子でないものに「parent」とかつけたら、そのほうがややこしくてたまらんわ。

**デフォルトの名無しさん** · 2019/11/25(月) 00:38:12.82

グラフ理論とか知ったら発狂しそうだね
なんでこれがpathなんだとか、どこがheadなんだとか

**デフォルトの名無しさん** · 2019/11/25(月) 02:14:23.37

>>848
最初の元ネタはTwitter
最近になって841が蒸し返したのはメールの親子関係をツリーと呼ぶ是非の話
Twitter APIはInReplyTo
メールはReplyToヘッダがRFCで定められてる
スレの趣旨は変数名として何が妥当か
流れを理解せずに勘違いで罵ってるアホはお前だよ

**デフォルトの名無しさん** · 2019/11/25(月) 02:41:05.02

>>850
何を言ってるのか意味が分かんないねw
それ、which is が省略されてるんじゃないの？w

それ以前にtoがどっちに掛かるのか自明でない、という反論として成立していない

**デフォルトの名無しさん** · 2019/11/25(月) 03:10:31.52

>>854
うわっ…お前の英語力、低すぎ…

**デフォルトの名無しさん** · 2019/11/25(月) 04:23:51.12

>>852
抽象と具象の違いってわかる？
わっかんねえんだろうなあ。

**デフォルトの名無しさん** · 2019/11/25(月) 10:52:44.05

>>804のアホが延々無知晒してんの最高に笑える

**デフォルトの名無しさん** · 2019/11/25(月) 12:50:56.59

お前らの対立軸はマクロで見るかミクロで物事を見るかの違いだな。

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

実際に返信関係あるメールだけのミクロで見ればツリーになるけど。

**デフォルトの名無しさん** · 2019/11/25(月) 13:00:47.98

プログラマーって中1レベルの英語も理解できないんだねw

**デフォルトの名無しさん** · 2019/11/25(月) 13:01:16.04

ディレクトリ構造の場合は必ずルート以外は親いるから、まさしくツリーになるけど。

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

もちろん、実際返信関係が成り立っってるミクロな部分だけ見ればツリーだけど。

**デフォルトの名無しさん** · 2019/11/25(月) 13:50:21.50

>>853
Twitterの話→ディレクトリ構造を例に親子関係論展開→Twitterは親子関係じゃない→
ディレクトリ構造を再度提示してこいつが親子なのにTwitterが親子じゃないのはおかしい→

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

この親子関係ｗｗくらい理解してから発言しとけ
まあこんな奴が居るからレス安価（メール）は親子関係じゃ分かりにくいよってなるわけだが

**デフォルトの名無しさん** · 2019/11/25(月) 20:37:57.87

>>860
それってWindowsみたいにドライブ毎にルートがあるような感じじゃないの？

**デフォルトの名無しさん** · 2019/11/25(月) 20:51:43.60

>>862
ムリヤリ親子にしなくてもよろしい。

**デフォルトの名無しさん** · 2019/11/25(月) 22:55:34.19

>>863
何を言いたいのか意味不明なんだけど…
どこからムリヤリとか出てきたんだ？

**デフォルトの名無しさん** · 2019/11/25(月) 23:36:15.23

ディレクトリ構造がツリーの親子だって？
よしハードリンクの話をしようぜ
ジャンクションでループを作ろう

**デフォルトの名無しさん** · 2019/11/26(火) 06:51:02.39

実際の親子でも近親相姦とかあるわけでそんな例外的な話でドヤるのはどうかと思うなw

**デフォルトの名無しさん** · 2019/11/26(火) 08:53:57.19

クソくだらない話が延々と続いてるのでちょうどいいかなと
それとも有意義な議論だったのかこの状況

**デフォルトの名無しさん** · 2019/11/26(火) 12:38:11.97

結局バカの壁は厳然として存在する、という事実が再確認されたまでだよ
世の中には具象の中に抽象的な構造を見出す類の思考がどうやっても出来ない人が存在する、というねw

**デフォルトの名無しさん** · 2019/11/26(火) 18:20:47.91

ツイートがツリー構造に見えるアホとかな

**デフォルトの名無しさん** · 2019/11/26(火) 18:40:00.61

ツリー構造という具象でしか見れてないことにすら気付かないツリーボーイww

**デフォルトの名無しさん** · 2019/11/26(火) 18:59:00.33

何に見えてるの？

**デフォルトの名無しさん** · 2019/11/26(火) 19:47:38.62

>>868
いやまったく。
具象と抽象の具合を図るのが命名の妙であり、このスレの目的。

なんでもかんでも抽象化すればいいってもんではない。
たまたまツリーに見えたとしても、本質的にツリーとして表現するべきかどうかを考えんとな。

**デフォルトの名無しさん** · 2019/11/26(火) 22:55:56.97

何度も同じ話を繰り返すのも壁の向こう側の人の特徴>>813

壁の向こう側の人は、

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

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

要するに他人と議論する以前に自分自身を欺いている。
自分に自信がないから、間違いを認めるのが怖いんだろう。

**デフォルトの名無しさん** · 2019/11/26(火) 23:02:59.13

○○に何が入るのか、じゃなくて変数に何が入るのか、だね訂正します

**デフォルトの名無しさん** · 2019/11/26(火) 23:59:30.95

>何度も同じ話を繰り返すのも壁の向こう側の人の特徴>>813
>要するに他人と議論する以前に自分自身を欺いている。
>自分に自信がないから、間違いを認めるのが怖いんだろう。

みんながお前に対して思ってることそのままでワロタww

**デフォルトの名無しさん** · 2019/11/27(水) 00:16:31.95

tweetが「ふつうにツリー構造」とか言っちゃった>>802君いきしてるぅ？？

**デフォルトの名無しさん** · 2019/11/27(水) 01:00:35.28

>InReplyToっていうメンバー変数を持つクラスのインスタンスがあるとして、
>InReplyToのtoがInReplyTo自身に掛かるのか、それともそれを内包する
>インスタンスの方に掛かるのか、自明じゃないように感じるよね

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

>- in reply toは「〇〇に対する返信」だが、「に対する返信」という変数名では○○に何が入るのか不明確

**デフォルトの名無しさん** · 2019/11/29(金) 10:07:39.73

Twitter、“会話”のネスト化ツリー表示を来年ローリングアウト
https://www.itmedia.co.jp/news/articles/1911/29/news071.html

**デフォルトの名無しさん** · 2019/11/29(金) 14:42:28.69

表示がツリーのようにされるだけ。
データの構造は別。

**デフォルトの名無しさん** · 2019/11/29(金) 15:38:36.89

>>802は相当悔しい思いをしているらしい

**デフォルトの名無しさん** · 2019/12/22(日) 06:42:09.17

迷ったらhoge

**デフォルトの名無しさん** · 2019/12/22(日) 10:15:02.45

いや、fooとどちらがいいか議論が必要ではないだろうか…？
fooならbar、bazと続くが、hogeはどうだ
piyoなのかhugaなのか
実に悩ましい

**デフォルトの名無しさん** · 2019/12/22(日) 16:02:00.13

https://ja.wikipedia.org/wiki/メタ構文変数

**デフォルトの名無しさん** · 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が微妙かどうかはコンテキスト次第

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