在LabVIEW中使用禁用或条件禁用图来组织和帮助文档代码是一个好主意吗？

Question

我现在是这方面的粉丝，是一名温和的LabVIEW程序员（几年以上的经验），但我想知道其他LabVIEW程序员的想法。

我喜欢使用条件禁用图作为组织和记录代码的方法。我将代码的各个部分组织成一个只有一个页面（启用）的条件禁用图表，然后使用顶部的注释来描述正在进行的操作。

好处是你可以按照你想要的方式在图表中排列，并告诉LabVIEW永远不要自动安排它。然后，LabVIEW会在自动排列时将整个块视为一个单元。如果你这么做了，你总是可以使用全局自动排列功能来很好地布局你的代码。

此外，这使得LabVIEW代码非常易于阅读和遵循。

这是个好主意吗？其他LabVIEW程序员会这样做吗？如果这不是一个坏主意，那么它的缺点是什么？

Answer 1

所以我没有看到任何原因这本来就很糟糕，而且我有类似的事情。我只想考虑几件事：

1. 我会使用平面序列结构框架，这具有相同的效果，并且更容易阅读，因为您知道没有使用其他情况。我使用文档的子图标签。
2. 但我会考虑你是否应该使用更多的子VI。具有单一目的的不同代码组调用形成子VI，这使得顶级代码更易于阅读。你希望以与其他代码不同的方式对待这一事实，即避免清理也表明至少其中一些应该是子VI。棺材中的最后一颗钉子就是如果你把它们复制到任何其他地方它们应该100％是subVIs（可能即使没有）

Answer 2

使用图表禁用代码文档的结构不是一个好主意，原因有几个。

1. 虽然你知道这是一个只有一个框架的子图，但任何其他程序员一眼就看不到它们，他们需要发现要浏览，使代码的可读性降低。使用平坦的序列结构（如jamesmc86所建议的那样）是更好的选择，尽管我也不建议这样做。
2. 启用/禁用图表有一个目的，主要是调试和测试。如果一个程序员在这样的结构上发生，他希望该程序的一部分仍在进行测试，一种算法的替代实现还没有完全正常工作或其他一些测试。或者在注意到没有禁用的情况下，假设它是一个未被删除的测试用例，并认为它是草率的编程。
3. 如果文档变得如此全面（标签会有多于一个或两个短语）需要结构，那么应该在实现文档的正确结构的地方制作子VI。
4. 不要将编程结构用于布局效果。使用编程结构会增加实际程序的开销并增加错误的变化。如果真的有必要使用标签和/或装饰品。我知道它们不是代码交互，因此可能很烦人，但如果代码以一种漂亮且结构化的方式编程，那应该不是问题。

总的来说，我会说如果图表禁用/启用结构用于代码文档，那么你没有使用足够的子VI。