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

2020/05/27(水) 20:28:41.27

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

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

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part147
http://mevius.5ch.net/test/read.cgi/tech/1582100741/
■関連スレ
C#, C♯, C＃相談室 Part94
http://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/index
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

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-a5dV) · 2020/11/29(日) 19:01:28.82

メソッドの戻り値を一回判定するだけなら
一行で書かないほうが変じゃね？
それをわざわざ一旦保存とか逆になんの意図があるのかと
たまにはデバッグやらログで出したいからと言うのはあるがそれは2回利用に当たるから入れて当然やしな

2020/11/29(日) 19:41:11.64

>>733
久々にふふってなった

まるで昨日の俺を見ているようだ……お前にもいつか悟れる日が来ると良いな

2020/11/29(日) 20:16:26.39

判定と取得を行いたいんじゃなくて取得を行いたい
なのに判定しないとプログラム上まずいことになるので判定機能付きの取得メソッドを使う
読む上でわざわざ判定と取得を別に書いてるならそこにあえての理由があるんだろうな、と推測しないといけない
今回のケースならあえてのケースなど無いので可読性を下げる要因でしか無い

2020/11/29(日) 20:17:12.32

>>735
きみ中学生？
男？女？どこ住み？

2020/11/29(日) 20:28:09.84

>>735
それは廓然大悟かね？

2020/11/29(日) 20:31:48.44

>>736
これのどっちが可読性良いかなんて個人の感想レベルだろ
実際俺は100%下のほうで書いてるけど一度もコードレビューで指摘されたことないしな
そして>>733が言うように実行効率は下の方が2倍近く良いので下を選択すべき理由はある
一方で上を選択すべき理由は見当たらない

if(! ini.ContainsKey(section)) return null;
if(! ini[section].ContainsKey(key)) return null;
return ini[section][key];

if (!ini.TryGetValue(section, out var keys)) return null;
if (!keys.TryGetValue(key, out var value)) return null;
return value;

2020/11/29(日) 20:43:57.67

一応言っておくけどここでは713や720に合わせて書いてるだけで実際には1行で書いたりこんなに複数retは使わない
returnは一つにしろというレビューは受けたことあるんでな

2020/11/29(日) 20:51:31.28

>>739
普通に英語として下の方が直感的に分かる
上だと今ですら非直感的な上に変数名によっては更に分かりづらくなる可能性をはらんでる

2020/11/29(日) 20:54:18.24

>>719
TryGetValue()知ってるオレカッケー
って言うおこちゃまだろw

2020/11/29(日) 20:56:55.50

無理に一行にするな、が通るならreturnを1つにしなくていいのでは？
数十行あるメソッドのいろんな箇所でreturnしてると気持ち悪いと思うが、こういうタイプなら複数returnで良い

可読性が個人レベルなのはそのとおり

文字の並びが似通っている、ではなくどういう機能を呼んでいるか？という意味
判定付き取得メソッドが標準で用意され、しかもメジャーな内容でパフォーマンスも良い
それでもあえてそれを呼ばないのは特殊な事情があるのでは？と読み手の思考を止めることにつながるという意味

2020/11/29(日) 21:06:40.39

>>739
上のコードを採用する理由は何の値を戻しているか即座に分かるところ、と俺は判断した

return ini[section][key];

この一文で読解に要する数秒を削る為だけに2倍程度のパフォーマンスを許容するのは普通にありだよ

2020/11/29(日) 21:23:27.82

メソッド名見りゃそれはわかんじゃん
return文にそういう責務を与える意味は？
どうしても必要というならコメントでも書いとけば良い

2020/11/29(日) 21:36:16.22

>>743
returnについては可読性に関わる納得できた理由はちゃんとあるんだが自分やチームが使わないというだけで別にうちのコーディング規約を議題に上げるつもりはない（ツッコんでくる人いそうだったから一応書いただけ）
まぁもう好きにしたらええんやない
C#メインで使っていきたいなら言語として用意されてるものは出来る限り利用すべきと思うけど
そこまで学習コスト払いたくないってことなら一つの方法を出来る限り使いまわすというのも利に適ってるしな

2020/11/29(日) 21:49:34.68

チーム内でのローカルルールがどうなってるかはどうでも良いんですよ
そのチームで合意が取れてるならなんの問題もない
ローカルルールを隠した状態で突っ込まれてローカルルールなんです！って言われても知るかよ、という感想しか出ない

ローカルなものでないなら、基本的には標準に準拠すべきで標準がわざわざtryメソッドを回避している書き方をしていない限り公の場でもそれに準じたほうが良いのでは？というだけ

2020/11/29(日) 21:53:07.17

>>747
いやだからTryGetValueに関してはそれが標準だろっていうのが一貫した俺の意見であってローカルルールなのは>>740で書いた事
実際にギブハブなんかで数多くのプロジェクト参考にしてきたけどLinqで手っ取り早く書く事は多くてもTryGetValueを使わずにContainsとインデクサとかいう非効率な方法採用してる人なんて見た記憶ないしな

2020/11/29(日) 21:58:49.11

>>748
なんで突っかかってくるかわからんけど747の前半は複数retの話、後半はtryの話
わざわざローカルの話である複数retのことなんざ話題に上げんで良いよ、try使うのが標準なんだからそれに習ったほうがよくね、
後半は君と同意見なんだよ

2020/11/29(日) 22:01:07.98

>>749
捕捉程度のノリで書いた事に異様に突っ込んでくるなと思ってビックリしたんでね
それも議題に上げたいのであれば>>739でそういう書き方してるから

2020/11/29(日) 22:11:12.12

>>750
前提として標準に準拠したほうが良いよね、という主張がある
標準では複数retなんて当たり前に使ってる
それをなぜか否定しているので突っ込んだらローカルルールだ！と言われる
そういうローカルルールがあるのは構わんが、それならそう明記しなきゃ標準に準拠しようという主張とズレてブレブレなだけでは？
まさかレビューを受けたことがある、がうちにはそういうコーディング規約があるんです、の意味だったの？

2020/11/29(日) 22:16:38.50

>>751
だから本気で否定したいなら739でもそうやって書いてるって言ってるやん
740で書いたのは「沢山return書いてる時点で可読性低い」みたいなツッコミが入るかなーと予測して"一応"と前置きして書いたと言っただろ
そこを議論するつもりはないと書いたのに異様に拘るんだな

2020/11/29(日) 22:22:25.03

複数リターン禁止ｗｗｗ

2020/11/29(日) 22:22:55.87

>>748
正直俺も見たことないが、>>720が書いてるんだからいるところにはいるんだろ
肝心なのはそいつが何を思ってそういうスタイルにしたのか察して評価してやることで、
>>729みたいに重箱の隅突いて喜ぶのはただの地雷コーダーだからやめるべきだよ

例えば誰かが「ギブハブ」とか言ってても、わざわざ「ギブハブってなんだよバカかよ」と噛み付く必要はないだろ？
GitHubなのは分かるし話は通じてるんだからこいつの中ではこうなのかと納得して「ほーん、ギブハブがどうした？」と聞き返すのが有能なんだよ

2020/11/29(日) 22:26:49.20

>>752
意味がわからんけど補足がなけりゃツッコミなんてなかったんだよｗ
こだわってるのはそっちでしょｗこっちはそうですか、という感想しか無いよって言ってるやんｗ

2020/11/29(日) 22:38:58.86

チャゲアスASUKAのギフハブに監視されてるネタに掛けてGitHubをギフハブと呼ぶのは5chの標準語だと俺も思ってたがそこまで浸透してないのか

2020/11/29(日) 22:42:09.42

なんとも不思議な世界があるんだなあ・・・・
TryGetValueを使うのが今どきの常識的なコーディングだと思ってた自分としては
老害（あるいは悪意があって不適切なコーディングを押し付けようとしてる人）が世迷言をほざいてるだけにしか見えないや

2020/11/29(日) 22:53:33.81

>>754
その理屈で行くとコードレビューなんて出来なくなるな
（これ明らかに意味のない文だけど何かスピリチュアル的な深い意味があるのだろうか…?配慮して指摘すべきではないか…?）なんて一々考察しなきゃいけないのかよ

2020/11/29(日) 23:00:13.09

了解

2020/11/29(日) 23:03:55.81

>>753
MISRAにもあるし高信頼性を要求される場面ではそれなりにありがちな話だよ

2020/11/29(日) 23:14:22.90

>>758
レビュー受けてるような新人はそんなこと考えなくていいと思うよ
多次元辞書でアクセスそのまま返す利点が分からないならまだお勉強段階なんだから、そういうやり方もあると素直に学んでおけば良い
とりあえずチューニングはベテランがもっと後でやる仕事だから、パフォーマンスがーとか言い出すのは十年早い

2020/11/29(日) 23:30:20.42

そう主張するのであれば具体的な利点を述べろよ
TryGetValue派は俺以外にもメリット述べてる奴いるけどContainsKey派は「そのほうが見やすい」程度の個人の感想以上は出てきてない
勿論それもメリットではあるがTryGetValueの方が見やすいと言う人もいるのでそこでは差は付かない

2020/11/29(日) 23:51:14.64

>>760
ねーよ

2020/11/29(日) 23:59:15.56

宗教論争オモロイなw

2020/11/30(月) 00:00:33.52

>>762
しょうがないな
こういうケースは極端化すれば明確になる

dic.TryGetValue(a, out var dic2)
dic2.TryGetValue(b, out var dic3)
dic3.TryGetValue(c, out var dic4)
dic4.TryGetValue(d, out var dic5)
dic5.TryGetValue(e, out var value)

vs

var value = dic[a][b][c][d][e]

とりあえず値の取得を比較した場合こうなる
非常に馬鹿げたコードだが後者の方が察しやすくバグりにくいのは分かるはず
これは分岐を差し込んでも同じこと
こんなコードは現実にあり得ないから無効と言い張るなら、所詮はその程度のレベルなんだから黙るべき

2020/11/30(月) 00:20:59.97

TryGetValue vs ContainsKey+[]の争いでしょ？
なら下はちゃんと一つ一つにContainsKey挟むべき
そして後者の方がバグりにくい理由が全く分からない。まず何のバグを対象としているのか明確に

2020/11/30(月) 00:25:39.57

レビューを受けるのが新人とか言ってる時点でまともじゃないでしょ
いつの時代のエンジニア思想よｗ

2020/11/30(月) 00:26:29.87

なんというかb7e4-nc77みたいなのがレビュアーやったら地獄だな
自分が新人だったらたまったもんじゃない

2020/11/30(月) 00:36:41.15

>>766
お前さんプログラマ向いてないから転職した方が良いよ、マジで
ちゃんと理屈で教えられたことを受け付けないとか先が無さすぎる

2020/11/30(月) 00:39:46.85

どうせ過疎スレだからスレ消費するのは問題ないと思うけど
あまりに下らな過ぎる論争で萎えるねw

よく読んでないので素っ頓狂なこと言ってるかもしれないけど、
iniファイルぐらいなら馬鹿正直にDictionaryをネストなんかしなくても
section+keyをキーにして平坦化しても良いような気もする

2020/11/30(月) 00:45:42.05

>>769
答えられないんだね

2020/11/30(月) 01:29:55.64

ini parserの中身を見たらContainsKey + インデクサだった
https://github.com/rickyah/ini-parser/blob/development/src/IniParser/Model/SectionCollection.cs#L62-L77

自分なら使う側のコードがシンプルになるようにini[section][key]かini[section]?[key]の形で
sectionかkeyがnullならnullを返すようにDictionaryを少し拡張するかな

2020/11/30(月) 05:30:56.15

>>763
お前がそういう世界を知らんだけ

2020/11/30(月) 08:23:44.56

相変わらず質問者無視で議論してるのウケる
テンプレ読めない人多すぎでしょｗ

2020/11/30(月) 08:57:23.41

>>770
そもそもini直接操作するならWin32APIにセクション名とキー名と無かった場合の規定値を突っ込むだけで良いからDictionaryすらも何もいらない
pascalにはMemIniみたいな基本はファイルには書き込まないクラスがあるからそれを実装しようと思ったらDictionaryがベストなんじゃない

>>774
section一覧を返す方法は一昨日の一番最初のレスでしたって昨日言ったはずだが無視してるのはお前の方だろ

2020/11/30(月) 09:04:32.51

>>772
そのプロジェクト見た感じTryGetValueを一度も使ってないから恐らくJavaか何か出身で存在知らないんだろうな
ContainsKeyは割と色んな言語にあるからこっちの方が認知度高いのは間違いない
なので昨日も言ったが一々C#に学習コスト払いたくないって人もいるだろうからそういう場合は好きにしたらいい

2020/11/30(月) 10:07:26.68

>>775
テンプレ読めよ
「議論」するなと言っているんだが

2020/11/30(月) 10:12:11.16

テンプレ読めないって事はレスも読めないんだから言っても無駄
粛々とNG

2020/11/30(月) 10:29:32.82

>>765-766
まあここまで極端な例なら
try {
var value = dic[a][b][c][d][e];
} catch(){
}
ってやる事を検討してもいいかも

2020/11/30(月) 10:45:42.20

>>776
お、ようやく自分の間違いを認めたか
まあContainsKeyの方が可読性高いのは当たり前なんだが

762 名前:デフォルトの名無しさん (ﾜｯﾁｮｲ 9f24-GtYN) [sage] :2020/11/29(日) 23:30:20.42 ID:yrxBBFH+0
そう主張するのであれば具体的な利点を述べろよ
TryGetValue派は俺以外にもメリット述べてる奴いるけどContainsKey派は「そのほうが見やすい」程度の個人の感想以上は出てきてない
勿論それもメリットではあるがTryGetValueの方が見やすいと言う人もいるのでそこでは差は付かない

2020/11/30(月) 11:16:43.36

>>780
可読性と認知度は全然違う意味だと思うけど、っていうのは置いといて
>>732とか>>765とかさすがに釣りでしょって思わせるレスがちらほらあるから、喧嘩両成敗はちょっと可哀想な流れ

2020/11/30(月) 11:55:30.78

>>773
ちょっとはググれよ

2020/11/30(月) 11:58:06.51

認知度と可読性が別物か
職場で宇宙人って呼ばれてそう

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-a5dV) · 2020/11/30(月) 12:11:19.73

>>779
これでええやん
例外が重い？知るかよ

2020/11/30(月) 12:13:44.19

>>782
> ちょっとはググれよ
ブーメラン過ぎる、ってかググっても悪魔の証明はできないぞw

2020/11/30(月) 12:15:09.00

TryGetValueを使うことに拘りすぎててアスペ臭しか感じない
好きにしろと言いながら必死で反論してんのが特にな

多様性を許容するっていうのは>>754みたいなスタンスなんだよ
ここまで言われて「何言ってんのか分かんない」と騒ぎ続けるのは感情で理解を拒んでるだけの地雷君
「そういうの嫌われるからやめよ？」って指摘されてるのに「なんで？　俺が正しいじゃん？」って返すのは馬鹿を通り越した何かだわ

2020/11/30(月) 12:26:00.27

こういうレスちんぽバトルやめねぇ？

2020/11/30(月) 12:51:21.50

>>785
MISRAって名前まで分かってるのに？

2020/11/30(月) 12:52:22.17

いまだに複数リターン禁止なんて言ってる時代錯誤なやつがいるのかよ…

2020/11/30(月) 14:08:46.39

>>788
？？？
ないことの証明だよ？
悪魔の証明って知らんの？

2020/11/30(月) 14:09:59.63

>>789
だからお前等の知らない世界があるって話
まあC++とかC#だと例外とか使えるからだいぶ緩和されるけど

2020/11/30(月) 14:11:44.42

>>790
まずはあることを示してから

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-a5dV) · 2020/11/30(月) 14:31:16.69

>>791
アセンブラ以外でFalseは即リターンなんてベストプラクティスやん
if elseとか基本ダサいんだよね

2020/11/30(月) 15:11:50.10

>>792
それこそ misra multiple return とかでググればいくらでも出てくるだろw
https://www.viva64.com/en/w/v2506/

>>793
だからそう言うのが非推奨な現場があるというだけの事
個人的には関数の頭でのエラーチェックでエラーだったら即リターンとかよくやってる

2020/11/30(月) 15:27:06.61

>>794
それのどこがC#なんだ？

2020/11/30(月) 16:36:59.20

関数の出口が、複数ある奴か。
危険だから、MISRA-C の禁止事項

一方、Linux では関数の冒頭で、処理しない場合は、即リターンするとかやってる。
関数の出口に、goto で例外処理をまとめたりとか

MISRA-Cを守らない場合は、逸脱手続きが必要。
トヨタなどは、MISRA-Cで、4/100 しか点数を取れなかったとか聞いたw

MISRA-C研究会にも、トヨタのベテランが加入してるのに

2020/11/30(月) 16:46:43.31

俺社環だけど、これ指摘したらそれは例外処理や自動メモリ管理がないCであって、C#ではそこまで気にする必要ないんじゃね？で終わったな

2020/11/30(月) 16:53:06.40

辞書のキーが存在しないのは、例外じゃない。
最初から想定内の事で、予想がつくから

例外はファイルが存在しないとか

Go では例外を嫌って、複数の戻り値で、エラー値を返す

**796** (ﾜｯﾁｮｲ b72c-OOND) · 2020/11/30(月) 16:56:08.66

漏れは、戻り値を変数に入れておいて、return は1つだけにしてる

if 条件
result = 1
else
result = 2
end

return result

2020/11/30(月) 17:07:26.72

うっかりミスってreturnし忘れてもIDEが警告してくれるから、分岐それぞれでreturnするほうが好き

2020/11/30(月) 17:08:29.73

複数returnとかワンライナーとかはそれこそ正解の無い事だから各々好きにしてくれよ
TryGetValueとContainskey+インデクサは正解があると思ってるからこっちはつい反論し続けてしまったが

2020/11/30(月) 17:11:06.92

なぜこのスレはテンプレを見る限り質問スレなのにスレタイにそれを示唆する文言が入っていないのですか？

2020/11/30(月) 17:15:26.09

ヌルチェックやりはじめてから一刻も早くreturnすることを考えて書くようになった
階層が深くならないので見やすいし、上の部分だけである条件にあてはまった処理が完結してるので読みやすい

2020/11/30(月) 17:24:24.88

>>797
ね、Cですら"推奨"なのに

2020/11/30(月) 18:17:44.47

>>796
>危険だから、MISRA-C の禁止事項
Mandatory, Required, Advisoryの3段階のうちAdvisoryなので禁止事項ではないね

2020/11/30(月) 18:30:53.38

>>800
さすがにMISRAとかが言ってるのはそう言う低レベルな話じゃなくて途中脱出でのリソース開放漏れとかを心配してる
なのでC#なら例外とかusingとかを適切に使えばそれほど問題にならない
クラス継承させた時のIDisposeのコーディングが面倒なのがたまにキズだけど

2020/11/30(月) 18:52:25.38

2020/11/30(月) 19:48:14.13

>>805
またRuby君がいい加減な知識で嘘を垂れ流そうとしてたわけか

2020/11/30(月) 21:11:19.50

いい加減なのは知識じゃなくて遺伝子じゃねえのか
欠陥品なんだから

2020/11/30(月) 21:11:29.21

少し調べてみたけどMISRAがsingle returnを推奨する根拠に上げてるIEC 61508には
”subprograms should have a single entry and a single exit only;”と書かれているだけ

そこに参考文献としてヨードン/コンスタンティンの「ソフトウェアの構造化設計法」を上げてるが
ヨードンやダイクストラが提唱したsingle exitは時代的にも意味が違うのでルール自体の根拠が薄い
https://softwareengineering.stackexchange.com/questions/118703/

1993年出版のCode Completeでも今回のようなケースはmultiple returnが推奨されてるくらいなので
single returnはリソースクリーンアップが必要だけど
他の方法がどうしても取れないような特殊なケースでしか意味がないと思って良さそう

2020/11/30(月) 21:15:38.40

どうでもよくねｗ

**796** (ﾜｯﾁｮｲ b72c-OOND) · 2020/11/30(月) 21:56:17.24

Cプログラミングの落とし穴
C Traps and Pitfalls, Andrew Koenig, 1989

ここから、Lint, MISRA-C などが出来た

2020/11/30(月) 22:27:10.33

c#スレなんですがそれは

2020/12/01(火) 11:25:23.55

C#とはC++++、つまりCとC++を継承した言語である
よってC#スレにおいてCとC++は範囲内
悔しかったら言語名を変えることだな

2020/12/01(火) 11:27:04.96

キチガイ

2020/12/01(火) 11:45:19.44

似た話でelseを省略するな派もたまにいるけど、元はCOBOLの文法ではelse書かないとブロックの区切りが分かりにくいかららしいね

2020/12/01(火) 12:14:20.95

そんな流派の人に会ったことないけど、意図はたぶん古典的なぶら下がり問題対策だろうね
俺はこんなミスしたことないしIDEの時代には杞憂だと思うけど

if (true)
　　if (false) {}
else Console.WriteLine("来ないはず");

2020/12/01(火) 14:56:29.62

elseを省略しちゃダメって言うのは俺も見たことないな
>>817みたいなのを避けるために { } を省略しちゃダメって言うのは見かけるけど

2020/12/02(水) 00:57:12.14

最近久しぶりに起動したらVSのテキストエディタの「自動メンバー表示」の項目ををカーソルキーで動かすのがとんでもなく重いんだけど俺環？

2020/12/02(水) 01:47:00.65

Dispose()しないといけない条件がいまいち分からないんですが、
コンポジションとして参照を保持しているメンバーがDispose()メソッドを持ってたら、Dispose()を実装しないといけない、ていう理解でいいんでしょうか？

**デフォルトの名無しさん** (JP 0H70-rBWM) · 2020/12/02(水) 10:14:54.41

>>820
たとえばファイルを開いて中身を書き換える処理をFileStreamでするじゃん
開いてる間は他の人やプログラムがそのファイルを使えない状況になるから
使い終わったらちゃんとDisposeで閉じましょうねって事

2020/12/02(水) 12:15:24.35

画像とかメモリ消費量が多いオブジェクトに対して、使い終わったらちゃんとDisposeで破棄しましょうねって事

2020/12/02(水) 12:32:26.40

>>820
基本はYes
内部でそのメンバをDisposeする仕組みが他にあるなら別に実装しなくても良いが、とは言えIDisposableを実装しておけばそのラップクラスでもusingステートメント使えるから分かりやすいしね
IDisposableはコードでDisposeせずともGCによる破棄タイミングでDisposeしてくれるから最悪し忘れても大丈夫だが（GCによるオートDisposeはパフォーマンスが悪いので出来れば避けるべきだが）

2020/12/02(水) 12:51:23.41

>>820
そうとは限らない
たとえば外部のAPIを使っていて、使い終わったら必ずある処理を最後に呼ばなければならないという決まりがある場合
たとえばある一連の処理の間は一時ファイルを作り、最後に消す必要がある場合
そういったユースケースをクラスにするならDisposeを実装することになるだろうな
Disposeってのはつまり、最後に特定の処理を必ず呼ばなければならないという規約に他ならない

2020/12/02(水) 18:14:26.77

>>820
エンジニアは教条主義的に考えてはいけない。
何も難しくない。

オブジェクトが自分のメンバー（フィールドかプロパティ）のDisposeを呼ぶべきタイミングを
自分で判断できるならわざわざDisposeを実装して他人にそれを任せる必要はない。
できないならDisposeを晒して他人にお願いする。

それだけでしょ。
でも「Disposeを呼ぶべきタイミングを自分で判断できる」のはメソッド呼び出しが
完了した後も別のスレッドで動作を続けるタイプのオブジェクトだけなので
そうは多くないはずだよね。

2020/12/02(水) 19:47:17.83

>>1
> なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#, C♯, C＃相談室 Part94
http://mevius.5ch.net/test/read.cgi/tech/1553075856/

ふらっと C#,C♯,C＃（議論用） [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1469538912/

テンプレも読めない奴らがする議論は、
もはや議論ではなくマウンティング合戦

2020/12/02(水) 20:41:49.29

>>826
君がやってるのもそのマウンティング合戦のうちなのは自覚して欲しいよねw
もはや5ch全体がそうだけど特にここは過疎スレなわけで、そんな目くじら立てることないと思うよ
誰か困る奴いるの？w
誰もいないって。

2020/12/02(水) 21:21:31.32

過疎スレでもルールは守れよ

2020/12/02(水) 21:58:13.02

マウンティング合戦なんか起こってたら
初心者が尻込みして書き込むのをやめてしまったりするわな

2020/12/03(木) 00:08:24.38

winformでwebview2を使ってるんですけどcookieをセットする方法がわからなくて困ってます
どなたかわかる方教えて下さい

**820** (ﾜｯﾁｮｲ fb54-9rBX) · 2020/12/03(木) 02:05:41.69

みなさんありがとうございます。
そして何かすみませんでした。

2020/12/03(木) 06:58:36.35

>>831
絶対に許さねぇからな
末代まで祝ってやるから覚悟しろよ

2020/12/03(木) 07:07:12.64

今更訊きづらいけどgoto文のラベルの命名ルールって

　　　　　goto maki;
hirohisa:
　　　　　System.Console.WriteLine("誰だよ");
　　　　　goto hell;
maki:
　　　　　System.Console.WriteLine("知ってる");
　　　　　goto hirohisa;
hell:
　　　　　System.Console.WriteLine("そうだな");

こんなんでいいの？