科学的コードは、一般的なコーディング標準を無視するのに十分な領域ですか？

最近、次の事実について心を包もうとしています。

一方では、「健康」、「クリーン」、「よく書かれた」などのコードと見なされるものについて、コーディングのガイドラインと標準が多数あります。ここでも広く議論されているように見える「クリーンコード」を参照してください。ルールの例：7行の長いメソッドと1または2レベルのインデント。従わないコードは、どういうわけか保守性が悪いために死ぬことが予想されます。

一方で、OpenCV、OpenCascade、VTKなどと連携するようになりました。これは科学的なコードです。彼らは2ページの長いメソッドを持っています（私自身）、OpenCascadeには10個のファイルに分割されたメソッドまたはクラスがあります（ここではジョークはありません）、VTKも混乱することがあります。しかし、これらのプロジェクトは繁栄し、維持され、広く使用されています！

キャッチはどこですか？科学的で数学が重いコードを、それが機能するように書くことは許されていますか？あなたは、もしあれば、そのようなプロジェクトのための独立した標準のセットですか？

素朴な質問かもしれませんが、私は物事を行う方法としない方法を設定しようとするプログラミングの無効のようです。これは高校で働くことを教えられた方法です。私は卒業して以来、私がやらなければならないこと、主にプログラミングについてのガイドラインのサポートがほとんどありませんでした。

科学的コードは、一般的なコーディング標準を無視するのに十分な領域ですか？

いいえ、ちがいます。

多くの場合、研究コードは「捨て去られ」、バックグラウンドで開発者ではない人によって書かれますが、学問的な信任は強いものです。私が書いた研究コードのいくつかは、私を泣かせるでしょう。しかし、うまくいきました！

考慮すべきことの1つは、プロジェクトのゲートキーパーが含まれるものを推進することです。大規模なプロジェクトがアカデミック/研究コードプロジェクトとして開始され、最終的には機能しなくなり、混乱になった場合、誰かが率先してリファクタリングする必要があります。

問題を引き起こしていない既存のコードをリファクタリングするには多くの作業が必要です。特に、ドメイン固有であるか、テストがない場合。あなたはいることがわかりますOpenCVのは、スタイルガイドがある完璧ではない場合でも、非常に包括的です。これをすべての既存コードに遡及的に適用しますか？それは..弱い人のためではありません。

すべてのコードが機能する場合、これはさらに困難です。壊れていないからです。なぜそれを修正するのですか？

しかし、これらのプロジェクトは繁栄し、維持され、広く使用されています！

これはある意味での答えです。作業コードは依然として有用であるため、維持される可能性が高くなります。

特に最初は混乱するかもしれません。これらのプロジェクトの一部は、おそらく「一度も再利用する必要はなく、捨てることができる」という1回限りのプロジェクトとして開始されたでしょう。

また、複雑なアルゴリズムを実装している場合、あなた（および科学的な側面に精通している人）はアルゴリズムを概念的によく理解できるため、より大きなメソッドを使用する方が理にかなっていることも考慮してください。私の論文の仕事は最適化に関連していました。メインアルゴリズムロジックを1つの方法として持つことは、それをバラバラにしようとするよりもかなり簡単に理解できます。確かに「メソッドあたり7行」ルールに違反していましたが、別の研究者が私のコードを見て、アルゴリズムへの変更をより迅速に理解できることも意味していました。

この実装が抽象化され、適切に設計されていれば、この透明性は非プログラマーには失われます。

仲間の回答者へ：この質問は、1つ以上の科学分野で計算集約的なタスクを行うためのオープンソースライブラリのコードベースを指します。この質問は使い捨てコードに関するものではありません。答えを書く前に、強調表示されているすべての側面を把握してください。

多くの人は、すべてのオープンソースプロジェクトが「ひどく人気があり、数千/数百万人が使用するライブラリの素晴らしいアイデアを持っている」と考え、すべてのプロジェクトがそのようになるという考えを持っていると思います。

現実には、多くのプロジェクトが開始されて終了します。プロジェクトの途方もなく小さな割合が、OpenCVやVTKなどのレベルに「到達」しています。

OpenCVは、Intelの研究プロジェクトとして始まりました。ウィキペディアでは、「一連のプロジェクト」の一部であると説明しています。最初の非ベータ版のリリースは2006年、つまり最初のリリースから7年後です。当初、目標は完全なコードではなく、意味のあるベータリリースであったと思われます。

さらに、OpenCVの「所有権」が大幅に変更されました。これにより、すべての責任者がまったく同じ標準を採用し、プロジェクトの期間中それらを維持しない限り、標準が変更されます。

また、OpenCVは、Clean Codeからインスピレーションを得たアジャイル宣言が公開される（およびVTKがほぼ10年になる）前に数年間存在したことを指摘する必要があります。VTKは、Clean Codeの公開の17年前に開始されました（OpenCVは9年前の「唯一」でした）。

科学者は開発者ではありません。彼らの仕事は、コード自体を書くことではありません。彼らの仕事は問題を解決することであり、プログラミングは彼らが使用するツールの1つにすぎません。

プロの開発者によって書かれたほとんどのエンタープライズコードは、プロの開発者が混乱しています。このコードのほとんどは、デザインパターンを使用したり、それらを誤用したりしません。ほとんどのコメントはTheDailyWTFの候補です。私たちの業界では、コードを書くことを仕事とする人々からそのような結果が得られるので、プログラムを書くことを仕事としない人々から何を期待しますか？

実際のプロの開発者が彼女のキャリアの間に学ぶすべての実践は科学者に利益をもたらすでしょうか？絶対に。すべての科学者がソフトウェア開発の学習に5〜10年を費やすことは可能でしょうか？おそらくない。したがって、コードの品質はそのままです。

別の要因は文化です。あなたのペアがきれいなコードを書かないなら、なぜでしょうか？誰も気にしないので、あなたは本当に余分な努力をする傾向はありません。

最後に、ほとんどの科学的コードの寿命は比較的短いです。特定の調査用のコードを作成し、調査が完了したら、コードを再利用しません。この習慣を身に付けたら、引用するライブラリなどの再利用可能なライブラリとコードを捨てるコードを区別するのは困難です。

無視しますか？いいえ。再検討して調整しますか？はい。科学的なコードの多くは、数学を集中的に使用し、パフォーマンスが重要です。関数呼び出しのオーバーヘッドなどは実際に問題になる可能性があるため、一般的な商用アプリで見られるよりも深くネストされた構造になる可能性があります。だからといって、最初に1000個のマイクロ最適化に飛び込む必要があるわけではありません。適切なアルゴリズムの選択に引き続き焦点を当て、効果を測定できる最適化のみを行う必要があります。

いくつかの違いは明らかであり、些細なものです。コーディングガイドラインでは、通常、意味のある変数名を選択する必要があり、1文字の名前はすぐに疑われます。科学的なアプリケーションには意味のある変数名が必要ですが、最も意味のある名前は1文字で、よく知られている方程式の変数を参照する場合があります。

既存の回答はすべて、この質問を包括的にカバーしていました。ただし、OpenCVなどの真の対極とは何かを指摘したいと思います。たとえば、優れたビジネスプラクティス（コードの完成、クリーンコード、SOLIDなど）に従って開発されたコードとは異なります。

一般に、ソースコードがKISSであると、ビジネス上の利点が多くあります。「シンプルに、愚かにしてください」。関連するYAGNI- 「あなたはそれを必要としません」もあります。

残念ながら、科学領域の計算集約型ソフトウェアの場合、ソースコードはめったに単純または無駄がありません。

従来、OpenCVは一般化の欠如（さまざまなオプションをサポートするためのコードの重複）に悩まされていましたが、VTKは過度の一般化（テンプレート）に悩まされていました。

初期の頃、OpenCVの特定の部分はもともとCで開発されていました。その後、OpenCVは今日よく知られているC ++ APIを採用しました。一部のアルゴリズムは、C ++インターフェイス（抽象基本クラス）およびC ++テンプレートを利用するように書き直されています。他のアルゴリズムは、元のCコードの単なるラッパーでした。これらのコードの残りは、「imgproc」モジュールに散らばっています。

OpenCVには、多くのSIMDプログラミング（ベクトル化）が含まれています。現在まで、C ++のSIMDプログラミングでは、組み込み関数（intel.com）、（arm.com）の使用が必要です。

SIMD組み込み関数はアセンブリ言語のように読み込まれますが、コンパイラが変数のレジスタ割り当てを処理し、コンパイラがパフォーマンス向上のために命令の順序を自由に入れ替えることができる点が異なります。SIMD組み込み関数を使用するように記述されたアルゴリズムは、保守コストが高くなりました。これが私が以前に尋ねた質問に言及した理由です-SIMDプログラミングコードベースのメンテナンスコスト。

SIMDプログラミングを行っていない人は、SIMDをエレガントにカプセル化でき、低レベルのSIMDプログラミングはもう必要ないはずだと簡単に信じてしまうかもしれません。これは実際には真実とはかけ離れています。フラクタルではなく、SIMDで有用なアルゴリズムを実装して、これらの提案されたカプセル化の使いやすさを確認してみてください。

以下は、計算ソフトウェアがKISSやYAGNIになれない理由を分析しようとする際のアイデアの長いリストです。ただし、これらのアイデアはすべて過度に一般化されており、上記の見解を支持していないようです。

主な要因は次のとおりです。

• ソフトウェア性能
• 多くのアルゴリズムオプションとトレードオフをサポートする必要性
• 多くの異なるハードウェアプラットフォームとコンパイラをサポートする必要性
  • これは、ソフトウェアのパフォーマンスの問題を悪化させます。多くのハードウェアプラットフォームとコンパイラにとって、パフォーマンスは良好である必要があります。
• リソースの不足、他の要因を損なうことなくコードの品質を向上させることができる知識のある人の不足などによる、進行中のコードベースの近代化の欠如。
  • オープンソースプロジェクトは、コモンズの悲劇に苦しんでいます。
  • 助成金を受け取るオープンソースプロジェクトは、特定の成果物を満たす必要がありました。通常、コード品質はその一部ではありません。
  • 特に、段階的なコード品質の改善を行ったり提案したりできる知識のある人さえ不足しています。これは「見当たらない」問題です -多くの人がコードの恩恵を受けていますが、コードを読むのに時間がかかった人はほとんどいません。
• コードレビュー、単体テスト、静的分析などのコード品質ゲートの歴史的欠如。
  • 大規模プロジェクトの場合、これらのコード品質ゲートは単なる手動の手順ではありません-それぞれにインフラストラクチャ（Webベースのシステム、単体テストシステム、ビルド自動化システムなど）が必要になります

上記の要因のいくつかは、ビジネスソフトウェア開発に対抗するものです。

• 通常、ビジネスソフトウェアは、計算ソフトウェアで見られるのと同じ高いデータスループットを処理する必要はありません。
• ビジネスソフトウェアは、単一のオペレーティングシステムとコンピューターアーキテクチャに関連付けることができます。
• ビジネスソフトウェアは、含める機能を決定する際にin約することができます。実際、ビジネスソフトウェアの開発では、適切なビジネスケースがない限り、管理者は新機能に反対することを推奨しています。
  • 社内ビジネスソフトウェアのユーザーは、コードを変更する必要を回避して、物事を異なる方法で行うようにトレーニングできます。
  • 商用ビジネスソフトウェアが1つの機能が欠落しているために1人の顧客を失い、シンプルさと使いやすさの改善により2人の新しい顧客を獲得した場合（「選択のパラドックス」を参照）、全体としては純益です-良いこの1つの機能が欠落していること。
• ビジネスソフトウェアは継続的な収益源によってサポートされているため、継続的なコードベースの近代化にその一部を費やすことができます。

科学的コードは、一般的なコーディング標準を無視するのに十分な領域ですか？

「一般的なコーディング標準」と呼ぶものに依存します。アジャイルの両極端を「普通」とは呼びません。特に、8行の長さが長すぎる関数、または2レベル以上のインデントが複雑すぎる関数は、数値/科学プログラミングの分野ではとんでもない基準です。

非常に単純な行列と行列の関数は7行以上であり、3レベルのインデントがあります。この関数は、効率を心配する必要がある場合よりもかなり複雑になります。これは非常に一般的な操作であるため、効率が重要です。それを細分化することは、あなたがしたくないことです。マトリックス分解はさらに複雑になります。

私はこれを新しい答えとして投稿することにしました。これはまったく異なる視点だからです。

コンピュータービジョンと画像理解の観点から、「クリーンコード」と見なすコードサンプルを見てみましょう。

https://github.com/opencv/opencv/blob/05b15943d6a42c99e5f921b7dbaa8323f3c042c6/modules/photo/src/seamless_cloning_impl.cpp

MATLABと科学計算に精通している人にとって、C ++のコードは、可能な限りクリーンなMATLABコードと同じくらい簡潔です。

ここで、なぜライブラリ全体のコードベース（この例ではOpenCV）がこのサンプルコードと同じ標準に書かれていないのかを尋ねる必要があります。

大規模な科学図書館のコードベースを抽象化レベルに階層化する必要があります。

で低レベル、あなたは再実装加減算文字通りです。または、各プラットフォームで文字通り、各操作を最速の実装に再マッピングします。

https://github.com/opencv/opencv/blob/master/modules/core/src/hal_replacement.hpp

中間レベルは、「最も汚い」コードを見つける場所です。このコード内で、CPU実行時間の80％〜90％が費やされる可能性があります。（同様に、科学研究とは別にソフトウェア開発の取り組みを数えると、開発努力の80％-90％が中間レベルで費やされた可能性があります。）

でハイレベル、我々は研究者によって書かれたきれいなコードを持っています。

これらのレベルが混在しないようにするために、ソースコードの編成における強力な卓越性が必要です。これはコーディング標準を超えていて、オープンソースのスチュワードシップに関係しています。

たとえば、1つのオープンソースプロジェクトを2つに分割することが決定される場合があります。これらのことをコードのコミットで実現することはできません。