matlab - 现代 MATLAB 代码风格 : what is missing?

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

5年前关闭。




Improve this question




我试图为 MATLAB 采用一种编码标准，但我不确定我是否选择了正确的标准。

据我所知，除了这个 document 之外，关于 MATLAB 编程指南的主题并不多。 .该文档写得很好，并有很好的反馈。标准由 Richard Johnson 于 2002 年(在 matlab 中心)发布，但此后一直没有更新。有没有更多最新 它的版本或类似的文件？ (我真的没能用谷歌搜索其他东西)。

背景动机假设

编码标准很重要

尽管 MATLAB 自 2002 年以来没有太大变化，但其他语言及其方法已经发生了变化。人们真的可以从这些做法中受益。

事实上，很多人都在使用 MATLAB 或 Octave 编写新代码。虽然，有人会争辩说这种语言实际上已经死了(等等)。我宁愿不去那里(让我们将其标记为偏离主题)。

为什么codestyle对我来说不够好

我想在这里总结一些事情。如果您花时间阅读该文档，您可能会发现它

试图太hungarian (这很神秘，在大多数情况下我真的很讨厌这个)

它有太多的快捷方式(更多与前一点相似)

Mathworks 不支持它(但它实际上可能是一件好事，因为 MATLAB 中的所有好东西都来自用户社区 IMO)

没有尊重这种编码风格的自动化质量控制工具(这里我的意思不是像 *lint 系列中的 mlint，而是更像 python 的 pep8.py)

我想之所以没有开发出这样的工具，实际上是缺乏一个被广泛接受的编码标准。

我真的很感激你的任何 对标准或信息的批评关于更好的。

您有使用此标准的经验吗？它的哪些部分对您不起作用？如果您从未使用过正式的编码标准，但确实有不适合的有值(value)的实践 - 请提供一个示例。

Answer 1

迄今为止最好的答案之一是引用 Amro 的评论:

“同一作者(理查德·约翰逊)”发表了一篇 book “MATLAB 风格的元素” (另见 wiki)2011:

Table of Contents

1. General principles
2. Formatting
3. Naming
4. Documentation
5. Programming
6. Files and organization
7. Development.

Loren 在 review of the book 上发表了一篇博文。 .我将只关注这里的评论:

7 在优美的点分割长代码行 - 我发现这个很有用，因为在任何编辑器中必须向右拖得很远是一种完全的痛苦，即使这是可能的。

10 不要使用硬标签 - 这有助于在可能具有不同编辑环境的团队中工作时保持理智。

43 为具有大范围的变量使用有意义的名称 - 这使得代码更易于阅读、理解和调试(如有必要)。

69 为它们做什么命名函数 - 因为函数执行一个 Action ，所以名称应该包含有关该 Action 的信息。

86 在数据文件名中使用可排序编号 - 如果您有许多类似的数据文件，合理的编号方案只能帮助您解决问题。

97 确保评论与准则一致 - 我永远不会忘记我的论文导师调用我的时间，因为他真的很生气。我给他留下了一个 Fortran 程序的副本，上面有很多注释，最后一个是“忽略上面的所有注释；它们是针对以前的版本的。”

135 避免加密代码 - 我发现一般来说，编写加密代码的好处比我预期的要少，而且比它所保证的更令人头疼。有时，我会在一些时间紧迫的事情上使用神秘的代码来提高性能。当我这样做时，我会尝试对其进行全面评论，包括在我测试过的评论中直接实现。这样，当性能权衡发生变化时，我了解代码应该做什么，并且有两个开始代码更新的选项。

150, 151 Minimize the Use of Global Variables 和 Minimize the Use of Global Constants -- 我自己会更强烈地这样说。处理您想要共享的信息有多种高级技术，无论它们是函数句柄、类及其属性，还是其他一些方法。由于许多原因，这些技术使用起来要安全得多 - 例如，如果需要的话，更容易控制副作用，并且代码可能更适合并行化。

172 使用括号 - 含义清晰是最重要的，尤其是当其他人需要理解、修改或翻译代码时。

176 尽可能避免使用 eval - 我确信对某些 MATLAB 用户来说似乎并非如此，但大多数情况下 eval 是可以避免的。

185-188 第一个是避免复杂的条件表达式 - 这些条目包含一些关于处理条件构造、案例排序等的有用想法。

271-275 其中第一个是编写小测试 - 我喜欢 Richard 将测试作为本风格指南的中心原则。如果没有强大的测试套件，我看不出程序员如何运作良好。

结论

与 2002 年的原始文档相比，这本书似乎过于笼统。我将继续阅读它并提供更多见解，但它似乎并不完全符合我对编码标准所需的严格性的理解。它融合了许多对初学者有用的一般思想，但对编程并不严格，以便他们可以自动测试代码(再次 PEP8)。