编写MATLAB代码的好习惯?

45 python matlab structure

我想知道编写结构良好的代码的基本原则和礼仪.

whe*_*ies 34

阅读代码完成,它将为一切创造奇迹.它会告诉你事情的地点,方式和时间.它几乎是软件开发的圣经(恕我直言.)

  • 我的Code Complete副本丢失了!都没了! (2认同)
  • 我写了我的Code Complete副本.失去你的是多么悲惨的事!d: (2认同)
  • 啊 - 史蒂夫麦康奈尔.那本书是老派但仍然如此相关!他的另一本好书是"快速发展" (2认同)

ant*_*ony 22

在编写代码时,这些是要记住的最重要的两件事:

  1. 不要编写您已编写的代码.
  2. 不要编写不需要编写的代码.


Mat*_*eau 17

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


小智 15

好吧,如果你想要外行的话:

我建议人们写出最有效的可读程序.

关于如何格式化代码,命名变量,设计类和单独的职责,还有很多规则.但是你不应该忘记所有这些规则只是为了确保你的代码很容易检查错误,并确保它可以由原作者以外的其他人维护.如果记住上面的推荐,你的程序就是这样.


Luk*_*ina 7

这份清单可能会持续很长时间,但有些重要的事情是:

  • 缩进.
  • 描述性变量名称.
  • 描述性类/函数名称.
  • 不要重复代码.如果它需要复制放在类/函数中.
  • 使用gettors/settors.
  • 只显示对象中的必要内容.
  • 单一依赖原则.
  • 学习如何写好评论,而不是写很多评论.
  • 以您的代码为荣!

两个好的开始:

清洁代码手册

代码完成


aoe*_*oeu 5

如果你想要一些东西用作参考或礼仪,我经常遵循官方的谷歌风格约定,无论我在哪种语言,如C++Python.

Rob Pike和Brian W. Kernighan 的编程实践也有一个关于风格的部分,我发现它很有帮助.

  • 为Kernighan和派克+1! (2认同)

Pau*_*han 5

首先,"代码"不是正确的用词.代码是另一种东西的表示,通常是数字.正确的单词是"源代码",源代码的复数是源代码.

-

编写好的源代码:

  1. 评论你的代码.
  2. 使用长度超过几个字母的变量名称.5到20之间是一个很好的经验法则.
  3. 更短的代码行并不是更好 - 使用空格.
  4. 用你的代码"聪明"是一个让你自己或其他人混淆的好方法.
  5. 将问题分解为其组件并使用分层设计来组装解决方案.
  6. 请记住,您稍后需要更改程序.
  7. 评论你的代码.

计算机编程有很多时尚.他们的支持者认为那些没有追随时尚的人并没有那么开心,也没有非常随意.目前的主流时尚似乎是"测试驱动开发"和"敏捷".20世纪90年代的时尚是"面向对象编程".了解周围的想法的有用核心部分,但不要教条,并记住最好的计划是完成它需要做的工作.

从我的头脑中过度浓缩代码的非常简单的例子

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

虽然这更具可读性:

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

第二个例子具有清晰可见的退出循环的逻辑; 第一个例子的逻辑与控制流程纠缠在一起.请注意,这两个程序完全相同.我的编程风格占用了大量的代码,但我从来没有遇到过关于风格很难理解的抱怨,而我发现更简洁的方法令人沮丧.

经验丰富的程序员可以并且将会同时阅读 - 上述内容可能会使他们暂停一下并考虑发生了什么.强迫读者坐下来盯着代码并不是一个好主意.代码需要显而易见.每个问题都具有表达其解决方案的内在复杂性.如果可能的话,代码不应该比解决方案的复杂性更复杂.

这是另一张海报试图传达的内容 - 不要让程序比需要更长.更长时间有两个含义:更多的代码行(即,将行括号放在自己的行上),更复杂.使程序比需要更复杂并不好.使其更具可读性是好的.

  • @Paul Nathan:你列了两次"评论你的代码".评论很重要,但重要的是不要过度.通常不应该说'代码在做什么' - 这应该从代码中显而易见; 如果不是很明显,那通常表明代码应该写得更清楚.评论应该关注"为什么"代码正在做某事,或者代码所做的假设.像"a + = 5;/*将4添加到*/"之类的评论不能提高可读性. (5认同)
  • 我发现第一个例子更清楚了.如果我看到10行代码,我希望它能做一些非常复杂的事情. (5认同)
  • @supercat:代码不是自我评论.过度评估比评估要好得多. (2认同)
  • @Harpreet不评论代码说什么,但不能说什么. (2认同)