12

I seek to adopt a coding standard for MATLAB, but I am not sure if I picked the right one.

To my best knowledge there is not that much available on topic of programming guidelines for MATLAB, other than this document. The document is well written and has good feedbacks. Standard was published in 2002 (on matlab central) by Richard Johnson but has not being updated since. Is there a more up to date version of it or similar document? (I really failed to google up something else).

Background motivation assumes

  • Coding standards are important
  • Although MATLAB has not change much since 2002, other languages and their approaches have. One could really benefit from those practices.
  • The fact is a lot of people are writing new code using MATLAB or Octave. Although, one would argue the language is virtually dead (blah blah). I would rather not go there (let's mark it as an offtopic).

Why the codestyle is not good enough for me

I'd like to summarize here a few things. If you take time to read the document you might find that it

  • tries to be too hungarian (it's cryptic and I really hate this in most cases)
  • it has too many shortcuts (more less similar to the previous point)
  • it is not supported by Mathworks (but it actually might be a good thing, since all the good stuff in MATLAB came from the user community IMO)
  • there is no automated quality control tools respecting such coding style (here I mean not something like mlint as in *lint family, but more like pep8.py for python)

I guess the reason why such a tool has not been developed is actually the absence of a widely accepted coding standard.

I would really appreciate any of your criticism on the standard or information about a better one.

Do you have any experience on working with this standard? Which parts of it did not work for you? If you never used a formal coding standard but do have a valuable practice that does not fit into it - please provide an example.

4

1 回答 1

4

到目前为止，最好的答案之一是引用 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）。

于 2013-07-03T20:04:32.390 回答