现代MATLAB代码风格:缺少什么？

Question

我试图采用MATLAB的编码标准,但我不确定我是否选择了正确的编码标准.

据我所知,除了本文档之外,MATLAB编程指南的主题并不多.该文件写得很好,反馈很好.标准版于2002年由Richard Johnson在matlab中心发布,但自那以后一直没有更新.是否有更新的版本或类似文件？(我真的没有想到其他的东西).

背景动机假定

• 编码标准很重要
• 尽管自2002年以来MATLAB没有太大变化,但其他语言及其方法也有所改变.人们可以从这些做法中获益.
• 事实上很多人都在使用MATLAB或Octave编写新代码.虽然,有人会说这种语言实际上已经死了(等等).我宁愿不去那里(让我们把它标记为一个offtopic).

为什么codestyle对我来说不够好

我想在这里总结一些事情.如果你花时间阅读文档,你可能会发现它

• 试图过于匈牙利语(这是神秘的,在大多数情况下我真的很讨厌这个)
• 它有太多的快捷方式(更不像前一点那样)
• Mathworks不支持它(但它实际上可能是件好事,因为MATLAB中的所有好东西都来自用户社区IMO)
• 没有自动化的质量控制工具尊重这种编码风格(这里我的意思不是像*lint系列中的mlint,而是更像pep8.py for python)

我猜这种工具尚未开发的原因实际上是缺乏广泛接受的编码标准.

我非常感谢您对标准的批评或有关更好标准的信息.

您是否有使用此标准的经验？哪部分不适合你？如果您从未使用过正式的编码标准,但确实有一些不适合它的有价值的做法 - 请举例说明.

Answer 1

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

“同一作者 (Richard Johnson)” 于 2011 年出版了一本书 'The Elements of MATLAB Style'（另请参阅wiki）：

目录

1. 一般原则
2. 格式化
3. 命名
4. 文档
5. 编程
6. 文件和组织
7. 发展。

Loren 有一篇博客文章对这本书进行了评论。我只会关注这里的评论：

• 7 在优雅点分割长代码行 - 我发现这个很有用，因为在任何编辑器中必须拖到最右边都是一种痛苦，即使这是可能的。

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

• 43 对大范围变量使用有意义的名称 - 这使得代码更容易阅读、理解和调试（如有必要）。

• 69 根据其功能命名函数 - 由于函数执行操作，因此名称应包含有关该操作的信息。

• 86 在数据文件名中使用可排序编号 - 如果您有许多相似的数据文件，那么合理的编号方案只会帮助您。

• 97 确保评论符合准则 - 我永远不会忘记我的论文导师打电话给我的那次，因为他真的很恼火。我给他留下了一份 Fortran 程序的副本，其中有大量注释，最后一条是“忽略上面的所有注释；它们是针对先前版本的。”

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

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

• 172 使用括号 - 含义清晰至关重要，特别是当其他人需要理解、修改或翻译代码时。

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

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

• 271-275 第一个是编写小测试 - 我喜欢 Richard 将测试作为本风格指南的中心原则。如果没有强大的测试套件，我不知道程序员如何能够很好地工作。

结论

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