C#, C♯, C＃相談室 Part95

2017/10/17(火) 00:41:22.60

■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part94
http://mevius.2ch.net/test/read.cgi/tech/1492843013/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。

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

2019/12/05(木) 15:24:41.41

MS推奨はPascal

2019/12/05(木) 15:28:13.82

>>219
Pascalにする慣習だしMSもそう推奨しているから従うだけ
命名規約はそれが存在し統一されていること自体に意味があるのであり、機能的な理由付けを求めることはナンセンス

2019/12/05(木) 16:33:23.52

昔はXML最強だと思ってたけど
jsonやyamlの天才的な手抜きにに触れて考えが変わった

2019/12/05(木) 17:22:34.08

>>219
constであることを意識させる必要がもしあるならFOO_BAR形式は決して悪くないと思う。
ただ、その必要性があるケースってよく考えるとあんまりないんだよね。

2019/12/05(木) 18:16:38.66

ぶっちゃけMS自身もconstが全部大文字だったりPascalだったりしてる
細けェことは気にすんな
命名なんて気分だ気分

2019/12/05(木) 19:17:29.95

C++→C#と来て久しぶりにC#に戻ったらC++の面倒くささに驚いた

2019/12/05(木) 19:18:00.89

C++に戻ったらの間違い

2019/12/05(木) 22:20:07.57

>>222
JSONはいいかげんコメント書けるようにしろよ

2019/12/05(木) 22:28:30.57

>>227
コメントというデータを仕込めばいいんじゃね？

2019/12/05(木) 22:56:27.93

ラベルダブルクリックでテキストがコピーされるのに初めて気づいた
何でこんな余計な機能つけるんだよ。せめてプロパティでオンオフできるようにしとけよ

2019/12/05(木) 23:33:27.61

>>228
そういうバッドノウハウに頼りたくない

2019/12/06(金) 12:42:16.61

JSONの"再発見"者ニキ「JSONにコメントを書けないようにしておいてよかった」

2019/12/06(金) 12:55:10.38

>>230
じゃあ、RFC4627 に口出しできる立場になって、自分で提唱すれば？

2019/12/06(金) 12:56:20.84

何がじゃあだよガキかw

2019/12/06(金) 13:58:14.26

どこがガキなのかわからん

2019/12/06(金) 21:08:55.37

えっ？
いきなりRfCとか言い出す>>232なんてガキの思考そのままだろw

2019/12/06(金) 22:18:00.52

なるほどガキらしい考えだ
ママに聞かせて褒めてもらいな

2019/12/07(土) 14:40:03.37

規格が気に入らないなら、それを変更するように影響を与えないといつまでも変わらない。
規格が気に入らない。可能な代替案も気に入らない。って喚いてるだけじゃん。
どっちがガキだよlol

2019/12/07(土) 15:36:41.80

>>237
敵対する言語の信奉者や作者が批判してしている可能性もあるんだから、
委員会に提案しない事が後ろ向きとは限らない。

2019/12/07(土) 17:37:24.28

>>237
そういうのを書生論って言うんじゃないかな？w
その実現可能性ってどの程度？
まあ、ガキだよねやっぱり。悪いけどさ。

そもそも>>227の人はそんな話（どうやったら変えられるか？）なんかしてないんじゃないのかな。
病気の人をからかう意図はないけど、アスペルガーとかじゃなかそんなの普通に分かるよね

2019/12/07(土) 17:47:06.56

ふらっとだけじゃなくここでも人格批判かよ
板違いだから余所でやってくれ

2019/12/07(土) 17:50:57.13

>>237
ほんそれ
叩いてる奴らはバカ類だからほっとけ

2019/12/07(土) 18:02:30.43

>>239
> アスペルガーとかじゃなかそんなの普通に分かるよね
せめて日本語がまともに使えるようになってから出直してこいよ

2019/12/07(土) 18:02:39.31

>>241
いや、C++を直して欲しくて書いているとは限らない。
良いアイデアを敵に与える必要はないので、提案などするひつ世はない。

2019/12/07(土) 18:07:14.42

>>243
あれ、JSONの話だった。

2019/12/07(土) 18:12:42.05

>>238
よくわからないんだけどC#と敵対してる言語ってなに？

2019/12/07(土) 18:21:09.76

大多数のC#erが敵と感じることが多いのはVBじゃないかな
MS的には敵はGoやJavaと言いたいだろうけど、まだまだC#は(Unityを除けば)Windowsでしか使われておらず、プラットフォームの制約で仕方なく選ばれる言語の域を出ない
その上でVBを選ぶかC#を選ぶかは完全に好みの問題なわけで、
そこで好みを優先できる組織ならそもそもサーバーにWindowsなんか採用しないよね

2019/12/07(土) 18:28:17.16

>>245
自分の好きな言語を広めたいと思っている人も居るわけですよ。

2019/12/07(土) 18:37:40.00

>>247
答えになってないんだけど
君が「C#と敵対している」と考えてる言語って何？

2019/12/07(土) 18:50:47.69

>>248
黙秘権を使います。

2019/12/07(土) 20:35:07.03

>>246
もともとunsafeなんかはC#だけだったけど
最近のバージョンは他の部分でも差が付いてるので
好みの問題だけじゃなくなってきてる

2019/12/07(土) 20:48:48.93

さすがに今どきVB.NETは有り得ないんじゃね？

2019/12/07(土) 20:53:05.32

ここ数年VBなんて見てないわ
他の選択肢が多すぎて選ぶ人なんて居ないだろう

2019/12/07(土) 22:43:02.88

1. 設定値を入力する画面がある
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの変数に値を渡す
3. 他クラスは画面の値でなく、設定用保管クラスの変数の値を参照する

みたいなクソ仕様のアプリを書いてしまいました。
なんで直接、設定値入力画面の入力値を参照しないのか・・・。
仕様を直したいんだけど、もうクソ長いコード書いてしまっていまさら直すのも数日かかりになりそう。。。

2019/12/07(土) 22:44:22.12

>>253
これやっぱり直すべきでしょうか・・・・。
工学系の院生の研究用アプリです。

2019/12/07(土) 22:46:49.22

普通じゃね？シリアライズするなら当然そうしねーか？

2019/12/07(土) 23:08:25.55

C#関係ないようなｗ
設定値の復帰させるとかでも一括で管理する部分あった方が取り回し楽になるし何がクソなのかもわからない
>>254
むしろ該当部分組みなおすのに数日かかってしまう形になっているのが問題では

2019/12/07(土) 23:09:21.20

>>253
言ってること誤解してるかもしれないけど、
UIの入力をダイレクトに設定に反映しないのはMSのお作法的には
むしろ正しいんじゃないの？

適用かOKをクリックするまで入力が設定に反映されず、キャンセルボタンを
クリックすると何もなかったことになる仕様なんだよねたぶん？

まあ、仕様が適切かどうかは要件次第だと思うんで、あんまり教条主義的に考えない方が...
要は使いやすければそれでいいんで

2019/12/08(日) 00:00:10.40

大まかな設計は悪くないと思うけど、
2. 設定値を入力して登録ボタンを押すと、設定値保管用クラスの「変数に値を渡す」
3. 他クラスは画面の値でなく、設定用保管クラスの「変数の値を参照する」 (画面の値でも同様によくない)
って仕組みは直した方がいいんじゃないかな
一箇所仕様を変えたら全部が狂うとか、変なことが起きてくるんじゃないの

2019/12/08(日) 00:29:06.09

>>258
まさにそこなんですよね。。。
他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。

2の変数の名前とか少し替えるとどこで参照先を全て直さなければいけない。
この仕様直したいんですけど、時間がかかるのと単純作業を繰り返すので、
考えただけで目眩がします。

2019/12/08(日) 00:38:02.22

え？何が悪いのかさっぱりわからん
～すればってのも俺には的外れに見える

2019/12/08(日) 00:50:00.57

>>259
変数の名前ならVisual Studioの機能で簡単に一括変更できるぞ
https://docs.microsoft.com/ja-jp/visualstudio/ide/reference/rename?view=vs-2019

2019/12/08(日) 01:02:05.03

変数名の変更はVSの機能で一発で済む
vsじゃなくても最近のIDEなら標準的な機能じゃないかな？

書いてある設計自体は普通でクソだとは思わん
設定値が1万個くらいあってそれを1個のclassに全部ぶち込んでるとかだと整理したほうがいいんじゃね？って思うけどそういうわけでもないんでしょ？

画面ロックすればよかったって言ってるってことはあとから値変えられて困ってるってこと？
登録ボタンなんて作らずに画面上の設定値が変更されたら即座に設定値管理用classに反映させればいいのでは？

2019/12/08(日) 01:04:08.10

>>262
それやると設定値にチェックが必要なとこで詰むぞ
やめるべき

2019/12/08(日) 01:06:23.59

>260
同じく、何がくそ実装なの分からない
普通はGUIの変数を直参照しちゃってるから>>253の2,3みたいに直したいって悩みそうなもんだけど

2019/12/08(日) 01:06:29.61

開始日、終了日の入力で
開始日から終了日の期間に制限がある場合とかバインドに弱い
開始値、終了値も同様

2019/12/08(日) 01:13:11.42

>>263
いや、何も詰まないけど？
反映するときにチェックして異常値であることがわかればいいじゃん
登録ボタンで登録時にチェックしてエラーとするのと何らかわらん

設定値保持classは常に正常な値のみを保持する
って要件ならそら無理よ

2019/12/08(日) 04:54:32.09

>>259
前の書き込みじゃわからなかったけど、主要な心配は、コードの保守性の問題じゃなくて処理中の入力に対する問題なの？
もし後者なら本当に作り直しレベルかも・・・・・

2019/12/08(日) 06:45:15.65

WPFとかだとそういう風に組むのが推奨されてるし

2019/12/08(日) 08:21:03.71

>って要件ならそら無理よ

このことを「詰む」って言ってたんではないかと

2019/12/08(日) 08:33:51.79

DocumetViewとかMVVMパターンでは普通の実装だね。

2019/12/08(日) 10:03:29.48

>>266
だからいつ？
ちゃんと考えて

開始と終了の期間に制限があるんだよ
組んだことないの？

2019/12/08(日) 10:24:22.87

>>264
>>267

1　画面に数値を保持して、開始ボタンを押すと画面入力はロックする
3　クラスは1の画面上の値を直接読みに行く

とすると2はいらなかったのかなと。

2があると、設定を増やしたり変数名を変更するたびに1→2→3全部直さなければいけず、
保守が面倒くさいので、後でソースを見た人にブチ切れられないかと・・・。
あと、画面上なら間違って他クラスから値を書き換えることはしないと思うのですが、
変数だと他クラスから不用意に値を書き換えてしまわないか不安で。。。

2019/12/08(日) 10:25:27.96

自分で途中からクソ仕様と思い始めてしまったんですが、これが標準なんですかね。
だとしたら安心して引き継げるのですが。

正直面倒くさくて直したくないorz

2019/12/08(日) 10:29:01.88

>>272
画面に範囲guyのヤツブチ込んでも誰も死なんの？
コントロールだから絶対に想定guyのヤツは来ないはないよ

2019/12/08(日) 10:34:32.17

>>272
>変数名を変更するたびに
vsなら参照してるところもすべて書き換える機能あるよ

2019/12/08(日) 10:48:39.51

>>273
引き継ぐならそのままにしてあげたほうが良い
わざわざ手間をかけて設計を壊して後任の恨みを買う必要はない

2019/12/08(日) 10:56:36.45

>>272
ちょっとした吐き捨ての設定ならそれで問題ないかもしれないけど、入力の項目が多くなってアプリを開いてあの設定を保存して呼び出したいってなった時とかどうすんの？とか結局仕様と設計の問題じゃないか？

2019/12/08(日) 10:57:28.44

>>273
てか、WinFormなの？それともWPF？
自分のこだわりがないならとりあえずフレームワークの流儀に倣ってりゃいいんじゃね

2019/12/08(日) 11:04:44.31

画面遷移されたら消えるの？
たまたま今回画面遷移せんの？
問題が起こりまくるから止めろと言っておく
コントロールの不正な入力を完璧にガードするのはよく知ってる奴でも結構難しいときあるし

2019/12/08(日) 12:32:23.17

>>271
ユーザーが設定値を変更したとき
そうやって突っ込むってことは
>設定値保持classは常に正常な値のみを保持する
って要件はないんだよね？
開始終了とか関係なくユーザーが設定した値保持するだけじゃん
mvvmとか見たこと無いの？

2019/12/08(日) 12:50:54.37

>>280
開始に1980/01/01
終了に1980/02/01
が設定されてたとき
期間に3ヶ月って制限がかかってたときに
開始と終了に2019/09/01-2019/10/01を設定したいとするわな？

よし、じゃ、開始に2019の・・・エラー!（終了に1980/02/01が入ってるので）
じゃ、終了に2019の・・・エラー!（開始に1980/01/01が入ってるので）

詰んだじゃん

2019/12/08(日) 12:55:17.97

>>275
それやったんですけど、なんか変更されないところも出てきて・・・。
ここ以外で変なことやってるのかもしれません。

2019/12/08(日) 12:56:57.51

>>279
開始ボタンをおしても、設定入力画面は開いたままで画面遷移させてないんですよね。

2019/12/08(日) 12:59:14.97

みなさんのお話を聞いていると、
登録ボタンを押して、変数記録クラスに画面の値を記録させるというのはクソ仕様ではなかったんですね。
ホッとしました。

2019/12/08(日) 13:00:29.22

>>281
エラーになる設定に値を設定への操作を許可してりゃ詰んでないじゃんｗ
そもそもそういう操作を禁止するなんて話どこにあった？
ユーザーの操作は何も制限なんてする必要は無い
設定保持classが現在入力されている設定値が正常か否かだけを分かってればいい

2019/12/08(日) 13:00:57.18

画面に入力された文字は変数記録クラスに記録させて、
変数記録クラスを参照していると、

「あれ、この変数って画面ではどこのことだっけ？」

とかなるのは自分の頭がクソ仕様ということか・・・。

2019/12/08(日) 13:04:18.68

この理論、パスワードは8文字以上でって制限だと
1文字目を打ったタイミングでエラー出して入力ボックス消すってことか？
そんでコピペ以外で8文字以上打つことができずに詰んだってか？
そんなびっくり仕様どこにあるの？

2019/12/08(日) 13:04:22.11

>>286
そこは間違いないな

2019/12/08(日) 13:06:20.25

だからワンクッション置かないと駄目だよねって話

2019/12/08(日) 13:08:13.78

>>286
変数記録クラスで変数を入れておくのをプロパティにしておけば、VSの機能で参照先をすぐに探せる

2019/12/08(日) 13:17:20.81

>>287
開始終了は入力中だけじゃなく
killfocusやvalidatedでもだめでしょ？

2019/12/08(日) 13:26:39.13

>>291
だからダメだったら何なの？
不正な値が入力されたらそうであることが参照するclassがわかればいいだけ
登録ボタン形式であっても登録時にチェックして正常異常を判定するのだから異常入力をユーザーに通知できるタイミングの違いでしか無い

何も詰まないのに詰むでしょ？考えて？組んだこと無いの？
って勝手に操作入力制限の要件足して突っかかってくるのやめてね

2019/12/08(日) 13:42:37.78

>>292
元は
>>262
の
>登録ボタンなんて作らずに画面上の
>設定値が変更されたら即座に
>設定値管理用classに反映させればいいのでは？
って発言に対するレスな

2019/12/08(日) 13:49:38.20

>>293
反映させ方にもいろいろあるから開始/終了の制限があっても別に詰まないよ
質問と関係ないからもうやめれ

2019/12/08(日) 13:50:09.94

>>293
そんなん分かってるよ
設定値管理用classが異常値を保持するだけで何も詰んでない

2019/12/08(日) 13:53:27.09

>設定値が変更されたら即座に
>設定値管理用classに反映させればいいのでは？

これ、バリデーションとか無い場合の方がやっかいだよね。
ユーザーは10を入力したかったのに1で処理されちゃうとか。

2019/12/08(日) 13:58:30.12

個人的に割とよくある設計だと思ってる
入力したタイミングからエラーチェックして早めにユーザーに通知できるメリットがでかい
webなんかではよく見る形式
で、そんなよくある設計を詰むよ、なんて言って初学者（かどうかわからんが）に対して無意味に敬遠させるべきでは無いと思う

2019/12/08(日) 14:06:24.08

>>294
え？コントロールの値を直接参照してるのにどうやるの？
無理ゲーじゃね？

2019/12/08(日) 14:08:43.35

>>297
ガチでどうやるの？
範囲指定があった時点でOKボタン的もんが必要でしょ？

2019/12/08(日) 14:18:51.74

MVVMを持ち出してる割にVMとMがごっちゃになってるように見える

2019/12/08(日) 14:19:22.37

>>299
何を無理だと感じているのかさっぱりわからん
from/toが範囲外になったってユーザーがそう入力してるならその値を保持するだけ
で処理に進む段階で異常値があるなら進ませない
登録ボタン形式なら異常値があるなら受け付けない

処理に進むのを実行ボタンとすれば
前者なら異常値があれば実行ボタンを無効化しておき、設定値が全て正常になったタイミングで有効化する
みたいな要件が実現しやすい

2019/12/08(日) 14:25:09.69

>>301
即時反映の話はどこいったん？

2019/12/08(日) 14:26:41.39

さらに設定値を参照してる奴全員に異常値の対応をさせるってありえなくね？

2019/12/08(日) 14:27:36.72

>>302
その値を保持する
ってのが反映だ
根本から話がずれてる

2019/12/08(日) 14:28:42.21

>>303
そんな仕様どこに書いてあった？

2019/12/08(日) 14:32:02.79

なんかすでに議論に勝つためだけに頑張っちゃってる感じ？

2019/12/08(日) 14:34:19.70

登録ボタンと実行ボタンがある前提で登録ボタンの方は無くせる、と言っているのかな？

2019/12/08(日) 14:41:07.50

>>299
入力中はアンダーラインを引いたりメッセージを出して通知はするが間違ってても即保存する
入力された不正な設定値を読み取る時に無視するあるいは警告を出して無視するはたまたエラーを出して失敗させる
後々設定をアプリ外から弄ることも視野に入れると読み取り時にデータの正確性を保証したほうがいい

2019/12/08(日) 14:50:30.86

UI→登録ボタンによるチェック処理→設定値保持class
UI→チェック機能を有した設定値保持class
こんだけ
前者はチェック処理で弾けば設定値保持classには異常値が入っていないことが担保できる
後者は設定値保持class自身が正常と判断してるかどうかで異常値があるかどうかを判断する

別に前者の設計が一概にダメとは思わないしこういうこともよくするが後者が詰むという理論は理解できん

2019/12/08(日) 14:51:48.07

>>272
一般的には読みやすくメンテしやすくするため
画面からの入力を処理する役割と設定値を管理する役割は別のクラスに持たせる
ただ簡単なプログラムなら画面クラスに設定値管理の役割を持たせるのでも別に構わない

他クラスから不用意に値を書き換えられないようにするのはそいうふうに設定管理クラスを作ればいいだけ

レス見る限り他のクラスの変数を
プロパティやメソッド経由せずに直接設定したり直接参照してる風に読めるんだが
もしそうなら役割ごとにクラスを分離したのに密結合してるのが一番の問題
でもブチ切れるレベルの人ならササッと書き換えるから心配する必要ないと思う

2019/12/08(日) 15:03:31.77

>>272
いやいや、2みたいなものは要るし、3は一番ダメだよ
問題なのはフィールドを他クラスのオブジェクトから読み書きする点で、ここをプロパティーやフレームワークの内部コマンドに置き換えたりしないと徐々にコードが酷くなっていくよ

2019/12/08(日) 17:55:31.29

この一連の流れは相談か？

2019/12/08(日) 18:19:08.18

そうだんですよ川崎さん

2019/12/08(日) 18:25:13.90

正直最初の質問が結局何を質問してるんだか俺にはいまいちよく分からないんだけど、
こんな雲をつかむような話でよくレスが50も進むよねw

まず質問者が何を聞きたいと思ってるのかを明確にするのが先だと思うんだけど

2019/12/08(日) 19:25:44.35

>>253の質問内容はわかるだろ
既に>>268, >>270で答え出てるし本人ぽい人も>>284で一応納得してる
レスが伸びてるのは場外乱闘してる基地害が２匹いるっていういつのも流れだからスルーでいい

2019/12/08(日) 19:40:58.07

>>315
漠然とは、ね。
逆にいうと漠然としか分からない

～だろ？w
頭悪そう

2019/12/08(日) 20:06:20.23

いや、わからないならスルーしとけよ
別にお前がわかる必要はないんだしw

2019/12/08(日) 20:19:46.26

また昨日の続きかよ

2019/12/08(日) 20:37:00.33

自分がわからないのは質問者のせいだ
って思い込んでる人は一定数いるからw