ふらっと C#,C♯,C＃（初心者用） Part129 [無断転載禁止]©2ch.net

2017/06/09(金) 18:36:01.72

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

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

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

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

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

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part128
http://mevius.2ch.net/test/read.cgi/tech/1493730340/

■関連スレ
C#, C♯, C＃相談室 Part94 [無断転載禁止]©2ch.net
http://echo.2ch.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/07/03(月) 17:52:47.65

俺にはウィルスにしか見えないわけだが
こいつの目的は何なの?

2017/07/03(月) 17:54:07.35

DOSじゃないんだからOS全体でアクティブなディレクトリなんて存在しないと思うよw

2017/07/03(月) 17:55:34.21

アプリケーションにドロップしたディレクトリじゃ駄目なのかよ

2017/07/03(月) 18:00:01.58

まず現行業務フローの洗い出しができてないよね
１日数百回フォルダ移動してる暇な奴ってすでに俺には聞き込み調査か粛清が必要なレベル
プログラムを組むんじゃなくて
ローキックの連打で解決できそうな臭いしてる

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:14:18.18

皆さん、いろんな意見をありがとうございます。

（笑わないで聞いて下さい。）
毎回落としてくる、エロ画像がボクの宝物なので、
大事にパスワードを設定してます。

開く時にパスワードを書いたメモファイルを何時も開き忘れるので、
フォルダを開いたと同時に表示して欲しいんです。

>>638
画像によっては属性が夢の様に、いっぱい詰まってるので毎回、移動させてます。

2017/07/03(月) 18:16:39.30

エクスプローラーもメモ帳も自分で作ればいいだけに見えるんだが・・・
それらの部品ならCodeProject漁れば出てくるよ

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:17:23.61

フォルダにパスをかけなければと言う人も居ますが、フォルダにパスワードは必要です。
メモファイルは隠しフォルダにしたら何とか隠せますが、パスがついてない画像は
閲覧されちゃいます。

2017/07/03(月) 18:24:04.65

>>640に賛成
ディレクトリの位置に紐つけたパスワードのデータベース作ればメモ帳起動する必要もなくなる

2017/07/03(月) 18:28:02.02

>>623
> 強制ガベコレすると落ちるけどしないと落ちないときあるじゃん
>>605みたいなケースだろ
そうじゃなくて普通に使っててそんなことになると言うならサンプルコードあげてみそ

**652** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:34:05.18

>>642
メモ帳が必要な理由としては、コメント書いてるんです。
「今日も可愛いね」「その猫耳が似合ってるよ。」とか書き込んで、
後から同じファイルを開いた時に追加してコメント入れてるんので、メモ帳を起動させたいのです。

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:35:12.16

間違えました。
652では無く、
625でした。

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 18:46:56.71

現状では634の方法で行きたいと思います。
一部を保留にしながら、632にを参考に進めて行きたいと思います。

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 20:33:26.13

レジストリを触りたくないので、メモ帳を起動後にフォントと文字サイズを変更
しようと思ってますが、やり方が見つかりません。

ファイル内に.txtが有るか調べる
ファイルを指定してメモ帳で起動するまで行きましたが、
起動後、メモ帳の設定の仕方が分かりません。
どなたか教えてくれませんか？

（ファイルへの書き込みと読み込みは結構、でてくるんですけどねｗ）

2017/07/03(月) 21:08:48.55

DLL AとAが参照しているDLL Bがあって、BでAのPOCOクラス使いたいんだけど循環参照になっちゃうからPOCOクラスをDLL Cとか別で定義するしかないよね？
C#なら別DLLにしなくてもいけると言われたんだが、どうやるのか見当つかない・・・

2017/07/03(月) 21:10:48.36

メモ帳だから出来ないんよ。
最低限テキスト編集機能しか無いからね。
ワープロじゃ無いから、テキスト編集さえ出来れば良い(高機能でも快適な編集が出来ればいい)ってのがテキストエディタ。
フォントとかはワープロの領分だよ。

2017/07/03(月) 21:11:02.19

>>648
Bに実装してAから呼び出す

2017/07/03(月) 21:15:30.82

>>648
AとBを一つのDLLにまとめる
どうせ切り離せないなら分ける意味ないでしょ

2017/07/03(月) 21:19:23.58

>>649
メモ帳にフォントと文字サイズの指定はあるぞ。
表示される文章全体に対してだが。

2017/07/03(月) 21:21:13.75

あったっけ。
ま、どうでも良いけど。

2017/07/03(月) 21:29:33.51

指定じゃ誤解を招くな。
そういうアプリの設定ね。

2017/07/03(月) 21:31:35.49

>>648
そうするしかない、というよりそうすべきだね。
俺は共通のenum一つのために別のdllに分けたことがありますw

2017/07/03(月) 21:34:16.70

>>650>>651>>655
やっぱり今のままじゃどうやっても無理だよね、サンクス

2017/07/03(月) 21:37:08.97

循環参照が発生した時点で設計バグなので楽しいリファクタリングタイムだ

2017/07/03(月) 21:52:41.27

んでまた資料も書かずに突貫工事でプログラム組んで余計ややこしいことになっちゃうまでが準備体操

2017/07/03(月) 21:57:30.38

あらゆる管理業務の負荷はコードの品質で天地の差が出る
循環参照してるようなクソコードのドキュメンテーションは地獄だ
リファクタリングしてからやった方がいい

2017/07/03(月) 22:01:47.75

そのリファクタリングが正しく出来なさそうだからまず資料作れって言ってんだよハゲ
っていう不毛な会話はもうしない
突貫工事が好きなところといい
きっと彼は土属性に違いないのだから

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/03(月) 22:32:44.15

てっきり無視されるかと思ってました。ｗ

フォルダを開くのを認識させるのは、どうしたら良いのでしょうか？
指定したフォルダを開く事はできても、これから開くフォルダを認識する事なんてできるのでしょうか？

質問ばかりで申し訳ないです。

2017/07/03(月) 22:35:33.59

>>656
よろしくないってだけで、無理ではないと思うが。

2017/07/03(月) 22:40:33.08

>>660
正しいドキュメントを書くことはコードを書くことよりはるかに難しい
循環参照するような破滅的コードが相手だとまともなドキュメントを工数に見合う時間で作れる見込みは少ない

そもそもコンパイラや静的解析ツールを利用して体系だった機械的なプロセスでコードの品質を高めて可読性を上げることができる
それがリファクタリングの中でも大きなメリットの１つだろ
そこへ来てドキュメントを書いてからリファクタリングなどというのは全く見当違いの馬鹿馬鹿しい行為なんだよ

ドキュメントを作るのはリファクタリングで整理されてドキュメント化可能な状態になってから
あるいは探索的リファクタリングで得た知識を忘れないようにドキュメント化する
なんにせよコードを弄った後の話だ

こんなこと普段からコードを書いてリファクタリングしてれば知識がなくとも体感的にわかることなんだけどね
この業界はコードを書かない自称エンジニアさんばかりでため息が出るね

2017/07/03(月) 22:42:41.27

>>663
せめて問題点がわかる粒度の表にするべきだと思うわ

2017/07/03(月) 22:46:38.52

>>663
お前、ドキュメント書いてからソース書いたことないな

異なる文化を持ってる会社と仕事したらボコボコにぶっ叩かれるな
設計書を完璧にfixしないとソースコード触らせてもらえないとこあんぞ
でも一度はそういうところに行くべきだと思う
きっと違った世界が見えるはずだ

2017/07/03(月) 22:50:03.47

どうでもいいよw
それ以上はチラシの裏に書いてよw

2017/07/03(月) 22:51:34.84

スタンダードはv字開発の方なんだけどな

2017/07/03(月) 22:58:15.68

リバースエンジニアリングは小規模でのみ通用する方式

2017/07/03(月) 23:06:11.28

>>664
リファクタリング対象を選ぶために、という理由でなら資料を作る意義はあるかもしれない

例えば複雑度、更新頻度、バグ密度などリファクタリングをする価値を判断できる数字というのは結構、ある
殆どのデータは自動収集できるものでレポートを手作りすることはないだろうが
ざっと目を通した時の難易度などは手作業の方が早いかもしれないね

でもね、リファクタリングの方法を探るために先に資料を作るというのは、ない
制限時間付きのパズルを解こうとしているのにまずはドキュメント？冗談でしょう
やるとしても、パズルを弄りながらメモ書き、程度でしょ

2017/07/03(月) 23:24:27.65

>>669
もうそれ設計でもなんでもねーじゃんｗ

2017/07/03(月) 23:24:29.30

>>665
ガラパゴスの国だからね
文化の違いは認めるよ
修正は設計書のレビューを通してからコーディングという現場に居たこともある
しかし徹底的なドキュメンテーションが正解だとは思わない
ドキュメンテーションには時間がかかるし統一的な記法も機械的な検証方法も無い
実際の挙動を決定するコードと同期しているか定かでは無い
何よりこの手の現場ではコードを弄るという探索的プロセスを軽視する傾向が強いことが問題だ

コードを弄らずにドキュメントだけ正しい状態に持っていこうとするということは
まるでパズルを頭の中で組み立てて手順を資料化するような馬鹿馬鹿しい行為だ
パズルに挑戦する人は誰だって自分の手でパズルを弄りながら考える
それと同じでリファクタリングの方法を考える人は自分の手でリファクタリングをしながら方法を考えるんだ
手を動かす前に思いつくようなアイデアはいつだって陳腐で使い物にならないものばかりだ

2017/07/03(月) 23:28:02.84

完成するかどうか分からんパズルと仕事をおなじにされてもなぁ

2017/07/03(月) 23:32:35.22

肉体言語の使い手だよね
メラ!（右フック!）

2017/07/03(月) 23:39:08.40

>>670
そもそも設計ってなんだと思う？

俺はビルドを実行する前までのプロセスが設計だと思う
コーディングは設計フェーズでコードは設計書
製造はビルダーの仕事

俺らが作るものは最終的には動くプログラムなんだよね
それでコードはそのプログラムがどういう仕組みでどういう風に動きますっていう定義をずらずらと書いたものだよね
それってまさにプログラムの設計書じゃないか

じゃあ世間の言う設計書ってなんだって話だけど
俺からするとそういうのは設計概要とか設計方針の方がしっくりくるんだわ

2017/07/03(月) 23:41:12.61

どっちのいいぶんもまぁわからんでもないが結局プロジェクトの規模によるんじゃないの？
みんなだいたい一人どれくらいのプログラムの量かくの？

2017/07/03(月) 23:41:26.60

宣言型言語で書くならそうだが、普通コードは命令書であって設計書じゃない。

2017/07/03(月) 23:42:46.19

>>673
もう投了ですか？

2017/07/03(月) 23:49:00.34

>>674
いやぁさすがにそれは詭弁にしか聞こえない
だってお前のは材料数も期間もなんもでねーじゃん
ただ単にパズルが解けるまで遊んでるだけで最悪なんの成果もないわけじゃん

2017/07/03(月) 23:51:24.33

>>676
世の中の多くの設計書が手続き(命令)的な書き方をされてますよね
年配のCOBOLエンジニアさんが書く設計書などがまさにそうですが
あれは設計書ではなかったと

2017/07/03(月) 23:52:11.27

だいたいリファクタリングとか言ってるけど
ここまで来てそんな問題起きちゃうのはただの設計ミスだよね?
設計書から完成させる文化の仕事受けて１回軍法会議にかけられて死ねばいいよ

2017/07/03(月) 23:53:02.74

ひとつの型が唯一解とは思わないが設計書は必要だよ
コーディング以降は各テストレビュー完了毎にメンテナンスするくらいの頻度でいい

アルゴリズムの伝達にプログラム要素は含まれない

2017/07/03(月) 23:59:24.25

>>678
現実的な時間で終わるかどうかの見極めはコード弄ってればすぐにわかるよ
むしろコード弄らずにドキュメントベースで話を進めると簡単だと思ったら実は思ったより時間かかりました～なんてことになる
悲しいけど世の中そんなプロジェクトで溢れかえってるのが事実なんだ

2017/07/04(火) 00:00:45.70

>>679
COBOLの設計書ってコード設計という名のコーディングシートを除けばわりと宣言的だぞ
関数型に近い

2017/07/04(火) 00:00:55.20

>>680
断言するけどそんな設計書はありません
就職すればわかるからそのあと出直してきな

2017/07/04(火) 00:03:06.32

>>682
それを外したからリファクタリングなんて名前の設計ミスの修正をやってるように見えるんだが?

2017/07/04(火) 00:10:19.18

>>681
概要を素早く把握するには設計書はちょうどいい文書だと思う
しかし概要を超えた明細はコードで語るべきだ
コードを直す前に必ず設計書修正しろなんてパラノイア的なやり方は負担を増やすだけで利益は少ない
コスト意識のない完璧主義者に付き合わされるのは苦痛だ

2017/07/04(火) 00:14:55.81

>>683
そうなのか
うちのCOBOL経験者はJavaのようなOOP言語でもコテコテの手続き的な設計書を書くよ
まあ人によるってことだろうね

2017/07/04(火) 00:16:28.89

>>686
テストレビュー完了毎にメンテナンスするって意味がうまく伝えられなくてすまん
修正毎とか時間と人件費の無駄、やってらんねーっすよってこと

俺にとっての設計書ってのはほぼテスト仕様書
詳細設計＝単体テスト
概要設計＝結合テスト
要件設計＝統合テスト

2017/07/04(火) 00:21:53.60

>>685
どんなに慎重にやっても設計ミスは出る
そもそも仕様そのものが業務の変化に依存している以上不変ではない
完全な設計書などこの世界には存在しない
設計書の間違いを検証する手段がないので設計書には間違いがないと勘違いする人が居る
設計ミスではなくともリファクタリングを行うことが多々ある

2017/07/04(火) 00:24:42.89

>>686
いやーさすがにテキストボックスが右詰めか左詰めかとかまで書かせるのはキチガイだと思うけど
全体の大まかな構造までしけちゃってるのを見ると流石に見逃せねぇ
ってところじゃん?
しかもそこからの対応もパズルとか言って用は動くまでブラウン管テレビぶん殴ってるババアと大差ねぇなと
これはねぇキミ、プロのやるこっちゃないよ

2017/07/04(火) 00:27:36.58

プロがこんなところでしょうもない揚げ足取りの議論なんかするかw
ばっかじゃねえのほんっと

**625** (ﾜｯﾁｮｲ 2e96-naxa) · 2017/07/04(火) 01:07:42.92

色々考えましたが、解決法が見つかりませんでした。
どなたか、何か良い案は有りませんかね？

2017/07/04(火) 01:17:30.16

エクスプローラーっぽいアプリを自作した方が楽だと思う。
メモ帳にしたって、アプリにテキストボックス埋め込んで表示すれば足りそうだし。

2017/07/04(火) 01:28:43.92

>>692
エロ動画を見ればいいんじゃん?
大半のエロ画像なんてゴミになるよ

2017/07/04(火) 02:03:27.54

nameofって短縮系の名前しか得られないの？
名前空間とかそのまま欲しいな

2017/07/04(火) 04:20:45.13

伸びてる時は

2017/07/04(火) 07:32:18.26

動的にはtypeof(...).Namespaceやらで取れるからそれで十分って判断じゃね
文字列で完全限定名が取れて嬉しいケースってあんまり思いつかん
属性で型名を指定するのはコンパイル時に型を参照できないからなわけでそこでnameofは使えないし

2017/07/04(火) 07:44:04.75

>>690
故障したテレビを外から眺めながら中身のことを妄想して原因はあーでもないこーでもないと議論するのが設計書文化

とりあえず安全確保はしておいてから、テレビを分解して内部構造を調べ、故障原因を理解し、原因を取り除いたり、より良い構造になるように努力するのがコーディング文化

どちらが有意義な仕事をして居るかは一目瞭然だね

2017/07/04(火) 08:55:00.74

>>698
でも仕組みわかってないんだろ？
触んなよｗ

2017/07/04(火) 10:52:33.77

>>698
技術力とちゃんとした設計書があれば、妄想じゃなくて起こりうる原因を挙げれるわけだが
妄想レベルの設計書しか書けないから有意義な仕事が出来ないんじゃない

2017/07/04(火) 19:27:22.44

C言語やC++やJavaを学んできたけど、C#が一番難しいです
こういう方居ますか？
また言語の難易度はどのようなものなのでしょうか

2017/07/04(火) 19:30:26.44

>>701
どういうところが難しいと感じますか？

2017/07/04(火) 19:31:23.02

むしろC++の何を知ってるのか聞いてみたい

2017/07/04(火) 19:32:43.87

>>702
競技プログラミングをC#でやりたいんですけど、C++と比べて難しいです…
難しいと思うのは、一番は全体像が多すぎて掴めないです

2017/07/04(火) 19:35:23.49

>>704
競技プログラミングなら、C++でいいんじゃ……

2017/07/04(火) 19:41:30.05

全体像が多すぎて掴めないってなにさ。競技プログラミング向きではないとおもうが。

2017/07/04(火) 19:42:09.30

>>703
昔はゲーム作ってました
今はunityでゲーム作ろうと思ってるんですけど、他のこともやってみようかな？って感じです
>>705
C#で書いてた人がかっこいいと思ったので…

2017/07/04(火) 19:47:44.39

>>706
自分でもわからないです
まだ触り始めたばっかだから色々作ることにします…

2017/07/04(火) 21:21:54.56

難しいと感じるところもあるかもしれないけど
いいところもいっぱいあるでしょ？

もうプロパティがない言語触りたくない

2017/07/04(火) 22:05:02.40

>>709
良いところもあるけど、色々作って試行錯誤します

2017/07/04(火) 22:05:31.08

>>709
プロパティは確かに便利ですね

2017/07/04(火) 22:09:38.11

慣れてくるとあんまりプロパティ作らなくなるけどね
C#初心者はWinFormsとかの「お客さん向け」設計を真似してプロパティを大量に作りがち
次第に整合性を重視するようになると自然にプロパティは減っていく

2017/07/04(火) 22:20:04.96

自然にプロパティが減ってく人でも皆無にはならない程度には便利だということ

2017/07/04(火) 22:22:09.64

>>712
良く分からん。
整合性を重視するってどういうこと。

2017/07/04(火) 22:27:37.54

お客さん向け設計ってのもわかるようなわからんような。

2017/07/04(火) 22:37:51.95

自分だけが気づいた何かがあると思いたいお年頃なんでしょう
ネットde真実の一種だねw

2017/07/04(火) 23:06:36.69

>>707
たまに競技プログラミングやるけど、スラスラC++書ける人格好良いと思うなぁ。

格好良さはさておき、C#で難しいとこってなんだろ？　デリゲート型とか？

2017/07/04(火) 23:22:54.20

>>714-715
プロパティを正しく公開するのって結構大変なんだよ
内部で生じた一時的な変な状態を外に見せないようにしたり、
常にプロパティの値が外から書き換えられることを考慮する必要があったり
不特定多数の人に便利に使ってもらうためのクラスならそこに手間をかける価値はあるけど、我々が作るクラスのほとんどはそうではない

2017/07/04(火) 23:28:02.70

プロパティを使わない（フィールド直公開？メソッド？）ことで問題が回避されるんじゃなければ
何言ってるのか意味不明だね

2017/07/04(火) 23:28:07.57

公開されてるからいつでも触っていいのかと思ったら
initの前だけかよって?

2017/07/04(火) 23:29:50.21

なんの注意書きもないから1ミリ秒単位で更新してたら死にやがったよコイツ的な?

2017/07/04(火) 23:32:37.20

update()するたびに使用メモリが増えて行くのは仕様ですか?

2017/07/04(火) 23:32:49.21

>>719
プロパティに限らず、余計なメンバを公開しないほうが楽だと言ってるだけだよ

2017/07/04(火) 23:34:22.56

アンカ付けたんなら「お客さん向け設計」の説明もしてくれよ。

2017/07/04(火) 23:36:17.05

>>723
語るに落ちてるじゃんw

要するに、それは上手にカプセル化して安全で使いやすいブラックボックスを作りましょうってことであって、
プロパティに限った話じゃない

2017/07/04(火) 23:37:40.88

お客さんは開発者だろ?
マイクロソフトが開発者向けに用意したコントロールと
うちらが仕事で仕様を満たすために作るものとは手間やクオリティが全然違うってことだろ

2017/07/04(火) 23:39:13.52

>>725
その通り。
特にプロパティは初心者が不必要に公開してしまう傾向がある、ということね

2017/07/04(火) 23:40:18.13

じゃあ誰かに公開して誰かに使わせる予定あるのかよ?
って言ったらほとんどないんじゃん?的な?
感じで代弁してみた

2017/07/04(火) 23:54:47.56

>>725
そんな傾向あるかね？
自動プロパティ限定の話ならわかる気もするけど

2017/07/04(火) 23:55:16.97

そういう話なら、初心者は何でもpublicにしがちだけど慣れてくると
適切なアクセス修飾子を使うようになる、とか言わなきゃ。

でもこれってそんな気張って言うような話じゃなくて、初歩の初歩の話だよねw

2017/07/04(火) 23:56:43.86

安価みすってた>>727ね

2017/07/05(水) 00:01:10.61

整合性を重視って妙な言い回しするから何かと思ったら…

2017/07/05(水) 00:40:08.75

初心者スレだよ

2017/07/05(水) 12:46:25.76

初心者が質問するスレな
初心者がプロパティガーって知ったかするスレじゃない

2017/07/05(水) 17:00:46.07

https://youtu.be/3MBQtuK2nZ8
これやってるんですけど乱数入れると2行目のレベルの数字がバグってしまいます
原因が全くわかりません
助けてください