アカウント名:
パスワード:
>「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われた。
ケースバイケースなんだけど特に業務ロジックなんかはこれで良いと思う。どうせ業務的な機能単位・業務的な処理単位に分けても再利用なんてしないんだし、その可能性もまず無い。
気ぃ効かせてわけたつもりでもどうせ上から下まで一直線のロジックなのにあっちこっち飛んで読むのめんどくさいだけ。IDEの機能使えばまぁ追えるけどさ、わざわざセンスの無いメソッド名と引数名付けてわけられてもね。変更あったときも修正に手間かかるし。そのくせ、小さいIF文で同じことの繰り返しなんかは抽象化してメソッドにわけれるのにやってない。メソッドの先頭に全部ローカル変数定義してる。
なんてコードだらけのプロジェクトもあるわけです。
だらだら長くても変数のスコープが最小化されていて、無闇やたらローカル変数を切らないで適切に書けば読みにくくはならないし手間もかからないんですよ。変にオブジェクト指向っぽくしようとするのは無意味。最終的に出来上がった数々の部品の組み合わせてだらだら並べたバッチ処理みたいのが読みやすい業務ロジックじゃないですか?
そういえば三項演算子はわかりにくいから使うなっていうところがあったな。DECODE(ORACLEのSQL)はOKなのに。
.NETで全メソッドを全部try~catchで囲めとか。折角の例外情報を捨てて上位にスローすれと。try~catchで囲まないと他の囲っているところと違うから保守性が落ちるとか。例外情報捨てたら保守性ガタ落ちだっつーの。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
業務ロジックの場合 (スコア:2)
>「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われた。
ケースバイケースなんだけど特に業務ロジックなんかはこれで良いと思う。
どうせ業務的な機能単位・業務的な処理単位に分けても再利用なんてしないんだし、その可能性もまず無い。
気ぃ効かせてわけたつもりでもどうせ上から下まで一直線のロジックなのにあっちこっち飛んで読むのめんどくさいだけ。IDEの機能使えばまぁ追えるけどさ、わざわざセンスの無いメソッド名と引数名付けてわけられてもね。変更あったときも修正に手間かかるし。
そのくせ、小さいIF文で同じことの繰り返しなんかは抽象化してメソッドにわけれるのにやってない。
メソッドの先頭に全部ローカル変数定義してる。
なんてコードだらけのプロジェクトもあるわけです。
だらだら長くても変数のスコープが最小化されていて、無闇やたらローカル変数を切らないで適切に書けば読みにくくはならないし手間もかからないんですよ。
変にオブジェクト指向っぽくしようとするのは無意味。
最終的に出来上がった数々の部品の組み合わせてだらだら並べたバッチ処理みたいのが読みやすい業務ロジックじゃないですか?
そういえば三項演算子はわかりにくいから使うなっていうところがあったな。DECODE(ORACLEのSQL)はOKなのに。
.NETで全メソッドを全部try~catchで囲めとか。折角の例外情報を捨てて上位にスローすれと。try~catchで囲まないと他の囲っているところと違うから保守性が落ちるとか。例外情報捨てたら保守性ガタ落ちだっつーの。