クリーンコードの原則を関数型言語に適用する

現在、Robert MartinのClean Codeを読んでいます。私はそれが素晴らしいと思うし、OOコードを書くとき、私は彼の教訓を心に抱いている。特に、意味のある名前の小さな関数を使用するという彼のアドバイスは、コードの流れをよりスムーズにするものだと思います。次の引用文で簡単に要約できます。

[W] eは、TO段落のセットであるかのようにプログラムを読むことができます。各段落は、現在の抽象化レベルを記述し、次のレベルで後続のTO段落を参照します。

（クリーンコード、37ページ：「TO段落」は、不定詞で表明された文で始まる段落です。「Xを実行するには、ステップYとZを実行します。」「Yを実行するには、...」など。 ） 例えば：

RenderPageWithSetupsAndTeardownsでは、ページがテストページであるかどうかを確認し、テストページである場合は、セットアップとティアダウンを含めます。どちらの場合でも、ページをHTMLでレンダリングします

私は自分の仕事のために機能的なコードも書きます。この本のMartinの例は、まるで段落のセットであるかのように読んでおり、非常に明確です。 。

Haskell標準ライブラリから例を取り出します：

maximumBy               :: (a -> a -> Ordering) -> [a] -> a
maximumBy _ []          =  error "List.maximumBy: empty list"
maximumBy cmp xs        =  foldl1 maxBy xs
                        where
                           maxBy x y = case cmp x y of
                                       GT -> x
                                       _  -> y

これは、Martinのアドバイスから得られる限りのことですが、それは簡潔で慣用的なHaskellです。彼の本のJavaの例とは異なり、私はそれを彼が要求する一種のリズムを持つ何かにリファクタリングする方法を想像することはできません。Clean Codeの標準に基づいて書かれたHaskellは、長く風変わりで不自然なものになると思います。

関数型プログラミングのベストプラクティスと対立するクリーンコード（少なくとも一部）を検討するのは間違っていますか？彼が言うことを別のパラダイムで再解釈する賢明な方法はありますか？

Clean Codeは何よりもスタイルマニュアルです。あなたがクリンゴン語で書いているとき、Strunk and Whiteは適用されません。考えは、コードを読む可能性が高いプログラマーに明確にしたいということです。モジュール化され、再構築しやすいコードが必要です。他の言語でこれを行う方法があるのと同じように、Haskellでこれを行う方法がありますが、正確な詳細は異なります。

そうは言っても、いくつかのスタイルがあります はいえ、Haskellにガイドラインがあります。スタックオーバーフローにもかなり包括的なガイドがあります。コーディングロジックを簡潔かつ簡潔に保つことは、ほぼ一定のようです。モジュール化につながるため、関数の一般化も強調されます。DRYコードも、Clean Codeと同様に強調されます。

最終的に、Clean CodeとHaskellのコーディングガイドラインは同じことを目指していますが、そこにたどり着くために独自の道を歩むことになります。

あなたがあなたの例で意味するものに従うかどうかはわかりません。パラグラフは、彼が説明しているように、長続きする必要はありません。彼は、コードが英語のように読まなければならないという意味ではありません。重要な部分は、論理レベルで同じレベルの抽象化で機能をグループ化することです。それはプログラミングのパラダイムを超越する理論的な構造概念です。

Bob Martinの「TOパラグラフ」形式で表現された、私はあなたの例を次のように読みました。

• を計算するにはmaximumBy、順序付け関数とリストが必要です。結果はそのリストの要素です。
• を計算するには maximumBy空のリストと順序付け関数はエラーです。
• maximumByリストのを計算するには、リストxsを折りたたみますmaxBy関数ます。
• maxBy2つのリスト要素を計算するには、指定された順序付け関数を使用してそれらを比較します。最初の要素が大きい場合は、それを選択します。それ以外の場合は、2番目を選択します。

命令型の例のように、最も一般的な概念から始めて、より詳細に進みます。「TO段落」のアイデアは、ページを上下にジャンプすることなく、十分な詳細が得られたときに特定の時点で読み上げを停止できるということです。確かにそうです。

おそらくいくつかの名前の方が優れている可能性がありますが、特に一般的な高階関数を作成する場合は、言語の一般的な規則です。高階関数名は、本の例のような命令動詞句にもうまく変換されません。なぜなら、それらは動詞間の関係をより詳しく説明しているからです。

「TOパラグラフ」ガイドラインに従わないこれを実装する方法があります。明示的な型署名を省略すると、上位レベルの「概要」文が省略されます。パターンマッチングの代わりにエラー処理にif式を使用できます。これにより、別の抽象化レベルで不適切に調整されます。インラインできますmaxBy後で詳細に説明できる名前を付ける代わりに、匿名関数としてます。

実際には、私のような構築物は考えるwhere実際に、より良いあなたは近い私たちは英語でそれを表現する方法だ方法で、より深く詳細に名前を与えるためにそれらを使用し、同様にAでその範囲を制限することができるので、段落のフォーマットに適し「段落」の文脈への明確な方法。