個人的には、LabView は設計された目的に対して優れたプログラムだと思います。どの言語でも問題となるひどいコードの継承は別として、優れた実践により、あらゆる種類のプロセス制御、自動化、テスト、および測定システムを非常に効率的かつ迅速にまとめることができます。テキスト コーディングと同様に、LabView を使用した良い方法もあります。ごちゃごちゃした乱雑な VI がある場合、それは言語ではなくコーダーのせいです。テキストコード化された言語も非常に混乱する可能性があります.不必要に混乱したコードや難読化されたコードを作成しない責任はプログラマにあります.
将来の拡張を念頭に置いてコードを書き始めれば、煩雑になることなくプログラムのニーズに合わせて拡張できる VI を作成することはまったく難しくありません。短期的な視点でハッキングすると、悪いテキスト コードがすぐに混乱するのと同じように、それ自体が大きくなり、保守できなくなります。ただし、言語や IDE を学ぶのに時間をかける必要があるのと同じように、LabView を学ぶのに時間をかける必要があることを意味します。
LabView があなたの努力を挫折させるなら、プログラムを作成するために何か他のものを使用するか、少なくともプログラムのそれらのコンポーネントのために何か他のものを使用する必要がある可能性があります。
たとえば、多くの文字列処理を行う必要がある場合 (LabView の文字列関数をハックするのは便利ではありません) が、アプリケーションの本質に LabView を本当に使用したい、または使用する必要がある場合は、多くのオプションが用意されています。 . DLL は、C などの好きな言語で簡単にコーディングでき、LabView の DLL インターフェイスを介してこれらの関数にアクセスできます。これは、基本的なLabViewツールで実装するのが難しい、あらゆる種類の高レベルまたは抽象関数に当てはまります.
これには 2 つの大きな利点があります。1 つ目は、テキスト コーディングを単に関数やプロシージャの記述に集中できることです。関数を中心にアプリケーションを構築するタスクは存在しなくなります。これを LabView と組み合わせることで、LabView の迅速で強力な UI ビルダーと計測器の接続性という 2 つ目の利点が得られます。
ソース管理に関して、あなたができる最大のことは、LabView の固有のモジュール性能力を柔軟にすることです。たとえば、未知の継承されたコードを整理しようとするときなどに役立つテキストツールはありませんが、抽象的な方法で同じことの多くを実行できる非常に強力な機能が他にもあります。おそらくリファクタリングが最も簡単な言語です。つまり、一般に、継承されたコードのリファクタリングは、その機能を学習しているときに実行できます。
たとえば、データ ソースに移動してワイヤを切断すると、接続されていたすべてのものが即座に表示されます。エラー リストには、そのデータ ソースへの依存が原因で壊れたすべての完全なリストが表示され、LabView スパゲッティをクリーンアップするためのバンドルとクラスターの作成にすぐに取り組むことができます。背面パネルの破損したデータ接続も強調表示されるため、すべてがどこにあるのかを追跡できます. サブ VI がメイン プロセスを混乱させていることが明らかな場合は、サブ VI にすばやくカプセル化することができます。
これに対する大きな例外は、プログラムが多くの不要なグローバルを使用した場合です。驚き - グローバルは LabView でも物事を複雑にします。その場合、あなたを混乱させた愚か者を呪うしかありません。それでも、それは世界の終わりではありません。
要するに、私が言おうとしているのは、LabView は非常に異なる言語であるということです。イライラするように思われる場合、それは、テキスト コーディングで慣れ親しんだことを行うためのツールが存在しないからではなく、単純に、それらが根本的に異なる方法で実装されていることが多いためです。たとえば、コードを grep すること自体が目的ではなく、目的を達成するための手段にすぎません。目的は、プログラム全体のリンクと参照を発見することです。LabView コードを grep することはできませんが、リンクや参照を見つけることはできます。これはまったく異なる方法で行われます。曲線の学習。