アカウント名:
パスワード:
「一画面に収まらない関数はダメ」とか、「ネストが深ければダメ」とか、これって処理内容を無視した評価基準ではないでしょうか。処理内容によっては、そういったやり方がベストな場合もあると思います。
オブジェクト指向にしてもそうです。アクセッサを使わずに、変数をpublicで公開しても良い場合もあると思います。変数のチェックをしない場合のアクセッサには、どれほどの意味があるのでしょうか？多態性を使わずにswitchで切り替えたほうがシンプルな場合もあります。staticなpublic関数？大いに結構じゃないですか、シンプルで最もオーバーヘッドが小さな実装法だと思います。
画一的な基準で評価するのは工学的アプローチと言えますが、ソフトウェアは芸術的・職人的な側面もありますから。
一画面というのは変な基準だと思いますがネストが深いのは改善すべきだと私の心のメトリックスは言ってます。ネストを浅くする何らかのロジック変更が効率がよくわかりやすくなることが多いです。経験上ね。
実際、ネストが深くなりすぎると”大本（1階層目）の判定基準がなんだったか解らなくなりがち”ですからね。特に他人のコードだと。
1画面も変な基準ですが、余りに階層が深くなったり、IFの中が長すぎるなら、関数化して、大本には何をしたいか、何を関数化したかコメントした方が、可読性は上がると思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
杓子定規な評価基準 (スコア:3, 興味深い)
「一画面に収まらない関数はダメ」とか、「ネストが深ければダメ」とか、これって処理内容を無視した評価基準ではないでしょうか。
処理内容によっては、そういったやり方がベストな場合もあると思います。
オブジェクト指向にしてもそうです。
アクセッサを使わずに、変数をpublicで公開しても良い場合もあると思います。
変数のチェックをしない場合のアクセッサには、どれほどの意味があるのでしょうか？
多態性を使わずにswitchで切り替えたほうがシンプルな場合もあります。
staticなpublic関数？大いに結構じゃないですか、シンプルで最もオーバーヘッドが小さな実装法だと思います。
画一的な基準で評価するのは工学的アプローチと言えますが、ソフトウェアは芸術的・職人的な側面もありますから。
Re:杓子定規な評価基準 (スコア:1)
一画面というのは変な基準だと思いますが
ネストが深いのは改善すべきだと私の心のメトリックスは言ってます。
ネストを浅くする何らかのロジック変更が効率がよくわかりやすくなることが多いです。
経験上ね。
Re: (スコア:0)
実際、ネストが深くなりすぎると”大本（1階層目）の判定基準がなんだったか解らなくなりがち”ですからね。
特に他人のコードだと。
1画面も変な基準ですが、余りに階層が深くなったり、
IFの中が長すぎるなら、関数化して、大本には何をしたいか、何を関数化したか
コメントした方が、可読性は上がると思います。