デッドロックして無様に射精することがあるからってのもそうなんだけど、じゃあデッドロックしない場面ではResult書いてもいいのだろうか。一切のWaitとResultを禁ずる。書き方を一辺倒にするべきである。思うのはJavaScriptのPromise(とthen、catch)にしてやられたから。Promiseで書かんでええもんを「まぁ間違ってはないし」の精神で許容し続けてたらもう可読性の落ちること風林火山の如しであることだよなぁと思い続けて早幾年たちました。async/await以外ゆるさん。Chainingとawaitnullableなインスタンスの持っているasyncなメソッド叩き、戻り値を受け取る場合。Resultを使いたくなったりする。Mainだけ見れば理解できると思う。確かに、以下の書き方だと怒られるんだわ。hoge?.Hogehoge();hogeがnullだと、nullをawaitしちゃうことになるから。「nullをawaitってなんじゃい。このエビフライ定食が。Resultは書いちゃ駄目。めっ💕めだぞっ💕こう書け。Task.FromResult(100));hogeがnullだったらTask.FromResultをawaitしてくれる。この例だと100が入ってるから100がaに入るわけです。Task<int>じゃなくてただのTaskだよってひとはTask.CompletedTaskを使いなさい。◆全部のメソッドをAsyncにするべき?いやいや。ネットワークまわりっていうか、ファイル操作だののI/O系をasyncにするだけでいい。I/Oって言ってんのは、画面の描画とかも含まれるよ。「asyncにするべき」っていうかTaskにするべき場合はある。I/O絡まない処理を、まぁTaskにはしてもいいけどasyncにする理由は無い。あるasyncメソッドをawaitしてる処理は、否も応もなく自身もasyncメソッドだろう。I/Oまわりだけに絞ってasyncメソッドとしたときに、どういう副作用が発生するか。それはすなわち、叩くメソッドがI/Oに関わるかどうかが一目でわかるようになる。I/Oしねぇくせに無理やり作ったasyncなメソッドがあると、その判断つかなくなってくる。「Async版とそうじゃない版どっちも作ればよくない?」っていう意見もあるけど、普通に作れば片方だけで事足りる。「Asyncしかない!困る!」とか言って変に詰んでるのは、それ設計っつーか見通しがおかしい。作る処理を想像した段階でI/Oするかどうかは判断できるはずだ。◆ConfigureAwait(false)する?書かない理由がなければ書くべき。書くべきだけど、単なるビジネスロジックなら書かんでもええねんダルいから。なんらかのライブラリを提供する側になったら考え始めろ。全部に書けばいい無敵構文ってワケでもにゃぁし、とりあえずは書かなくていいんだよ。時に書くべきかもしれんが、書くメリットと書かないメリットを天秤にかけるべきだろうが。歯医者についての記事書こうと思ってたら、なんでかしらんが技術記事書いてた。