虹裏img歴史資料館

1 21/10/09(土)12:35:27 No.854398701

わからん…

2 21/10/09(土)12:36:39 No.854399052

見た限りだと同じ意味の文を短く記述できる

3 21/10/09(土)12:37:48 No.854399383

オシャレ

4 21/10/09(土)12:38:14 No.854399491

素コード丸々引っ張ってきたらたまに怒られるけどラムダ式のコードだと絶対に怒られないのが嬉しい

5 21/10/09(土)12:38:14 No.854399494

めっちゃ容量削減してる！

6 21/10/09(土)12:38:20 No.854399527

何をやりたいのかは見やすいな

7 21/10/09(土)12:38:27 No.854399556

みたまんまコードが短く読みやすくなるだろ 逆に匿名クラスだと何がうれしいんだ

8 21/10/09(土)12:39:22 No.854399856

>素コード丸々引っ張ってきたらたまに怒られるけどラムダ式のコードだと絶対に怒られないのが嬉しい 何気なく最悪なことを言うんじゃない

9 21/10/09(土)12:40:02 No.854400073

スレ画見ただけでもめっちゃわかりやすく嬉しいだろ！？

10 21/10/09(土)12:43:10 No.854401119

素人質問で恐縮ですがrobocallEligibleDriversは何のためにあるのですか？ ただrobocallMatchingPersonsを使うだけでいいのでは？

11 21/10/09(土)12:44:57 No.854401701

現場全員がラムダ式に精通していることを前提とすれば可読性は高い ベースパッケージ開発とかなら積極的に使うべき

12 21/10/09(土)12:47:52 No.854402704

「」もラムダ式で定型部分を短くできないだろうか

13 21/10/09(土)12:47:59 No.854402746

C#ならLINQとの相性が良すぎるんで使わない手はない

14 21/10/09(土)12:49:13 No.854403156

引数に関数を要求する系の処理だとラムダ式で関数作ったりするね

15 21/10/09(土)12:49:56 No.854403421

読みづらいからいらない

16 21/10/09(土)12:51:21 No.854403894

数学やっててもラムダ式うんぬん言ってくるやつがいる 表記の仕方が変わったようにしか見えなくて数学的な意義が見えない

17 21/10/09(土)12:51:44 No.854404020

>ただrobocallMatchingPersonsを使うだけでいいのでは？ 1回しか使わないならそれでもいいけど

18 21/10/09(土)12:51:59 No.854404103

クロージャとして放り込みやすい

19 21/10/09(土)12:52:11 No.854404177

>表記の仕方が変わったようにしか見えなくて数学的な意義が見えない 基本的にはそう

20 21/10/09(土)12:53:35 No.854404689

無駄な関数の宣言が抑えられる

21 21/10/09(土)12:55:20 No.854405267

js/ts書いてるとこれなしでは生きていけない

22 21/10/09(土)12:55:52 No.854405425

単体テストと合わせると超うれしい

23 21/10/09(土)12:57:51 No.854406082

条件いっぱいで複雑になってる三項演算子とか素直にif文で書いてってなる

24 21/10/09(土)13:00:52 No.854407032

>条件いっぱいで複雑になってる三項演算子とか素直にif文で書いてってなる 各節ごとに同じ変数に代入する式を書くのが嫌

25 21/10/09(土)13:01:03 No.854407091

書く側としては楽だが読む側としては微妙だと思う あとデバッグが面倒な言語もある

26 21/10/09(土)13:01:24 No.854407213

いちいちprivateメソッド作るより楽

27 21/10/09(土)13:02:35 No.854407597

>>条件いっぱいで複雑になってる三項演算子とか素直にif文で書いてってなる >各節ごとに同じ変数に代入する式を書くのが嫌 むしろ条件少ないならifでいいんだよな 分岐多いのに代入する変数が全部同じだから:?のネストが一番すっきりする ちゃんと改行インデントしておけば可読性も悪くない

28 21/10/09(土)13:05:58 No.854408647

if(A) x=a; else if(B) x=b; else if(C) x=c; else x=z; x = A ? a 　: B ? b 　: C ? c 　:　　 z;

29 21/10/09(土)13:07:10 No.854409006

三項演算子いいよね… というかvarを使いたい場合は必須になる

30 21/10/09(土)13:07:39 No.854409154

基本的に再利用されないから最適化しやすいのでは

31 21/10/09(土)13:07:40 No.854409164

コメントがないこいつとデリゲートをふんだんに使った他人のコードを読むのは最高だぜ！

32 21/10/09(土)13:08:23 No.854409394

まぁでもLINQのselect関数とwhere関数にラムダ放り込むくらいなら読めるじゃろ

33 21/10/09(土)13:08:46 No.854409519

switchとかcaseとかの方が良くない？

34 21/10/09(土)13:08:47 No.854409526

同じことして容量削減出来るならその方が良いよね？

35 21/10/09(土)13:09:07 No.854409632

俺はswitch文大嫌いマン！

36 21/10/09(土)13:09:19 No.854409708

このpだのnだのどっから来たんだってなる

37 21/10/09(土)13:09:59 No.854409919

>switchとかcaseとかの方が良くない？ 言ってる意味がわからない switchとかcaseとかってなんだ それ別々に使う言語あるのか

38 21/10/09(土)13:11:08 No.854410275

>このpだのnだのどっから来たんだってなる どっから来たのかはアローで示してある

39 21/10/09(土)13:11:09 No.854410279

スレ画のようなケースだとあんまり恩恵を感じられない LINQだとすごい簡潔になってありがたい…ってなる

40 21/10/09(土)13:11:14 No.854410295

>俺はswitch文大嫌いマン！ 嫌い過ぎてif分を濫用しなければまあ…

41 21/10/09(土)13:11:30 No.854410372

自分で書いたコードなのに後から見返すときになんだこれってなる

42 21/10/09(土)13:12:00 No.854410523

>俺はswitch文大嫌いマン！ 生理的に無理とかそういう？

43 21/10/09(土)13:12:12 No.854410594

>>俺はswitch文大嫌いマン！ >嫌い過ぎてif分を濫用しなければまあ… if分の入れ子だらけで可読性が下がったコードいいよねよくない

44 21/10/09(土)13:12:25 No.854410673

>switchとかcaseとかの方が良くない？ たぶん三項演算子のネストのこと言ってるんだろうけど switchだと結局毎回代入文書くのは変わらないしいちいちbreakが要るし そもそも判定条件が一個の式の値でないといけないから汎用性はない

45 21/10/09(土)13:12:52 No.854410812

verilogだとif文は使わないで三項演算子で書くスタイルが普通だった

46 21/10/09(土)13:13:36 No.854411025

さすがに入れ子にはしないよ大丈夫大丈夫 switch文があったとこにはif文または三項演算子が生えてくるけど もしくはenumextendで済ますこともたまに

47 21/10/09(土)13:13:36 No.854411033

言語によってどれが最適ってのは違うよね

48 21/10/09(土)13:14:07 No.854411192

rubyだと三項演算子とifがそもそも分かれてなかった気がする そっちの方が良いよね

49 21/10/09(土)13:14:20 No.854411270

複雑な条件判定は関数に切り出せ その関数内ならどんな実装しててもいい

50 21/10/09(土)13:14:51 No.854411428

ラムダ式はコメントなくても可読性良いだろ

51 21/10/09(土)13:15:12 No.854411522

三項演算子をネストする発想がなかった 目からうろこだわ

52 21/10/09(土)13:16:13 No.854411846

うちは三項演算子のネストはコーディング規約になっている 単純なスイッチ文の置き換えならむしろネストしちゃいけない規約にもなっている

53 21/10/09(土)13:16:26 No.854411911

一つの条件でたくさんの処理に分岐するならswitch 多数の条件で同じ代入処理をするなら?: どっちでもうまくないならif else

54 21/10/09(土)13:16:34 No.854411956

その場だけのソート処理とかはラムダ式よくつかうイメージ

55 21/10/09(土)13:16:55 No.854412081

三項演算子のネストってExcelのifみたいな事態になるんじゃないの

56 21/10/09(土)13:17:02 No.854412128

visual studioでフォームロードのところでタイマー関係に使うとスッキリしていいわよ ほぼそれしか使わない

57 21/10/09(土)13:17:12 No.854412188

個人的には三項演算子好きだけど規約で禁止している場合も多いんだよな

58 21/10/09(土)13:17:12 No.854412190

俺は参考演算子のネストよく使ってるけど switchの方が誤読する可能性ないからよくない？と言われたら反論できない

59 21/10/09(土)13:18:23 No.854412540

可読性とスッキリさを両立することは難しい

60 21/10/09(土)13:18:25 No.854412550

switch文だって処理の入り口には使いやすいもんなんだ 奥で書くな

61 21/10/09(土)13:18:50 No.854412687

ラムダ式と言うかアロー演算子が視覚的にめっちゃわかり易くて好き

62 21/10/09(土)13:18:59 No.854412743

三項演算子論争はいつでも無限に駄弁れる魔法の話題 20年前も同じこといってたような気がする

63 21/10/09(土)13:19:06 No.854412791

つまりLisp最高という結論でいいのか？

64 21/10/09(土)13:19:34 No.854412930

いいですよねPerl…

65 21/10/09(土)13:19:56 No.854413039

LISPって何が最高なの？

66 21/10/09(土)13:20:06 No.854413085

>三項演算子論争はいつでも無限に駄弁れる魔法の話題 >20年前も同じこといってたような気がする きのこたけのこ戦争みを感じる

67 21/10/09(土)13:20:19 No.854413147

Pythonのスライスも三項演算子の一種だと今調べて知った

68 21/10/09(土)13:20:42 No.854413266

未だにラムダ式わからない現場ってあるの？

69 21/10/09(土)13:20:54 No.854413341

>未だにラムダ式わからない現場ってあるの？ あるかないかで言えばある

70 21/10/09(土)13:21:21 No.854413483

結局は馴染みの問題だからなぁ

71 21/10/09(土)13:22:00 No.854413691

>未だにラムダ式わからない現場ってあるの？ だってうちまだJavaが…

72 21/10/09(土)13:22:04 No.854413710

LINQないでしか未だに使ってない…

73 21/10/09(土)13:22:25 No.854413813

ラムダ式使うなって現場が続けば触らなくていいかなってなるだろうしな

74 21/10/09(土)13:22:53 No.854413977

C#だと外部の変数をキャプチャしてくれるのが バグを生むときも助かるときもある

75 21/10/09(土)13:23:19 No.854414124

ラムダって要は関数ポインタを今風に言ってるだけだろって思って20年ぐらいを過ごしてしまった

76 21/10/09(土)13:23:30 No.854414173

デバッグしづらい…

77 21/10/09(土)13:25:48 No.854414897

関数ポインタからデリゲートときてラムダ式は順調に進化してる感ある

78 21/10/09(土)13:26:27 No.854415091

フロントいると書き方が定期的に新しくなるから楽しめるぞ！ たのしくない

79 21/10/09(土)13:26:49 No.854415197

無名関数？

80 21/10/09(土)13:27:17 No.854415342

なんかフロントは宗教戦争激しそうだなって偏見がある

81 21/10/09(土)13:27:24 No.854415374

ラムダ式はまだ読み易い なんでもリアクティブにするのは分からんしやめてくれと思う

82 21/10/09(土)13:27:41 No.854415472

同じ無名でもタプルはいまいちまだ使えない keyvaluepairよりは使いやすいような…そうでもないような…

83 21/10/09(土)13:30:11 No.854416234

たぶん1番のメリットは引数名考えなくて済むだと思う

84 21/10/09(土)13:30:28 No.854416312

タプルはかなり好き response型とか作らないで済む

85 21/10/09(土)13:31:33 No.854416626

適当に読んでるとどこがコールバックでどこが戻り値でどこが処理なのかパッと見て分からんからこの書き方マジでやめろ 自分ではやります

86 21/10/09(土)13:32:19 No.854416830

>No.854408647 下の言語うらやましい

87 21/10/09(土)13:32:33 No.854416883

不適切な関数名をつけるくらいなら無名の方が読みやすいはありそう

88 21/10/09(土)13:32:38 No.854416918

ラムダ式と匿名関数だとスコープが違うんじゃなかったっけ thisが指すものがそれぞれ違う

89 21/10/09(土)13:32:59 No.854417029

読みにくいけどなんかテクニック持ってるやつの方が強いから何も言えねえ

90 21/10/09(土)13:33:10 No.854417082

>下の言語うらやましい 3項演算子ここまで使うならif文使うかな…

91 21/10/09(土)13:34:07 No.854417365

わざとバラしてみたりするとコード量とか結構違ってくるのが分かる クロージャが絡んでると特に 何重にもしてなければ問題ない

92 21/10/09(土)13:34:21 No.854417424

>読みにくいけどなんかテクニック持ってるやつの方が強いから何も言えねえ パフォーマンスが同じなら「読みにくいから使わない」というコーディング規約を制定すれば行ける 「こちらの方が高速」とか「こちらの方がメモリが節約できる」って利点があるなら苦しくなる

93 21/10/09(土)13:34:55 No.854417578

慣れたら読めるよ

94 21/10/09(土)13:35:11 No.854417653

enumのフラグ用法は難しいので使わないでください って言われた時はマジかよってなったな

95 21/10/09(土)13:35:45 No.854417823

少なくともラムダ式分からなきゃJava 8以降分からないってことだからなあ

96 21/10/09(土)13:36:16 No.854417979

>enumのフラグ用法は難しいので使わないでください >って言われた時はマジかよってなったな なんだかんだ一番下に合わせるのは大事 軍隊みたいな

97 21/10/09(土)13:36:37 No.854418095

読みにくいはエンバグの原因にもなるから無理して使うことは無い 努力はして欲しいけど