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

2017/10/09(月) 19:00:56.93

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。

他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。

内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。

なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください

>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part131
http://mevius.5ch.net/test/read.cgi/tech/1504861931/
■関連スレ
C#, C♯, C＃相談室 Part94 [無断転載禁止]©2ch.net
http://mevius.5ch.net/test/read.cgi/tech/1492843013/

■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/

■情報源
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/

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

2017/10/15(日) 20:14:55.96

タイトルバーのこと？

2017/10/15(日) 20:32:23.95

UWPだと、画面のサイズに依ってフォントのサイズどころかコントロールのレイアウトから何から何まで変更することが可能です
VisualStateManagerとAdaptiveTriggerってのを使うんだが、ちょっと説明には骨が折れるから興味ある人はググってね

単純なものでも、この複雑さだからね
https://blog.naotaco.com/archives/840

2017/10/15(日) 21:09:13.78

>>133
そうです。スレ違いでしたね
透明の箇所はスタートメニューから全部無効化したいですね
急ぎじゃないんで適当に調べてみます

2017/10/15(日) 21:25:24.68

>>136
http://news.mynavi.jp/column/windows/385/
ここにレジストリの変更でできるって書いてあるが、後は頑張ってね

2017/10/16(月) 06:32:34.43

>>130
おお、大丈夫なのか
ありがとう
原因を分けて対応しないと駄目だな～

2017/10/16(月) 08:01:21.51

二つの同じ長さの配列A,Bの末尾から5つを取り出してその全ての要素がA>BならTrueを返す

↑これってLINQでうまく書ける？

2017/10/16(月) 08:05:12.77

>>139
友の会行けよ
明らかに初心者スレじゃねぇよ

2017/10/16(月) 09:40:47.13

LINQの定義次第っていうか
LINQ to ObjectsならTakeLast拡張メソッドを自分で実装すればいける

2017/10/16(月) 09:50:04.77

>>139
A.Reverse().Zip(B.Reverse(), (a, b) => new { a, b }).Take(5).All(ab => ab.a > ab.b)

>>141
十分初心者レベルだよ
自分がわからないからスレ違いってw

**142** (ﾌﾞｰｲﾓ MM0d-QEog) · 2017/10/16(月) 09:51:11.95

すまん
わかると思うけど下のアンカは>>140の間違い

2017/10/16(月) 09:53:43.90

なんで推敲する程度の余裕すらないんですかね…
寿命が近くて生き急いでるのかな？

2017/10/16(月) 10:01:59.84

>>142
こんなコード見やすいと思ってる時点で頭がイカれてる

2017/10/16(月) 10:13:40.50

またLINQに親殺されたマンのスイッチ入ったな

2017/10/16(月) 10:15:02.52

逐次的に読むだけだから難しくはないと思うが…

2017/10/16(月) 10:15:18.65

まあ、動作も遅いしね

2017/10/16(月) 10:16:28.62

>>148
ちょっと興味あるから同じ処理をわかりやすいように書いてみて

2017/10/16(月) 10:25:12.95

>>145
勢いで書いて後から見てワケワカランで
こんな糞コード誰じゃと調べたら自分だった事が多々あるw

2017/10/16(月) 10:51:30.20

>>148
LINQ難しくて嫌いだからってケチ付けるなよｗｗｗｗｗｗｗｗｗ

2017/10/16(月) 10:57:04.66

>>151
いや、遅いのと見難いから嫌い

2017/10/16(月) 11:02:26.88

メソッドチェーンってそんなに見づらいか?
クエリー構文はキモくて嫌いだが。

2017/10/16(月) 11:05:31.52

LINQに全てを奪われたマンだろ

2017/10/16(月) 11:07:08.78

>>153
テトリスを一行で書きました（改行コードがないだけ）
みたいな臭いがして臭い

2017/10/16(月) 11:07:49.77

>>142はLINQ好きじゃない俺でも十分読める
ちょっと思ったけど
A.Reverse().Zip(B.Reverse(), (a, b) => a > b).Take(5).All(x => x);
こっちの方がいい気が

Tがboolの時predicatorじゃなくて要素そのものを評価するオーバーロードってないんだね

2017/10/16(月) 11:17:17.26

>>142
ありがとうありがとう
なんでかTakeLastが使える(最近追加された？)んでリバースなくて行けました
けどめちゃくちゃ遅かった…

ちょっとLinqでやるんが無理だったんかな、でもすごくためになりましたありがとう

2017/10/16(月) 11:18:16.37

>>155
こんなに普及してるjQuery全否定か

2017/10/16(月) 11:21:16.85

>>155
頼む、ｱｳｱｳｵｰ Sa63-qY8Gなりの同じ処理のコードを書いてくれ
そっちのほうが分かりやすかったら味方も増えるだろ

2017/10/16(月) 11:22:50.09

しかも最近流行りの状態を持たない関数型プログラミングだし

2017/10/16(月) 14:46:59.09

SQL使ってた人にはLINQは分かりやすいけど長いと読む気なくすのはSQLも同じ

2017/10/16(月) 14:54:15.28

>>161
linqのクエリ式とsqlは別もん。
sqlを知らない方が良いかもね。

2017/10/16(月) 15:12:28.85

TrackBar のツマミを、タッチ操作用に大きくしたいんですが、どうすればいいんでしょうか。
検索しても解決に至っていない質問がちらほらあるぐらいです。もしくはこれでもかってぐらい
自分で書いたオリジナルのトラックバーとか。
そこまでしなくても、ツマミが大きくできるだけでいいのですが。

2017/10/16(月) 15:21:38.99

>>162
別物(キリッ)とか言われても
同じだなんて言ってないけど

ただ取っ掛かりの部分でSQLの知識が活かせるから個人的には学習コスト低かったし、
逆にSQL知らない子に教えて慣れさせるのには苦労したわ

2017/10/16(月) 15:32:11.28

>>164
メソッド式だけで充分

2017/10/16(月) 15:34:39.13

>>164
自分の場合はSQL知っててクエリ式を見たときは何じゃコリャと思ったもんで^^;
冗長だけどメソッド式が好み。

2017/10/16(月) 15:58:03.25

>>165
そう思ってるのお前だけだからクエリ式があるんだろ
悟れよ

2017/10/16(月) 15:59:01.02

>>166
面食らうのはわかるけどすぐ慣れるでしょ

2017/10/16(月) 16:04:24.32

>>163
https://msdn.microsoft.com/en-us/library/system.windows.forms.trackbarrenderer(v=vs.110).aspx

2017/10/16(月) 16:09:03.51

>>168
linqの出始めの頃はクエリ式を多く見かけた気がするが、最近のグーグル先生ではメソッド式を多く見かける気がする。
どっちが主流なんだろ?

2017/10/16(月) 16:12:46.47

今はメソッド式のほうが主流なんじゃない
最初は皆珍しがってクエリ式使ってたけど
今はほとんど見ない

2017/10/16(月) 16:28:30.74

>>171
vb.netだと状況が違うかも。
メソッド構文が冗長過ぎるよ。

2017/10/16(月) 17:44:59.60

>>167
クエリ式で可能なことは全てメソッド式で可能。逆は成り立たない。

2017/10/16(月) 17:46:24.26

>>167
充分の意味がわかってないということは中卒かな？

2017/10/16(月) 17:48:04.85

>>113
>>131
コードも書いて頂いてありがとうございました。
恐縮しております。
いろいろいじってみたところ、
WPFでできそうなのでやってみます。

2017/10/16(月) 18:08:02.80

>>172
Functionがウザすぎてクエリ式使うわ

2017/10/16(月) 18:19:09.19

リファクタリングって実際にやる事って多いのでしょうか？
とりあえず動くものを作ると手直しが大変で、設計を考えてから作るならそんなにリファクタリング起こらない様な感じもしますが
後から機能追加していくと分割しようとかってのもあるのでしょうか

2017/10/16(月) 18:25:44.09

多いです

2017/10/16(月) 18:40:53.97

むしろそんなんばっかで嫌になる
最初の仕様書もっぺん見てみろや禿げと言いたくなるね

2017/10/16(月) 18:51:38.88

>>174
じゃあお前はILで書ければC#要らないんだろうな高学歴さん
そもそも糖衣構文なんてどれも使い方次第だろ
言われないとわからんか？

2017/10/16(月) 18:57:14.07

>>180
ILがc#並に使い勝手良ければそうだろうね

2017/10/16(月) 19:03:30.59

教科書見ても全然わからんかったのにスイスイ理解できる

2017/10/16(月) 19:03:49.47

ミスった

2017/10/16(月) 19:22:10.94

>>177
それって誰の金でやってんの？
次の開発なんかあるかどうかわからないのに無駄じゃない？

2017/10/16(月) 19:22:42.93

>>177
設計を考えてから作ったあとにリファクタリングとか、設計が糞だからやり直すようなもんだわな

2017/10/16(月) 19:23:29.95

リファクタリングって設計がクソだからやるの？

2017/10/16(月) 19:30:37.46

>>177
一度書いたコードは問題なく動いている限りリファクタリングなんてすることは無いよ。
リファクタリングする工数なんて何処にも無いからね。

元のコードを大きく改変する必要があるとか類似システムを作るときは
思い切ってリファクタリングするけどね。そっちの方が品質も安定するし早いから。
ま、そんだけ元のコードが酷いって事さwww

2017/10/16(月) 19:30:40.89

>>184
主力製品の機能変更で売ってくようなスタイルだと機能追加の度にコードが増えてくけど、その度に仕様変更でバグが混入する可能性があるからコード直ししたいとかあるってパターンもあると思います
既に基底が整備されてるとかプロジェクト毎に違う製品作るパターンならこういうことは無いと思いますが

2017/10/16(月) 19:34:29.63

>>188
でもお客の要望がリファクタリングの方向とズレてる場合って
かけたコストが丸損じゃない？

2017/10/16(月) 19:38:56.50

>>189
あくまでお客とのやり取りではなく、コードは会社の資産という観点でリファクタリングするという考えですね

お客の要望で機能追加する前提のものなので、そこで保守するコストやバグによる信用低下からプログラムそのものの価値が下がるって概念になると思います
まぁ実際はリファクタリングするには大きすぎるので理想はあっても実行は中々できないと思いますが

2017/10/16(月) 19:39:51.97

>>173
letとSelectManyの連鎖はクエリー式でないと辛すぎるですたい

2017/10/16(月) 19:48:17.74

リファクタリングのやり方がおかしいんじゃないかな
リファクタリングでコードがシンプルになればその後の開発工数が激減する

2017/10/16(月) 20:21:04.95

レガシーシステムに手をつける前に必ずリファクタリングするって常識でしょ
レガシーシステムは恐ろしいスパゲティの塊なのでそのまま手を出すとあっという間に破綻する
まずはリファクタリングで保守可能な状態を作らなければならない
最悪でも拡張する機能をテスト可能な状態にすること
顧客がバカでコミットできない場合でも知識を得るためにリファクタリングが最適
腐ったコードはどれだけ読み込んでも理解できない

2017/10/16(月) 20:21:22.23

>>190
いや今まで設定ファイルから読んでたけど
ネットワークから取得するわ
一括ではなく個々のデータを使用するときに常に最新データを個別に取得するわ
ってなったら絶対無駄になるよね？

2017/10/16(月) 20:26:56.04

>>192
それは改修時にする設計だよね
それは理解できる
でも、動いてるところをわざわざぶっ壊して作り直すって
お客に見積り通らないよね

2017/10/16(月) 20:29:25.51

>>194
それで無駄になるケースってどういう場面でしょうか？
設定ファイルとコードが依存してなければ設定ファイルの取得部分の追加変更でリファクタリング自体は無駄にならないと思いますが
変更できないような設計なら確かに無駄になると思いますが・・・

2017/10/16(月) 20:31:20.88

>>195
スレチ

2017/10/16(月) 20:31:55.64

>>196
設定ファイルを読み込む前提でリファクタリングしたなら
ネットワークからデータを個別に取得するようになるわけだから無駄だよね？

2017/10/16(月) 20:34:39.53

無駄になる可能性もあるけど無駄にならない可能性もある
汚いコードだった場合ほど無駄にならない

2017/10/16(月) 20:34:54.38

設定ファイルは起動時に１回一括で読み込むだけかも知れないね

でもネットワークからデータが必要になるたびに個別に最新を取得だから
ぶっちゃけ対応できないんじゃないかな？

2017/10/16(月) 20:36:10.80

>>200
スレチ

2017/10/16(月) 20:37:35.41

>>199
そう？
逆にこれが対応できるほど汎用性を上げたら明らかに無駄なコードだと思うよ

**デフォルトの名無しさん** (ｽﾌｯ Sd33-iAGE) · 2017/10/16(月) 20:38:05.31

ID:BTwHB29Waが何言ってるかわかるエスパーいる？

2017/10/16(月) 20:41:07.21

>>203
簡単にいうと仕様変更がかかったらリファクタリングなんて意味ねーじゃんってこと

2017/10/16(月) 20:55:07.11

>>204
仕様変更ってリファクタリングしててよかった～って一番実感するときだろ
まあやったことない人にはわからない感覚だとは思う
リファクタリングに工数かかるのは事実だから
目の前のコストしか見えない人だってそりゃいるよね

2017/10/16(月) 20:57:22.92

それはリファクタリングというかテスト書く話では

2017/10/16(月) 20:57:25.32

>>205
でも>>194とか無理でしょ？

2017/10/16(月) 21:05:31.13

>>207
設定ファイル一括読み込みクラスをリファクタリングして
設定問い合わせインターフェースにする
設定ファイル一括読み込みクラスは設定読み込みインターフェースを実装する

設定読み込みネットワークになったわー読み取りは毎回取り直しだわ～ってなったら
設定テーブルセレクトクラスを作る
設定テーブルセレクトクラスは設定読み込みインターフェースを実装する

DIの設定を変更して終わり
簡単だろ？

2017/10/16(月) 21:06:54.06

>>208
誤字訂正

＞設定ファイル一括読み込みクラスは設定読み込みインターフェースを実装する
設定問い合わせインターフェースを実装する

＞設定テーブルセレクトクラスは設定読み込みインターフェースを実装する
設定問い合わせインターフェースを実装する

2017/10/16(月) 21:08:49.18

組み直しに近いよね

2017/10/16(月) 21:12:10.02

設定ファイル一括読み込みクラスは会社の資産とのことだけど
どこ行くの？

また、設定ファイルから読み込むこともあるかも知んないから残しとく？
別の会社に売ったら
「うちはいちいちネットワークなんて繋げなくていいよ」
って言うかもね
こっちもサポートし続ける？
捨てちゃう？

2017/10/16(月) 21:15:35.05

>>195
業態によるんじゃないかな
客先の社内に入ってる常駐型とかweb開発では継続的インテグレーションが当たり前
納品して終わりのシステムなんて大手は少ないんじゃないかな？

2017/10/16(月) 21:16:23.03

リファクタリングしてないと組み直しになる
ネットワークから取ってくるって機能に切り替えたいだけなのに
なぜか設定読み込み処理そのものやそれを呼び出してるところを一生懸命調べたり直さなきゃならない
本当にやりたいことはそんなことじゃないのに！

リファクタリングしてあればまさにネットワークから取ってくる処理を追加するだけで済む
既存の処理はそのまんま
やりたいことを過不足なくやるだけ

解放閉鎖原則ってやつだね

2017/10/16(月) 21:18:26.26

>>212
継続案件でも納得してリファクタリングに金払う客居たら見てみたいわ
どうにもならなくなった糞コードを何とかする手段としてリファクタリングを使うケースは偶に見かけるけど

2017/10/16(月) 21:19:42.39

>>212
京都市とシステムズが争ってんじゃん
11億円の案件らしいけど
次の仕事あると思う？

2017/10/16(月) 21:21:16.99

客が選べないのはお前が無力だから

2017/10/16(月) 21:21:25.94

>>213
浅はかだな
一部設定ファイルから
一部ネットワークから
って可能性もあるよ
改修仕様が決まってから出ないとリファクタリングもゴミだなって気づけよ

2017/10/16(月) 21:21:40.28

>>211
必要な顧客と不要な顧客が居るなら取っておいたほうがいいね
インターフェースで綺麗に分離されてるから機能有効化無効化の管理も超簡単

2017/10/16(月) 21:22:06.38

てかマ板でやれよ
底辺チンカスコーダーの分際でうるさいわ

2017/10/16(月) 21:22:56.52

>>218
ネットワーク状態によって分岐するかもしんねーぞｗ
どこまでインターフェースで対応できんだ？ｗ

2017/10/16(月) 21:23:54.08

>>217
それもリファクタリングしてあれば簡単にできるよ
単に設定ファイル読み込みクラスとネットワーク問い合わせクラスのミックスインを作るだけ
実装するのにまあ15分もかからないと思うね
リファクタリングしてなかったらこれは絶望的だよ

2017/10/16(月) 21:24:30.99

>>214
MacはOSを途中で変えた
古いOSは改修に次ぐ改修で複雑に絡み合いリファクタリングすらできず
将来性がなかったから

windowsだって10までバージョンがあがったけど
そこまでのOSの変更費用は利用者が払ってる
将来性や利点があるならちゃんと説明して金をとるべき

あ (ﾜｯﾁｮｲ 7b99-b3d+) · 2017/10/16(月) 21:26:54.92

リファクタリングは組み直しだろ。
なんでやるのかっつーと、いろんな意味でその次を楽にするため。
次の改修だったり、次の案件に使いたかったり。
ただし、それは改修と併せてやってはいかん。
改修、つまり「今より良くするもの」「悪いものを直すもの」の正しい評価ができん。

会社でやるなら、金の出処は研究開発扱いとしてやるしか無い物だと思うわ。
機械で言うと「新素材の研究が一段落していい感じだったんで、それ使ってネジのコストカットしました」とか「量産安定してきたんで金型のランナーをちょっと樹脂ケチる感じに引き直しました」とかそんなレベルの話。
もし客にバレたなら、単なる不具合の改修でしかない。

2017/10/16(月) 21:26:56.03

>>220
それも簡単に対応できるね
ネットワークの状態を見てスイッチングするデコレーターを作るだけでしょ

リファクタリングしてなかったらあっという間に炎上する案件だよねこれって

2017/10/16(月) 21:28:07.20

>>221
どのデータがネットワークからでどのデータが設定ファイルからかわからないのに？
自由に変えられるように組んであるの？

2017/10/16(月) 21:28:59.41

>>223
だから次の仕様が明確にならないと意味ないって

2017/10/16(月) 21:29:59.81

>>224
そもそもそれは俺が言ってから君がリファクタリングの方法を変えてるだけで
実際はもう対応できてないじゃん

2017/10/16(月) 21:33:18.73

ｱｳｱｳｵｰ Sa63-qY8G
ﾜﾝﾄﾝｷﾝ MMd3-pbEI
板違いで真っ赤とかNG推奨

2017/10/16(月) 21:33:19.62

>>225
仕様はあるんだろ？
それ見て作ればいいだけ

なんならそれも設定から読むようにしようか？
ルート設定情報を見てファイルかネットワークか選ぶ
ネットワークが死んでたら何回かリトライ
それでもダメならファイルから
ファイルがダメなら埋め込みデフォルト値
みたいな感じで

リファクタリングしてれば簡単にできるぞ

あ (ﾜｯﾁｮｲ 7b99-b3d+) · 2017/10/16(月) 21:34:59.19

>>193
不思議なもんで、理解はできるが、なんでこうなってんのかわかんねえ、って半日悩んで、スクラッチすっか、と最低限の条件からだんだん込み入った事書いてくと最終的に「これ最適解じゃん。すげぇ」ってなる事あるな。
Fortranの処理系のメンテしたほうがマシ、と言う結論に至った事がある。

>>226
次の仕様に合わせてやるのは、対応。
そうじゃなくて、「これ事故りそうだな、今手が空いてるから直しとくか」がリファクタリング。
フツーに仕事してたら納期次第で不味い手を打たざるを得ない事もあるしな。
32767回目で死ぬ事がわかってる、年に100回しか打たれないはずのコマンド、とか。
何故かそういう物に限って変な活用されたり、10年生きてたりする。

2017/10/16(月) 21:35:00.32

そもそも設定ファイルの読み込みルーチンだけど
すでに納めた客の対応はどうするの？
変えちゃうのはいいけどさ
動いて無いとまずいんちゃう？

インターフェースで対応できるの？

2017/10/16(月) 21:35:17.50

お前ら、プログラムの仕様を変えたらリファクタリングじゃねーわw

あ (ﾜｯﾁｮｲ 7b99-b3d+) · 2017/10/16(月) 21:36:09.29

>>231
出しても出さなくても良いのがリファクタリング。