1 名前:デフォルトの名無しさん mailto:sage [2021/12/13(月) 22:53:21.18 ID:dhjmiKBp0.net] !extend:checked:vvvvv:1000:512 次スレを立てる時は↑を2行冒頭に書くこと(1行分は消えて表示されない為) 「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。 他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、 ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。 内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。 なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。 C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください >>980 を踏んだ人は新スレを建てて下さい。>>980 が無理な場合、話し合って新スレを建てる人を決めて下さい。 ■前スレ ふらっと C#,C♯,C#(初心者用) Part152 mevius.5ch.net/test/read.cgi/tech/1629888256/ ■関連スレ C#, C♯, C#相談室 Part94 mevius.5ch.net/test/read.cgi/tech/1553075856/ ■コードを貼る場合は↓を使いましょう。 https://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/ https://referencesource.microsoft.com/ https://source.dot.net/ ・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
391 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 00:56:20.83 ID:fuEg19Cq0.net] >>384 それはC#でも同じでしょ。
392 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 00:59:38.17 ID:JsfvM5KJM.net] C#ではI/Oが生じる場合にも型が嘘をつくことはない 例えばこうだ int x = Parse<int>(inputStream); パースエラーにより実行時に例外が発生することはある それはどの言語でも起こりうることだ しかし、依然としてxにstringが入ったり、DateTimeが入ったり、という、TSでは普通にあり得る悍ましい挙動を示すことは無いのだ なぜならC#はTSと違って型が嘘をつかないから C#の型は信頼できる TSの型は嘘つきで信頼できない
393 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 01:00:08.39 ID:fuEg19Cq0.net] >>384 大規模アプリ開発では、何層もの見えない層があった結果これが起こる。 オブジェクトの型を破壊的に変換 - C#と諸々」でググってみ。
394 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 01:00:59.54 ID:fuEg19Cq0.net] >>387 じゃあTSはどうしてxにStringやなにがしかが入るの?どこで入れてんのよ?w
395 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 01:10:21.43 ID:JsfvM5KJM.net] >>386 全く異なる C#ではdynamic、リフレクション、コード生成を使えばコンパイラの検証を回避して、間違った型の変数に値を設定できる しかし、C#でこれをやると実行時にエラーになるのだ TSで何事もなく処理が進むのとは、全く趣が異なる そう、TSではstringと指定した筈の変数にnumberやDateの変数が入ったまま、何事もなく進んでしまうのだ これは本当に恐ろしい挙動だ つまり、バグを仕込んだところから、しばらく処理が進んだところで被害が顕現する、ということだ これはまるで、潜伏期間の長いコロナウイルスのように厄介な特性だ この挙動はC言語などではよくあるものだったが、原因と結果が離れているのでデバッグがしにくい、とのことで先人達は大いに苦しめられたものだ まがりなりにも後発の言語であるTSが、大昔の言語設計と同じ失敗を繰り返しているのは残念でならない
396 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 01:17:22.12 ID:JsfvM5KJM.net] >>388 低レベルなメモリアクセスでランタイムを破壊できるのはどの言語でも当たり前のことだろう TSのように低レベルメモリアクセスでもなんでもない、ただの代入で型安全を破壊できるようなものと同列に扱うべきではない
397 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 01:19:07.95 ID:JsfvM5KJM.net] >>389 困ったことにTSではどこででも起こりうる だから欠陥言語なんだよ C#のように低レベルメモリアクセスで無理やり破壊すればできるよ、といった次元とはわけがちがう
398 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 01:46:29.20 ID:lnjYKBBj0.net] >>379 varの上にマウスカーソル合わせてツールチップに表示される型を見るだけ
399 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 07:33:07.78 ID:OXnyWrYu0.net] >>384 既に>>349 で挙げているがそこに注意してプログラミングすればいいだけ。 お前は馬鹿だからそれができないんだろうが世の中の人間がみなお前と同じように馬鹿なわけではない。
400 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 07:38:49.44 ID:t5pkfnoc0.net] JSなんて使いたくて使ってるやつはいないって事だよ ほかに選択肢がないから仕方なく使ってるだけで そもそも本来TSのようなトランスパイラはこの世に存在し得ない存在
401 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 09:23:21.76 ID:bvaGXVet0.net] なんでc#スレで一生懸命TSの悪口言ってるの?
402 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 09:53:21.58 ID:SNzZltS0M.net] 欠陥指摘できる俺すげー君だろw スルーしとけ
403 名前:デフォルトの名無しさん [2022/01/05(水) 09:57:56.22 ID:5ORhcVX2D.net] WinFormのlistViewをタブレットで使いたいのですがlist部分を指で上下してlistをスクロールする事は出来るでしょうか スクロールバーで上下出来るのですがスマホのように出来ないかなと
404 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水)
] [ここ壊れてます]
405 名前:10:15:33.57 ID:Zzh6nSy3M.net mailto: >>394 挙げられたリストでは全く足りない こういう認識の甘さがバグを仕込むキッカケになるのだろう そもそも人間は間違える余地があれば、いつか必ず間違える 注意してれば大丈夫、などという考え方では到底ダメだ [] [ここ壊れてます]
406 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 10:17:21.15 ID:Zzh6nSy3M.net] >>396 しつこく返してくる奴がいるから仕方なく付き合ってやってる そいつがTSの型は安全でないという当たり前の事実を素直に受け入れれば俺もこんなレスバしなくても済むんだが
407 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 10:34:58.47 ID:TbL+VltAd.net] TypeScriptなしではJS開発やってられなくなってしまったな 特にチーム開発
408 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 11:00:24.24 ID:dUhlmVC50.net] >>398 一応標準でサポートされてるはずだけど なんかスクロール遅いし慣性の扱いが下手糞だけど…
409 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 11:06:50.05 ID:llHLsWPPp.net] >>400 おまえは相手がうんと言うまでスレチ議論続けるつもりか
410 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 11:43:03.34 ID:93Qk8F8ua.net] 例えばリストビューを作るときにアイテムのTagに日時を代入しとく そうしたら選択したアイテムの日時がすぐにわかるから。こんなのはよくやる手法だよね で、実際にアイテムがクリックされたときにTagを読んで日時を取得しようとしたらstringだったりDateTimeだったりして型エラー。バリデーションwが必要になる こんなの(アホがプログラミングしたら)c#でも日常茶飯事だからな tsでも同じ。アホがプログラミングしたらバリデーションwは必須だし、普通にプログラミングしたら不要
411 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 11:54:44.06 ID:ZRZErZAVM.net] >>404 君は議論の焦点を全く理解してないようだね
412 名前:デフォルトの名無しさん [2022/01/05(水) 12:07:48.08 ID:2gwkfiFL0.net] すまんが、昔、Linux + LLDBでのC#のデバッグ方法が公式サイトに書かれていたようが気がするんだけどさ そんなようなページってどこにあるのか、誰か知ってたら教えて!!!
413 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 14:47:28.15 ID:kRupjksVa.net] 昔OSも乗ってない小規模組み込みをアセンブリでずっと書いてたけど、 アセンブリには当然型なんて概念そのものが存在しないが、 だからintとBCDを間違えたり、構造体のポインタを別の構造体のポインタと勘違いする ミスが多いかと言うと、そこは意外とそうでもなかったりする。 それより生産性に対する影響の方が大きい印象だね。 まあこれは小規模かつ基本1人の開発だったからそうだっただけで、大規模かつチーム開発だと 話が変わってくるのかもしれない。 この辺はゲーム業界の人が詳しそうだね。 あの世界は下手したら90年代の終わり頃までアセンブリでやってたはず
414 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 15:04:40.06 ID:XpPjLRYm0.net] バグには様々な要因があるから、不正な型が代入された場合だけを過度に心配してもね
415 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 15:08:39.22 ID:C1Xb8B3u0.net] 型を気にしない馬鹿はテストも当然にしないから
416 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 15:14:15.12 ID:ROW6egx4d.net] >>384 自分が守らなければそりゃ保証もされないだろ。 C#ならある型にはある値しか入らないと思ってそう。 例えば構造体につっこんでFieldOffsetで上書きすればあっさり壊れるぞ。 [StructLayout(LayoutKind.Explicit)] struct XXX { [FieldOffset(0)] public DateTime Value; [FieldOffset(0)] public ushort Tag; } でXXX.Tagに適当なもの入れ
417 名前:スらValueは無茶苦茶になる。 [] [ここ壊れてます]
418 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 15:54:13.43 ID:qaVNdYDmM.net] 参照型の変数にnullが入ってるかもしれないし、C#の場合は例外の型もドキュメントの記載を信じるしかないよね 結局は程度問題なんだよ 前者のnullの問題についてはnull許容参照型を使えば型として区別できるけど、null非許容だからといって絶対にnullが入らないわけではなく簡単にnullを混入させることができる 彼の大嫌いなTSと同じく、特にランタイムチェックのない紳士協定だ
419 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 16:24:00.16 ID:kRupjksVa.net] っていうかこれたしか元はvarの話だよね。 繰り返しになるけど、元々の問題提起、つまり 「右辺の型が推測しづらいケースでもvarを使うのは不適切じゃないのか?」は正しいよ完全にw 匿名型を受ける場合以外のvarの目的は、「見れば分かる」冗長な繰り返しを避けて シンプルにすること。 「かっこ悪い」みたいな中二病的動機で意地でも型を明示しないことに固執する奴はアホだが、 困ったことに現実にはそういうアホが結構いる。 この辺LINQの乱用が嫌われるのと同じなんだろうねw シンプルにするための道具を使ってわざわざ難解にするバカw たぶん彼はシンプルとは文字数が少ないことだと倒錯している
420 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 17:12:39.57 ID:x9hFTlB3d.net] varの型が分からん分からんってこいつメモ帳で開発してんのか?
421 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 17:24:59.67 ID:5TZJeeZKa.net] IDEだけでしかソース見ない奴は問題ないんだよ ぐぐってブラウザ上で見るソースなんてマウスあてても型表示してくれないからな
422 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 17:28:23.80 ID:C1Xb8B3u0.net] どんだけ小さなプロジェクトしか関わったことないのか知らないが code reviewするときに数百、数千というvarをおまえはいちいちマウス乗せてチェックしてるのか? 型を気にしないならオープンソースもコードを確認せずビルドして使うタイプだろう。 OSS品質=誰かがチェックしてくれるはず=テストしてない=今のMSのコード品質
423 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 17:32:31.52 ID:5TZJeeZKa.net] var使ってるぐらいで崩壊するようなとこは大きいの作れないから気にする必要ないよw
424 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 17:43:11.47 ID:t5pkfnoc0.net] varなんて大抵は右辺見たら型わかるやろ? 何が分からんのだ?
425 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 17:48:48.78 ID:C1Xb8B3u0.net] 実験結果は分かった気になって実は全然分かってないでした。 でも分かった気になってるのでいつまでもなぜ分からないのだ?と問い続ける。
426 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 17:52:58.23 ID:t5pkfnoc0.net] いやマジで何が分からんの?アホの子なの?
427 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 17:58:12.21 ID:bWjicXEh0.net] つか、変数名見ればクラス名も分かる程度にしておくのが普通だから マウスで調べなくてもだいたい分かる
428 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 17:58:55.28 ID:C1Xb8B3u0.net] 自演じゃないよ、彼はそう信じてるんだ。笑わないでほしい。
429 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 18:09:44.71 ID:R56PdZ5+0.net] >>421 このスレの住人はお前のことを笑っているぞ
430 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 18:09:55.54 ID:t5pkfnoc0.net] staticおじさんみたいなもんだな
431 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 18:21:06.82 ID:C1Xb8B3u0.net] そして彼は笑いながら未テスト納品を繰り返す。そしてまたスパコンのデータを吹き飛ばす。
432 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 18:39:16.92 ID:w42D9Ab/0.net] コードレビュー時にローカル変数の型をいちいち調べる意味がよくわからん 必要になるのってバグの原因調査する時だけでしょ
433 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 18:41:30.05 ID:jje+EFiu0.net] TS、JSの型がゴミなのはわかる c#のvarも俺は嫌い 普通に読みにくい 最近は派遣先会社のVSに仕込まれた強制変換スクリプト?で保存すると勝手にvarが明示的な型に置き換えられて 久しく見ない問題だったが
434 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 18:42:19.84 ID:C1Xb8B3u0.net] 何も知らないなら喋らなきゃ無知はバレない。
435 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 19:07:10.79 ID:5TZJeeZKa.net] >>425 人のソース読むのにvarで省略されてるよりも、型が使われてる方が理解しやすい もちろん>>420 のようにしてくれればvarでも変わりゃしないけど、世の中そういうソースばかりじゃないし酷いのになると名前で型を騙されることあるからな 整数型にn、floatにfついてるからdがついてたらdoubleかと思ったらそれも整数だったり。そりゃないだろ・・・
436 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 19:19:51.10 ID:fuEg19Cq0.net] 限度の問題では? MSの規約にあわせれば良いでしょ。 IEnumerable<T>で受けるべきなのにList<T>で受けてるとかそういう不適切な状態になってない限りvarで良いと思うけどな。 varは省略の為に使うのではなくて推論の為に使うんよ。
437 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 19:53:56.06 ID:jje+EFiu0.net] varなんて右クリックメニューで元に戻せるから書くだけ書いたら明示的な記述に直しちゃった方がいいよ
438 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 19:57:59.86 ID:kRupjksVa.net] >>429 推論はするよりしない方が脳への負担が低いはずなので、 君の説を採るとvarは全面禁止すべきという結論になってしまうよw 少なくともコードの読み手(書き手ではなく)にとってのvarのメリットは 右辺の型が分かりきっている時に左辺の方でもくどくどそれを繰り返される冗長さが回避されることだ。
439 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 20:04:49.66 ID:lXYh5E9eM.net] 型推論 https://ja.wikipedia.org/wiki/%E5%9E%8B%E6%8E%A8%E8%AB%96
440 名前:デフォルトの名無しさん [2022/01/05(水) 20:09:49.34 ID:34fypwCFM.net] 書くやつは楽 コピペ盗作するやつは脳味噌が必要 var大勝利じゃん
441 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 20:11:27.06 ID:jje+EFiu0.net] >>432 そもそもこれがゴミなのか有効なのか? って議論がなされないまま突然導入されてほら使えだからな VSの右クリックメニューにもvarを元に戻す機能が付いたってことはあんまり評判よくないだろコレ
442 名前:デフォルトの名無しさん [2022/01/05(水) 20:16:51.17 ID:eampx4mf0.net] 議論に参加できるぐらい出世しろ
443 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 20:20:48.72 ID:jje+EFiu0.net] >>435 お前の会社は社長が1番技術力高いのか?
444 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 20:41:21.39 ID:P9kF/5N50.net] varで推論しないほうが脳への負担が低いというのはどういうことですか?
445 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 20:42:40.80 ID:C1Xb8B3u0.net] >>437 型が分からなくてもイライラしない人はそもそも負担がありません。
446 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 21:00:44.67 ID:jje+EFiu0.net] アホが作った無意味なマトリョーシカクラス追わなくて済むからな
447 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 21:16:57.60 ID:w42D9Ab/0.net] 15年近く前から導入されてるものに対して いまだに文句を言い続ける「熱量」には感心する
448 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 21:20:57.24 ID:jje+EFiu0.net] >>440 正直、クラスから嫌いです 構造体以上のメリットを全く感じたことない
449 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 21:56:49.45 ID:LjEcMnXra.net] >>441 そこは「しっくりこないんです」、と書いて欲しかったw
450 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 22:09:26.64 ID:R56PdZ5+0.net] staticおじさん生きてたのかw
451 名前:デフォルトの名無しさん [2022/01/05(水) 23:32:21.89 ID:9KUuQ3bM0.net] わかってる奴がvar使うのはOK 馬鹿がvar使うのはNG
452 名前:デフォルトの名無しさん mailto:sage [2022/01/05(水) 23:33:33.69 ID:HyMzvNe00.net] じゃあdynamicつかうね
453 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 02:10:11.97 ID:jegOl+WX0.net] >>431 推論させる方が脳への負担は低いよね? 型がわからなくてイライラすると言うけど、解る必要ある部分ではないのでは? 極端な
454 名前:bメソッドの入口と出口は型が決まってんだから。 [] [ここ壊れてます]
455 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 02:36:29.67 ID:Vr7+jyV40.net] そのメソッド追っ掛けるのが面倒だって話ではないのか
456 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 02:50:36.77 ID:ChZ1cCgVa.net] >>446 推論の主語が変わってるよw あなたの言ってる推論の主はコンパイラ(開発環境)だよね?w ついでに言うと、あなたがたぶん言いたいことは「書く時の負担が減らせる」ということ。 だからそうじゃなくてコードの読み手にとってのメリットが重要なのよw そう書いてるよね?>>431 だってそうでしょ。 コードを書いてる時の書き手にとってはどの変数がどの型かなんて 当然自明なんだからvarにはメリットしかないよ。そんなの当たり前でしょw 結局varについても意見が割れるのは前にも書いた(>255)こういう意識の差があるからだろうね。 世の中KISSなんてただのお題目だと思っててなぜ重要か体感レベルで実感できない人が結構いる。
457 名前:デフォルトの名無しさん [2022/01/06(木) 03:46:43.08 ID:Jy6L3sVt0.net] >>448 >コードを書いてる時の書き手にとってはどの変数がどの型かなんて当然自明なんだから 馬鹿はvarを使えばエラーが出ないという理由でvarを使っているだけで型なんか理解もしとらんのだよ
458 名前:デフォルトの名無しさん [2022/01/06(木) 06:07:27.91 ID:WSidiaMA0.net] >>449 その発想はなかったわ バカの考えは馬鹿にしかわからないのだな
459 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 08:30:02.04 ID:GGuE86Bnd.net] >>448 違うよ。 コードの書き手も読み手も楽が出来る。 varで宣言されている変数に関しては、推論を行わせて、自動的に型が決まっていても良い、というシンプルな話。 Task<IQueryable<Bar>> foo() { var masters=getMasters(); //なんかmastersを使った処理 // : var predictate= e=> ... ;//変換したmastersを使った関数 IQueryable<Bar> result = xxxx.Where(predicate).Take(10); //resultの確認 return result; } こんながあったとき、predictateとmastersはvarで充分では?
460 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 09:18:51.63 ID:BMV6DlOj0.net] 全く論点が不明 コードレビューでは全てのvar変数をマウスオーバーして型を確認しなければならないと言うのもシチュエーションとして理解不能、猿が働いてる企業なのか? そもそもそんな使用の是非の議論が必要な話なら世の中にvar禁止の組織はさぞかしあるんだろ? 御託並べる前にgithubでvar禁止にしてるC#プロジェクトでも持ってこいよw
461 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 09:23:52.72 ID:BMV6DlOj0.net] この手の「一人のstaticおじさんに大勢が説教する図」はさまざまなスレで見かけるけどまったく生産性ゼロで不毛だよな ほかに同調する奴いない時点で自分が間違ってる可能性か考えろよ まず自分を疑うのはエンジニアの基本やろ
462 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 09:37:12.69 ID:VWdkYx+r0.net] >>440 また低能馬鹿論理でましたね。WPFでも同じ馬鹿なこと言ってる人がいました。
463 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 10:00:08.90 ID:WPmMIBV7M.net] >>451 C#だとresultの型は推論できないんだっけ?
464 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 10:02:24.36 ID:VWdkYx+r0.net] >>ID:BMV6DlOj0 論点すら分からない馬鹿でも喋らなきゃ無知はバレない。
465 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 10:07:20.21 ID:sIABQ4ka0.net] 初心者スレで無知晒しても別に構わんだろ ちゃんと教えてやれよ
466 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 10:10:39.02 ID:jegOl+WX0.net] >>455 resultというか、メソッドの宣言的には省略不可。 なので、returnしているということはvarでも良いかもしれんな。
467 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 10:11:51.45 ID:VWdkYx+r0.net] >>ID:BMV6DlOj0 いちいち捏造してはマウンティングしてきて 相手を猿だの罵倒してくるクソ野郎にはクソレス返しで十分。
468 名前:デフォルトの名無しさん [2022/01/06(木) 10:36:42.54 ID:cm3DDwaa0.net] 議論用でやれば 凄い流れるんだけど
469 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 10:38:33.11 ID:BMV6DlOj0.net] 数千のvarをマウスオーバーして型を調べるってんだからそんなもん猿以外の何者でもないだろw それでカネ貰えるんだからいい仕事だなあ で、var禁止のC#プロジェクトは見つかったのか? さっさと探してこいよ
470 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 10:42:17.16 ID:VWdkYx+r0.net] ID:BMV6DlOj0 ←無職のクソ野郎が仕事を語る
471 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 10:52:01.70 ID:XJZjWgUBd.net] 戦犯は>>323
472 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 10:58:22.55 ID:VWdkYx+r0.net] >>463 馬鹿の壁の社会実験。参加してくれた馬鹿に感謝する。
473 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 11:41:47.82 ID:CKbwlJU4M.net] >>458 メソッドの宣言? ここの話だろ > IQueryable<Bar> result = xxxx.Where(predicate).Take(10); xxxx の定義によるけど普通は var で良くね?
474 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 12:18:50.36 ID:+o9sIybza.net] IQueryable<Bar> result = xxxx.Where(predicate).Take(10); ↑だとこの一行でBarとってるとわかる var result = xxxx.Where(predicate).Take(10); これだとなにかを取ってるとしかわからない。たった数文字の差だけど受け取れる情報が多くなって読みやすい 俺みたいなエスパー能力低い人間にとっては普通に書いてくれた方がありがたい
475 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 12:34:17.18 ID:B4j0C8aZM.net] 試してみたけどpredicateの型を明示的にExpression<Func<T>>にしてないと WhereがIEnumelableで解釈されてだめやね resultの型をIQueryable指定しててもコンパイルエラー Whereにlambdaのリテラル入れた場合は varでOk
476 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 12:57:35.75 ID:jegOl+WX0.net] >>465 すまん、そこ間違えた。varで良い。 言語によってはTask<IQuerable<Bar>>が要らない言語があるんよ。 確かにBar取ってるとわかるが、Barを取っているとわかる必要はある? >>467 スマホで書いたらダメだな、すまん。
477 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 13:20:28.91 ID:+o9sIybza.net] Barだと分かる必要はないけど分かったほうがありがたい 無地のジグソーパズルでも問題なく完成できるけど、絵柄があったほうがありがたいのと同じ
478 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 13:50:37.41 ID:A4g6fK0TM.net] わかる必要はないのわかったほうがありがたい? 初心者にありがちな必要ないのにやけに細部にこだわるタイプなのかな?
479 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:04:18.23 ID:+o9sIybza.net] その行の前後見ればvarとあってもそれがBarだとわかる でもBarと明示してくれたら前後見る手間なく分かる、たったそれだけの差をありがたいと言ってる var result = colBar.Where(predicate).Take(10); xxxxでなくcolBarというように書かれてたらvarでもBarだと分かるからありがたいし もっと言えばresultとかやめて var resBarTop10aroundPOI = colBarInTokyo.Where(predicate).Take(10); こんな風にしてくれたら、この一行見るだけでそれが何しているのかが分かってありがたい 俺みたいに理解力に乏しい人間にとっては情報量多いほうがありがたいんだよ。無駄に多すぎるのは勘弁だが
480 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:08:45.09 ID:t38juXmg0.net] class HogeBase { ・・・ } class Hoge : HogeBase { ・・・ } static Hoge GetHoge() { return new Hoge(); } の場合 HogeBase hoge = GetHoge(); だと右辺の型確認しない主義の人はhogeの実態がHogeBase型だと勘違いしたまま作業することになるからまずいんじゃないの?
481 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:13:52.71 ID:HsEWm91X0.net] それは勘違いじゃないんじゃないの?
482 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:15:52.97 ID:+o9sIybza.net] それはHogeBaseとして扱いたいからHogeBaseに入れてるんでしょ 中身はHoge2やHoge3かもしれない。Hogeと知らなくてもいいよ
483 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:19:47.84 ID:t38juXmg0.net] virtualメソッドがHogeとHogeBaseで違う動きするよ? virtualがHogeBaseの動きする前提でレビューしていいのかい? >>473 >>474
484 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:29:24.20 ID:HsEWm91X0.net] 何か問題が? それで困るなら派生させちゃ駄目
485 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:33:13.09 ID:+o9sIybza.net] HogeBaseがさらにIBaseってインターフェース派生だったらどうするよ IBase hoge = GetHoge(); hogeは何も実装できないInterfaceだから何の動作もしないはずなんて思うやつはいない そもそも型に対して前提としてる考え方が違う GetがHogeじゃなくてHogeBase返してきたら右辺見ても区別つかないよ static HogeBase GetHoge() { return new Hoge(); }
486 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:33:43.94 ID:t38juXmg0.net] >>476 へー、呼ばれるメソッドを間違えて認識しててもレビューできるんだ すげーな
487 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:37:00.03 ID:t38juXmg0.net] >>477 うん、だからレビューするなら真面目に右辺のメソッドの中身まで確認しろってこと
488 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:41:37.87 ID:A4g6fK0TM.net] >>478 えっ? 多態使ったことないんか?
489 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 14:54:39.91 ID:t38juXmg0.net] 使ってるからこの話題持ち出したんだけど >>480
490 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 15:15:22.51 ID:FKeKEAH4M.net] hoge.fuga(); って言うコードをレビューする時に実際に呼ばれるメソッドがまだ作られてないケースもあるんだけどどうやってレビューしてるの?
491 名前:デフォルトの名無しさん mailto:sage [2022/01/06(木) 15:19:14.44 ID:Rudq/m5Ya.net] >>451 人の話聞かない人?何が言いたいのかさっぱり分からん。 恐らく誰も、少なくとも俺は 「varを使うと自動的に左辺の変数が不明瞭になるからvarは一切使うな」 などとは言ってないの。 例えば>>431 むしろ現実的にはほとんどの場合varでいいんだよ。 それはコードの書き手にも読み手にもメリットがある。 論点は>>412 に書いた通り、「右辺の型が推測しづらいケースでもvarを使うのは不適切じゃないのか?」だ。