線形コードのほうが読みやすい

• Google Testing Blog が示した観点に異議を唱え、線形コードの可読性について論じる記事
• 著者は、抽象化レベルを分離した関数のほうが可読性が高いという Google Testing Blog の主張に同意しない
• 著者は、上から下へ読める線形コードのほうが、さまざまな抽象化レベルの間を行き来するコードよりも直感的で理解しやすいと主張
• 著者はピザを焼く関数の例を挙げて自説を説明し、ピザを焼く関数がオーブンを温めるのか、それともオーブンをあらかじめ予熱しておくべきなのかという疑問を提起
• 著者は、コードの可読性は抽象化レベルを分離する構造そのものによるのではなく、コードの各部分が何をするのかを明確に説明していることによるものだと提案
• 著者は線形コードから小さな関数を抽出することに反対しており、特に一度しか使われない場合には、その利点は線形性の喪失を相殺できないと結論づける
• 著者はまた、ピザを焼く関数に関する潜在的な問題も指摘し、ピザを作るたびに新しいオーブンが生成される理由に疑問を呈しており、これは実際のコードでは性能上の問題を引き起こす可能性がある
• 著者は、オーブンは関数の引数であるべきで、その提供は呼び出し側の責任であり、関数はピザではなく箱を返すべきだと提案

[GN⁺]

Hacker Newsの意見

• 線形コードとモジュール式コードの可読性はスタイルの問題であり、優れた判断力とセンスが必要です。
• 過度な抽象化は、コードの早期結合を招く可能性があります。
• 作業単位を抽象化するために関数を抽出することは、アルゴリズムを整理できますが、慎重に使うべきです。
• 提示されたサンプルコードは単純で、拡張性に欠けます。再利用性や単体テストのしやすさも考慮すべきです。
• 過度なリファクタリングは、コードの別の部分を移動する必要が生じるため、保守をかえって難しくすることがあります。
• 線形コードは実行順序に従うため読みやすい一方で、大規模なコードベースでは拡張性に欠けます。
• 深くネストしたコールスタックを持つ簡潔な関数は、大規模なコードベースでは悪夢になり得ます。
• 良い線形コードは読みやすい一方で、保守やテストはより難しくなります。
• 関数は可能な限り小さく保ち、単一の目的に近づけるのが良い実践です。
• コードの構造は、移動しやすいようにビジネス上のユースケースに合わせて構成されるべきです。
• 線形コードもモジュール式コードもどちらも線形に読めますが、関数の順序は可読性に影響することがあります。
• 実際のコードはしばしばより複雑であり、読者が詳細に迷い込まないよう、高レベルの概要が必要です。