21/12/13 09:12:51.67 7pnzZ4JB0.net
>>945
条件式をネストしたり＆でつないだりと複雑にするのは難読性が高くなるから分けたほうがいいだろ
どういう条件ならMthod()を呼ぶのか明確に
if(Input){
//事前処理
judge=(A==null) ? true: //Aがnullのとき
A.Bool==false ? true: //Aの子要素がfalseのとき
false; //それ以外
if(judge) Method();
//共通処理
...
}
1005:デフォルトの名無しさん
21/12/13 09:51:11.81 g+jxvcxo0.net
>>960が分かりやすく見えない…
>>948が誰が見ても一目瞭然でいいと思うわ
シンプルな条件分岐なんだからこだわる必要ない
1006:デフォルトの名無しさん
21/12/13 11:44:51.75 zykNHKxZ0.net
skipするほうが例外的処理だろうからskip条件を明確にしてearly returnしたほうがいいと思う
論理式の細かい書き方よりも意図が伝わるかどうかのほうが大事
if (ShouldSkip(a)) {
return;
}
Method();
bool ShouldSkip(A a) {
return a?.Bool ?? false;
}
1007:デフォルトの名無しさん
21/12/13 14:01:49.98 z2L+bKXw0.net
メソッドにすんのはいいけど、>>945 が入力を検知したときメソッドを実行したいって言ってんだからその通りに書けばいい
設計書通りに条件分岐すりゃいいのに無駄に置き換えて実装する人多いけどなんなんだろうね
if(入力検知(input, A)){
Method();
}
bool 入力検知(bool input, A a){
return input && a != null && a.Bool;
}
1008:デフォルトの名無しさん
21/12/13 14:22:24.69 6wRfW5vFa.net
昼飯食いながら適当だから何か勘違いしてるかもしれないけど、>>945って要は
ある条件を満たした時だけMethodを実行したい、それだけでしょ？
だったら四の五の言わずに素直にそう書くのが一番じゃないの。
if( input && (!A?.Bool ?? false)) Method();
1009:デフォルトの名無しさん
21/12/13 14:29:51.31 KmNdaGVTa.net
求めてるのは「もっとスマートな書き方」だからな
主観的な問題だから、俺らが言えるのは「こういう書き方もある」ってのだけ
正解（どれが一番か）を決めれるのは本人だけ
1010:デフォルトの名無しさん
21/12/13 14:47:42.73 6wRfW5vFa.net
コードでも文章でも読み手に「要するにそれってどういうこと？」って思わせないのが一番。
これもコードでも文章でもそうだけど、読みにくいものは書いた本人がそこをよく理解せずに書いている。
1011:デフォルトの名無しさん
21/12/13 15:06:50.29 WUjUV8JM0.net
ReSharperが薦めるように書き換えたら、何をしてるのかわからなくなった。
1012:デフォルトの名無しさん
21/12/13 15:10:10.54 pxTkbBAYM.net
最近のc#はマルチパラダイムで構文が増えてカオスだ
1013:デフォルトの名無しさん
21/12/13 16:35:33.81 zykNHKxZ0.net
>>963,964
>>945を読む限りでは入力を検知する処理と
検知した後に特定の処理をスキップするかどうかを判断する処理は別じゃないのかな？
「A.Boolがtrueなら入力を検知しない(or 入力を無視する)」ってことなら
入力よりも先にA.Boolを確認するよね
1014:デフォルトの名無しさん
21/12/13 16:52:41.40 KmNdaGVTa.net
ちなみに回答ざっと見てこんなだな
こういうのはコードが長くなっても動作が分かりやすい方がいいと思う
>>947,948,960
おｋ
>>962,963
バグあり
1015:デフォルトの名無しさん
21/12/13 22:23:58.46 s0FccnDO0.net
>>968
それ。言語の表現力が豊かでも、自分やチームで一貫性を担保するのが面倒ξ
1016:デフォルトの名無しさん
21/12/14 09:16:58.78 cLXTODpXM.net
>>971
そして、コーディング規約が底辺プログラマーに合わせられて生産性が低下する
1017:デフォルトの名無しさん
21/12/14 20:46:07.43 4rMew3mV0.net
どうせ好き勝手に言語機能使って上がる生産性なんて微々たるもん
1018:デフォルトの名無しさん
21/12/14 23:18:34.83 gu+YKYdX0.net
.net の 1.1 で書くとめちゃくちゃ不便で絶望するぞ
1019:デフォルトの名無しさん
21/12/14 23:43:50.97 5qKKFixV0.net
linqがある.NET Framework3.5ですら今これでやれって言われたら不便に感じるしなぁ
使えるものは使わせてもらった方が全然楽だわ
1020:デフォルトの名無しさん
21/12/15 08:20:32.57 YtxEX99t0.net
色々使えた方が個人的に楽だと思うのは否定しないが、もっともらしく「生産性が上がる」とか言っちゃうと
意外とそうでもなかったり。
1021:デフォルトの名無しさん
21/12/15 09:41:14.43 flSodCtX0.net
>>974
特にList<T>が無いのはキツイわ
1022:デフォルトの名無しさん
21/12/15 12:10:36.77 KtX6zlRp0.net
心配しなくても今どき1.1で書いたり書かされたりすることはないでしょ
1023:デフォルトの名無しさん
21/12/15 16:03:58.38 w2vh5jVl0.net
1.1とか極端すぎるやろ
1024:デフォルトの名無しさん
21/12/15 16:14:56.34 Jy+USlABM.net
2.0の知識で止まってるヤツも多いよね
1025:デフォルトの名無しさん
21/12/15 16:57:55.56 RMHVQ2YW0.net
さすがに今どきvar使うなとかLINQ使うなとか言われないよね？
1026:デフォルトの名無しさん
21/12/15 17:25:02.67 ik5KT4gs0.net
>>981
var使うとわからなくなるというのは名称が明示的になってないだけだと思うわ
1027:デフォルトの名無しさん
21/12/15 17:31:22.22 KBNxuXv0M.net
>>982
ハンガリアン記法?
1028:デフォルトの名無しさん
21/12/15 18:19:16.59 UGnWEqDI0.net
MS公式はvar推奨してるけどさすがにintとかstringとか基本的な型はvarにはしないな
1029:デフォルトの名無しさん
21/12/15 21:30:02.16 lA94GyTo0.net
明示的に型を書かないとダメなところ以外全部varで書くよ
1030:デフォルトの名無しさん
21/12/15 21:44:12.20 M2QFYQSl0.net
最近はnew()で書けるようになったから、極力varはやめてる
Hoge hoge = new();
実装当初の想定通りlinqの戻りくらいかなvar、使うの。
1031:デフォルトの名無しさん
21/12/15 23:22:27.06 l+MEhncN0.net
new()使えるのってc#いくつからだっけ
1032:デフォルトの名無しさん
21/12/15 23:43:54.17 NZjG441V0.net
はやくおれのレベルまで上がって来い
上で待ってるぞ
1033:デフォルトの名無しさん
21/12/16 00:21:19.35 R2Peltay0.net
new()で書けるようになったけど、コンストラクタで初期設定値渡すようにしちゃうから全然使わんなぁ。
セッター潰してコンストラクタで設定するのが好き
1034:デフォルトの名無しさん
21/12/16 07:48:14.53 Ymr34XoE0.net
>>987
C# 9.0
1035:デフォルトの名無しさん
21/12/16 09:44:30.84 P4pOcLuS0.net
C#がどんどんボクのしらないものになっていってる
いっそC##やDと名乗っていただきたい
（Dは既にある、は受け付けない）
1036:デフォルトの名無しさん
21/12/16 10:15:25.85 80W3ywqF0.net
C#に毛が生えた程度だろ
C丼でええがな
1037:デフォルトの名無しさん
21/12/16 10:54:52.18 Ni3FtdydM.net
c井
1038:デフォルトの名無しさん
21/12/16 11:01:26.24 DM4zUQcN0.net
C⛩
1039:デフォルトの名無しさん
21/12/16 11:42:40.19 plhBUTFD0.net
C升
1040:デフォルトの名無しさん
21/12/16 11:47:41.44 e2PzMi3oM.net
>>991
ほんと、氷川きよしくらい変わってしまった
1041:デフォルトの名無しさん
21/12/16 23:46:42.90 vtDDQtO+0.net
if(item is {} a){
...
}
null判定でこんな書き方あるんだな。Resharperさんに提案されて初めて知ったわ。
個人的にはあまり使いたくないけど。
1042:デフォルトの名無しさん
21/12/17 00:40:01.77 fAwtu2PR0.net
>>997
それやるとaの色がローカル変数色にならず白のままになるのが不満なんだけど俺の環境だけか？
1043:デフォルトの名無しさん
21/12/17 02:39:12.84 KpFo6Hw/0.net
C林
1044:デフォルトの名無しさん
21/12/17 11:21:38.48 b89m5ifd0.net
>>997
C#9なら
if (item is not null)
って実に直感的に書けるから早くこっちにこいよ…
ところでその式でaで受ける意味なくね？
1045:デフォルトの名無しさん
21/12/17 13:42:40.65 KpFo6Hw/0.net
C極
1046:デフォルトの名無しさん
21/12/19 09:44:58.73 QHfeHH9E0.net
WinFormsを独学でやっているのですが教えて下さい
そこそこの規模のソフトは作れるようになってますが
VSで開発していくうえで、フォルダ構成ってどう考えればいいですかね
いままではDB関連をDBフォルダ
フォームはFormにまとめてさらにその中に機能別にフォルダを
細かいクラスファイルはClassというフォルダに
DBとの受け渡し（sｑｌ書いてFormとの受け渡しModelみたいなもの？）は
Modelというフォルダにまとめています
プロの皆様はチームで作っていかれる際に
会社によりけりかもしれませんが一般的なフォルダ構成の考え方ってあるんでしょうか
1047:デフォルトの名無しさん
21/12/19 09:58:37.55 eMi6YEPC0.net
そんなもの存在しないから適当でいいよ
まぁあえて口出しするならFormフォルダはFormクラスと名前が被るからやめとけって位かな
1048:デフォルトの名無しさん
21/12/19 10:00:48.95 n0pWJPWXa.net
なんのフォルダなのか理解できない
プロジェクト（visual studio上でのプロジェクト）内じゃフォルダ切ることはないな
プロジェクトがある程度大きくなったらクラスライブラリに分ける
1049:デフォルトの名無しさん
21/12/19 10:16:13.92 UEQjoSys0.net
シングルアセンブリ構造なのかな
1050:デフォルトの名無しさん
21/12/19 10:33:08.48 QHfeHH9E0.net
>>1003
そうなんですね、気をつけます
>>1004
たとえば画面数でも１００超えて、機能部分のClassファイルも１００越えてくると
いちいち該当ファイル探すのが面倒でフォルダに分けたって感じです
前はPHPのフレームワークとか触ったときは
たとえばcontroller model viewとフォルダも階層構造みたいになっていて
そういう感覚もあります
チームでやられていると、どこに何のファイルが散らばっているか
わからなくなったりしないのですか？ きちんと仕様書があるから関係ないのですかね
やっぱりクラスライブラリ（DLL化？）もちゃんと理解しないと駄目ですよね
一人で作ってるので、DLL化するほうが手間な気がして避けてました
1051:デフォルトの名無しさん
21/12/19 10:44:47.17 n0pWJPWXa.net
どこに何がは命名の問題もあるんじゃないかな
classも変数も先頭、末尾にそれが何か分かるように名前つけてるから名前順にソートされてればすぐわかる
1052:デフォルトの名無しさん
21/12/19 10:53:09.81 UEQjoSys0.net
>>1006
機能ごとにProjectを作るんだよ。
1053:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1004日 15時間 55分 34秒
1054:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています