erukitiのmiscなやつ

雑にいろいろ

その事例だとコメントは不要だと思います

「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話 - 土屋つかさのテクノロジーは今か無しか および 「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話(補足編) - 土屋つかさのテクノロジーは今か無しかで、計算式の意図を説明するためにコメントを書こうぜという主張が書かれてますが、この内容だと全く賛同できませんね。別にコメントを全否定するわけではありませんが、この主張の例だと不適切です。

//フェードインが未完了の場合
if (alpha < 1.0f){
 //処理A
}

元記事の主張は、alpha < 1.0f という計算式はコメントなしでは本来の意味であるフェードインが未完了の場合、というものがさっぱりわからないということでした。つまり意味情報の欠落を問題にしています。

const isFadeinCompleted = () => alpha < 1.0
if (isFadeinCompleted()) {
  //処理A
}

これでいいのでは?jsっぽいコードサンプルとのことなので、普通にアロー関数でラムダ式書くだけでいいですね。これならコメント一行増えるのと、それほど手間変わらないし、名前空間汚染なんてのも発生しません。ちなみにisFadeinCompletedに引数を指定するまでやるかどうかはぶっちゃけどっちでもいいと思います。

まぁ案3でもかまわないと思います。一度変数に結果を格納するというのは、普通にリファクタリングで使われるテクニックでもありますし、なぜそこに抵抗を感じるのかが不思議ですね。

あと、id:ono_matope さんが言うような、isFadeinCompletedalpha < 1.0を結びつけるのがいやだということなら、二段階で定義すればいいだけですね。

const isTransparent = () => alpha < 1.0
const isFadeinCompleted = () => isTransparent()
if (isFadeinCompleted()) {
  //処理A
}

追記:

OkadaHiroshi id:erukiti の const isFadeinCompleted = () => alpha < 1.0 と書くのは、この定義を宣言の有効範囲外に出るまで覚えていなくてはならない、頭のスタックを余計に消費するのは避けたい。関数化するかは行数でなく抽象化できるかだ。

id:OkadaHiroshi さんのブコメですがここにて。alpha < 1.0という式にisFadeinCompletedという意味(名前)を与えるというのはごく自然だと思います。(命名が正しいかどうかとかはいったん棚上げにしておく)

頭のスタックということであれば、そもそもその関数(メソッドかもしれないけど)が長すぎるのでは?適切な分量の関数であれば、constのスコープが問題になるとは考えにくい。むしろその状況であればほかの変数も危険ですね。リファクタリングにおける「臭い」ではないですか?

冒頭に書いた通りコメントのすべてを否定するつもりはありませんが、不要なコメントに頼らざるを得ないのは、筋の悪い設計をしている可能性が高そうです。

if 文の次の文を読む時も頭の片隅に isFadeinCompleted が定義されていることを覚えてなくてはならない、関数の長さではない。気にならないのは無自覚になっているだけで思考のリソースを浪費しているのでは。

const hoge = () => {
    ...(1)
    const isTransparent = () => alpha < 1.0
    if (isTransparent()) {
        ...(2)
    }
    ...(3)
}

僕が言った関数の長さはconst isFadeinCompletedの定義されている関数のほうです。つまり、こういうコードだとすればhogeの長さ次第だという主張です。isTransparentという変数が増えて気になってしまう状況というのは、(1), (2), (3)が長すぎる事例ではないでしょうか?特に(3)です。

その場合、(もちろん状況に応じてですが)、hoge自体にリファクタリングが必要になるはずです。たかだか一つのconstが増える程度で問題になる状況ならば、おそらくhogeもテスタブルではないでしょうね。ユニットテストの観点からもリファクタリングにおける「臭い」があるはずです。

コメントを一つへらすためにラムダ式を一つ持ち出すのは、プラマイで言えばマイナスだと考えます。単純に改訂前の方が簡単に読める。(文化依存の見解です)

プラマイに関しては見解の相違っぽいのでおいておきますが、文化依存という点は賛同します。書いてる言語や設計アーキテクチャ(ブコメだとDDDの話もありました)などによります。

僕も思想・設計判断(特にwhy)を何らかの形で文章化すべきで、むしろ重要度は高いと思っています。