ふらっと C#,C♯,C＃（初心者用） Part150

2021/03/23(火) 12:58:24.10

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part149
http://mevius.5ch.net/test/read.cgi/tech/1608085775/
■関連スレ
C#, C♯, C＃相談室 Part94
https://mevius.5ch.net/test/read.cgi/tech/1553075856/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries
http://referencesource.microsoft.com/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2021/05/10(月) 12:08:15.82

下手に英語やローマ字使うより日本のプロパティ名を使った方が分かり易いこともありますな
敢えて外人だけに意味を理解しにくくさせたいときなんかにも使えそうですな

2021/05/10(月) 12:21:43.63

>>866
どんな場面を想定しているのか、すげぇ気になる

2021/05/10(月) 12:34:14.65

enumの要素が日本語だとコメント要らずではある
本体がアルファベットならインテリセンスも問題ない

2021/05/10(月) 12:37:31.60

国民健康保険保険者番号、という単語を変数名にするときは、だいぶ議論した上で、
kokuho_hnoになったな。
national_health_insurance_insurer_numberはとても反発が大きかった。

2021/05/10(月) 12:56:28.88

英語力がボトルネックになってるケースはむしろ少ない気がするね。
命名下手な人は日本語でも意味不明な名前付けそうな気がする
というより、だいたい命名以前の問題で既に失敗してるんだよね

普通のプログラマはそれが何をするメソッドなのか、「何者」なのかを
明確にしてからメソッドを書き始める。

命名で止まっちゃう人はそこがいい加減なんだよね。抽象化が出来てない。

2021/05/10(月) 13:00:52.85

enumって継承できない？

2021/05/10(月) 15:31:20.10

>>841
良い心掛けをお持ちですね
大事になすってください

2021/05/10(月) 15:37:52.56

>>869
プロジェクト全体で使えるならnhi_insurer_numberみたいな略語ならありだと思うけどね

2021/05/10(月) 15:58:21.88

グロサリーは作った方がいいけどNHIで辞書に載ってるから（普通何だこれと思ったらググるよね？）
それはNhiIDでいいでしょ

2021/05/10(月) 16:21:26.47

>>869
>>873
https://www.youtube.com/watch?v=qQDGX7Lj-RE

2021/05/10(月) 17:51:27.04

俺も別に良いと思ったんだけど、とにかく反発がやばかった。
HNI_Insurer_No推しだった。
俺的には番号とついてるものにIDはまずい気がする。

2021/05/10(月) 17:56:24.33

kokuho_hnoだと保険者番号と被保険者番号の区別がつけにくいので
nhi_insurer_numberとnhi_numberくらいがいい気がする
kokuho_insurer_numberでも別にいいかな

2021/05/10(月) 18:24:14.99

変数名は単体で使ってるのか？
それともPersonクラスなどののメンバーなのかによって扱いが違う

2021/05/10(月) 18:31:34.09

>>877
被保険者番号はhhnoという悲しいスタイルに。。

2021/05/10(月) 18:37:55.44

>>876
識別のために割り当てる符号は数字だろうがギリシャ文字だろうがID(identifier)でしょうw
ただ、保険者（業者）と被保険者を区別する必要があることに気づかなかった
この場合NhiIDはまずいね

まあスレ違い甚だしいな

2021/05/10(月) 18:42:01.34

hhnoかぁ

nhiもそうだけどhhnoやhnoみたいな普段の会話で使わない略語よりも
kokuho_hokensha_noとkokuho_hihokensha_noみたいに
普段の会話で使う日本語読みに寄せたほうが何かと良さそうだね

2021/05/10(月) 18:42:58.08

番号なのにnoとか付けないってセンスなくね？

**デフォルトの名無しさん** (JP 0H0a-aC2w) · 2021/05/10(月) 18:46:43.73

被保険者番号みたいなのは
コーディング規約をいじる裁量があれば日本語変数名が最強なんだよなあ
入力はちょっと大変だけど、視認性最強でドキュメントコメント不要になるし
英字表記に悩んだり表記ゆれに煩わされることもない、変な英略語覚えるのに頭使わなくて済む

2021/05/10(月) 18:46:58.67

みんな業務はjavaの人なんだなと

2021/05/10(月) 21:46:48.97

基底クラスでenumのステータス持ってて
継承してそのステータスの種類が増えるとき
enumが継承できないとステータスの種類が増やせなくない？

2021/05/10(月) 21:56:52.64

>>885
enumは決まった値しか取り得ない型
継承して取りうる値が増えたら、それは基底クラスにおける「決まった値のみを取る」という規約を破ってしまうことになる
規約を破らずに値を追加するには、継承せず普通にenumに追加しなければならない

2021/05/10(月) 22:00:17.01

>>886
したらステータス値はどうやって持つべきだと思ってる？
ここでenumが使えないと言うなら一体どこで使えと言うの？

まあ、const intで頑張ってるけど

2021/05/10(月) 22:38:40.75

>>871
出来ぬ、出来ぬのだ
俺も出来たら便利だよなーと思ったけどダメだった

2021/05/11(火) 00:18:16.99

率直に言ってenumを継承するって発想自体が理解不能w

>>885
enum Eを継承してFを作れるとして、Eの型のプロパティHogeを持つクラスAを継承してBを作っても、
Hogeの型をFに変えることはできないよね？

スーパークラスでステート値を増やすって発想に無理がある気がする

2021/05/11(火) 00:47:29.66

>>889
継承してステータスの取りうる状態が増えるときはどーするの？
ステータスはenum使えってみんなが言うから使ったらこのザマだよ
所詮、プログラムなんか組んだことないアホの戯言だった
継承して増える可能性のある値はenumなんか使っちゃ駄目だってことだね
俺は一生使わないと思う

2021/05/11(火) 01:06:35.85

>>890
まずそういうケースがあんまりありそうもない気がするけどあるとして、

(1) ベースクラスを書く段階でサブクラスでありうる拡張を織り込んで予約しておく

(2) それが無理なら
enum BorderStyle {None, Single, Double, ExtendedStyle };

みたいにしておいて、BorderStyle == BorderStyle.ExtendedStyle
の時には別のプロパティでスタイルが決まるようにする

2021/05/11(火) 01:27:29.73

> Console.WriteLine("Hello, {0}! Today is {1}, it's {2:HH:mm} now.", name, date.DayOfWeek, date);
> Console.WriteLine($"Hello, {name}! Today is {date.DayOfWeek}, it's {date:HH:mm} now.")

上の書き方の場合、文字列部分を定数で宣言できたってメリットあったと思うんだけど、$使う文字列挿入だとできないよね
使い分ければ良いだけだと思うんだけど、他に冴えたやり方あったりする？

2021/05/11(火) 01:28:06.43

class作ってメンバでconst intにしようと思ったら
採番が面倒だから結局intになったわ
と思ったらそれもログ出力が面倒で
結局、状態クラス作ったわ

2021/05/11(火) 01:31:27.37

enumは基本的に定数をならべただけだから不変のものにしか使っちゃだめ

ステータスを表すクラス作れよ

2021/05/11(火) 02:06:49.74

>>894
不変よ
少なくともプログラムが実行されてからは
だって状態を表してるんだから
変更が必要になるのは継承で分岐するソースコードの修正作業時だけ

こういう形でenumが使えないなら
今後継承を行う可能性が少しでもあるならそのクラスではenumは一切使えないということ
実際使わないほうがいいと思う

赤青ランプを継承して
赤青黃ランプを作ったときに
状態赤青がenumで作られてたらゴミ箱にブチ込むしか道はない

2021/05/11(火) 02:09:51.01

挿入文字列はコンパイル時に解析される（実行時に解析されるわけじゃない）と思うので（知らんけど）
stringの変数に挿入文字列自体を入れるとかできないと思うけど、そもそも何でそんなことがしたいの？

多言語化のために文字列リソースにしておきたいという動機なら理解できるけど
変数に入れたい動機が思いつかない

2021/05/11(火) 02:10:54.04

>>896
ログ出力したいんじゃん？

2021/05/11(火) 02:12:53.21

>>895
enumの定義をclassの外に出して独立させれば

2021/05/11(火) 02:13:54.09

>>898
何の解決にもなんなくね？

2021/05/11(火) 02:16:57.22

>>898
赤青黄と赤青緑に継承で分岐したとき
どんなenum定義するって言ってる？

2021/05/11(火) 02:38:14.36

>>900
派生元も派生先も関係なく1つのenumで定義すればって意味で書いた
使う時はプロパティやメソッドでそのクラスで利用可能な値かをチェック

2021/05/11(火) 02:41:03.08

だからそもそも根本的に考え方がおかしいと思うよw
集合論的に考えてみて

例えば、

自然数⊂整数

ってことは明らかに「整数 is　自然数」ではないでしょ。
自然数を継承して整数を作る、とう発想がそもそもおかしい。

2021/05/11(火) 03:32:52.71

>>895
赤青ランプを継承して赤青黄ランプを作るってのがそもそも筋が悪いだろう
N色ランプを作って赤青でも虹色でも好きに作ればいい

2021/05/11(火) 07:38:19.05

は？設計書にそう書いてあって
矛盾なく動くのに何がおかしいんだよ
頭いかれてんのか
いいからこの場合どういうenumになるのかさっさと書けよクズ

2021/05/11(火) 08:46:28.86

普通そう言う場合enum使わんしょ
継承後色がどうなるか確定的じゃないし
stateを普通にintで管理して、それにRGB入りの配列で色を割り当てたら？

2021/05/11(火) 08:55:42.36

>>905
それだとプログラムの拡張の際に取りうる値が増える（実行時ではない。ソース修正時）可能性がある項目は全部enum使えないじゃん

まあ、実際使えないけど

2021/05/11(火) 09:52:12.74

>>904
実装上の都合で赤青ランプに後付けで黄色を取り付けたのだから、色を表す定数として赤青のenumとは別に黄色の定数を定義することになるのは自然だろう。
それをあたかも三色同格のランプだと見せかけてるんだから、定数についても見かけ上同列に扱うためのenumを新たに定義しなければならないのは仕方ない。設計がいびつなのだから、内部処理的にもいびつになる。

2021/05/11(火) 10:10:24.00

>>907
何言ってるかわかってる？
基底に20個ぐらいステータスあってさらに増え続けてるとき
継承した分だけenumに同じステータスを追加しまくれっていってんだよ
継承10も20もやったら大変だぞ
もう実際はハードごと20種類以上追加しないといけなくてやってられないから
俺はenumはゴミと切り捨てたけどね

2021/05/11(火) 10:33:16.06

>>908
だから追加できたところでそのステータスを何に使うんだよ
増やしたところで基底型では扱えない未知の値なんだから継承の意味がないだろ

2021/05/11(火) 10:45:31.24

♪燃～～えろよ燃えろ～～よ～～

2021/05/11(火) 11:02:46.92

>>909
は？
お前、状態遷移組んだこと無さそうだからいいやｗ

2021/05/11(火) 11:03:10.18

>>908
まだ言っとるんだねw
だから根本的に考え方が間違ってるんだってw

特化/汎化って言い方をすると思うけど、継承っていうのは
汎用的なものを特定用途に「特化」するものなんだってw

だから>>902に書いた通り汎用性が小さい自然数を継承して整数にする、って考えは根本的におかしいし、
汎用性が小さい2ステートを継承して3ステートの物にするというのも間違ってる

考え方が逆だ。
多ステートの特殊形が3ステートで、3ステートの特殊形が赤青黄でしょ。
赤青のロジックの一部を赤青黄で使いまわしたいなら継承以外の方法で考えましょう。

例えば、RGB.RをRB.Rに変換する変換関数は書けるんだから、
Color ToColor(RGB rgb){ ... }
というメソッドは、中で
Color ToColor{RB rb){ ...}
と使いまわすことはできる

2021/05/11(火) 11:06:54.31

>>912
赤青黄はあくまで例であって実際にはハードの差分管理してんだよ
だから全部定義し直したらものすごい量になっちゃうの

2021/05/11(火) 11:11:17.08

はっきり言うけど
べき論は結構だけど
enum型がこの仕様のままなら
なんにも使えない
もしくは使わないほうがいいと思う俺は

2021/05/11(火) 11:14:26.45

じゃあ、いっそenumって定義をやめよう
state型が必要です

これでおｋ？

おそらくこれができたら
enumなんか誰も使わない
それだけの話

2021/05/11(火) 11:14:32.61

>enumはゴミ

知ってた

2021/05/11(火) 11:18:15.50

>>895
不変っていうのは、実行時に変わらないって意味じゃないぞ
修正／機能追加でも変わらないってことだ
結論としては自分で書いてる通り
>今後継承を行う可能性が少しでもあるならそのクラスではenumは一切使えない
だよ。Enum継承したいってことはつまり変更したいってことだから

Color.RedやColor.BlueはEnumじゃないだろ
まあSystem.Drawing.Colorは構造体で継承できなかった気がするけど
そんな感じで作っとけ

2021/05/11(火) 12:02:27.73

>>915
話が通じない人だなw
問題はenumにあるんじゃない。
>>902にはどこにもenumなんか出てきてないでしょw

汎化するのに継承を使うのがおかしい。
継承は特化するのに使うんだってw

2021/05/11(火) 12:55:03.04

どれの話をしてるのかわからんけど困ったことない

Enumでやる
virtual List<enum> Lamps => 赤、青を返す
override List<enum> Lamps => base.Lampsと黄を返す

Flagでやる
virtual Color Lamp => Color.赤 | Color.青
override Color Lamp => base.Lamp | Color.黄

Flag側で継承
[flag]
enum Color{
赤=1,
青=2,
黄=4,
Hoge=赤 | 青,
Hoge2=Hoge | 黄
}

2021/05/11(火) 13:34:53.46

>>917
そんなの未来永劫保証できないじゃん
enum作った人本当にバカなんだね
使えないもん作ってろよって感じ

2021/05/11(火) 13:38:39.20

>>919
基底に黒とグレーを追加

2021/05/11(火) 14:03:01.12

>>921
別に俺が作ってる訳じゃないからそんなこと言われても知らんがな
enumでやりたくないならそれでいいと思うし好きにやりなよ

2021/05/11(火) 14:27:53.86

>>919
enumの利点はコンパイル時に名前の集合を型として定義できる、
名前の集合が確定していて、だからインテリセンスが使えたり
集合に含まれないはずの名前が使われている間違いをコンパイル時に検出できることなので
それは代用にならんでしょ。

質問している人の問題はたぶん継承に固執してること。

部分集合を再利用して上位集合を定義したいって問題意識は分からんでもないけど、
emumなんてただの名前の集合なんだからそういう場合はコピペ継承するのが多分正解。

2021/05/11(火) 14:31:08.99

適材適所

2021/05/11(火) 14:40:19.26

C#や諸々の言語はそもそも、継承の仕様が出来損ないなんだよね
Java 16みたいにSealed Classを定義できるなら、まだしもねぇ

どんなクラスでも継承できます、なんて言われてもね
全てのサブクラスの面倒を見るなんて、事実上不可能だろ

だからサブクラスを限定する仕組みが必要なのだが…
C#はまだまだ、遅れてるね

2021/05/11(火) 14:45:04.15

>>923
ああ、そういう事ね
Nullとか空とかのEnumを用意しとくべきかみたいな話と似てるな

2021/05/11(火) 15:00:11.95

>>925
Javaのことは知らんけど
C#のsealed classでは駄目なの

2021/05/11(火) 15:07:01.36

自分ならカスタム属性と拡張メソッド作って、集合.Hoge.Colors()で一覧を取れるようにするかな
まあケースバイケース

enum 集合{
[AddColor(Color.赤, Color.青)]
Hoge,
[InheriteColor(集合.Hoge)]
[AddColor(Color.黄)]
Hoge2
}

2021/05/11(火) 15:14:49.86

>>927
そっちじゃなくて継承できる型を限定する機能だね
ShapeインターフェイスをRectangleクラスとCircleクラスのみ実装可能にする
他の奴がTriangleクラスを作ってShapeを実装するのは認めない

2021/05/11(火) 15:43:37.19

>>929
なるほどC#に限定する機能はないね
コンストラクタのアクセス権をinternalにしてアセンブリを分ければ実用上はそんなに困らなそうだけど

2021/05/11(火) 16:04:08.87

>>919
>override List<enum> Lamps => base.Lampsと黄を返す

これはEnumでやってるんじゃなくListでやってるだけのような・・
取りうる状態の範囲をEnumで表現してないしコンパイル時のチェックも無理だよね

>override Color Lamp => base.Lamp | Color.黄

こっちも型としてはColorになるので既存のColor定義が赤と青だけなら
全く別のEnumを新しく定義することか、既存の定義自体を変更して黄を足すかになるので
既存のコードを維持したまま新しいコードを追加することはできないよね？

Enumを使うべきユースケースじゃないからできなくて当たり前なんだけどさ

2021/05/11(火) 16:18:03.82

>>896
文字列の雛形をDBに持たせて、パラメータ部分を置換して出力するみたいなことやってたのよ
『置換して出力』部分を$使う挿入文字列で置き換えられたらいいなって夢想した

pythonの似たような機能でキーワード引数による指定が出来るから、似たようなこと出来ないかなって
> print('{first} and {second}'.format(first=a, second=b))

string.format使えばいいだけなんだけどね

2021/05/11(火) 20:06:26.01

>>932のやりたいことが挿入文字列を共通化したいってことならおとなしくメソッド化して
string ToHelloText(string name, DateTime date) => $"Hello, {name}! Today is {date.DayOfWeek}, it's {date:HH:mm} now.";
で
Console.WriteLine(ToHelloText(name, date));
みたいな使い方するほうがいいんじゃ

2021/05/12(水) 09:24:40.12

プラごみを減らすためにレジ袋有料化するって話と似てるな
そもそもピントがずれてるし前提も可笑しい

2021/05/12(水) 14:46:53.00

リソースで他言語対応すると考えると欲しい気持ちは分かる
"Hello, I'm {givenName} {surname}."
"こんにちは、私は {surname}{givenName} です。"
みたいに書きたい

2021/05/12(水) 14:52:52.50

All your base are belong to us

2021/05/12(水) 18:25:12.05

evalをやりたいと言うことだな

テスト不可になるからいらんけど

2021/05/12(水) 22:11:27.01

c#ってvisual studioインストールしたときに入ってるコンパイラじゃなくて
.Net 5に移行するのが良いでしょうか？
Microsoftも.Net 5移行を推進していきますかね？

2021/05/12(水) 22:18:36.03

同じもの

2021/05/12(水) 23:16:35.91

そうだったんですね！

2021/05/13(木) 01:52:12.91

コンパイラは同じ
実行環境やフレームワークは違う

2021/05/14(金) 12:23:19.63

まさかC#でメンバ変数名のprefixにアンダーバー付けてないやつおる？
https://anond.hatelabo.jp/20210513215649

2021/05/14(金) 12:27:21.06

なんで今更感が半端ない
アンダースコアつけて怒られた記憶あるわ

2021/05/14(金) 12:32:54.76

アンスコあかんの？

2021/05/14(金) 12:45:33.90

今まで記載がずっとなくて、同じMicrosoftの子会社が出してるStylecopっていうコード解析ツールの言ってることなら正しいだろうって風潮だったんだけど逆転敗訴した感じ

2021/05/14(金) 12:49:56.23

前までただのキャメルだったよな？　何かしっくりこないなあと思いつつあわせてたのに
というか>>942はちゃんとprivateのメンバ変数って書いてくれ

2021/05/14(金) 12:59:44.72

俺は今まで通り m_ + PascalCase でいく

2021/05/14(金) 13:15:24.24

キャメルケースの事をキャメルって略すのはどうも抵抗がある

2021/05/14(金) 13:52:15.03

スコープで付けると便利だけどね

gグローバルgUnko
mメンバmUnko
in引数入力inUnko
out引数出力outUnko
valローカルvalUnko

2021/05/14(金) 14:00:51.83

>>942
さすがにアホなガイドラインでほとんど同意は得られない気がする。
バッキングフィールド限定なら少なくとも俺は賛成するけど。

まあ、普通のフィルドもバッキングフィールドも出番減ってるから
どうでもいいと言えばどうでもいいかも

2021/05/14(金) 14:04:32.36

アンダースコアはライブラリと被った記憶
C言語時代だが

2021/05/14(金) 14:10:10.14

ぶっちゃけ客先のカスタマイズできない環境で文字ちっちゃくて見にくいときあるからイラネ

2021/05/14(金) 14:16:07.40

しかし、_でプリフィクスしとくとインテリセンスでフィールドが一覧できて便利だよ、
ってコメントは泣けてくるねw

普通逆じゃないかw
インテリセンスの候補に登場して欲しくない奴を_でプリフィクスするのが普通のセンスだと思うけど。

2021/05/14(金) 14:36:58.65

>>953
そのコメントどこに書いてある？

ところで別の話なんだけど、
とあるデータの集計や加工をメソッドチェーンで書きたい考えと、その集計や加工をデータとは別のクラスかつステートレスで書きたい考えって両立できるのかな？
拡張メソッド使うくらい？

2021/05/14(金) 16:32:10.35

>>954
コンテナ(データ).加工(…).集計(…)

インスタンスメソッドは暗黙的にthisを使ってるのでステートレスじゃないってことなら拡張メソッドも同じじゃない？

2021/05/14(金) 19:49:54.05

オセロのプログラム作っています。
オセロが盤面にの上にくると影を描きたいのですが
これはフォームアプリでできますか？

2021/05/14(金) 20:01:11.64

>>946
publicなメンバ変数って一般的か？

2021/05/14(金) 20:03:38.54

>>956
半透明の影を書き込んだ画像と影なしの画像の2種類を用意しといて切り替えたらいい
それ以上を求めるならFormsなんか捨ててちゃんとゲーム作りとしてUnityとかに再入門した方がいいよ

2021/05/14(金) 20:38:27.45

>>956
あくまでもWinFormでやるならGDI+っていう機能を調べて、
円をキャンバスに描けばオセロ程度のアプリケーションを作るのは楽かもね。
そりゃあ本気でｹﾞｰﾑ作るならUnityだろうけど、
オセロの内容にこだわるなら、コンソールで十分なんだけど。

2021/05/14(金) 20:41:16.98

WPFならDropShadowEffectで一発

2021/05/14(金) 21:13:06.87

>>946
いや、そもそもそんなコーディングガイドラインは存在しなかった。各ツールやライブラリごとに好き勝手やってる
あと、privateだけじゃなくてinternalもな

2021/05/14(金) 21:29:52.56

>>956
「オセロが盤面にの上にくる」っていうのがどういう状況かよく分からんのだけど、
プレーヤーが置いた位置まで石が移動するアニメーション的な演出をしたいってこと？

2021/05/14(金) 21:45:19.42

m_とかアンダースコアつけるとかは原始人に見えてしまう

2021/05/14(金) 21:49:55.96

フィールドにmつけるのは割とそんな悪い習慣じゃないと思うけどアンダースコアは要らんね
mFooでいい。m_Fooにする意味が分からん

2021/05/14(金) 21:50:54.76

そっちの方が原始人度が高いとおもうがｗ