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

**デフォルトの名無しさん** · 2017/10/17(火) 04:02:10.51

■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が建てる事
建てられない場合は他を指定する事。

**デフォルトの名無しさん** · 2018/03/26(月) 20:59:12.56

>>558
MJD?

**デフォルトの名無しさん** · 2018/03/26(月) 21:17:19.46

ファ～

**デフォルトの名無しさん** · 2018/03/26(月) 22:59:08.42

>>559
おまいのネイティブの定義を教えてくれ

**デフォルトの名無しさん** · 2018/03/26(月) 23:58:46.84

>>565
UWPはツールチェインに.NET Nativeが組み込まれているだけの話じゃね

**デフォルトの名無しさん** · 2018/03/27(火) 00:24:37.94

>>562
>>563
VB６はネイティブコンパイラだよ

**デフォルトの名無しさん** · 2018/03/27(火) 01:27:10.71

あんな質の悪いコードをネイティブなんて(蝶々蜻蛉も鳥の内）

**デフォルトの名無しさん** · 2018/03/30(金) 23:05:49.35

Console.WrteLine("{0}です", number);と
Console.WriteLine(number+"です");だとどっちがいい？
最初の方をよく使うんだけど

**デフォルトの名無しさん** · 2018/03/30(金) 23:10:00.95

「どっちがいい」の基準が分からん
string.Formatでも同じだが可変要素が多いときは上の方が分かりやすいとしか言えない

**デフォルトの名無しさん** · 2018/03/30(金) 23:10:21.60

Console.WrteLine($"{number}です");

**デフォルトの名無しさん** · 2018/03/30(金) 23:19:57.93

某プログラミング言語勉強サイトで後者で打ってる模範があって見にくくてつい質問をしてしまった

**デフォルトの名無しさん** · 2018/03/30(金) 23:20:52.58

>>571
{0}派だったけど今はこれしか使わないな

**デフォルトの名無しさん** · 2018/03/31(土) 00:01:03.73

>>571
な、なんじゃこりゃあ！！

**デフォルトの名無しさん** · 2018/03/31(土) 00:03:06.14

>>569
下のほうが目の動きが自然

**デフォルトの名無しさん** · 2018/03/31(土) 00:53:06.98

>>573
同じ変数を何箇所も使いたい場合は{数字}の方が便利

**デフォルトの名無しさん** · 2018/03/31(土) 01:14:29.83

国内のドカタワールドはC#2.0で早くも息切れしてきて3.0で脱落者が出始めて4.0以降はほとんど追従できてない酷い有様
string interpolationなんて抜群にドカタ向きだから、dobonあたりが取り上げて宣伝したら流行ると思うけどね

**デフォルトの名無しさん** · 2018/03/31(土) 08:18:54.87

string.formatって1.0の頃から存在した気がする

**デフォルトの名無しさん** · 2018/03/31(土) 08:32:15.65

EFの文脈で$@"select * from Foos where {p}"って書くとちゃんとプレースホルダーに置き換えてくれるってので感心した

**デフォルトの名無しさん** · 2018/03/31(土) 10:35:32.87

ほんとコロコロと書き方が変わってほんと糞言語になったな。

**デフォルトの名無しさん** · 2018/03/31(土) 11:12:51.16

C#7.0-7.1は6までちゃんとキャッチアップできてる現場なら自然に受け入れられるものだけど、C#7.2はヤバい
C++厨こじらせた奴がチームにいたらカオスになりそう
そして8.0ではついにnull非許容参照型が導入され、年内には現在ある全ての既存C#コードに対して膨大な数の警告が出るようになる

**デフォルトの名無しさん** · 2018/03/31(土) 12:26:40.13

最高じゃねえか
ついてこれないレガシー人材も放置されてるレガシーシステムも要らん

**デフォルトの名無しさん** · 2018/03/31(土) 12:41:52.94

そもそもプログラミングは低脳がやっていい仕事じゃねーからな
この期に日本式の文系マと専門学校マは全員処分したらいい

**デフォルトの名無しさん** · 2018/03/31(土) 12:44:53.69

>>583
文系かどうか、専門学校出かどうかは、本質とは関係ないのではないか？
馬鹿なやつを特定して排除するならまだしも、経歴 **だけ** で判断するのはいかがなものか？

**デフォルトの名無しさん** · 2018/03/31(土) 12:46:24.77

な、文系だろ？

**デフォルトの名無しさん** · 2018/03/31(土) 12:49:40.91

レッテル貼りして思考停止して片付けるのは楽だよな
>>581
現状でもVSで推奨されないことに「メッセージ」は出るけど「警告」は出ないぞ
下位互換無くすのなら別の問題になるけどな

**デフォルトの名無しさん** · 2018/03/31(土) 13:51:41.50

>>581
ヌルポ許容しない理由はなんでしょうか？

**デフォルトの名無しさん** · 2018/03/31(土) 14:00:03.82

そもそも納品物がヌルポでよく落ちるのは単体テストをしない、手抜きだからであって、
新機能を好んで使う馬鹿は、null非許容参照型を導入しようとテストをしないのは変わらないわけで、
むしろバグが隠蔽される。VBのOn Error Resume Nextのバグ隠蔽機能の再来。

varと同様、コード品質を落とすアホ機能である。

**デフォルトの名無しさん** · 2018/03/31(土) 14:15:45.12

単体テスト
それは企業によって意味が全く異なるワードである

**デフォルトの名無しさん** · 2018/03/31(土) 14:23:43.23

爺さんそろそろ引退した方がいいぞ

**デフォルトの名無しさん** · 2018/03/31(土) 14:30:41.24

単体テスト
・関数単位のテスト
・アプリケーションをビルドして作成・修正した箇所を開発者本人が動作確認するテスト

大きくわけてこの2種類の解釈
xUnit世代は単体テストってアレだよねっていう共通認識があるかもしれないが
老舗企業でそんな意味で単体テストっていう言葉を使うと恥をかくぞ

**デフォルトの名無しさん** · 2018/03/31(土) 14:35:37.85

>>587
if (arg == null) throw new ArgumentNullException(nameof(arg));
とか
Assert.That(Hoge(), Is.Not.Null);
みたいな頭の悪いチェックやテストケースが不要になる

**デフォルトの名無しさん** · 2018/03/31(土) 14:52:49.36

>>588
一般に、新しいものを使いたがるPGの方がスキルが高いので品質も生産性も高いよ
もちろん、メンバーの状況によっては縛りをかける判断が適切な場合もあるけど、
それはあくまでスキルの低いメンバーの生産性と品質の低下を避けるためだ
新しいものを使いたがる系の奴に古いものを強制しても、生産性と品質が大きく低下することはない

**デフォルトの名無しさん** · 2018/03/31(土) 16:18:58.20

しかし、linqだって１０年モノ・・・新しい古いってレベルじゃねーよな

**デフォルトの名無しさん** · 2018/03/31(土) 16:25:39.38

新しいフレームワークに飛び付く層はモチベーションの影響で生産力はあるかも知れないが、スキルが高いかというと微妙

**デフォルトの名無しさん** · 2018/03/31(土) 17:11:47.69

varって気を付けないと000abdだと整数読み込みでするからstringで扱う時はstringでやるわ

**デフォルトの名無しさん** · 2018/03/31(土) 17:29:38.76

>>588
ワロタ

**デフォルトの名無しさん** · 2018/03/31(土) 18:44:14.32

C#プログラマは全員、ライセンスで訴えられるリスクを負う。とても危険。

**デフォルトの名無しさん** · 2018/03/31(土) 18:51:34.87

春だなあ

**デフォルトの名無しさん** · 2018/03/31(土) 18:52:23.42

>>598
詳しく

**デフォルトの名無しさん** · 2018/03/31(土) 19:27:52.75

ユニットテストを意識するようになればメソッドやクラス構成マシになるのに、どうせ単体テストやるしと数百行のメソッド大量生産の俺社

**デフォルトの名無しさん** · 2018/03/31(土) 19:38:17.35

メソッドは原理原則通り20行まで・・・ってのはやりすぎかもしれんけど
全ては関数にわけられるだけわける
１つの関数に2つ以上の機能があれば冗長だとは思う

**デフォルトの名無しさん** · 2018/03/31(土) 20:01:38.03

関心事が1つであるべきだよ
機能数は複数あってもいい
例えば顧客オブジェクトを取得する/作成する/更新する/削除するための顧客リポジトリ
こいつの機能は4つだが関心事は顧客オブジェクトの永続化という1つだけ

**デフォルトの名無しさん** · 2018/03/31(土) 20:41:54.64

>>602
でもやたら関数に分けまくるのもやり過ぎの悪例だからなぁ
一行メソッドのたらい回しとか可読性低すぎて引き継いだとき殺意が湧くし

**デフォルトの名無しさん** · 2018/03/31(土) 21:12:12.52

1行でも意図が明確化するならメソッドにする
C++とかやってきた人なら当たり前の感覚なんだけどね

**デフォルトの名無しさん** · 2018/03/31(土) 21:20:51.16

Expression Bodyのプロパティやメソッドがなぜ導入されたのか
1行のプロパティやメソッドはそれだけ使用頻度が高いってこと

**デフォルトの名無しさん** · 2018/03/31(土) 21:50:23.14

バカが書くオブジェクト指向()を舐めるなよ？

あいつら『かめはめ波()』の機能を
か()
め()
は()
め()
波()
にするレベルでバカだからな

**デフォルトの名無しさん** · 2018/03/31(土) 21:55:29.44

意味を理解しておらず側だけ真似するからそうなる
猿は木の実でも取ってろ

**デフォルトの名無しさん** · 2018/03/31(土) 21:57:45.44

独立している機能なら一行でも良いが
一連の塊で動いてる機能を再利用性の欠片もないパーツに切り分ける奴は頭が悪い
しかもその切り分けた関数で他の関数を実行してたらそれはもうただの難読化だ

**デフォルトの名無しさん** · 2018/03/31(土) 23:47:58.41

>>607-609
バカw

**デフォルトの名無しさん** · 2018/04/01(日) 07:17:31.62

>>609
再利用性だけで分けるのは典型的な素人

**デフォルトの名無しさん** · 2018/04/01(日) 07:24:17.48

>>606
これが答えだよ
Microsoftや達人プログラマ達は1行メソッドの価値を理解して言語仕様まで変えてしまった
それほどまでに重要なものってことだ
一方で雑魚プログラマのお前らは価値を理解できずにぐちぐちと文句を言う
程度の低さを伺えるね

**デフォルトの名無しさん** · 2018/04/01(日) 08:28:43.58

コメント代わりに関数使う>>611みたいなのが害悪なんだよな

**デフォルトの名無しさん** · 2018/04/01(日) 08:32:44.17

プログラム構造が見渡せる行数になれば、ソレ以上の細分化は無意味なんだけどね
メソッドの分割は中身を理解しやすくするのが最大の目的で、それを阻害するほど分割したら意味がない

**デフォルトの名無しさん** · 2018/04/01(日) 08:45:42.44

俺もコメント代わりに分けまくる派
純粋関数で責任が明確なら可読性は上がるよ

**デフォルトの名無しさん** · 2018/04/01(日) 08:59:28.91

一目見たら分かる処理をオレオレ命名で飛び地化
お一人様開発なら良いがチームでやんなよ

**デフォルトの名無しさん** · 2018/04/01(日) 09:02:43.00

void MoveAX(unsigned short val);

**デフォルトの名無しさん** · 2018/04/01(日) 09:11:29.06

>>613
コードで表現できるものをコメントで書くバカが本物の害悪だよ

**デフォルトの名無しさん** · 2018/04/01(日) 09:16:10.30

マーティン・ファウラーはいつも良いことを言うね
底辺PGでも少しは見習ったほうが良いぞ

https://martinfowler.com/bliki/FunctionLength.html

**デフォルトの名無しさん** · 2018/04/01(日) 09:17:34.95

>>618
コードで表現出来てることをわざわざ関数名で伝えようとするバカが何だって？

**デフォルトの名無しさん** · 2018/04/01(日) 09:25:16.65

>>614
中身を理解しやすくするのは実装の仕事
メソッド化する最大の目的は実装と意図を分離すること
僕が引用したリンク先でマーティン・ファウラーがわかりやすく説明してくれてるからぜひ読んで欲しい

**デフォルトの名無しさん** · 2018/04/01(日) 09:28:59.77

三行で書かれてるコードならその場でその三行を修正するだけで済むが、
それを三つの関数に分けるとわざわざ別の行までスクロールして修正する作業が三回発生する

どちらが効率的で生産性が高いのか普通なら考えるまでもなく分かることだが、自意識過剰なバカには分からないのかも知れない
何せ自分のことを『達人』とか思い込んでるレベルのバカだし

**デフォルトの名無しさん** · 2018/04/01(日) 09:33:48.86

>>620
コードで表現していることを関数名で抽象化するんだよ
抽象化はプログラミングをする上で最上級に重要な概念だけどどうもIQが凡人以下だと理解できないらしい
物事を理解するにはその内容に応じた知能がどうしても必要になる
凡人が数学者や物理学者に成れない
難しい概念がわからないという感覚は人としてどうしようもないものなんだ
だからこのスレにも抽象化がわからない人が居てもおかしくはない

**デフォルトの名無しさん** · 2018/04/01(日) 09:36:24.52

>>622
場合によるんじゃないかな？
その一行が何度も出てくるなら関数化したほうが修正が楽

何百回修正するか
一回修正するか

**デフォルトの名無しさん** · 2018/04/01(日) 09:38:21.16

>>622
そのコードがなんのためにあるのかということを考える作業が3回も発生する

そのコードを変えて他に影響がないか確かめる作業が3回も発生する

同じことを他の場所でしていないか確かめる作業が3回も発生する

酷い無駄だ

**デフォルトの名無しさん** · 2018/04/01(日) 09:39:10.89

関数化で抽象化はされる

抽象化された関数で何をやってるか詳しく関数名に入れると無意味なことになることもある
むずかしいよね

**デフォルトの名無しさん** · 2018/04/01(日) 09:40:28.60

bool IsEmpty() => this.Length == 0;

このレベルの実装であれば何も文句はないが、大半はそうじゃないのが現実

**デフォルトの名無しさん** · 2018/04/01(日) 09:40:36.80

適切な直行化ができてれば、一連の処理の流れに関わる多数の関数を一緒に修正するなんてことはそうあるものではない
その程度のスキルレベルなら分け過ぎはよくないのは同意する

**デフォルトの名無しさん** · 2018/04/01(日) 09:42:35.89

もともと一行関数だったものが徐々に成長していくこともある
でも呼び出し元のコードは変わらない
ロジックが変わってないからね
これは大変素晴らしいことだと思う

**デフォルトの名無しさん** · 2018/04/01(日) 09:46:33.53

十分に責任の明確化ができている関数は中身を見る必要が無くなる
不要になって消すことはあっても中身を弄ることはめったにない
この名前でこの引数を受け取るならこの結果が返るのが当然、と思えるのが正しい関数だ

**デフォルトの名無しさん** · 2018/04/01(日) 09:48:36.16

>>627をバカが真似した例

void Increment(ref int a) => a++

（※現実にあったコードです）

**デフォルトの名無しさん** · 2018/04/01(日) 09:52:46.42

>>631
そのレベルの現場ならCOBOLみたいにMOVE羅列してる方マシだね
世の中そういうところばかりではないから文句があるならさっさと転職しろ

**デフォルトの名無しさん** · 2018/04/01(日) 09:54:39.84

コードを書いてる時点で将来をすべて予見できるような素晴らしい環境にいるならいいけど
大体はそんなことはない

仕様を考えたのが他人であろうと自分であろうと

**デフォルトの名無しさん** · 2018/04/01(日) 10:25:24.90

>>631
範囲を扱うアルゴリズムに使わせる目的で使うイディオムだよ
こうしておけばプリミティブの数値も数値っぽい型(例えば巨大整数クラス)も同じように扱える
ようするにただのストラテジだな

**デフォルトの名無しさん** · 2018/04/01(日) 10:45:43.34

まあ正直C#で>>631は無意味とは言わないまでも違和感あるけどな
>>631もC#だけでなくc++とか経験してみるとこういう短い関数の真価を理解できるんじゃないかな

**デフォルトの名無しさん** · 2018/04/01(日) 11:56:21.61

巨大整数とか仕様にカスリもしない未来を妄想して複雑化して「これがシンプルなんだよ！」と強弁するとかアホの典型だな
グループ開発の経験もない無職かよ

**デフォルトの名無しさん** · 2018/04/01(日) 12:03:50.05

>>636
一例に過剰反応バカキター

**デフォルトの名無しさん** · 2018/04/01(日) 12:12:43.78

最初から無駄に俺様カスタマイズしたがるのはこじらせたC++erによくあるYAGNIだね
そして、Incrementの例のように基礎的な部分には異常に拘るくせに普通のアプリケーションコード部分は巨大なメソッドを生産する奴が多い
その割にはポインタ演算は大好きで、配列操作になるとウッキウキしてクソ低レベルなアスタリスクと++だらけのコードを垂れ流す
そういう連中だよ

**デフォルトの名無しさん** · 2018/04/01(日) 12:36:30.52

昨日からNG大繁盛だわ

**デフォルトの名無しさん** · 2018/04/01(日) 12:42:38.07

ふらっとも伸びているようだし承認欲求に飢えているアホどもが暴れているのか

**デフォルトの名無しさん** · 2018/04/01(日) 12:53:48.82

>>638
でもそれってお前の妄想じゃん
c++の仕事任されるほどスキルないっしょ？

**デフォルトの名無しさん** · 2018/04/01(日) 12:59:36.34

>>641「巨大整数にも対応してるオレ様のフレームワークを使えー！」

**デフォルトの名無しさん** · 2018/04/01(日) 13:07:10.47

どんな面白い問題で盛り上がってるのかと思ったらしょうもな。

(1) 道具が多すぎる道具箱は使いづらい

からと言って

(2) 短すぎるメソッドは「無駄な道具」である

などと言えるわけがない。
そうである場合もない場合もあるに決まってる。

こんなくだらない話でよく盛り上がれるな

**デフォルトの名無しさん** · 2018/04/01(日) 13:16:23.13

>>643
だから無駄な道具を乱造して散らかす奴が悪いんだろ？
いくら「これが正しい！」と喚いてもゴミ屋敷をスマートとは言えんわ

**デフォルトの名無しさん** · 2018/04/01(日) 13:24:59.02

なんかずれてんな
いやわざとか？

みんな「1行コードはクール」
みんな「いや害悪だ」

>>631「1行コードにはこんな意味不明な頭悪いコードが実在するんだぜぇ」

>>634「いやーそれはストラテジでしょ。普通のコードだよ」

あほ「巨大整数ガー！ゴミ屋敷ガー！」

途中から明後日の方向に向かってんだよ
一例に過剰反応バカが湧いてきたあたりからね

**デフォルトの名無しさん** · 2018/04/01(日) 13:28:56.88

一つ言えるのは、一行コードをセンスが無いやつが書くとゴミクズになるってことだな
まあ何行でもゴミと言えるかもしれんが、一行のゴミはメンテする時腹が立つ

**デフォルトの名無しさん** · 2018/04/01(日) 13:30:25.54

1行メソッドの利点を理解できないアホが逆ギレしてるだけのパターンもあるということは忘れないで

**デフォルトの名無しさん** · 2018/04/01(日) 14:14:15.06

一行のゴミにも何か利点はあるはずだと頑なに改めようとしない>>647なのであった

マジでゴミ屋敷の主だな

**デフォルトの名無しさん** · 2018/04/01(日) 14:20:30.29

>>645はstrategyも理解してないアホの子だから許してあげて
ただのラッパーを戦略と勘違いしてるなんて、きっと今年の春から働き始める新人だから

**デフォルトの名無しさん** · 2018/04/01(日) 14:28:00.99

上司「なんでこのインクリメントを関数に分けてんの？」

新人「様々な型に対応する為のストラテジです！巨大整数などにも対応できます！」

何というか無能な働き者って言葉がしっくり来るな
たぶんこいつは誰からも理解されずに五月病患って数ヶ月で退職するわ

**デフォルトの名無しさん** · 2018/04/01(日) 14:39:00.26

インクリメントの(多相じゃなくて正しい意味での)ストラテジって何だろうね
++とInterlocked.Incrementを切り替えるとか？
エイプリルフールネタにもならんな

**デフォルトの名無しさん** · 2018/04/01(日) 14:39:37.29

>>640
春休み

**デフォルトの名無しさん** · 2018/04/01(日) 14:47:04.79

ここには初心者スレに行ったほうがいいような連中しか居ないようだな

**デフォルトの名無しさん** · 2018/04/01(日) 15:13:55.41

ゆとり世代はなんでも揃ってるところからスタートだから楽でいいよな
iteratorの実装なんて考えたことすらないんだろう
羨ましいよ

**デフォルトの名無しさん** · 2018/04/01(日) 15:50:22.39

老害

**デフォルトの名無しさん** · 2018/04/01(日) 17:15:29.85

>>650
何で巨大整数に対応する必要ない状況を前提としてるの？
対応すべきという状況を前提とした途端に真逆の結論になると思うけど

**デフォルトの名無しさん** · 2018/04/01(日) 17:31:26.23

仕様上ありえない予測
それを人は　妄想　と呼ぶのだ

**デフォルトの名無しさん** · 2018/04/01(日) 17:45:28.27

巨大整数対応を勝手に仕様上あり得ないことにしている点
「○○にも対応できるように」の○○に巨大整数を入れるのはあくまで一例であり他にも山ほどあり得る点
この辺りが問題かな
言われた通りの物を納品すればいい所謂IT土方系の環境なら問題にならないんだろうけど

**デフォルトの名無しさん** · 2018/04/01(日) 17:47:21.74

>>656
対応すべきという状況を前提にしたとしても、>>650の新人がストラテジパターンを誤解している阿呆であるという結論は覆らない
>>631を型ごとに用意するのは一般にはパラメータ多相、あるいは単にオーバーロードと呼ぶんだよ

**659** · 2018/04/01(日) 17:49:35.48

すまん訂正
パラメータ多相じゃなくてアドホック多相だな

**デフォルトの名無しさん** · 2018/04/01(日) 17:49:42.89

この手のっていつも「自分の前提」の元に議論初めてかみ合わないんだから止めとけよ
ネタが下らないことだし、そんなことにこだわるしかやることないのかよ

**デフォルトの名無しさん** · 2018/04/01(日) 17:53:38.19

int型をBigInt型に切り替える必要が生じたとして、
型宣言から書き直さないといけないのにインクリメントを分離しておいて何が効率化できたというのかと
そもそもオブジェクト指向に則ればその型自体にインクリメントを備えるだろっていう

現実に設計したこともない新人が本の知識で言ってるだけだなこりゃ