C#, C♯, C＃相談室 Part95

**デフォルトの名無しさん** · 2017/10/17(火) 04:02:10.51

■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part94
http://mevius.2ch.net/test/read.cgi/tech/1492843013/

■次スレは>>970が建てる事
建てられない場合は他を指定する事。

**デフォルトの名無しさん** · 2018/04/01(日) 09:16:10.30

マーティン・ファウラーはいつも良いことを言うね
底辺PGでも少しは見習ったほうが良いぞ

https://martinfowler.com/bliki/FunctionLength.html

**デフォルトの名無しさん** · 2018/04/01(日) 09:17:34.95

>>618
コードで表現出来てることをわざわざ関数名で伝えようとするバカが何だって？

**デフォルトの名無しさん** · 2018/04/01(日) 09:25:16.65

>>614
中身を理解しやすくするのは実装の仕事
メソッド化する最大の目的は実装と意図を分離すること
僕が引用したリンク先でマーティン・ファウラーがわかりやすく説明してくれてるからぜひ読んで欲しい

**デフォルトの名無しさん** · 2018/04/01(日) 09:28:59.77

三行で書かれてるコードならその場でその三行を修正するだけで済むが、
それを三つの関数に分けるとわざわざ別の行までスクロールして修正する作業が三回発生する

どちらが効率的で生産性が高いのか普通なら考えるまでもなく分かることだが、自意識過剰なバカには分からないのかも知れない
何せ自分のことを『達人』とか思い込んでるレベルのバカだし

**デフォルトの名無しさん** · 2018/04/01(日) 09:33:48.86

>>620
コードで表現していることを関数名で抽象化するんだよ
抽象化はプログラミングをする上で最上級に重要な概念だけどどうもIQが凡人以下だと理解できないらしい
物事を理解するにはその内容に応じた知能がどうしても必要になる
凡人が数学者や物理学者に成れない
難しい概念がわからないという感覚は人としてどうしようもないものなんだ
だからこのスレにも抽象化がわからない人が居てもおかしくはない

**デフォルトの名無しさん** · 2018/04/01(日) 09:36:24.52

>>622
場合によるんじゃないかな？
その一行が何度も出てくるなら関数化したほうが修正が楽

何百回修正するか
一回修正するか

**デフォルトの名無しさん** · 2018/04/01(日) 09:38:21.16

>>622
そのコードがなんのためにあるのかということを考える作業が3回も発生する

そのコードを変えて他に影響がないか確かめる作業が3回も発生する

同じことを他の場所でしていないか確かめる作業が3回も発生する

酷い無駄だ

**デフォルトの名無しさん** · 2018/04/01(日) 09:39:10.89

関数化で抽象化はされる

抽象化された関数で何をやってるか詳しく関数名に入れると無意味なことになることもある
むずかしいよね

**デフォルトの名無しさん** · 2018/04/01(日) 09:40:28.60

bool IsEmpty() => this.Length == 0;

このレベルの実装であれば何も文句はないが、大半はそうじゃないのが現実

**デフォルトの名無しさん** · 2018/04/01(日) 09:40:36.80

適切な直行化ができてれば、一連の処理の流れに関わる多数の関数を一緒に修正するなんてことはそうあるものではない
その程度のスキルレベルなら分け過ぎはよくないのは同意する

**デフォルトの名無しさん** · 2018/04/01(日) 09:42:35.89

もともと一行関数だったものが徐々に成長していくこともある
でも呼び出し元のコードは変わらない
ロジックが変わってないからね
これは大変素晴らしいことだと思う

**デフォルトの名無しさん** · 2018/04/01(日) 09:46:33.53

十分に責任の明確化ができている関数は中身を見る必要が無くなる
不要になって消すことはあっても中身を弄ることはめったにない
この名前でこの引数を受け取るならこの結果が返るのが当然、と思えるのが正しい関数だ

**デフォルトの名無しさん** · 2018/04/01(日) 09:48:36.16

>>627をバカが真似した例

void Increment(ref int a) => a++

（※現実にあったコードです）

**デフォルトの名無しさん** · 2018/04/01(日) 09:52:46.42

>>631
そのレベルの現場ならCOBOLみたいにMOVE羅列してる方マシだね
世の中そういうところばかりではないから文句があるならさっさと転職しろ

**デフォルトの名無しさん** · 2018/04/01(日) 09:54:39.84

コードを書いてる時点で将来をすべて予見できるような素晴らしい環境にいるならいいけど
大体はそんなことはない

仕様を考えたのが他人であろうと自分であろうと

**デフォルトの名無しさん** · 2018/04/01(日) 10:25:24.90

>>631
範囲を扱うアルゴリズムに使わせる目的で使うイディオムだよ
こうしておけばプリミティブの数値も数値っぽい型(例えば巨大整数クラス)も同じように扱える
ようするにただのストラテジだな

**デフォルトの名無しさん** · 2018/04/01(日) 10:45:43.34

まあ正直C#で>>631は無意味とは言わないまでも違和感あるけどな
>>631もC#だけでなくc++とか経験してみるとこういう短い関数の真価を理解できるんじゃないかな

**デフォルトの名無しさん** · 2018/04/01(日) 11:56:21.61

巨大整数とか仕様にカスリもしない未来を妄想して複雑化して「これがシンプルなんだよ！」と強弁するとかアホの典型だな
グループ開発の経験もない無職かよ

**デフォルトの名無しさん** · 2018/04/01(日) 12:03:50.05

>>636
一例に過剰反応バカキター

**デフォルトの名無しさん** · 2018/04/01(日) 12:12:43.78

最初から無駄に俺様カスタマイズしたがるのはこじらせたC++erによくあるYAGNIだね
そして、Incrementの例のように基礎的な部分には異常に拘るくせに普通のアプリケーションコード部分は巨大なメソッドを生産する奴が多い
その割にはポインタ演算は大好きで、配列操作になるとウッキウキしてクソ低レベルなアスタリスクと++だらけのコードを垂れ流す
そういう連中だよ

**デフォルトの名無しさん** · 2018/04/01(日) 12:36:30.52

昨日からNG大繁盛だわ

**デフォルトの名無しさん** · 2018/04/01(日) 12:42:38.07

ふらっとも伸びているようだし承認欲求に飢えているアホどもが暴れているのか

**デフォルトの名無しさん** · 2018/04/01(日) 12:53:48.82

>>638
でもそれってお前の妄想じゃん
c++の仕事任されるほどスキルないっしょ？

**デフォルトの名無しさん** · 2018/04/01(日) 12:59:36.34

>>641「巨大整数にも対応してるオレ様のフレームワークを使えー！」

**デフォルトの名無しさん** · 2018/04/01(日) 13:07:10.47

どんな面白い問題で盛り上がってるのかと思ったらしょうもな。

(1) 道具が多すぎる道具箱は使いづらい

からと言って

(2) 短すぎるメソッドは「無駄な道具」である

などと言えるわけがない。
そうである場合もない場合もあるに決まってる。

こんなくだらない話でよく盛り上がれるな

**デフォルトの名無しさん** · 2018/04/01(日) 13:16:23.13

>>643
だから無駄な道具を乱造して散らかす奴が悪いんだろ？
いくら「これが正しい！」と喚いてもゴミ屋敷をスマートとは言えんわ

**デフォルトの名無しさん** · 2018/04/01(日) 13:24:59.02

なんかずれてんな
いやわざとか？

みんな「1行コードはクール」
みんな「いや害悪だ」

>>631「1行コードにはこんな意味不明な頭悪いコードが実在するんだぜぇ」

>>634「いやーそれはストラテジでしょ。普通のコードだよ」

あほ「巨大整数ガー！ゴミ屋敷ガー！」

途中から明後日の方向に向かってんだよ
一例に過剰反応バカが湧いてきたあたりからね

**デフォルトの名無しさん** · 2018/04/01(日) 13:28:56.88

一つ言えるのは、一行コードをセンスが無いやつが書くとゴミクズになるってことだな
まあ何行でもゴミと言えるかもしれんが、一行のゴミはメンテする時腹が立つ

**デフォルトの名無しさん** · 2018/04/01(日) 13:30:25.54

1行メソッドの利点を理解できないアホが逆ギレしてるだけのパターンもあるということは忘れないで

**デフォルトの名無しさん** · 2018/04/01(日) 14:14:15.06

一行のゴミにも何か利点はあるはずだと頑なに改めようとしない>>647なのであった

マジでゴミ屋敷の主だな

**デフォルトの名無しさん** · 2018/04/01(日) 14:20:30.29

>>645はstrategyも理解してないアホの子だから許してあげて
ただのラッパーを戦略と勘違いしてるなんて、きっと今年の春から働き始める新人だから

**デフォルトの名無しさん** · 2018/04/01(日) 14:28:00.99

上司「なんでこのインクリメントを関数に分けてんの？」

新人「様々な型に対応する為のストラテジです！巨大整数などにも対応できます！」

何というか無能な働き者って言葉がしっくり来るな
たぶんこいつは誰からも理解されずに五月病患って数ヶ月で退職するわ

**デフォルトの名無しさん** · 2018/04/01(日) 14:39:00.26

インクリメントの(多相じゃなくて正しい意味での)ストラテジって何だろうね
++とInterlocked.Incrementを切り替えるとか？
エイプリルフールネタにもならんな

**デフォルトの名無しさん** · 2018/04/01(日) 14:39:37.29

>>640
春休み

**デフォルトの名無しさん** · 2018/04/01(日) 14:47:04.79

ここには初心者スレに行ったほうがいいような連中しか居ないようだな

**デフォルトの名無しさん** · 2018/04/01(日) 15:13:55.41

ゆとり世代はなんでも揃ってるところからスタートだから楽でいいよな
iteratorの実装なんて考えたことすらないんだろう
羨ましいよ

**デフォルトの名無しさん** · 2018/04/01(日) 15:50:22.39

老害

**デフォルトの名無しさん** · 2018/04/01(日) 17:15:29.85

>>650
何で巨大整数に対応する必要ない状況を前提としてるの？
対応すべきという状況を前提とした途端に真逆の結論になると思うけど

**デフォルトの名無しさん** · 2018/04/01(日) 17:31:26.23

仕様上ありえない予測
それを人は　妄想　と呼ぶのだ

**デフォルトの名無しさん** · 2018/04/01(日) 17:45:28.27

巨大整数対応を勝手に仕様上あり得ないことにしている点
「○○にも対応できるように」の○○に巨大整数を入れるのはあくまで一例であり他にも山ほどあり得る点
この辺りが問題かな
言われた通りの物を納品すればいい所謂IT土方系の環境なら問題にならないんだろうけど

**デフォルトの名無しさん** · 2018/04/01(日) 17:47:21.74

>>656
対応すべきという状況を前提にしたとしても、>>650の新人がストラテジパターンを誤解している阿呆であるという結論は覆らない
>>631を型ごとに用意するのは一般にはパラメータ多相、あるいは単にオーバーロードと呼ぶんだよ

**659** · 2018/04/01(日) 17:49:35.48

すまん訂正
パラメータ多相じゃなくてアドホック多相だな

**デフォルトの名無しさん** · 2018/04/01(日) 17:49:42.89

この手のっていつも「自分の前提」の元に議論初めてかみ合わないんだから止めとけよ
ネタが下らないことだし、そんなことにこだわるしかやることないのかよ

**デフォルトの名無しさん** · 2018/04/01(日) 17:53:38.19

int型をBigInt型に切り替える必要が生じたとして、
型宣言から書き直さないといけないのにインクリメントを分離しておいて何が効率化できたというのかと
そもそもオブジェクト指向に則ればその型自体にインクリメントを備えるだろっていう

現実に設計したこともない新人が本の知識で言ってるだけだなこりゃ

**デフォルトの名無しさん** · 2018/04/01(日) 18:21:49.73

正しい設計
INum num = new Num()
// INum num = new BigNum() ←クラス名を変えるだけ
num++ ←機能は型で規格化されてるので変更無用

間違った設計
Num num = new Num()
// BigNum num = new BigNum() ←型から変える必要がある
Increment(ref num) ←何これ？

void Increment(ref Num n) 処理
void Increment(ref BigNum n) 処理
↑型の数だけオーバーロードする必要がある

**デフォルトの名無しさん** · 2018/04/01(日) 18:47:25.76

どーでもいいことかもしれんが、セミコロンがないのが凄く気になる

**デフォルトの名無しさん** · 2018/04/01(日) 19:40:56.03

>>660
はぁ? どう見てもストラテジだろカス

void func<T>(T mi, T mx, FuncObj<T> increment) {
for(T i = mi; ! i.Equals(mx); increment.Exec(i)) {
//
}
}

class BigIntIncrent : FuncObj<BigInt> {
public Exec(ref BigInt x) {
x = x.Add(1);
}
}

**デフォルトの名無しさん** · 2018/04/01(日) 19:44:56.66

>>663
なんでBigIntのソースが手元にある前提なんだよ
まあ素人は標準のパッケージ以外を持ってきて使うなんて経験はないのかもしれんから間違えても仕方がないか
君素人っぽいし

**デフォルトの名無しさん** · 2018/04/01(日) 20:02:44.23

>>665
惜しい。一旦クールダウンしてよく考えよう。
同じ入力(コンテキスト)に対して複数のStrategyを定義し、状況によって使い分けるのがStrategyパターンだ。
一方incrementの場合、実装は入力の型に応じて一意に決まるだろ？「同じ入力」に対して複数の実装があるわけじゃない。
そういう、引数の型に応じて静的に実装を選択するのを一般に「多相」という。
特に、君のコードは関数型言語で型クラスと呼ばれるものに近い。ググってみると勉強になるよ。

**デフォルトの名無しさん** · 2018/04/01(日) 20:08:31.72

>>667
1つ飛ばしでイテレートしたい場合とか同じ型でも幾らでもバリエーションは考えられるわけだがわかんねえだろうな用意されたもの使うだけのゆとりには

**デフォルトの名無しさん** · 2018/04/01(日) 20:10:41.80

>>665
なにこの頭悪すぎるゴミ
意図が読めない典型じゃん

**デフォルトの名無しさん** · 2018/04/01(日) 20:13:25.61

>>669
あらゆる物事に対してそれを理解するために必要な知能の下限が存在する
これって１つの真理だと思うのよ

**デフォルトの名無しさん** · 2018/04/01(日) 20:20:07.28

>>670
funcって何？
funcObjって何？
miって何？
mxって何？
Execって何？どういう機能？
BigIntでAdd？コレクションなん？

パッと見ただけでこれだけ疑問が湧くんだが、
プログラマ百人に聞いたら百人が死ねって返すレベルのクソだぞこれ
命名だけでバレる実力なら無理して書くなよ

**デフォルトの名無しさん** · 2018/04/01(日) 20:22:40.27

>>668
そうだね。確かに君の言う通りだ。
じゃあ君はなぜ>>665でわざわざジェネリックを使ったのかな？
>>665を見た殆どの人は、型に応じて++の実装を切り替えたいのだろうと思うだろうね。それを君はストラテジだと言っている。
このままでは誤解してしまう人もいるだろうから指摘したんだよ。
君自身はもしかしたら本当は正しく理解してたのかもしれないけど、衆目に晒すにはあまりにも不適切なレスだ。

**デフォルトの名無しさん** · 2018/04/01(日) 20:25:32.72

文脈読めない、中心になってる話題を理解して枝葉末節を気にしない、っての実践するにもある程度の知能が必要なんだろうなー
そういうの苦手な人ってミーティングの時とか相当鬱陶しがられてると思うから注意したほうがいいよ

**デフォルトの名無しさん** · 2018/04/01(日) 20:28:38.03

>>665
これforでローカルに代入してるが値型のつもりなのか？

**デフォルトの名無しさん** · 2018/04/01(日) 20:30:19.04

>>673
悪いけど、文脈を読んだら>>665のコードは100人中100人が型++を切り替えようとしてるのだろうと解釈すると思うぞw

**デフォルトの名無しさん** · 2018/04/01(日) 20:35:04.55

>>675
ほらな
読めてない

**デフォルトの名無しさん** · 2018/04/01(日) 20:40:22.21

>>672
ジェネリックかどうかは関係ない話だろ
この例も仮にスクリプト言語だったら型引数は無くても動作する
たまたま型の指定が必要な言語を例に使ったからジェネリックになっているだけ
しかしそのエッセンス自体は何も変わってない
まずはそこを理解しよう

**デフォルトの名無しさん** · 2018/04/01(日) 20:54:39.80

>>665を読むとこいつうちにいた新人より頭悪い気がする
ストラテジとか言いながらやってることが関数型だし
これでデザパタのつもりなら学校通い直すのを勧める

**デフォルトの名無しさん** · 2018/04/01(日) 20:55:42.47

ここでいうエッセンスというのは
* 処理の一部を外部から与えることによってアルゴリズムを交換可能にするテクニックをストラテジーパターンと言う
* ストラテジーはしばしばインクリメント処理のように非常に小さな処理になることがある
* その一例が>>631であり>>631馬鹿げたコードでもなんでもなく実用的なコードの断片である
という3点のことな

**デフォルトの名無しさん** · 2018/04/01(日) 20:59:08.51

>>678
λや関数オブジェクトがサポートされる言語では暗黙的にストラテジーの考え方が利用されている
そうと意識してないだけだ
ちょうどいい時期だ上司に頼んでお前も新人研修受けてこい

**デフォルトの名無しさん** · 2018/04/01(日) 21:00:23.18

何も見せてなければ何とでも言えたろうが、
>>665を見せてしまったらもう無理だな
レベルの低さが露呈してるから言い訳にもならない

正直>>665を見たあとだと>>631が優秀に見えるくらいだし

**デフォルトの名無しさん** · 2018/04/01(日) 21:03:04.23

>>680
世間一般的にstrategyというのは>>663の例を指す
お前のは違う

**デフォルトの名無しさん** · 2018/04/01(日) 21:04:15.87

>>682
君は論外なのでまた今度な

**デフォルトの名無しさん** · 2018/04/01(日) 21:11:29.38

そもそも関数の細分化は可読性を損ねるって話なのに、
抽象的で省略しまくりの名前付けてる時点でな
設計に口出すのは十年早いと思うわ

**デフォルトの名無しさん** · 2018/04/01(日) 21:17:25.87

どうでも良いが>>665をよく見るとこいつrefの使い方すら知らないど素人くさいな
値次第でループバグ起こす構造だしこんなコード実務で仕込まれたら俺ならテロ認定する

**デフォルトの名無しさん** · 2018/04/01(日) 21:22:05.92

>>685
>>673

**デフォルトの名無しさん** · 2018/04/01(日) 21:24:13.70

本気で書いたコード貶されたら

「あれは手抜きだからｗ」と言い出す

まあリアルにいるよな

**デフォルトの名無しさん** · 2018/04/01(日) 22:24:04.17

ミーティングとか言い出して露骨に話題を避けようとしてるの笑える

**デフォルトの名無しさん** · 2018/04/02(月) 09:41:43.90

皆Do()にすればええんや

**デフォルトの名無しさん** · 2018/04/04(水) 16:05:17.38

stringが参照型ってことはさ

string str;
void Reset() => str = "";

とするより

string str;
string None = "";
void Reset() => str = None;

と生成済みのテキストを使い回した方が効率良いの？

**デフォルトの名無しさん** · 2018/04/04(水) 16:35:31.54

String.Empty

**デフォルトの名無しさん** · 2018/04/04(水) 18:12:04.75

str =null;
ってやってたは・・・

**デフォルトの名無しさん** · 2018/04/04(水) 18:30:15.85

>>692
null代入するのはC#8.0で警告対象

**デフォルトの名無しさん** · 2018/04/04(水) 20:17:49.55

>>690　変わらないと思われ

string Func0(){return "test";}
string Func1(){return "test";}
string Func2(){return "te"+"st";}
string Func3(){return "TEST".ToLower();}

string a=Func1(), b=Func2();
Console.WriteLine(Object.ReferenceEquals(a,b));

**デフォルトの名無しさん** · 2018/04/04(水) 21:03:49.28

>>694が何を言いたいのかまるで理解できない

**デフォルトの名無しさん** · 2018/04/04(水) 22:46:17.62

>>693
非推奨になるのか！
って、C#5.0から変える気が無いけどもｗ

**デフォルトの名無しさん** · 2018/04/04(水) 22:48:58.58

>>690
これILはどっちも一緒の結果にならないのかね

**デフォルトの名無しさん** · 2018/04/04(水) 22:59:51.77

>>696
またvs2013使ってんの？

**デフォルトの名無しさん** · 2018/04/04(水) 23:47:32.40

>>698
Formしか使わないからね
まぁ最近はスマホが多いのもあるけど

**デフォルトの名無しさん** · 2018/04/05(木) 03:02:50.85

C#ってどんどん惨くなってねーか。業務じゃもう使えないだろ。

**デフォルトの名無しさん** · 2018/04/05(木) 08:16:57.82

アメリカではソフトウェアの内製化やクラウド化により、
ソフトウェアは自己責任でどんどんリリースできるようになってるの
自己責任ならデグレ出したらこっそり直してすぐにリリースしちゃえばいいの
SI型ビジネスとは違い、過剰にリスクを避ける必要がない
VSやC#もそういう変化に適応して開発やリリースのポリシーが変わってしまった
もうジャップランドのSIでは使えないよ

**デフォルトの名無しさん** · 2018/04/05(木) 09:34:30.77

ジャップ式業務かぁ…

**デフォルトの名無しさん** · 2018/04/05(木) 14:08:48.47

>>700
おじいちゃんには無理かな

**デフォルトの名無しさん** · 2018/04/05(木) 14:24:27.07

>>700
具体的にどこがそうなのか教えて

**デフォルトの名無しさん** · 2018/04/05(木) 14:39:36.05

リッチテキストボックスでDetectUrlsをTrueにしてハイパーリンクを開けるようにしたんだけど、
ハイパーリンクをクリックして既定のブラウザで開くと、勝手に最終行までジャンプしてしまう。
仕方がないのでEnabledをいったんfalseにして、その後開き、もう一度trueに戻すとジャンプはしなくなったんだけど、
リッチテキストボックスの任意の場所をクリックすると、やっぱり変な場所に表示が移ってしまう。
なんか対策ないでしょうか？

**デフォルトの名無しさん** · 2018/04/05(木) 14:43:10.44

＞Enabledをいったんfalseにして、その後開き、もう一度trueに戻す
ごめん何言ってるのか全然わからない

**デフォルトの名無しさん** · 2018/04/05(木) 14:44:33.22

>>706
すいません、こうです
private void richTextBox1_LinkClicked(object sender, LinkClickedEventArgs e)
{
richTextBox1.Enabled = false;
System.Diagnostics.Process.Start(e.LinkText);
richTextBox1.Enabled = true;
}

**デフォルトの名無しさん** · 2018/04/06(金) 01:34:01.86

treeViewのちらつき防止ってどうやるんだろう？
5chブラウザとか、mousemoveでテキストにアンダーラインが出るようにしても全然ちらつかないよね
ダブルバッファでいけるのかと思ったら、treeViewはそれでは解決しないようで・・・

**デフォルトの名無しさん** · 2018/04/06(金) 17:11:38.73

>>705
ミニマムコード書いて確認しろよ
クリックした位置にカーソル出ないのなら分かるが勝手に最終行までジャンプとか意味不明
あと初心者スレ池

**デフォルトの名無しさん** · 2018/04/06(金) 19:56:07.03

>>700
もうここ10年新規案件やってないな。全部Javaに持ってかれたまま。
当然といえば当然だな。老害ヘジの暴走を誰も止めることができなかった。
ID:d442a5v8　←みたいな低スキル信者の取り巻きばっかなんだろうな。

**デフォルトの名無しさん** · 2018/04/06(金) 20:07:45.08

CAD系だから低身の見物
流石にJAVAでやれと言われた事は無いな

**デフォルトの名無しさん** · 2018/04/06(金) 20:29:12.80

会社で生産管理ソフト導入したらそれ.netだった
描画はネイティブのDLLに丸投げだったけど

**デフォルトの名無しさん** · 2018/04/06(金) 20:31:28.54

業務で言えばjava : c#　=　1000　:　1　ぐらいなイメージ

**デフォルトの名無しさん** · 2018/04/07(土) 07:53:48.13

業務だと冗長でもいいからバカでも使える単純な機能だけで組まなきゃいけない
三項演算子程度のものも使用禁止
C#とは無縁の世界

**デフォルトの名無しさん** · 2018/04/07(土) 07:59:59.71

それだけじゃ足りない
どんな初心者、いろんな人が保守しても長期間にわたって大きく崩さないような土台を建てる必要がある
超絶技法で難解なプログラムを作るよりよほど難しい

**デフォルトの名無しさん** · 2018/04/07(土) 08:48:38.33

そして冗長でコピペだらけの巨大なシステムが出来上がって別の意味で保守できなくなるんだろ
業務系ってそんなシステムばっかりじゃん
誰でも読めるようにひらがなだけで六法全書を書く並みにバカ
余計わかりにくくなるだけ

**デフォルトの名無しさん** · 2018/04/07(土) 09:06:01.54

それは分かりやすさというより開発のスケーラビリティの問題
日本のSEってトップダウンのコード設計が全くできないから、
開発規模をスケールさせようとすると重複上等でなるべく個別の機能ごとに独立した形にするしかないの

**デフォルトの名無しさん** · 2018/04/07(土) 09:59:33.70

重複した分だけ開発・保守工数が増えてくから重複上等じゃスケールしないよ
あっちでバグがあった、仕様が変わった、横展開しろ、って炎上の王道パターンだよね

つかわかりやすさの問題だ
言語機能は便利でわかりやすいから追加された
それを使わないということはそれだけわかりにくくなるということ

ベタなループ書くよりLinqの方がわかりやすいからLinqが発明された
そういうこと