个人认为，LabView是一个非常优秀的程序，它可以高效快速地组合各种过程控制、自动化、测试和测量系统。除了继承糟糕的代码（这在任何语言中都是一个问题），通过良好的实践，LabView非常高效。就像文本编码一样，LabView也存在着良好的实践方法 - 如果你有一个混乱的VI，那么这真的是程序员的问题，而不是语言的问题。文本编码语言也可能变得非常混乱 - 责任在于程序员不要创造不必要的混乱或难以理解的代码。
如果您从未使用过LabView，建议您花时间学习它，因为只有这样，您才能更好地利用其功能。如果您开始编写代码时考虑到未来的扩展，那么创建可随程序需要增长而不会变得笨重的VI并不难。与文本代码一样，如果您带着短期的视角草率编写代码，只会使代码变得混乱且难以维护。
如果LabView让您感到沮丧，那么您可能应该使用其他工具来创建程序，或者至少对程序的某些组件使用其他工具。例如，如果您需要处理大量字符串 - 多于使用LabView的字符串函数方便的量 - 但您真正想或需要使用LabView来创建应用程序，则有许多选择。您可以轻松地在C或您喜欢的任何语言中编写DLL，然后通过LabView的DLL接口访问这些函数。这适用于任何类型的高级或抽象功能，这些功能使用基本的LabView工具实现会很麻烦。
这有两个巨大的优点 - 首先，您可以将文本编码集中在编写函数或过程上。构建应用程序围绕您的函数的任务变得不存在了。通过与LabView混合，您获得了LabView快速而强大的UI构建器和仪表连接的第二个优点。
在源代码控制方面，您可以灵活运用LabView固有的模块化能力。虽然没有文本工具可以帮助您解决未知继承代码的问题，但它确实具有其他非常强大的功能，以抽象的方式可以实现许多相同的功能。它可能是存在的最容易重构的语言，这意味着通常可以在学习代码时进行重构。
如果您访问数据源并断开连接，您会立即看到它所连接的所有内容。例如：错误列表将提供一个完整的列表，显示由于依赖于该数据源而中断的所有内容，并且您可以立即开始创建捆绑和集群来清理LabView混乱的代码。它甚至会在后台面板上突出显示损坏的数据连接，以便您可以追踪每个连接的位置。如果明确表明某些内容正在主过程中造成混乱，则可以快速将其封装为子VI。当您弄清楚代码的含义时，它就变得整洁干净，容易维护。
唯一的例外是，如果程序使用了大量不必要的全局变量。令人惊讶的是，在LabView中，全局变量也会使事情变得复杂。在这种情况下，除了咒骂留下这个烂摊子的人之外，没有其他办法。但这并不是世界末日。
简而言之，LabView是一种非常不同的语言。如果它似乎令人沮丧，那并不是因为没有工具可以像文本编码那样做你想做的事情，而只是因为它们通常以根本不同的方式实现。例如，搜索代码并不是一个终点，而只是一个手段——目的是发现程序中的链接和引用。虽然您无法搜索LabView代码，但可以以完全不同的方式发现链接和引用。这需要学习曲线。
