クラス名・変数名に迷ったら書き込むスレ。Part29

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

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

命名規則や設計の善し悪しについて議論するのは基本的に禁止。
設計などが話題になるのなら他のスレでどうぞ。

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

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

命名の相談時に設計についてのアドバイスや指摘を受けてもよい
というかたには、下記の別スレがあります。

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

**デフォルトの名無しさん** · 2021/05/25(火) 06:58:41.32

コンパイラの進化で変数名を漢字にできるようになって久しいしこのスレの役割もほぼ終わったな

**デフォルトの名無しさん** · 2021/05/25(火) 15:45:05.82

スレの役割と言うより、5ch自体の過疎化と老人ホーム化が顕著で活発な人が居ない

**デフォルトの名無しさん** · 2021/06/28(月) 16:55:20.87

変数名というよりUI側の日本語表記だけど、購入日付は hoge_date 時間は hoge_time となんの疑問もない変数名において
UI表記の方の日付が「購入日付」とするならば「購入時間」、「購入日」とするならば「購入時」とするべき？
みたいなお前らオレオレルールありますか？

「購入日」「購入時間」と書いたところでふとしょーもない疑問が

**デフォルトの名無しさん** · 2021/06/28(月) 17:07:07.04

購入日時とするより分けた方がいいのか

購入日付より購入日
購入時より購入時間
購入時だと購入時に何かするのかってなるかもしれない

**デフォルトの名無しさん** · 2021/06/28(月) 17:08:33.67

表記の文字数を合わせるかって意味ならそんなこだわりは無意味だと思うが、「購入時」じゃ
point of purchaseの意味になっちゃうし、「購入時間」ってのも日本語としてちょっと変じゃないかw

普通は「購入時刻」でしょう
店に入ってから会計するまでにかかった時間のことを言ってるなら話は別だけど

**デフォルトの名無しさん** · 2021/06/28(月) 17:16:42.77

「時間」は、できれば使わないようにしてるかな。
datetimeかtimeかdurationか、はっきりしないから。

**デフォルトの名無しさん** · 2021/06/28(月) 17:54:27.40

時間は単位hourのことでもあるので紛らわしいね
時刻です

5 · 2021/06/28(月) 18:03:21.43

>>5で書いた通り最初は「購入日」という表現が普通かなと思っていたところ、
続けて「購入時間」と書いてからふとある意味国語表記的に「購入時間」に対する言葉は「購入日付」
にしないともしかしてダメなのかなと思った次第です

たしかに、そもそも皆さん仰る通り「時間」もおかしいですね
「購入日」の方はそのままで「購入時刻」が妥当ですね

対する言葉とかいう謎な考えは忘れます
どうもありがとうございました

**デフォルトの名無しさん** · 2021/09/03(金) 21:39:09.50

複雑な検索処理の命名に悩む

**デフォルトの名無しさん** · 2021/09/04(土) 01:37:01.23

SearchPlus, UltraSearch
真面目に答えると単に複雑では的を得ず「何を」「どんな条件で」に依るんじゃないか

**デフォルトの名無しさん** · 2021/09/04(土) 02:20:20.76

complex search
compound search

**デフォルトの名無しさん** · 2021/09/04(土) 08:36:31.57

Fukuzatsu_na_Kensaku

**デフォルトの名無しさん** · 2021/09/04(土) 09:51:33.08

RichSearch, DeluxeSearch, GorgeousSearch

**デフォルトの名無しさん** · 2021/09/04(土) 12:40:01.73

SuperUltraGreatDeliciousWonderfulSearch

**デフォルトの名無しさん** · 2021/09/04(土) 14:04:21.33

SelectAsterFromTable1WhereCostGreaterThan3000Yen

**デフォルトの名無しさん** · 2021/09/04(土) 14:51:26.08

守秘義務があるのでボカして言うけどモノは掲示板システムでクエリはこんな感じ

自分が所属してる全グループに所属してる全ユーザー
ユーザーの最新のアクティビティを添える
（アクティビティはログイン、ログアウト、レス投稿、レス編集、レス削除、グループ加入、グループ離脱などシステムイベントのことで種類は多岐に渡る
現行システムではイベントをエンティティとして管理しておらず、多数のテーブルを結合して取得している）
並び順は最新のアクティビティのタイムスタンプ
ページング機能付き

**デフォルトの名無しさん** · 2021/09/04(土) 15:08:38.41

GetUsersWithNewestActivity

**デフォルトの名無しさん** · 2021/09/04(土) 15:27:09.51

ボカしてるか？ｗ

**デフォルトの名無しさん** · 2021/09/04(土) 15:42:30.62

「自分が所属してる全グループ」
「自分が所属してる全グループに所属してるユーザー」
「自分が所属してる全グループに所属してる全ユーザー」

この辺の概念に名前をつけることを考えるといい
要件定義時に毎回「自分が所属してる全グループに所属してる全ユーザー」と連呼してたのかな

**デフォルトの名無しさん** · 2021/09/04(土) 15:48:15.86

引数込みで表現できればいいから極端な話GetUsersとかGetAllUsersで十分な場合もある
類似メソッドの存在次第

**デフォルトの名無しさん** · 2021/09/04(土) 15:59:11.51

ページングも含めてクエリがベッタベタに特定画面向けの専用品に成り下がっていて、一切の転用の見込みがないなら、俺ならクエリ名も「○○機能向け一覧取得」みたいなものにする
あとNewestという語はだいたいLastで置き換えたほうが自然になることが多い

**デフォルトの名無しさん** · 2021/09/04(土) 16:44:33.28

Latest ?

**デフォルトの名無しさん** · 2021/09/04(土) 16:59:10.50

それだとどんな条件でユーザーを絞りこんだのか、並び順がわからないかな

**デフォルトの名無しさん** · 2021/09/04(土) 17:01:40.12

>>21
なるほど
>>22
さすがにそれは大雑把すぎるかなぁ
>>23
多数の画面、バッチで使用するので画面専用の命名は困る

**デフォルトの名無しさん** · 2021/09/04(土) 17:25:01.65

多数の画面とバッチで使うメジャーなクエリなら逆に、The・アクティビティ付きユーザー一覧取得くらいの名前でもいいかもな
たとえば所属にまつわる話がそのシステムにおける標準の閲覧可能範囲なのだとしたら名前に含めないことを検討する

**デフォルトの名無しさん** · 2021/09/04(土) 17:36:57.74

こう考えた方がいいと思うよ。

「その」検索がどんなに複雑だろうが特殊だろうが、
仮に別の検索が存在しないならメソッド名は単にSearchかFind、
せいぜい検索対象（ナニを探しているか？）をくっつけてSearchHogeで何も問題はないはず。

だから「その」検索が他とどう違うか、大事なのはそこでありそこだけだと思うんだけど。

**デフォルトの名無しさん** · 2021/09/04(土) 17:49:16.39

検索という言葉を使ってるが>>18を読んだ限りでは
SearchやFindでの命名が適切なケースではなさそう

**デフォルトの名無しさん** · 2021/09/05(日) 01:42:12.11

全ユーザーのアクティビティから対象ユーザーに関係(所属グループに属するユーザー)しているユーザーのものをフィルタリングって事？

**デフォルトの名無しさん** · 2021/09/05(日) 19:39:16.08

それは非効率だなぁ

**デフォルトの名無しさん** · 2021/10/14(木) 03:59:56.99

puts "緊急事態発生".red.on_yellow
って書ける着色ライブラリがあったとして
カラーコード明示するのがだるいからと
puts "緊急事態発生".error
puts "緊急事態発生".warning
puts "緊急事態発生".e
puts "緊急事態発生".w
とラップしたら意味不明？

**デフォルトの名無しさん** · 2021/10/14(木) 05:55:29.93

>>32
目的ベースで命名するのはいいプラクティスだと思う
ただし色を変更していることは分かるように str.error_color とか
もしかしたら色以外の表示もカスタムするかもしれないから例えば str.error_style とか
errorだけだとちょっと情報量がなさすぎるので、自分ならそのくらいは情報持たせるかな
1文字は今どき論外

**デフォルトの名無しさん** · 2021/10/14(木) 08:30:59.91

>>32
loggerを使ってlog levelと出力先によって表示をカスタマイズしたほうがいい
logger.fatal(message)とかlogger.warn(message)にする
設計方面の話なので別の命名スレかRubyのスレで聞くといいかも

**デフォルトの名無しさん** · 2021/10/14(木) 09:50:10.48

>>32
他人にはかなり意味不明。
でも、場面や頻度なんかで関係者にはあきらかなら、ナシではないんちゃう。

**デフォルトの名無しさん** · 2021/10/14(木) 20:11:05.85

抽象化する箇所が間違ってるよね
つか命名関係ない