就个人而言，我认为 LabView 是一个出色的程序，它的设计目的是。除了继承糟糕的代码（这在任何语言中都是一个问题）之外，通过良好的实践，它可以非常有效且快速地将各种过程控制、自动化、测试和测量系统组合在一起。与文本编码一样，LabView 也存在良好的实践——如果你有一个乱七八糟的 VI，那么这真的是编码器的错，而不是语言的错。文本编码的语言也会变得非常混乱 - 程序员有责任不创建不必要的混乱或混淆代码。
如果您开始编写代码时考虑到未来的扩展，那么创建可以随程序需求增长而不会变得麻烦的 VI 一点也不难。就像糟糕的文本代码很快就会变得一团糟，如果你用短期的眼光来破解它，只会让它自己长大并变得无法维护。但是，这确实意味着您必须花时间学习 LabView，就像您必须花时间学习任何语言或 IDE 一样。
如果 LabView 让您的工作受挫，您可能应该使用其他东西来创建程序，或者至少为程序的这些组件使用其他东西。
例如，如果你需要做大量的字符串处理——比使用 LabView 的字符串函数更方便破解——但你真的想要或需要使用 LabView 来处理你的应用程序，那么有很多选项可供你选择. 您可以轻松地用 C 或任何您喜欢的语言编写 DLL，然后通过 LabView 的 DLL 接口访问这些函数。这适用于使用基本 LabView 工具难以实现的任何类型的高级或抽象功能。
这有两大优势 - 首先，您可以将文本编码集中在简单地编写函数或过程上。围绕您的函数构建应用程序的任务变得不存在。通过将它与 LabView 混合，您可以获得 LabView 快速而强大的 UI 构建器和仪器连接的第二个优势。
在源代码控制方面，您可以做的最大的事情就是发挥 LabView 固有的模块化能力。虽然您没有文本工具来帮助您，例如在尝试整理未知的继承代码时，但它确实具有其他非常强大的功能，这些功能以抽象的方式可以做许多相同的事情。它可能是现存的最容易重构的语言，这意味着，一般来说，重构继承的代码可以在您学习它的作用时完成。
例如，如果您转到数据源并断开线路，您会立即看到它连接到的所有内容。错误列表将为您提供因依赖该数据源而损坏的所有内容的完整列表，您可以立即创建包和集群以清理 LabView 意大利面条。它甚至会在后面板上突出显示损坏的数据连接，以便您跟踪所有内容的去向。如果很明显它们在主进程中乱扔垃圾等，您可以快速将它们封装在子 VI 中。当您弄清楚代码的作用时，它已经干净整洁并且突然可以重新维护。
最大的例外是程序使用了很多不必要的全局变量。惊喜 - 全局变量也使 LabView 中的事情变得复杂。在那种情况下，除了诅咒让你一团糟的笨蛋，别无他法。尽管如此，这还不是世界末日。
我想，简而言之，我想说的是 LabView 是一种非常不同的语言。如果这看起来令人沮丧，那并不是因为没有工具来完成您在文本编码中习惯的事情，而仅仅是因为它们通常以完全不同的方式实现。例如，Grepping 代码本身并不是目的，而只是达到目的的一种手段——目的是发现整个程序的链接和引用。虽然您无法 grep LabView 代码，但您可以发现链接和参考资料——只是以完全不同的方式完成。学习曲线的东西。