编写MATLAB代码的好习惯？

我想了解编写结构良好的代码的基本原则和礼节。

Answer 1

在编写代码时，要记住以下两点：

1. 不要编写你已经写好的代码。
2. 不要编写你不需要编写的代码。

Answer 2

阅读代码完成 ，它会做任何事情的奇迹。 它会告诉你在哪里，如何，什么时候重要。 这几乎是软件开发的圣经（恕我直言）。

Answer 3

理查德·约翰逊的MATLAB编程风格指南是一个很好的资源。

Answer 4

那么，如果你想用通俗的话来说：

我build议人们编写最简单的可读程序 。

关于如何格式化代码，名称variables，devise类和单独的职责有更多的规则。 但是你不应该忘记，所有这些规则都只是为了确保你的代码很容易检查错误，并确保它可以被原作者以外的人维护。 如果记住上面的build议，你的计划就是这样。

Answer 5

这个列表可能会持续很长时间，但一些主要的事情是：

• 缩进。
• 描述性variables名称。
• 描述性的类/函数名称。
• 不要复制代码。 如果需要重复放入类/函数。
• 使用gettors / settors。
• 只揭露你的对象所需要的东西。
• 单一依赖原则。
• 学习如何写好评论，而不是很多评论。
• 以您的代码为荣！

两个好地方开始：

清洁代码手册

代码完成

Answer 6

如果你想要一些东西作为参考或礼仪，我经常遵循正式的Google风格约定，无论我工作在哪种语言，比如C ++或Python 。

Rob Pike和Brian W. Kernighan 的编程实践也有我发现有用的风格部分。

Answer 7

首先，“代码”不是正确的用法。 代码是另一件事的表示，通常是数字。 正确的单词是“源代码”，源代码的复数是源代码。

–

编写好的源代码：

1. 评论你的代码。
2. 使用比几个字母更长的variables名称。 5到20之间是一个很好的经验法则。
3. 较短的代码行不是更好 – 使用空格。
4. 用你的代码“聪明”是一个很好的方式来混淆自己或其他人以后。
5. 将问题分解成其组件，并使用分层devise来组装解决scheme。
6. 请记住，您以后需要更改程序。
7. 评论你的代码。

计算机编程有许多时尚。 他们的支持者认为那些没有追随时尚的人并不是非常喜欢。 目前的主要时尚似乎是“testing驱动开发”和“敏捷”。 在20世纪90年代的时尚是“面向对象编程”。 学习出现的想法的有用的核心部分，但不要教条，记住最好的scheme是完成工作，它需要做的。

过分浓缩代码的非常微不足道的例子

for(int i=0,j=i; i<10 && j!=100;i++){ if i==j return i*j; else j*=2; }} 

而这更可读：

 int j = 0; for(int i = 0; i < 10; i++) { if i == j { return i * j; } else { j *= 2; if(j == 100) { break; } } } 

第二个例子有退出循环清晰可见的逻辑; 第一个例子的逻辑与控制stream程纠缠在一起。 请注意，这两个程序完全相同的事情。 我的编程风格占用了很多代码行，但是我从来没有遇到过难以在风格上理解的抱怨，而我发现更加简洁的方法令人沮丧。

一个有经验的程序员可以同时阅读 – 上面可能会让他们暂停一下，并考虑发生了什么。 强迫读者坐下来盯着代码不是一个好主意。 代码需要很明显。 每个问题都有其内在的复杂性来expression其解决scheme。 如果可能的话，代码不应该比解决scheme的复杂性更复杂。

这是其他海报试图传达的内容 – 不要让程序比需要的时间长。 更长有两个含义：更多的代码行（即把大括号放在自己的行上），更复杂。 制作一个比需要更复杂的程序并不好。 让它更可读性好。

Answer 8

看看程序员应该知道的97件事情 。
它是免费的，包含了很多像这样的gem：

有一句话我觉得对于所有的软件开发人员来说，都是非常有用的，

风格和谐，优雅和节奏的美丽取决于简单。 – 柏拉图

我认为这句话总结了我们作为软件开发者应该追求的价值。

在我们的代码中有很多我们努力的方面：

• 可读性
• 可维护性
• 发展速度
• 美的难以捉摸的质量

柏拉图告诉我们，所有这些品质的促成因素都是简单的。

Answer 9

Python风格指南始终是一个很好的起点！

Answer 10

欧洲编写和logging可交换标准Fortran 90 Code已经在我的书签中，像永远一样。 另外，这里有一个线程，因为你对MATLAB有兴趣， 组织MATLAB代码 。

Answer 11

就我个人而言，我发现我通过SICP学习了更多关于编程风格的知识，这是麻省理工学院（MIT）对Comp SCI文本的简介（我介绍了四分之一的篇幅）。 话虽如此，如果你要使用Python，Google风格指南是一个很好的开始。

我读过的地方大多数程序（反正脚本）永远不会超过几行。 所有必要的function应该被抽象为function或类别。 我倾向于同意。

Answer 12

上面已经提出了很多好的观点。 我绝对是第二个以上所有。 我还想补充说，编码中的拼写和一致性是你练习（也是现实生活中的）的东西。

我和一些离岸团队合作过，虽然他们的英文很好，但拼写错误却引起了很多混乱。 例如，如果您需要查找某个函数（例如，getFeedsFromDatabase），并且他们拼写错误的数据库或其他的东西，这可能是一个大大小小的头痛，取决于您对该特定函数的依赖关系。 在代码中一遍又一遍地重复的事实将首先closures，驱使你疯狂，其次，使其难以分析。

另外，要保持命名variables和函数的一致性。 有许多协议可以通过，但只要你在做什么的时候一致，与你一起工作的其他人将能够更好地阅读你的代码，并感谢它。

Answer 13

几乎所有在这里说的，还有更多。 在我看来，关于你在找什么的最好的网站（特别是python的禅宗部分是有趣和真实的）

http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html

谈论PEP-20和PEP-8，一些复活节彩蛋（有趣的东西）等…

Answer 14

你可以看看斯坦福大学的在线课程： 编程方法CS106A 。 老师给了几个很好的写源代码的指令。

其中一些如下：

1. 编写程序让人们阅读，而不只是让电脑阅读。 他们两个都需要能够读懂它，但是一个人阅读并理解它是非常重要的，而且计算机仍然能正确执行它。 但这是思考的第一个主要软件工程原理。

2. 如何发表评论：在评论中提出澄清scheme中的事情，这并不明显

3. 如何分解

   1. 一种方法解决了一个问题
   2. 每种方法的代码约为1〜15线
   3. 给方法好名字
   4. 为代码写评论

Answer 15

unit testing
Python和matlab是dynamic语言。 随着代码库的增长，您将被迫重构代码。 与静态types语言相比，编译器不会检测到项目中的“损坏”部分。 使用像xUnit这样的unit testing框架不仅可以补偿缺less的编译器检查，还可以对项目的所有部分进行持续validation的重构。

源代码pipe理
跟踪您的源代码与版本控制系统，如SVN ， GIT或任何其他派生。 您将能够在代码历史中来回访问，为部署/发布的版本创build分支或创build标签。

错误跟踪
使用错误跟踪系统，如果可能的话，连接到您的源代码pipe理系统，以保持您的问题。 您可能无法或不得不立即解决问题。

减less熵
在现有代码库中集成新function的同时，您将添加更多的代码行，并且可能会增加复杂性。 这会增加熵。 尝试通过引入接口或inheritance层次来保持devise的清洁，以便再次减less熵。 不重视代码熵会使您的代码在一段时间内不可维护。

所有以上提到
纯编码相关的主题，如使用风格指南，不重复的代码，…，已被提及。

Answer 16

在这里已经有了关于Matlab的精彩答案：

• 避免长的脚本，而是在不同的文件中写入函数（子例程）。 这将使代码更易读，更易于优化。

• 使用Matlab的内置函数function。 也就是说，了解Matlab提供的许多function，而不是重新发明轮子。

• 使用代码分段 ，以及最新的Matlab版本提供的其他代码结构。

• 学习如何使用timeit和profile 来对您的代码进行基准testing 。 你会发现有时候循环是更好的解决scheme。

Answer 17

我问这个问题时得到的最好的build议如下：

 Never code while drunk. 

Answer 18

使其易读，使其直观，使其可以理解，并使其评论。