1 名前:デフォルトの名無しさん [2019/12/11(水) 22:12:11.28 ID:d09CciDz0.net] !extend:checked:vvvvv:1000:512 次スレを立てる時は↑を2行冒頭に書くこと(1行分は消えて表示されない為) 「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。 他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、 ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。 内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。 なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。 C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください >>980 を踏んだ人は新スレを建てて下さい。>>980 が無理な場合、話し合って新スレを建てる人を決めて下さい。 ■前スレ ふらっと C#,C♯,C#(初心者用) Part145 https://mevius.5ch.net/test/read.cgi/tech/1570446977/ ■関連スレ C#, C♯, C#相談室 Part95 https://mevius.5ch.net/test/read.cgi/tech/1508168482/ ■コードを貼る場合は↓を使いましょう。 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/index https://docs.microsoft.com/en-us/dotnet/standard/class-libraries referencesource.microsoft.com/ ・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
2 名前:デフォルトの名無しさん [2019/12/11(水) 22:32:15.34 ID:mMKqVbip0.net] C#
3 名前:デフォルトの名無しさん (ワイーワ2 FFfa-uKDx) [2019/12/12(Thu) 09:41:18 ID:a67Hqgb2F.net] O2
4 名前:デフォルトの名無しさん [2019/12/12(木) 14:29:42.64 ID:56xY8w560.net] ひらがな文字列をヘボン式ローマ字に変換するプログラム作りたいのですが やっぱ正攻法でswitch-caseで123個くらい分岐させますか? でも長音や促音の例外処理とか難しそうだなあ・・・
5 名前:デフォルトの名無しさん [2019/12/12(木) 14:47:29.26 ID:b3wcvAqBF.net] 変換テーブルと検索
6 名前:デフォルトの名無しさん mailto:sage [2019/12/12(木) 17:38:52.89 ID:OYDho7HG0.net] UNIXのShellのソースでコマンドを切り分ける場所では思いっきりswitch文の嵐だったな 1文字目でまず切り分けで、次にに文字目ってな具合で 速度なら圧倒的にswitch分だと思うが、作りやすかったり保守が簡単なのはDictionary使ったパターンだと思う
7 名前:デフォルトの名無しさん mailto:sage [2019/12/12(木) 17:42:49.22 ID:NIaj3T140.net] 要素数が多くなれば多くなる程switch文よりDictionaryの方が速度的にも早くなるのでは?
8 名前:デフォルトの名無しさん mailto:sage [2019/12/12(木) 17:52:34.02 ID:VQC2yHD50.net] つ libstree
9 名前:デフォルトの名無しさん mailto:sage [2019/12/12(木) 18:32:36.61 ID:Ijd1d2r8M.net] >>7 C#コンパイラは多数の分岐先を持つswitchの場合には二分探索を行うコードを生成したりする 基本的に人間が最適化するより速い
10 名前:デフォルトの名無しさん [2019/12/12(木) 19:09:09.93 ID:56xY8w560.net] >>4 です ありがとうございます switchでコツウコツやることにします 要素の数え漏れでもっと増えそうだし 例外を拾う処理も考えなきゃww
11 名前:デフォルトの名無しさん mailto:sage [2019/12/12(木) 19:47:35.25 ID:XSG0K+ND0.net] vs2017ExpressでC#のフォームを使ってSQLiteのデータをDataGridViewに表示させたいです セキュリティの関係でSystem.data.SQLiteを使うには申請が必要でMicrosoft.data.SQLiteを使っています SQLiteをデータソース欄に追加する方法を教えてもらえないでしょうか?
12 名前:デフォルトの名無しさん mailto:sage [2019/12/12(木) 21:16:54.09 ID:XSG0K+ND0.net] ソース貼り忘れました https://dotnetfiddle.net/DXwCTe よろしくお願いします
13 名前:デフォルトの名無しさん [2019/12/13(金) 10:16:06.63 ID:V90d9jYdF.net] いくら払えますか
14 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 11:41:55.37 ID:D/hLKfPDd.net] >>13 自宅でSystem.data.SQLiteをインストールして同じコードを書いたらデータベースに接続出来ました 恐らくSQLiteConnection等の参照が足りずにエラーなっていると思いますが、解決策が思い浮かばなかったのでSQL Serverを使って試したいと思います 申し訳ありません
15 名前:デフォルトの名無しさん [2019/12/13(金) 12:10:09.33 ID:SSw9bcJtd.net] Microsoft Visual Studio International Feature Pack を使うんだ! KanaConversion クラスだったかに RomajiToHiragana メソッドがあったと思う
16 名前:デフォルトの名無しさん [2019/12/13(金) 17:23:20.97 ID:f86+e1mZM.net] >>10 亀レスで申し訳ないが、正規表現と Dictionary と LINQ を使えば 5 行くらいで書けるよ。 var kana = “あ|い|う|え|お|か|き|く|け|こ”; var roman = “A|I|U|E|O|Ka|Ki|Ku|Ke|Ko”; var dic = kana.Split(‘|’).Zip(roman.Split(‘|’), (l, r) => new { Key = l, Value = r}).ToDictionary( x => x.Key, x => x.Value ); Console.WriteLine(Regex.Replace(original_string, $”({kana})”, match => dic[match.Value]));
17 名前:デフォルトの名無しさん [2019/12/13(金) 17:33:03.63 ID:f86+e1mZM.net] あとは 50 音を全パターン書いてね。 ただし注意点があって、長いワードは短いワードよりも (例えば「ちょ」は「ち」よりも) 先に並べるんだ。 そうしないと短いワードが先に部分マッチしてしまう。
18 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 17:47:39.93 ID:s9cNxHbdd.net] テーブル作る前提なら始めからdictionary作ればよくね?
19 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 17:49:41.61 ID:s9cNxHbdd.net] 一文字ずつ正規表現でマッチしてたらとんでもなく時間食いそうだな 姓名の変換くらいならどうとでもなるだろうけど
20 名前:デフォルトの名無しさん [2019/12/13(金) 18:16:48.88 ID:RrhzxBUdM.net] >>18 作っているのはテーブルだけではないし、このように書くとスッキリ書ける。 >>19 処理の重さの本質はワード比較による分岐であって、switch 分岐もそれに引きずられるから、C# で比較するならどちらも大差ないと思う。 正規表現の方が、むしろ、最適化がかかることに期待できる。
21 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 18:33:49.64 ID:KAf60mjk0.net] まったくスッキリしてない 圧倒的にswitchが早い
22 名前:デフォルトの名無しさん [2019/12/13(金) 18:44:01.44 ID:8Ub64SZCM.net] >21 それは感情論だな。計時してみてくれよ。 Perl, JavaScript, Java, C# で正規表現を使うこと 30 年弱になるけど、パターンの複雑さによらず、正規表現が目に見えて遅いということはなかったな。 アセンブラでゴリゴリに最適化したものと比べたら遅いだろうが、同じ言語のユーザー定義関数より目に見えて遅いことはまあないと思うよ。
23 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 18:48:06.09 ID:04gYwNVod.net] これならDictionary作るわ
24 名前:デフォルトの名無しさん [2019/12/13(金) 18:51:56.74 ID:8Ub64SZCM.net] >>23 何か勘違いしてないか? こっちも Dictionary つくっているが。
25 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 19:49:57.23 ID:KAf60mjk0.net] 2文字置換を考慮したらスッキリは書けなかった すまんこ こんなクソみたいなコードでもregexよりは数倍早い https://ideone.com/c7ILX4 頭良い人がもっとスッキリしたコード書いてくれそう 長文のほうがreplaceは不利だろうから数千文字にしたけどそれでも余裕 速度気にしないならregexで良いと思う
26 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 19:58:53.60 ID:KAf60mjk0.net] 最終文字が2文字置換対象じゃないときにsubstringで範囲外例外出るわ 条件1個追加しといて
27 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 20:57:05.81 ID:9t702OJgd.net] 小さい「っ」が未対応なことに気付いた これ正規表現でもめんどいね 正規表現ならっを無視してreplaceした後に1個ずつ置換かなぁ
28 名前:デフォルトの名無しさん [2019/12/13(金) 21:07:14.03 ID:M1n71JyZ0.net] 多少簡略化したロジックで計測してみた。 マッチ文字列が 1 文字固定なら、ユーザー定義関数の方が正規表現より 8 倍速かったが、1 〜 2 文字可変なら所要時間は同じ。 パターンマッチの文字列長が可変・複雑になるとそれをハンドルするための分岐が増えるせいでユーザー定義関数は遅くなる。 もちろん置換をかけるオリジナル文字列の文字出現パターン&確率にもよる。 チューニングするなら C やアセンブラで書くべきだし、C# で書くなら正規表現で簡潔に書けるほうがよいのでは?
29 名前:デフォルトの名無しさん [2019/12/13(金) 21:12:22.88 ID:M1n71JyZ0.net] >>27 おもしろいところに気づいたね。 例えば仮文字 $ とかに変換しておいて、最後に直後の子音字に変換。 ちゃっと => cha $ to => cha t to
30 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 21:22:02.14 ID:VulPdUq80.net] どうあがいてもregexは遅くないという結論にしたいみたいだけど string単体で見ても遅いのにregexが遅くないわけがない 簡潔に書くならregexがスマートなパターンが多いのは分かってるよw 処理速度求められるパーサーなんかではまずregexなんか使わない 遅いと言っても数万文字の処理が何万回も必要とかでなければ気にするようなレベルではないので問題ないなら素直にregex使ったほうが良いよ 25ですでにそう言ってるしね
31 名前:デフォルトの名無しさん [2019/12/13(金) 21:26:23.93 ID:M1n71JyZ0.net] あるいはワンショットで置換するなら、下記のようなパターンを使って後方参照し、第1マッチ文字列が空でないなら、第2マッチ文字列の置換先の1文字目に置換するとか。 (っ?)(あ|い|う|え|お|か|き|く|け|こ)
32 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 21:26:56.26 ID:yXJ+I/RUa.net] 「ンョ゛ハー ゛」みたいなのが来た時の対応とか考え出すと仕様肥大化するだろうなあ ひらがなカタカナ両対応とか、半角カナとか、 長音の代わりにハイフン使いだした場合とか 「ヴァッソ」とか テストパターン考えるのも厄介そうだね
33 名前:デフォルトの名無しさん [2019/12/13(金) 21:30:11.16 ID:0IHjBlJG0.net] LALRを受理するジェネレータ書いたことがあるんだけど、状態表の大きさは字句解析のほうが遥かに大きくなるのが普通みたいですよ。 字句解析と構文解析は一つの表にまとめられるのに、なぜ分けるのかというのが最初の疑問だけど、なぜか答えが載ってる本が無い。 実際にやってみると表の大きさが爆発的に大きくなるからでした。 状態機械は分けられる箇所があるなら積極的に分けたほうが効率的になるようです。
34 名前:デフォルトの名無しさん [2019/12/13(金) 21:30:12.87 ID:M1n71JyZ0.net] >>30 文字列操作だからもちろん絶対的には遅いよ。 C# で書いたユーザー定義関数と比べたときに正規表現が相対的にそんなに不利かといったらそうではないだろうという予想を立てただけで。実際測ったら同等だったわけだけど。
35 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 21:30:26.83 ID:7oWhly6q0.net] 日経だったか「むかっっ」という促音が 重なる文章というか記事があったな
36 名前:デフォルトの名無しさん [2019/12/13(金) 21:33:36.65 ID:0IHjBlJG0.net] 字句解析におけるNFA対DFAというのも最初に気になる部分です。 結論から言うと、NFAの選択は十分に考慮できるはずです。 僕も最初はDFAにこだわっていました。 でも、字句解析は表が大きくなりがちです。 特にregex並みの便利機能を組み込もうとすると、とても大きくなります。 たいていはNFAで十分かと思います。
37 名前:デフォルトの名無しさん [2019/12/13(金) 21:37:02.69 ID:0IHjBlJG0.net] ちなみに、DFAにこだわる理由は、多くの本がDFAのほうが効率的と述べているからです。 みんなそうだと思います。 最悪のケースではその通りですし、最悪のケースを考慮するのはセキュリティにも関わります。 でも最悪のケースはめったになく、たいていはNFAで十分で、たいていは効率的だと思います。
38 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 21:39:05.74 ID:VulPdUq80.net] >>34 その同等だったっていうコード貼ってくれない? 25で貼ったコードで1文字2文字の比率変えてもregex側が常に3〜4倍くらい遅いんだよね 古い.NETだとsubstringが遅いとかあった気がするんだけどその影響じゃないよね?
39 名前:デフォルトの名無しさん [2019/12/13(金) 21:42:16.88 ID:M1n71JyZ0.net] >>38 コード書いてくれてたんだね。 25 があぼーんで読めない。。。
40 名前:デフォルトの名無しさん [2019/12/13(金) 21:42:32.85 ID:f+S2ArPq0.net] >>4 でーす >>16 以降、何書いてるのかサッパリ分かりません! なんせまだifとforとswitchと文字列操作のメソッドくらいしか知らないもんでww 半年くらい後に読みに来まーす
41 名前:デフォルトの名無しさん [2019/12/13(金) 21:51:25.19 ID:M1n71JyZ0.net] >>38 コードは長すぎて多分アップできないと思う。 やっていることは switch 式を2 文字マッチの場合と 1 文字マッチの場合で 2 種類つくり、残文字列が 2 文字以上あるなら前者にかける (破棄パターン _ => で後者を呼び出す)、1文字なら後者にかけ、インデックスを進めるだけ。 置換後文字列の連結には StringBuilder 使っているし、メソッド呼び出しは AggressiveInlining している。ユーザー定義関数を意図的に遅くするようなことはしていない。 1文字あるいは2文字の切り出しに Substring 使っているけど、それが遅いのかな?
42 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 21:52:27.04 ID:yXJ+I/RUa.net] ローマ字変換でばっとググってみた お勉強用ならJavaScriptで書かれてるこれを理解しながらC#に移植するのがよさそうかな ソースコードも簡潔だし悪くなさそう https://www.pandanoir.info/entry/2016/03/29/190000 とにかく動けばいいというならMicrosoftが配ってるらしい「Japanese Kana Conversion Library」?でもこんなの使ったことないや
43 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 22:00:14.44 ID:+9OE4qBy0.net] ンボマはmboma ンバッペはmbappe だからね 練習用なんだろうけど 簡単に見えても文字変換を自力でやるのはかなり面倒くさい
44 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 22:10:51.66 ID:+9OE4qBy0.net] 正規表現のほうが単純文字列比較より遅いのは当たり前 1文字比較の場合に単純比較と同等になるような 最適化が施されてるエンジン積んでれば数倍とかの差はつかない 少し古いバージョンのブラウザのJSのなら平気で10倍近い差が出てた でもその差がUXに影響を与えるようなユースケースはそう多くはない ちなみにstringのswitch caseは数が増えると .NET Core以前は内部的にDictionary使うみたいよ .NET Coreもhash比較するのは同じだけどDictionaryをアロケートしない方法にしてるらしい
45 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 22:12:49.12 ID:VulPdUq80.net] >>39 これで見えるかね ttps://ideone.com/c7ILX4 このコードはswitchじゃなくDictionaryでやった おそらくswitchのほうがこれより早くなるか最適化で同程度になるはず switch版までは作るのめんどい 配列の境界値チェックも遅い要因なのでできるだけチェックが発生しないのが望ましい このコードでは2文字変換したときに境界値チェックが入ってしまうので2文字変換比率が高いと性能が悪くなる 2文字変換ばかりにしてもregexよりは早い
46 名前:デフォルトの名無しさん [2019/12/13(金) 22:38:36.62 ID:M1n71JyZ0.net] >>45 ありがとう。週末に評価してみる。 switch より Dictionary の方が処理性能がぶれない気がする。ハッシュで検索がワンショットに決まるから。switch は if カスケードを通ることで前スレで議論したパイプライン処理の影響を受けるため、処理速度がデータに強く依存する。 そんなわけでこの件の性能はコードの書き方 (チューニング含む)、データ、環境にかなり依存すると思う。 これは価値観の問題なのでみなが同じように考えるとは思わないが、正規表現で 3 - 4 倍程度の性能悪化なら、ユーザー定義関数よりチューニングより正規表現を私は採用する。 10 倍の悪化なら用途によっては考える。(パターンが複雑・多岐の場合) 正規表現は開発効率と保守性が 10 倍よいと思うので。
47 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 22:59:26.50 ID:x4Cvv/aS0.net] >>46 switchとdicの関連は44が説明してくれてる 最適化次第でいい感じにしてくれるはずだからどっちもたいさない感じになると思う 個人的には性能差が10倍だろうが1000倍だろうが許容できるケースなら可読性を取る 今どき文字→数値変換でc-'0'なんて書かずに大体int.Parse使うのと同じ UIに入力された氏名のローマ字変換みたいな1ユーザー1回で済むような処理に速度なんて無意味 GB単位のログデータをいじるなら数倍の差でも考慮すべき なんなら入力データの傾向に応じてチューニングしやすい単純処理のほうが更に高性能にしやすい
48 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 23:21:38.26 ID:Lnvxq+5t0.net] 俺なら、ひらがな小文字の変換は、変換元「ちゃ」とか「ぱっ」のパターンを文字数降順で優先的に置き換えるかな。 配列で変換パターンを保持して、それにない文字パターンは先頭から徐々に削っていく。 それなら「ぱ」と「は゜」なんかも判りやすく対応できると思うよ。
49 名前:デフォルトの名無しさん [2019/12/13(金) 23:36:31.48 ID:M1n71JyZ0.net] >>44 , 45, 47 みんな有益な考察をしてくれるのでありがたい。感謝。 今まで正規表現が際立って遅いと体感することなかったけど、利用目的を想定した評価をきちんとしたことなかったので一連の議論はとても参考になりました。
50 名前:デフォルトの名無しさん mailto:sage [2019/12/13(金) 23:57:37.29 ID:+9OE4qBy0.net] オリジナルの文字列を1文字ずらしでzipして 2文字ずつ取得するイテレータでやるのがいいかなとか思ってたが 多少非効率でも↓ここの実装みたいに繰り返し変換していく方が 条件分岐が少なくて読みやすいかも https://tools.m-bsys.com/original_tooles/romaji.php https://tools.m-bsys.com/js/romaji.js function hebonG(s) { s = s.replace(/ん([aiueoy])/g, "n$1"); s = s.replace(/ん/g, "n"); s = s.replace(/n([bpm])/g, "m$1"); … var hebonGMap = { "kuぁ": "kua", "kuぃ": "kui", "kuぇ": "kue", "kuぉ": "kuo", … } … s = s.replace(/っch/g, "tch"); s = s.replace(/っ([kstnhmyrwgzdbp])/g, "$1$1");
51 名前:デフォルトの名無しさん mailto:sage [2019/12/14(土) 11:11:39.02 ID:8NRAnTxB0.net] >>49 正規表現が遅いのは、コンパイルだろ 実行時ではなく、初期化時にコンパイルするようにと、Go の本には書いてある
52 名前:デフォルトの名無しさん mailto:sage [2019/12/14(土) 11:24:37.56 ID:8NRAnTxB0.net] >>4 Ruby では、条件分岐しなくても、変換用の辞書で書ける >>16 も、これに似ている hash = { 'ab' => 'あ', 'xy' => 'ん' } p re = Regexp.union( hash.keys ) #=> /ab|xy/ p "9xy9ab9xyx".gsub( re, hash ) #=> 9ん9あ9んx
53 名前:デフォルトの名無しさん [2019/12/14(土) 16:02:25.78 ID:BZ704rid0.net] >>51 まあね。ただ、C# の Match Evaluator 付き Regex.Replace は事前コンパイルできないと思う。 ちなみにあの後何度か測り直したのだが、switch より事前コンパイルなし正規表現は 2 倍遅かった。同等ではなかった、すまん。 45 によると Dictionary & ユーザー定義文字列操作は正規表現より 3-4 倍良かったそうだから、今回のケースでは Dictionary : switch : 事前コンパイルなし正規表現 = 3-4 : 2 : 1 くらいの性能比かと考えられる。 switch はカスケードがさらに増えると内部で Dictionary 化して最適化されるから、一般論としては 正規表現は事前コンパイルすれば switch に肉薄する、あるいは、多少超えるかもしれないが switch に Dictionary 最適化がかかったらまた離されるかもって感じではないかと。 >>52 ありがとう。Match Evaluator 正規表現でハッシュ置換するのはもう四半世紀も使っているテクだけど他で見たことなかったから、Ruby の例は参考になる。
54 名前:デフォルトの名無しさん mailto:sage [2019/12/15(日) 00:27:58.57 ID:x+hGNtUDa.net] このスレにいる人たちで C#を日本語で記述ってのを実際にやってる人、どれくらいいるかな https://togetter.com/li/1441951 を読んで試してみてもいいかなと思ったんだけど VisualStudioのコード補完が利く環境ならIME切替の手間もさほどかからない気もするし 何か致命的なデメリットとかあるんだろうか
55 名前:デフォルトの名無しさん [2019/12/15(日) 02:49:23.51 ID:SZPXyEbKa.net] >>54 ほとんどいないのでは?w デメリットはインテリセンスとの相性の悪さに尽きるね。 どうでもいいけど「C#を日本語で記述」の是非というより識別子に日本語を使うことの是非だよね 論より証拠、やってみたらいかに非合理な試みか分かると思うよ
56 名前:デフォルトの名無しさん (ワッチョイ e22c-3siJ) mailto:sage [2019/12/15(日) 05:39:16 ID:fpSJINfx0.net] Ruby では、RSpec(BDD)のユニットテストで、 日本語の関数名を付ける人はいるけど まあ、テストだからね
57 名前:デフォルトの名無しさん (ワッチョイ 62ad-zBV4) mailto:sage [2019/12/15(日) 05:45:38 ID:cmnyuAvp0.net] テストのメソッド名とかなら使っちゃうかな
58 名前:デフォルトの名無しさん (ワッチョイ e242-xO71) mailto:sage [2019/12/15(日) 06:17:17 ID:6XATZvNs0.net] enumの要素で使うと便利 どうせ数はないからインテリセンスも問題なし
59 名前:デフォルトの名無しさん mailto:sage [2019/12/15(日) 13:41:49.81 ID:TLgol4W/0.net] >>54 補完のために半角英数+日本語が便利 これなら最初だけだしIME切り替えは
60 名前:デフォルトの名無しさん mailto:sage [2019/12/15(日) 14:56:15.21 ID:pFDibfNW0.net] 補完はomnisharp + migemoで解決できる 他言語で変数名に日本語使うのはよくやってるけど扱う対象の用語が固まってる場合は便利 そうじゃない場合は結構厳格に命名ルールを決めないと逆にわかりにくくなったりする
61 名前:デフォルトの名無しさん [2019/12/15(日) 16:18:24.21 ID:QBANyAHK0.net] 俺が英語ができなかったり、デザインパターンの理解が足りなかったりするせいだとは思うけどさ どうしてもファイル名=ネームスペース名=クラス名=主なメソッド名になりがちなんだわ 単一責任の原則に合わせた時、ファイル名〜メソッド名まで決める簡単な基準とかあったら教えて欲しいな
62 名前:デフォルトの名無しさん [2019/12/15(日) 16:21:28.32 ID:NIombkpjF.net] Javaやりすぎると後遺症でそうなることがあるな
63 名前:デフォルトの名無しさん mailto:sage [2019/12/15(日) 16:49:35.38 ID:pFDibfNW0.net] ファイル名=publicクラス名.csは一般的 ネームスペース名はそのクラスが属するレイヤーとかコンポーネントの名前 アーキテクチャが整理されてればあんまり迷わないと思う クラス名=主なメソッド名は状況による FormatterクラスにFormatメソッドがあるのは自然 Utilitiies > Formatter > Format
64 名前:デフォルトの名無しさん mailto:sage [2019/12/15(日) 17:58:43.69 ID:LwtoOKkQd.net] 日本語を使った感想 メリット 名称に悩まない(重要) 比較的読みやすい デメリット インテリセンスと相性が悪い imeの切り替えが面倒 大文字小文字がないから名称が被りやすい システムハンガリアン推奨 他にも何かあった気がする
65 名前:デフォルトの名無しさん [2019/12/15(日) 18:23:34.11 ID:yHa/r3w4a.net] プロパティーやフィールドはいいけど、メソッドやイベントの名前は馬鹿っぽくはなるねw
66 名前:デフォルトの名無しさん mailto:sage [2019/12/15(日) 18:24:56.51 ID:ltDbPg3S0.net] プロパティはいいとしてメソッドは動詞(+名詞)の形にするの 日本語だと不自然だけどどうしてるのかな
67 名前:デフォルトの名無しさん mailto:sage [2019/12/15(日) 18:30:01.27 ID:cmnyuAvp0.net] >>58 中点使ってるせいでC#6.0対応時にエラー吐いたプロジェクトあったわ
68 名前:デフォルトの名無しさん mailto:sage [2019/12/15(日) 18:49:58.62 ID:yNhbn0Xna.net] >>54 DBテーブル名/カラム名が日本語名のWindows業務システムで、 Entityクラスや画面コントロールの命名をDBそのまんまの日本語にしたら ソースが滅茶苦茶読みやすくとても良い感じになった 以後、積極的に日本語で命名するようにしてる 自分の書き方だと、 日本語を使うのは画面項目や業務用語の名詞のみ、動詞は英語 英語とチャンポンして Update利用情報()、Is有効期限内 みたいなメソッド/ブロパティをよく作る ローカル変数はiとかsとかtとか適当なプレフィクスをつけて無理やりcamelにする フィールドは_始まり とかかな 日本語で書くコメントが大幅に減らせてメリット大だと思う デメリットは…C#関係ないけど postgresだとテーブル名が日本語だとテーブルエクスポートが出来なくて不便、 多分ASP.NETみたいなWebシステムだと日本語名を使うのはリスク高い、 とか
69 名前:デフォルトの名無しさん mailto:sage [2019/12/15(日) 20:10:28.99 ID:KTmzWILYa.net] 訳のわからん不具合踏みそう 日本語使ってると
70 名前:デフォルトの名無しさん [2019/12/15(日) 21:16:07.17 ID:eTsOryw+0.net] Listについて質問なのですが BindingList<T>にはToList()では代入できないのでしょうか? LINQの結果をToListで代入しようと思ってたのですが 型が違うとか出るんです(自作クラスによるListです) 普通のList<T>へならできるのでBindingList固有の問題かと思います 仕方なくforeachで一つずつ代入して一応目的は達成してるんですが LINQでforeach使わず抽出しておきながら 最後に代入でforeach使うのはバカらしいなあ・・・と思いまして どうすれば直接LINQの結果をBindingListに入れられるのでしょう?
71 名前:デフォルトの名無しさん mailto:sage [2019/12/15(日) 21:26:38.59 ID:ltDbPg3S0.net] new BindingList<Hoge>(fuga.ToList())
72 名前:デフォルトの名無しさん [2019/12/15(日) 22:05:28.60 ID:eTsOryw+0.net] >>71 おお!何かわからんけど、できた 初期化したらキャストできるの? でもdataGridViewのDataSorceプロパティに入れてたのも外れるから もう一度入れ直さないといけないけど・・・
73 名前:デフォルトの名無しさん (ワッチョイ 57da-boqi) [2019/12/16(月) 05:42:00 ID:cXUrIyKd0.net] razor page のコーディングについてなんですが、 1ページのデータ量が多くなれば必然的にソースも長くなりますが、2000行とかになるとごちゃっとして「目に優しくない」ソースになっちゃいます。 目に優しいコーディング方法やら規約やら法則があれば教えてください。
74 名前:デフォルトの名無しさん mailto:sage [2019/12/16(月) 07:41:26.07 ID:v/vzDWBs0.net] >>73 1メソッド300行以内っていう社内ローカルルール
75 名前:デフォルトの名無しさん mailto:sage [2019/12/16(月) 15:28:44.50 ID:+KWK+mzK0.net] >>73 Partial ViewとかView Component使って分割する 再利用しなくても分割する 個人的には200行超えると黄色信号 >>74 1メソッド300行ってすごいな
76 名前:デフォルトの名無しさん mailto:sage [2019/12/16(月) 17:57:20.50 ID:I8DdFnIZ0.net] 200も300も大差無いような…
77 名前:デフォルトの名無しさん mailto:sage [2019/12/16(月) 20:05:28.74 ID:FR/i0CTk0.net] やっと会社の環境がvisualstudio2010から2019になったわ、これで非同期無双できるw
78 名前:デフォルトの名無しさん mailto:sage [2019/12/16(月) 20:08:09.24 ID:X2KrPzv7M.net] そんな環境で2019なんか入れて大丈夫か? アップデートで不具合引いてダウングレードさせられないように、不用意なアップデートはやめとけよ
79 名前:デフォルトの名無しさん mailto:sage [2019/12/16(月) 20:09:20.42 ID:J5g2Edewd.net] 2010とかサポート切れ直前やな
80 名前:デフォルトの名無しさん mailto:sage [2019/12/16(月) 21:08:24.24 ID:LIM2IbDka.net] 2010だとNuGetすら使えないんじゃ 54だけどレスありがとう>ALL 実践してる人もそこそこいるのね テーブルやカラムを日本語で命名できるのってAccessに限らないのか・・・・ 不具合の事例も知りたいけど、具体的に出てきたのは>>67 くらい? C#に閉じた範囲で使うぶんには大丈夫そうかな・・・・今度試してみるよ
81 名前:デフォルトの名無しさん mailto:sage [2019/12/16(月) 21:33:12.54 ID:+KWK+mzK0.net] >>76 viewの行数とメソッドの行数の違い
82 名前:デフォルトの名無しさん mailto:sage [2019/12/17(火) 09:59:27.04 ID:GVP8bqm50.net] >>80 全角ピリオドとか&とかヤバそうに思えるのは使わないのが無難 date前月末とか昔から使ってます 昔々のACCESSで一部の通常全角文字が使えないとかありましたが、今はもう大丈夫と思ってます 将来的にトラブル可能性はゼロではないとしても、可読性のメリットのほうが遥かに大きい 例えば「要介護認定等基準時間」みたいなのを英字変数にするとかアホにもほどがある
83 名前:ダーク王鍬大使 mailto:sage [2019/12/17(火) 18:03:06.99 ID:9VuoOKjt0.net] 質問でふ(^^ Unityのアセットとか覗いたりするとifは使われてまふよね(^^ Switchが使われているの見たことないんでふが(^^ あれって使っちゃいけないとかってあるんでふか?(^^ ボッキング!(^^
84 名前:デフォルトの名無しさん mailto:sage [2019/12/17(火) 18:30:01.62 ID:I793zFiP0.net] 最適化すると数行のswitch文はifに自動変換されるんじゃなかったっけ
85 名前:ダーク王鍬大使 mailto:sage [2019/12/17(火) 18:39:07.95 ID:9VuoOKjt0.net] そうだったんでふか(^^ 教えていただき感謝感謝のボッキング!(^^
86 名前:デフォルトの名無しさん mailto:sage [2019/12/17(火) 19:40:18.25 ID:vR4SZ06Rd.net] class Hoge{ int Id ICollection<Hoge> Hoges } ってクラスをEntityFramework使ってテーブルにしたんだけど無理だったりする? Hogeテーブル(Id)と、Gehoテーブル(id、HogeId、HogeId2)後ろ二つ外部キーみたいなイメージなんだけどこういうパターンが調べても出てこない
87 名前:デフォルトの名無しさん mailto:sage [2019/12/18(水) 15:34:43.72 ID:bmnVQ6Qnd.net] >>86 この構成じゃ出来ないことが分かったので質問を取り下げます
88 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 00:36:26.71 ID:TZyBuNxJS] APIでTokenを取得するため、以下のコードを書きましたが、デバッグすら出来ずに摘んでいます。 (ちなみにスクレイピングではなく、正式なAPIサービスです) 先輩方、アドバイスをいただけないでしょうか var parameters = new Dictionary<string, string>() { { "id", "user" }, { "pass", "password" }, }; const string method = "PUT"; const string endpoint = "https://apitest/v1"; const string path = "/token"; using (var request = new HttpRequestMessage(new HttpMethod(method), endpoint + path)) using (var content = new FormUrlEncodedContent(parameters)) { content.Headers.ContentType = new MediaTypeHeaderValue("application/json"); request.Content = content; ↓↓ここのresponseがみたいのですが、ステップインできない(プログラム '[12345] 〇〇.exe' はコード 0 (0x0) で終了しました。 var response = await HttpClient.SendAsync(request, HttpCompletionOption.ResponseHeadersRead); return await response.Content.ReadAsStringAsync(); }
89 名前:デフォルトの名無しさん (オイコラミネオ MMab-7F0B) mailto:sage [2019/12/19(Thu) 01:57:08 ID:Ty/KdhcjM.net] webview使ってブラウザ操作してるんですけど、相手がASP使ったサイトだとボタン押したりテキストボックスに文字入れたりって操作は無理ですかね?
90 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 12:09:36.23 ID:WCM9NoNV0.net] jsonファイルを読んで、木構造を編集して、jsonファイルに出力する ファイルの入出力はJson.NETを使用 この場合内部のデータ構造はどう持つのがいいでしょうか? Json.NETのJTokenを使うか、自作するか考えてますが、 標準的な手法は有りますか?
91 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 12:13:14.10 ID:+iaW+uMUM.net] ちゃんと型を付けてデシリアライズ→加工→シリアライズする 型を付けるまでもないアドホックな処理ならそもそもC#なんか使わずに他のスクリプト言語を使う
92 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 18:39:36.79 ID:IsJpyVgV0.net] 質問なのですが エンティクラスを配列に入れて使うようなことはできないでしょうか? 数が多いのでループでコードをすっきりさせたいです。 こんな感じなのを public class test() { using (var context = new MyContext(connection)) { var datalist1 = context.MyEntities1.ToList(); 〜 var datalist100 = context.MyEntities100.ToList(); } //以下 共通処理 } こんな感じで使いたい string[] MyEntitiesList = new string[100]; MyEntitiesList[0] = "MyEntities1"; MyEntitiesList[1] = "MyEntities2"; 〜 MyEntitiesList[99] = "MyEntities100"; for(var i =0;i<100;i++) { var datalist1 = context.MyEntitiesList[i].ToList(); }
93 名前:デフォルトの名無しさん [2019/12/19(木) 19:11:55.40 ID:aq+5Nz0cF.net] var datalist1 = 上書きで良いなら最後のだけ入れろ
94 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 19:54:28.09 ID:IsJpyVgV0.net] >>93 すまないよくわからないのでもう少し説明をお願いしたい >>92 こんな感じで使いたいを修正してみました。 string[] MyList = new string[100]; MyList[0] = "MyEntities1"; MyList[1] = "MyEntities2"; 〜 MyList[99] = "MyEntities100"; public class test(int i) { for(var i =0;i<100;i++) { using (var context = new MyContext(connection)) { var datalist1 = context.MyList[i].ToList(); //以下 共通処理 } } }
95 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 20:10:40.73 ID:AGyCFxKvM.net] >>94 92 は for ブロック内部の代入式の左辺が変わってないよ、というツッコミ。 やりたいことは、抽出対象プロパティをテキストで指定してシステマティックにデータ抽出したいってことでしょ? Dictionary やインデクサで、テキスト => 対象プロパティ or 抽出メソッド、のマップを作って、Reflection か何かで呼び出せばできそうな気がするけど、LINQ to Entities でワークするかどうかは試してみないとわからないな。
96 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 20:25:17.21 ID:qKbwpXVq0.net] >>94 有益な回答を得るためにもう少し説明が必要かも。 なぜ抽出対象プロパティをテキストで指定する必要があるの? 1 カラムごとに 100 回抽出しようとしているけど、まとめて 100 カラムをワンショットで抽出してから加工するのではなぜダメなの? また環境が EF6 なのか EF Core なのかも言及した方がいいかもね。
97 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 20:38:12.29 ID:qKbwpXVq0.net] ごめん、勘違いしていた。 テキストで指定したいのはカラムじゃなくてテーブルなんだね。
98 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 20:58:33.77 ID:IsJpyVgV0.net] そうですそうです。 データを取り出すところ以外はほぼ変わらないのに ↑のコードだけでも1テーブルの数が多い場合余裕で1万行超えてしまうので public bool test1() { } public bool test2() { } 〜〜〜〜 public bool test1000() { } と用意して test1(); test2(); 〜〜 test100(); を public bool test() { } for(var i =0;i<100;i++) { test( iLop ); } だけにできないかと思っています。
99 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 21:00:56.21 ID:IsJpyVgV0.net] >>96 環境はEF Core3.1 です。
100 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 21:11:26.20 ID:qKbwpXVq0.net] 抽出テーブルを動的に指定したいなら、DbSet<T> を返すプロパティが DbContext の派生クラスに定義されていると思います。 型引数 T にテキストは直接指定できないので、その DbSet<T> 型のプロパティをラップするメソッドを定義して、テキストを引数で渡してやればよいのではないでしょうか。こんな感じで。 class MyDbContext : DbContext { DbSet<MyEntityDataModel1> MyEntity1 { get; set; } DbSet<T> GetTable<T>(string table) where T : CommonBaseClassOfMyEntityDataModels => this.GetType().GetProperty(table) as IQueryable<T>; } // 呼び出し側 context.GetTable(“MyEntity1”).ToList();
101 名前:デフォルトの名無しさん mailto:sage [2019/12/19(木) 21:54:02.04 ID:qKbwpXVq0.net] >>98 そういう目的ならテーブル名をテキストで指定する必要もなくて、 foreach (var prop in context.GetProperties()) { var table = (prop as IQueryable<CommonBaseClass>).ToList(); // table に対するテスト処理 } でよいかもしれない。 ただし下準備として、DbContext の全プロパティのデータコンテナを共通で受ける基底クラス CommonBaseClass を定義する必要がある。 似たようなことはやったことあるのだけど、このコードが手直しなく動くかどうかはわからない。 テスト処理もラムダ式のリストで用意しておいて、各テーブルと Zip() して適用するなど、LINQ を活用するとよいと思うよ。