上一节:
下一节:

  Perl 编码标准

  • 编码标准

    当然，每个程序员在格式化方面都会有自己的喜好，但是有一些通用准则可以使您的程序更易于阅读，理解和维护。最重要的是始终在-w标志下运行程序。您可以通过no warnings杂注或$^W变量（如果需要）将代码的特定部分显式关闭。您还应该始终在严格使用下运行，或者知道为什么不这样做。使用sigtrap甚至使用诊断实用程序也可能很有用。关于代码的美观性，Larry唯一关心的问题是多行BLOCK的右花括号应与启动构造的关键字对齐。除此之外，他还有其他不太强的偏好-
    • 4列缩进。
    • 如果可能，在与关键字相同的行上打开curl，否则对齐。
    • 多行BLOCK的开始卷曲前的空间。
    • 单行块可以放在一行上，包括冰壶。
    • 分号前没有空格。
    • 在“短”单行BLOCK中省略了分号。
    • 大多数操作员周围的空间。
    • “复杂”下标周围的空格（方括号内）。
    • 执行不同功能的块之间的空白行。
    • 别无所求。
    • 函数名称与其左括号之间没有空格。
    • 每个逗号后的空格。
    • 运算符后的长行（和和或除外）。
    • 当前行上最后一个括号匹配后的空格。
    • 垂直排列相应的项目。
    • 只要不影响清晰度，就可以省略多余的标点符号。
    以下是一些其他需要考虑的实质性样式问题：仅因为您可以以某种特定方式进行操作并不意味着您应该以这种方式进行操作。Perl旨在为您提供几种执行任何操作的方式，因此请考虑选择最易读的方式。例如- 
    
open(FOO,$foo) || die "Can't open $foo: $!";
    优于- 
    
die "Can't open $foo: $!" unless open(FOO,$foo);
    因为第二种方式在修饰符中隐藏了语句的要点。另一方面， 
    
print "Starting analysis\n" if $verbose;
    优于- 
    
$verbose && print "Starting analysis\n";
    因为要点不是用户是否键入-v。
    当 Perl 提供最后一个运算符时，不要经过愚蠢的扭曲而在顶部或底部退出循环，这样您就可以在中间退出。只是“突出”一点，使其更加可见- 
    
LINE:
for (;;) {
   statements;
   last LINE if $foo;
   next LINE if /^#/;
   statements;
}
    让我们看一些更重要的要点-
    • 不要害怕使用循环标签-它们在那里可以提高可读性以及允许多级循环中断。请参阅前面的示例。
    • 避免在void上下文中使用grep()（或map()）或`backticks`，即当您丢弃它们的返回值时。这些函数都有返回值，因此请使用它们。否则，请改用foreach()循环或system()函数。
    • 为了实现可移植性，当使用并非在每台计算机上都可能实现的功能时，请评估一次该构造以查看其是否失败。如果您知道实现了特定功能的版本或补丁程序级别，则可以测试$]（英语中的$PERL_VERSION）以查看它是否在那里。当安装Perl时，Config模块还将允许您询问由Configure程序确定的值。
    • 选择助记符标识符。如果您不记得助记符是什么意思，那就有问题了。虽然像$gotit这样的短标识符可能没问题，但请使用下划线将较长标识符中的单词分开。
    • 通常，$var_names_like_this比$VarNamesLikeThis更容易阅读，尤其是对于非英语母语的人。这也是一条与VAR_NAMES_LIKE_THIS一致的简单规则。
    • 程序包名称有时是该规则的例外。Perl非正式地为“pragma”模块保留小写的模块名称，例如integer和strict。其他模块应以大写字母开头并使用大小写混合，但由于原始文件系统将模块名称表示为必须容纳几个稀疏字节的文件的限制，因此可能没有下划线。
    • 如果您的正则表达式真的很毛茸茸，请使用/ x修饰符并放入一些空格，使其看起来更像行噪。当您的regexp有斜杠或反斜杠时，请勿使用斜杠作为分隔符。
    • 始终检查系统调用的返回码。好的错误消息应该发送到STDERR，包括引起问题的程序，失败的系统调用和参数是什么，并且（非常重要）应包含发生错误的标准系统错误消息。这是一个简单但足够的示例-
      • 
opendir(D, $dir) or die "can't opendir $dir: $!";
    • 考虑可重用性。当您可能想再次做类似的事情时，为什么要浪费脑力呢？考虑将代码泛化。考虑编写模块或对象类。考虑使代码严格使用严格运行，并有效使用警告（或-w）。考虑放弃您的代码。考虑改变您的整个世界视野。考虑...哦，没关系。
    • 始终如一。
    • 对人好点。
上一节:
下一节: