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

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

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

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

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

**ネミ子** · 2017/05/07(日) 18:03:36.48

無関係スレ
設計・命名スレ
http://echo.2ch.net/test/read.cgi/tech/1477368563/

設計から喧々諤々されたい殿方は別スレがございますので、そちらをご利用ください。

**デフォルトの名無しさん** · 2017/05/07(日) 18:17:56.16

乙

**デフォルトの名無しさん** · 2017/05/10(水) 02:45:04.00

データベース的なものを想像して欲しい。
あるデータ群（オブジェクトの配列）を画面出力するとき、出力イベントをフックして

　・「表示/非表示」を切り替える（単純にreturn falseだけで済むような処理ではない）
　・「見た目」を切り替える（色変更や予め用意した画像に変更など）

の2つが必要なとき、それぞれどんな単語を使えばいい？
紛らわしくなく、かつ統一感のある関数名にしたい。

上記2つは呼び出すタイミングが微妙に異なるため、一括にはしにくい。
また、出力を切り替えると言っても、実際には個々のオブジェクトに含まれている値やメンバ変数を読み込み、
その設定を適用させるといった内容になる。

**デフォルトの名無しさん** · 2017/05/10(水) 07:56:10.53

visibityとstyle

**デフォルトの名無しさん** · 2017/05/10(水) 08:06:31.31

ありがとう、それでいく
出社前にスレ確認できてよかった

**デフォルトの名無しさん** · 2017/05/16(火) 21:12:59.38

通信やファイルへ書込を伴う処理で
一旦変数に代入（書き込み予約）してから、任意のタイミングで確定させて処理したい

確定処理ってupdate？ apply？ commit？ finalize？ save？
それとこの場合の代入ってsetでいい？

**デフォルトの名無しさん** · 2017/05/16(火) 21:43:09.50

もう少し詳しく書かないと何とも状況が分からんね

**デフォルトの名無しさん** · 2017/05/16(火) 22:08:11.06

むしろ確定の方をsetにした方がいいような…

を確定するの英訳｜英辞郎 on the WEB：アルク
https://eow.alc.co.jp/search?q=%E3%82%92%E7%A2%BA%E5%AE%9A%E3%81%99%E3%82%8B

予約、だと自分はreserveをよく使うな…

**デフォルトの名無しさん** · 2017/05/16(火) 22:12:30.84

stageとcommitかな
でもwriteやsendといった実際の物理的な動作をイメージさせる名前を差し置いてまで強調するようなことだとは俺は思わないけどな
抽象的な名前は基本的に糞

**デフォルトの名無しさん** · 2017/05/16(火) 23:16:14.08

ReserveFoo()とかが並ぶのか
代入の接頭詞はset、みたいなイメージあると代入にしろ確定にしろ結構離れる感じね

>>10
一応、write()と同じくらいのレベルでsave()を想定してた

**デフォルトの名無しさん** · 2017/05/17(水) 10:22:15.30

>>7
その言語でよく使われているORマッパーとか参考にすると
他の人にも理解してもらえそう

**デフォルトの名無しさん** · 2017/05/17(水) 10:24:01.10

setかどうかはmodelかviewかによるかな
modelならset

**デフォルトの名無しさん** · 2017/05/17(水) 11:04:25.83

>>7
BufferedFile f;
f.write(data);
f.flush();

BufferedConnection c;
c.write(data); // or c.send(data)
c.flush();

**デフォルトの名無しさん** · 2017/05/18(木) 12:25:59.00

Series を列挙する型と、それを格納する変数。
C# だと

enum Series {
　A,
　B
}
Series Series;

とできなくはないけど、別にしたい。
たいていは列挙の方を複数、変数を単数にするんだけど、複数と単数で変化がないものはどうしたもんか。

**デフォルトの名無しさん** · 2017/05/18(木) 12:39:39.31

>>15
靴に足を合わせた方がいいと思うよ

型名と変数名が同じだと気持ち悪いという感覚が時代遅れだから、
名前を小細工するより自分の感覚を修正した方がいいんじゃないかしら

**デフォルトの名無しさん** · 2017/05/18(木) 13:22:41.48

>>15
型名は大文字から、変数名は小文字から始めればよい

**デフォルトの名無しさん** · 2017/05/18(木) 21:24:31.73

十分にスコープが狭いならsでも別にいいや感

**デフォルトの名無しさん** · 2017/05/19(金) 01:40:19.91

1年後に1画面に入らないくらいまで広がっててsってなんだっけー

**デフォルトの名無しさん** · 2017/05/19(金) 02:53:52.81

１画面くらいならそこまで問題にならんだろｗ

15 · 2017/05/19(金) 08:38:09.61

んー、時代遅れか。
C# の例は挙げたけど、できない言語の場合にどうしようかってのもあったんだがな。
大文字小文字の場合も。
これといった案はなさそうだね。
いろいろ意見ありがとう。

**デフォルトの名無しさん** · 2017/05/19(金) 15:07:17.02

>>21
> できない言語の場合にどうしようかってのもあったんだがな。
> 大文字小文字の場合も。

enum SeruesOption {A, B}
SeriesOption series = A

**デフォルトの名無しさん** · 2017/05/20(土) 03:47:13.80

最初の質問で「できなくはないけど」と言いつつ
「できない言語の場合」って追記するの、ちょっとずるくない？

**デフォルトの名無しさん** · 2017/05/20(土) 09:02:34.55

>>23
やり取りを円滑にするために最初に忘れず言おうな、とは思う。

が、ズルくはないだろ。
それで質問者が何か得したわけでもないし、
君が何か論破された訳でもないんだから。

**デフォルトの名無しさん** · 2017/05/20(土) 09:52:00.08

まあできない言語なら >>16 みたいな回答はないから初めから書いとけ
って言うのは正しいと思う
でももう終わった話だしいちいち蒸し返す意味ない

**デフォルトの名無しさん** · 2017/05/20(土) 09:58:35.64

言語に関わらず共通のスタイルを使うという発想自体がそもそもの大間違い
郷に入れば郷に従え
C#では型名とプロパティ名に同じ名前を付けることが推奨されていてenumにXXEnumみたいなのは禁止されている
他の言語には違ったルールがある、それに従うだけ
その良し悪しを判断するのはお前でもこのスレでもない

**デフォルトの名無しさん** · 2017/05/20(土) 10:00:30.34

あとC#ならenumの型名にs付けていいのはビットフラグの場合だけだ

**デフォルトの名無しさん** · 2017/05/20(土) 15:02:41.50

>>27
そんな違いあるのか。ちょっと面白い

**デフォルトの名無しさん** · 2017/05/20(土) 16:07:08.58

型の名前は型自身じゃなくてインスタンスの性質を表しているべきだって
発想かもしれんけど、拡張メソッドの入れ物の静的クラスにExtensionsなんてのもあったりして
ちょっと統一感ないね

**デフォルトの名無しさん** · 2017/05/22(月) 08:56:31.87

>>29
インスタンスの性質は分かるけど、型自身の名前って例えばどんなの？

Extensions だって性質を表してるんじゃない？
詳しく表してるとは言い難いけど。

**デフォルトの名無しさん** · 2017/05/22(月) 10:19:43.12

The name of a type should express the charactor of not a type itself, but the instance

**デフォルトの名無しさん** · 2017/05/22(月) 23:54:30.25

確かに、やや低レベルな名前って気はするかな
具体的にどうすればいいかは分からんけど

**デフォルトの名無しさん** · 2017/06/21(水) 16:36:34.47

現時点ではスレチだけど、いずれ設定周りの名称に出没しそうなのでご容赦ください。

スタンドアロンのシステムが既に稼働していますが、一部機能をクラウド化して併用する計画があります。
クラウド化してもスタンドアロンの方もそのまま運用を続けます。
いわゆる半クラウド？とでも言うのでしょうか、このようなシステムの場合、
何と呼べばいいでしょうか？

**デフォルトの名無しさん** · 2017/06/21(水) 16:54:36.57

ぐぐったらこんなのが見つかった
https://www.ibm.com/blogs/solutions/jp-ja/what-is-hybrid-cloud/
なんかベタだねw

**デフォルトの名無しさん** · 2017/06/21(水) 18:34:51.54

>>34
ありがとうございます。
色々調べましたが、ハイブリッドクラウドとは
パブリッククラウドとプライベートクラウドなどの複数のインフラ周りを
組み合わせた場合に呼ぶようです。
サーバーデータの保全や負荷分散という説明も見ると、
今回のケースに該当するのかというと、う～ん。。。

**デフォルトの名無しさん** · 2017/07/01(土) 12:23:57.34

単項検証: SingleFieldValidation
相関検証: MultiFieldsValidation

データベースで行と行を比較する検証や表を超えて検証する場合はなんと言いますか？
日本語と英語の両方ともわからない

**デフォルトの名無しさん** · 2017/07/08(土) 15:58:43.96

>>36
相関　correlated
行　row　または　record
表　table

**デフォルトの名無しさん** · 2017/07/15(土) 09:19:26.23

ちょっと物事を単純化して話しますが
オブジェクトの有効期間を変数として持たせたいんです
リストの中にぶっこんでいって
リストを触る奴がその値によってリストから削除したりをさせたい

このとき、有効期限をどう表現しますか？

色々考えた結果
long lifetime = now + duration;
と初期化しておいて
if (obj.lifetime < now) list.remove(obj);
というふにしました

もっと名前、初期化、運用に他のやり方があったかなと心配しています
名前は単にtime_to_removeでもよかったかなと思ってます

**デフォルトの名無しさん** · 2017/07/15(土) 10:13:38.40

クッキーを参考にしたまえ

**デフォルトの名無しさん** · 2017/07/15(土) 10:41:48.41

expire

**デフォルトの名無しさん** · 2017/07/15(土) 13:45:28.74

>>38
有効期限が本当にそのオブジェクトが管理すべき情報なのか、それともそのオブジェクトを使う側が
管理すべき情報なのか、それだけじゃ分からんけど、前者だとして

CreationTime（作られた時）
LifeSpan（寿命）
TimeToLive（余命 CreationTime + LIfeSpan - now）
IsAlive（TimeToLive > 0）

こんだけの情報を持たせた方が扱いやすいかも

**デフォルトの名無しさん** · 2017/07/15(土) 14:31:14.53

>>39 ありがとうございます見てみます
>>40 expireは既に別のとこで使っておりまして

>>41 もう少し正確にお話すると
class WithLifetime<T> {
public final T org;
public final long lifetime;
WithLifetime(T org, long duration) {
this.org = org;this.lifetime = System.currentTimeMillis() + duration;
}
}
こういうのを
list.add(new WithLifetime<Foo>(foo, TimeUnit.HOURS.toMillis(5)));
こう使ってますね
あくまでlistありきで
list中の生存期間を、listを使う側の都合で勝手に決めてるという
List<Foo> listのままで、Map<Foo, Long> lifetimeみたいなのを併用
っていうのも最初は考えたりもしたんですが、それでいくと
list0, map0, list1, map1, list2, map2みたいな煩雑さがチラついてきますんで
この形式にしました

**デフォルトの名無しさん** · 2017/07/16(日) 03:26:58.87

>>42
そのlistを拡張した方がいいんじゃないの
管理対象のobjectは何も知らない方がいい
listを使う側も同期とか以外は知らなくていいくらいに
そしたら汎用でも使える

**デフォルトの名無しさん** · 2017/07/16(日) 12:39:20.68

>>43
ありがとうございます
とても有力な手だと思います

ただ、みなさんも覚えがあるかもしれませんが
こういうコンテナラッパーを気軽に書いても
意外とスッキリしていかねえな、ということです

1) 最初から十分なインタフェースをそろえるのはめんどい（主に指の疲労）
2) だから最初はsize, add, removeくらいで始めるのだが
あとで結局また加筆していくことになる
3) コンテナクラスの理想は中身を知らないこと
でもこういう作りにするとそこに想定が入ることになる
だからと言ってすぐ困りはしないが、そのことに小さい不満が残る
removeExpired()みたいなこともさせたいが、何か不満が残る
それに引数を与えてやりたいが、ここでその引数の名前が難しすぎる
何をどういう基準でremoveしてるかを表現しきるメソッド名も難しい

最後までぐだぐだ申しましてすみません
不満ばかりできりが無いのでこれにて閉じさせてくだしあ

**デフォルトの名無しさん** · 2017/07/16(日) 16:29:38.83

Listのextendできない環境なのか

**デフォルトの名無しさん** · 2017/07/17(月) 08:04:36.40

>>44
remove_if(predicate)

**デフォルトの名無しさん** · 2017/07/17(月) 10:09:00.03

>>45
もしくはその知恵がないかやりたくない理由があるんだろ
>>44の文章見るとなにか異様にこだわりあるみたいだし

**デフォルトの名無しさん** · 2017/07/18(火) 02:42:58.10

俺は同じような状況でexpires_onにしたことがある

**デフォルトの名無しさん** · 2017/08/31(木) 08:14:10.71

Optionsみたいに複数形ってクラス名には不適切？

OptionBagか
OptionsBagにすべき？

**デフォルトの名無しさん** · 2017/08/31(木) 08:48:46.76

Containerとか

**デフォルトの名無しさん** · 2017/08/31(木) 12:53:15.50

>>49
別に複数形でもいいと思うけど、規約か何かで使えないなら
「諸設定」っぽニュアンスがあるようなないような気がするconfigurationにするとか

**デフォルトの名無しさん** · 2017/08/31(木) 14:19:34.74

OptionSetとかOptionListでいいんでない

**デフォルトの名無しさん** · 2017/08/31(木) 14:54:36.74

>>52
言語によってはデータ型としてSetやListが用意されていて、その場合はそれらの性質を持っていないのに
そういう名前を付けるのは望ましくない。

**デフォルトの名無しさん** · 2017/08/31(木) 15:58:56.77

listはともかく、setはちょっときついだろ。
意味が多すぎる。

**デフォルトの名無しさん** · 2017/08/31(木) 18:00:27.66

逆でしょw

>>49が言ってるようなクラスは普通に考えたら
雑多な（型も意味もバラバラの）optionの寄せ集めなんだろうから
あえて何かつけるならsetの方がニュアンス的に近い

**デフォルトの名無しさん** · 2017/08/31(木) 22:46:11.83

>>49
そんな再利用性のないもんをクラスにすんな（直球）

汎用的なクラスをつくっといて、
変数名でもって特殊化して運用セヨ

**デフォルトの名無しさん** · 2017/08/31(木) 22:54:08.86

>>53
継承したら

**デフォルトの名無しさん** · 2017/08/31(木) 23:53:16.30

Optionの単数形でも別にいいと思うけどね
各オプションには具体名があるだろうし

責務によってはOptionManager/OptionHandler/OptionContainerみたいなer系も有り
オプションバッグ、オプションセット、オプションリストとかは普段からそういう名前で呼んでも問題ないかどうかに依る
あとは汎用コレクションクラスを使ってList<Option>みたいな選択肢も

**デフォルトの名無しさん** · 2017/09/01(金) 00:29:25.98

>>58
> List<Option>みたいな選択肢も
だいたい後悔するんじゃね？
ただし、拡張メソッドがあるC#ならなんとか。

**デフォルトの名無しさん** · 2017/09/01(金) 22:02:43.64

javaはPropertiesクラスがあるから複数でもいい気が

**デフォルトの名無しさん** · 2017/09/20(水) 20:11:34.47

ある値と、それに掛け合わされる係数fooがあります。
元の値が500、fooが30だとすると、500の30%アップで650といった具合です。

このとき以下の関数名をお願いします。
(a)そのまま30を返す
(b)0.3を返す（30%→0.3なので）
(c)130を返す（元の値を130%する）
(d)1.3を返す（元の値に1.3をかける）

関数を1つにまとめて、フラグなり呼び出し元で計算するなりしろよ思わないでもないですが、
名前変更以外の修正を伴うので避けたいところ。
ちなみに既存のコードはGetFoo1()、GetFoo2()…という命名になっているので
ちょっとキレそうです。

61 · 2017/09/20(水) 20:18:55.20

>61に追記です。
圧倒的に使用頻度が高いのは(a)の「そのままの値を返す」でした。
ほかは同じくらい、

**デフォルトの名無しさん** · 2017/09/20(水) 21:27:00.99

>>61
> (c)130を返す（元の値を130%する）
> (d)1.3を返す（元の値に1.3をかける）
申し訳ないが意味わからん

**デフォルトの名無しさん** · 2017/09/20(水) 21:35:02.04

>>61
(a) deltaInPercent
(b) delta
(c) multiplier
(d) multiplierInPercent

スレ違いだしたぶん余計なお世話だと思うけど、可能なら「係数」自体を
クラス化した方がいいんだろうね

**デフォルトの名無しさん** · 2017/09/20(水) 22:07:22.07

税率、税抜き価格、税込価格、税額みたいに
文脈に応じた名前を付けたほうがいい気がするけど
“〇〇係数”みたいな名前がついてるんじゃないの？

**デフォルトの名無しさん** · 2017/09/20(水) 23:55:11.31

>>61

**デフォルトの名無しさん** · 2017/09/21(木) 00:05:51.85

>>61
(a) なし
(b) increase rate
(c) なし
(d) increase multiplier

パーセント版はいらんやろ。その場で100倍すればいいじゃん。
どうしてもというなら、末尾に_percentとかつければ。命名としては歪かもしらんけど、わかりやすかろう。

**デフォルトの名無しさん** · 2017/09/21(木) 00:08:16.78

>>64
deltaは増分であるべき。

**デフォルトの名無しさん** · 2017/09/21(木) 00:33:44.66

>>68
だから増分だってw
ほかにもっといい表現があるならよろしく

**デフォルトの名無しさん** · 2017/09/21(木) 01:31:41.29

deltaは差分(足し算の増分)のイメージが強いなあ
x = 500
rate = foo/100 = 0.3 だとして、
delta = rate * x = 150
って感じ

**デフォルトの名無しさん** · 2017/09/21(木) 02:14:32.44

お買い物に例えないと算数理解できないデキの悪い小学生じゃないんだからw
正規化された増（減）分って考え方は普通だと思うよw
もともとパーセンテージ自体がそうなんだし