C#, C♯, C＃相談室 Part93©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/
■コードを貼る場合はこちら
http://ideone.com/
■前スレ
C#, C♯, C＃相談室 Part92
http://echo.2ch.net/test/read.cgi/tech/1485589613/
■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured >>386
思い違いをしていた
A.B().ToString()とA.B.ToString()で区別できる
クラスにフィールドとメソッドを同名にできないから区別できる
右結合と左結合は関係なかったけど >>384
エスパーすると、言いたいことは分かった。
お前は「第一級オブジェクト」も理解しておらず、「誤解」している。ちゃんと勉強しろ。
「第一級オブジェクト」ってのは、通常のオブジェクトと関数オブジェクトを区別しない。
だから書式は当然同じだし、正しく理解していればこの点が疑問になりようもない。
>>387
なら日本語を勉強しろ
> B()というメソッド自体に係ってるのか
これで何を表現しようとしたか言ってみろ。それは
> A.B.ToString()
ではないだろ。 >>385
誤解は悲惨
delegateを削除しろと言って削除してみたらActionもFuncも使えませんでした
eventも使えませんでした
もちろん言語レベルで変数としてのデリゲートの代わりになるものもありません
>>388
＞ > A.B.ToString()
＞ ではないだろ。
いやいやそこはそのままであってるし普通にそう理解できないのか？
A.B.ToString()が正解
逆にどう勘違いしたのか聞きたい 本当にC#からdelegateを削除しろって言ってるんだったらどこかおかしい
何にも理解してない プロパティなんて関数オブジェクトみたいなもんだな
プロパティに引数渡してぇ >>389
日本語で言うと、
> B()というメソッド自体に係ってるのか
と理解したって事だよ。
>>390
お前がな。
他言語にはdelegateなんて無いが、何も問題ないだろ。
あれ？って思えないのか？
(今すぐ廃止していいかどうかはまた別だが)
>>387
> クラスにフィールドとメソッドを同名にできないから区別できる
これは先見の明があったかもな。
関数を「第一級オブジェクト」に昇格させるのに文法的制約がない。
Javaに対しての利点にはなり、生き残る道かも。 >>391
JavaScriptではオーバーライドすれば出来る。
フィールド/メソッドの区別がなく、名前だけだから。
C#的には派生クラスで「プロパティ」「を同名の「メソッド」でオーバーライドだが、
これが型チェック的に無理なのか？
しかし名前の重複を許していないのだから、今後の拡張は可能のはずだが。
JavaScriptのデタラメ文法はどうかという奴もいるが、慣れてしまうと、
型あり言語の「型が違うだけ」で色々制約されるのも相当な糞だと気づけるぞ。
型検査はエラーではなく警告に留めるべきで、
プログラマがOKすれば型が不一致でも通してくれた方がマジで楽。
一番近いのはCってことになってしまうが。 友人ゼロのキモオタオッサンは他にやることないのかい 他の言語はともかくC#はGUIのイベントの管理にデリゲートのマルチキャスト使ってるんだから無かったら困るだろ だからメソッドがオブジェクトかどうかなんて話はただの衒学趣味的な無益な話w
そんな話は「ではオブジェクトって何？」って不毛な議論になるだけでしょw
初心者がデリゲートを理解して使えるようになるための屁の役にも立たないよw
>>397
素直に考えればデリゲート自身にマルチキャストの機能を持たせるんじゃなく、
シングルキャストのデリゲートのリストとして実装する方法もあったはず
なんか理由があって「こういう」風になってるんだろうが俺には積極的理由はよくわからんね。
ジェネリックをデリゲートで制約できないことと関係があるのかもしれないが
なまじマルチキャストなんて機能があるせいで何だかわかりづらくなってる面は否定できないと思う >>397
GUIに関してはdelegateの導入は不要だったで決着してる。
GUIにはOOPよりMVCの方が数段マシで、WPFもそうなってるだろ。
onclickにthisがバインドされている意味がそもそも無いんだよ。
決着が付いてないのはデータフロープログラミングをするときだ。
JavaScriptではObject.observeの導入が計画され、一部フィーバーしていたが、ポシャった。
https://www.html5rocks.com/ja/tutorials/es7/observe/
以下によると、非同期なのが使えなかったらしい。
http://tech.nitoyon.com/ja/blog/2015/11/18/death-of-oo/
JavaScriptの非同期は最早宗教だが、
はっきり言って無駄に非同期すぎて、余計にやりにくくなっているケースもある。これもそう。
C#は独自eventを実装出来るし、そのためにdelegateが用意されているから、
「データフロープログラミング」を文法的にサポートしているとは言える。
ただ、それ以前に、「データフロープログラミング」が主流ではないが。
お前らも実際、やってないだろ。
関数型の次に来るって事もなさそうだし。
とはいえ、上記の通り、今のJavaScriptではデータフロープログラミングは面倒だし、
getter/setterを頑なに拒むC++ではものすごくウザくなって事実上無理だ。
次の波が来ればevent/delegateも再評価されるかもしれん。 >>398
> シングルキャストのデリゲートのリストとして実装する方法もあったはず
同感。 理解してなくても問題なく使えるからって、それを理解しようとするのは悪い事じゃないけど
もとの発端はなんだったんだこれ 誰かさんの大好きなLinqはdelegateの塊なんだけどdelegateなくなっていいのかな
他の実装ではdelegate使ってないけど今の.netではデリゲートで実装されている デリゲートにラムダ式にLinq大好きだ！
これ無くして生きてけない！
チームの誰も読めないから放置されて我が道を歩んでいる。
生産性と品質が高いから客には好評です。 >>405
チームの誰もが読めないという事は保守性に欠けると言う事ですね そうだね。
でも、Linqバリバリ使ったらそうなるよね。
みんなの勉強しろよってこと。 Linqが分からないってのはラムダ式を理解できないってことなの？ 行列計算ライブラリ書いてるときに
おれ掛け算わからんからおれに合わせて全部足し算で実装して
おれはいまお前の案件に関わってないけど将来そのライブラリメンテするかもしれんからヨロシクな
とか言う同僚がいたらこいち頭おかしいのかなって思うじゃん
いやいや掛け算を勉強してからっていうか最低限の単位を取ってからメンテしろよってなるじゃん普通
これがLinqやλやデザインパターンになると当たり前のように底辺至上主義がまかり通る不思議な業界 LINQはC#にしかないからまだわかるけどラムダ式はいまどきの言語ならほぼ実装してるから知ってないとまずいよね Linqにも類似品あるよ
Javaのstreamやpythonのリスト内包表記など
というかそもそも単なるiterator patternでしかないからC#が起源ってわけでもない Linq以前にIEnumerableの意味が解らない人がいるからどうしようもない
.NET2.0から順に教えろってことかよ・・・ >>409
と、底辺至上主義がまかり通る所の意識高い系が申しております
>>412
どう見てもSQLが起源だろ >>414
クエリ形式の文法はSQLが起源かもしれんが
実装はSQLとは全く関係がないよ
C#などの実装はまさしくiterator patternだけど
SQLの実装をiterator patternでやろうとしたら遅すぎる そもそも書けない奴は論外として、使うなってのは同意できる
簡潔に判りやすいラムダ書いてくれりゃいいが、わざとやってんじゃねってぐらい難読化する奴いるからな
正規表現、SQ、掲示板の長文も同じだな Linqに限らず最近のソフトウェア技術は高度で生産性も高くなってる。
昔も人によって生産性に差が出たが、最近だと理解出来るか出来ないか？ぐらいの圧倒的な格差だ。
理由出来ない人は辞めればいい。
生産性が飛躍的に上がってるので理解出来る奴だけで間に合うよ。 自称プログラマー(趣味)ならともかく職業プログラマーでLinqすら理解出来ないやついんの？ Linqを十分に理解できても、可読性や保守性を大事にする人は
多少冗長でも他人が理解しやすい易しいコードを書くんじゃないの？ Linqてそんな可読性悪くないと思うけどなぁ
コメント書いときゃ何となくわかるべ >>417
出来ない人にも生活あるから辞めろとは言えないけどチームは分けて欲しい
使えて使いたい人がどんどん流出して出来ない人だけの会社になると悲惨 >>419
圧倒的に生産性が高かったらどうなの。
最近の案件は短納期になってるし、昔のコボルみたいに何十年もメンテして使うシステムも少ないと思う。 LinqよりSQLの方が難しいぞ。
SQLは難しいから使うなって言うのか？ 業務でいじるレベルのコードなんて知らないものでもグーグル先生いりゃ大抵なんとかならない？
linqも初めて見たときはとっつきにくくてわかりづらかったけど使ってりゃ嫌でも覚えちゃうよ
つっても当然すべてを使いこなしてるわけじゃなくて自分に必要な範囲のみ理解してる程度
業界によってだいぶ差はありそうだけど 生産性は保守運用まで含めてトータルで考えるべきで
保守性が損なわれればトータルコストも引き上がる >>423
あんたの書き込みがゴミだから。
オレらのやりとりがゴミだって言うなら、そう感じさせる様な高踏的な書き込み頼む。 保守性の低い Linq のコードってたとえばどんなの？
自分は他人のを読む場合でも特に困ったことないけどな〜。 >>415
イテレータの起源なら、C++(1983)は最初から持ってた。
C++のOOPはSimula発で、そっちが持ってたかは知らん。
いずれにしても、Java発の技術は存在しないぞ。
C#はLinqと、多分asyncもか？頑張ってる方だと思うが。
(あとちょっと違うがIDEのインテリセンスもC#が初のはず） クソカスの分際で人間様に話しかけてくるな
クソカスが引っ付くわ >>429
> (あとちょっと違うがIDEのインテリセンスもC#が初のはず）
インテリセンスはVB5.0の時代からあるんだが... >>425
> 自分に必要な範囲のみ理解してる程度
多分これくらいが適正で、これなら大して問題にならないんだよ。
問題は、意識高い系馬鹿の>>417
> 昔も人によって生産性に差が出たが、最近だと理解出来るか出来ないか？ぐらいの圧倒的な格差だ。
みたいな、おかしな奴がいることだよ。
Linq自体でそんなに格差が出来るはずもない。
仮に、Linq部分を関数呼び出しに変えたところで、本体のコード構造は全く変わらないだろ。
便利機能だが、その程度でしかないんだよ。
逆に言うと、制御構造の違いで勝負出来ない、
新文法が読めることしか威張れない馬鹿がそこに無駄に拘っている気がする。 linq で Where と OrderBy 使ったところをチームリーダーから For と List<T>.Sort() に書き換えられたことはある。理由は「他と違うから」
他と書き方を合わせておくのが大事なのはわかるけど… >>433
他と違うからって理由で直すのは良くないと思うな
本来関係ないはずのクラスの間に存在しないはずの関係性を作りこんでしまう
その結果、必要ない作業や、縛りを生み出して生産性を下げることになる
俺が経験したものだと
すでに書き終えたforeachをすべてforに統一
テスト済のDAO、DTOのsnake_caseを他レイヤに合わせてCamelCaseに統一
この2つが最高にバカバカしかった カプセル化を知らない人が少なくないのかな
「publicメンバーはクラス間のコミュニケーション円滑化のために規約として形式化しましょう」ぐらいならまあ理解できるが
「Linqはやめてループにしてくれ」なんて内部実装の形式にまで踏み込んでくるなよな
クラススコープで違和感なければそれでいいだろ >>433
俺はC#erではないが…。
単発のLinqも認めてもらえないのならご愁傷様。あれは普通に読める範囲だ。
見た目、Linq自体にはサブクエリ無しか？ならそんな酷いことにはならないはずだが、
例えばSQLでは再帰呼び出しが出来たりして、
マンデルブロだパズル解くだとか、おかしな事になってる。
https://www.sqlite.org/lang_with.html
Linqでどこまで出来るか知らんが、こんなん書かれたら殴りたくもなるだろ。
基本的には関数呼び出しにしてその先は隠蔽、
つまりLinq実装かFor/List/Sort実装かは上位からは見えない、ってことにすれば関係ないはずだ。
ただ、その場にベタで「何を選択しているか」が書かれている方が読みやすいことは多々あり、
Linqもその局面で使われているとは思うので、全面書き直しだと余計に読みにくくなるとも思うが。 >>436
どうでもいい議論だけど、一言。
カプセル化っていうのは「メソッドの中は可読性考えなくてよい」って意味じゃないよw
LINQ（というかクエリ式）嫌いの大半は批判してる人間がそもそも理解してないだけだと思うが一理はある。
それは使い方によっては複数の処理が有機的につながった、適切に分割統治されてない、
可読性の低いコードになるからだ
実際、筋の悪いプログラマが好む100行オーバーのメソッドに近い物になりうる >>439
どう読んだら「メソッドの中の可読性は考えなくていいよ」になるんだろ
外部の都合を内部実装にまで持ち込むな
クラス内での可読性が十分ならそれでいいだろ
って主張な
正しく動いて綺麗なコードを他のクラスの都合で書き直す
俺はこれある意味カプセル化破壊と言っていいと思う
もちろん本来の意味でのカプセル化とは違うのはわかってる >>440
どう読んでもそうとしか読めません
自分で自分の書いてあることが理解できないのかw
「メソッドの中は可読性考えなくてよい」と言っているのでなければ
>>436の1行目と4行目はつながらない。
カプセル化を理解していてもメソッドの中の可読性、例えば
「Linqはやめてループにしてくれ」と言うことはあり得る。
なぜなら、カプセル化とは「メソッドの中の可読性は考えなくていいよ」という意味ではないからだ >>441
いきなり訂正
× >>436の1行目と4行目はつながらない。
〇 >>436の1行目と3行目はつながらない。 ランダムな指定回数オブジェクトを作成する方法ないですか
7時まで待つ >>441
横からだけど、そう思えるのはお前さんがLinq使ったら可読性悪くなるって決めつけてるからじゃないの? >>435
コーディング規約を読んでないお前か
コーディング規約を定めてないお前の組織がバカなだけ 変数を関数の先頭に書く
returnは1つまで
変数名の先頭に型の略字を書く
varは使ってはいけない
こういうひと昔前まで大衆が信じてたバカ規約
システム全体で統一感のあるコードを書くって規約もいずれその仲間入りするとおもう
いまはまだIT業界全体が未熟だからみんな気付いてないだけ ちょっといいですか、この関数100行超えてます。
規約違反で可読性なくなります！
レビューで積極的に発言するサル、何も知らないで自分は立派なプログラム書いてると思っている。
ちなみににLinqの方が可読性上がるよ。
Linqはやりたいことをズバッと書ける。
古いやり方だと、このforループなに？ってなる。
forループは実装手段であって目的じゃないから。
単に慣れ、新しいこと勉強したくない連中が可読性だの規約だの持ち出す。 分割すれば良いじゃん
それが出来ないことを相手のせいにするな 俺が知りたいのは、オブジェクトをｘ回作るやり方なんだよ for(var i=0;i<n;i++)Days[i]=new Day(i); linqで発狂してるジジイはSQL絡みでよくわからないエラーに出くわして理解できなかったんじゃないの 保守性の低い Linq を使ったコードの実例を見たいんだけど。 クエリ式を使ったのは単純なのはわかりやすいけど複雑になるとお手上げ
メソッド形式で使ったとしても逆にクエリ式のfromを二重の使ったほうがいいのにSelectManyを使ってるやつは非常に醜い
JoinやAggregateも可読性が以上に低い 意見は分かれると思うが、川俣大先生が連載記事で引用してた
このサンプルあたりがボーダーラインかね
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/linq/how-to-query-for-duplicate-files-in-a-directory-tree-linq
個人的にはこれも読みづらい
実にどうでもいい話だが、LINQは頭字語のはずなのでLinqって表記には違和感しか感じない。
あと、これもくどいが、LINQじゃなくてクエリ式の話をしてるんじゃないのかと >>463
これはだめな例じゃないかな？
何をやってるかがわからない これの事？
var queryDupNames =
from file in fileList
group file.FullName.Substring(charsToSkip) by file.Name into fileGroup
where fileGroup.Count() > 1
select fileGroup;
基礎的なものだけで構築されていて何をやっているか一目瞭然じゃん これがわかんないって言うならもうlinq禁止しか無いね
そんな人間がいるプロジェクトには関わりたくないけど 全員linq読めても将来読めない人がメンテするかもしれないから禁止
実際にあった話 ああこれが分からないってんなら確かに LINQ 禁止だわ。w
でもそんなのに付き合ってやる義理はないんじゃね？ あとは規約の問題だな。 分からないなら勉強するなり聞くなりすればいいじゃんとは思うけどな
可読性あげるのは理解できるが便利な関数を規制するのはおかしいくない？
いつまでたっても個人の技術力上がらなくなるけどいいの？とは思う わからないって意味を誤解してるだろ
var queryDupNames = fileList.Groupby(f=>略, f=>略).Where(g=>g.Count>1);
メソッドだとほぼ一瞬で何をやってるかわかるだろ
わざわざ行数を割いて理解に時間のかかるクエリ式を使う意味はねえよ あークエリ式じゃなくてラムダで書いた方が見やすいって話？
それなら同意 リファクタリングするにもユニットテストで担保取れないレベルの酷いプログラム沢山あるからなあ 低レベルなプログラマに合わせたコードはテストしにくいひどいコードになりがち
インターフェース禁止だとか当たり前のように言ってくるからねあいつら 低レベルなプログラマとの話し合いは無駄だと言うことがよくわかった リファクタリングをリファクタ言うの非常に気持ち悪い
refactor は refactoring から派生した単語
refactor という動詞は使われだして日も浅く、まだ技術系のスラングの域でしかない
VS には「リファクター」としてリファクタリングを行うメニューが提供されているが
小洒落た動詞として使用される分には気にならないが、
日本人が「リファクタする」とか使ってると「カンパニーのコンプライアンスをガバナンスする」とかと同様に見える
いやもっとあれか「コンプラをガバーンする」とかと同じレベルかな？ （govern は正しい動詞）
https://english.stackexchange.com/questions/57750/is-there-a-verb-refactor-meaning-doing-refactoring-in-english
……MSのスペルチェッカで引っかかってたのか（現在は知らんが） カタカナ表記する時点で英語のことなんて気にしてちゃやってられんよ 唐突に何なんだろうねw
まあ、某社のVS用のリファクタリングツールの旧名がRefactor !"だったね。 英語はよく知らんが 〜ing から派生して 〜 ができるとかあり得るのか？ うん、そもそも refactoring が造語
初出が誰なのか不明（Martin Fowler ではない）だが、
1992年には論文で見られるっていうほんとに新しくできた単語なのよ 接頭辞と接尾辞を付けただけだから別に造語ってほどじゃ無いだろ？ もとの言葉がfactor、factoringで、factorは動詞としても使われているのだから、
英語圏ならrefactoringという言葉が登場した時点でrefactorという言葉も同時発生的に生まれていると思うが… どうでもいい話だけど、派生した順番はたぶん
factor(名）→ factoring → re-factoring
なんだろう。
完全に想像で何の根拠もないけど、computingが動詞のcomputeの動名詞ではない（たぶん...）
ように、factoringも動詞のfactorの動名詞ではないような気がする ■ このスレッドは過去ログ倉庫に格納されています
