perlstyle - 云端在线

程序：

您的姓名

perlstyle - Perl 风格指南

商品描述

当然，每个程序员在格式方面都有自己的偏好，
但是有一些通用的指导方针可以让你的程序更容易阅读，
理解，维护。

最重要的是在下面运行你的程序 -w 任何时候都旗帜。 你可以
通过“无警告”编译指示或
如果必须，$^W 变量。 您还应该始终在“使用严格”下运行或知道
为什么不呢。 “使用 sigtrap”甚至“使用诊断”pragma 也可能证明
有用。

关于代码布局的美感，Larry 唯一关心的是
多行 BLOCK 的右大括号应该与关键字对齐
开始构建。 除此之外，他还有其他不那么强烈的偏好：

· 4 列缩进。

· 如果可能，在与关键字相同的行上打开卷曲，否则排成一行。

· 多行 BLOCK 开头卷曲前的空格。

· 一行 BLOCK 可以放在一行上，包括卷曲。

· 分号前没有空格。

· 在“短”单行 BLOCK 中省略分号。

· 大多数操作员周围的空间。

· “复杂”下标周围的空格（括号内）。

· 做不同事情的块之间的空行。

· 不拥抱别人。

· 函数名和它的左括号之间没有空格。

· 每个逗号后的空格。

· 长行在操作符后断开（“and”和“or”除外）。

· 当前行最后一个括号匹配后的空格。

· 垂直排列相应的项目。

· 只要不影响清晰度，就可以省略多余的标点符号。

拉里对每件事都有他的理由，但他并没有声称其他人的
头脑的运作方式和他的一样。

这里有一些其他更实质性的风格问题需要考虑：

·只因你 CAN 以特定的方式做某事并不意味着你 应该 做
那样。 Perl 旨在为您提供多种方法来做任何事情，因此请考虑
选择最易读的一个。 例如

打开(FOO,$foo) || die "无法打开 $foo: $!";

优于

die "无法打开 $foo: $!" 除非打开（FOO，$ foo）；

因为第二种方式将语句的要点隐藏在修饰符中。 在
另一方面

如果 $verbose，则打印“开始分析\n”；

优于

$verbose && print "开始分析\n";

因为重点不在于用户是否输入了 -v 或没有。

同样，仅仅因为运算符让您假设默认参数并不意味着
你必须使用默认值。 默认值适用于惰性系统
编写一次性程序的程序员。 如果你想让你的程序可读，
考虑提供论据。

同样的道理，只因为你 CAN 在很多地方省略括号不会
意味着你应该：

返回打印反向排序 num 值 %array；
返回 print(reverse(sort num (values(%array))));

如有疑问，请加括号。 至少它会让一些可怜的笨蛋反弹
在 % 键上 vi.

即使你不怀疑，也要考虑一下不得不这样做的人的心理健康
在你之后维护代码，谁可能会把括号放在错误的地方。

· 不要通过愚蠢的扭曲来退出顶部或底部的循环，当 Perl
提供“last”运算符，因此您可以在中间退出。 只是“突出”它一个
很少让它更明显：

线：
为了 （;;） {
报表;
最后一行如果 $foo;
下一行 if /^#/;
报表;
}

· 不要害怕使用循环标签——它们在那里是为了提高可读性以及
允许多级循环中断。 请参见前面的示例。

· 避免在空上下文中使用“grep()”（或“map()”）或`反引号`，也就是说，当你
只是扔掉它们的返回值。 这些函数都有返回值，所以使用
他们。 否则，请改用“foreach()”循环或“system()”函数。

· 为了可移植性，当使用可能不是在每台机器上都实现的功能时，
在 eval 中测试构造以查看它是否失败。 如果你知道什么版本或
patchlevel 实现了特定功能，您可以测试 $] ($PERL_VERSION in
“英语”）看看它是否会在那里。 “配置”模块还可以让你
询问由确定的值 配置 安装 Perl 时的程序。

· 选择助记符标识符。 如果你不记得助记符是什么意思，你有一个
问题。

· 虽然像 $gotit 这样的短标识符可能没问题，但使用下划线来分隔单词
在更长的标识符中。 阅读 $var_names_like_this 通常比阅读更容易
$VarNamesLikeThis，尤其适用于非英语母语人士。 这也是一个简单的
与“VAR_NAMES_LIKE_THIS”一致的规则。

包名称有时是此规则的一个例外。 Perl 非正式地保留
“pragma”模块的小写模块名称，如“integer”和“strict”。 其他
模块应该以大写字母开头并使用大小写混合，但可能没有
由于原始文件系统对模块的表示的限制而使用下划线
命名为必须适合几个稀疏字节的文件。

· 您可能会发现使用字母大小写来表示一个范围或性质是有帮助的。
多变的。 例如：

仅限 $ALL_CAPS_HERE 常量（注意与 perl vars 的冲突！）
$Some_Caps_Here 包范围内的全局/静态
$no_caps_here 函数作用域 my() 或 local() 变量

函数和方法名称似乎最好全部小写。 例如，
“$obj->as_string()”。

您可以使用前导下划线来指示变量或函数不应
在定义它的包之外使用。

· 如果你的正则表达式真的很麻烦，请使用“/x”修饰符并放入一些
空白使其看起来不像线噪声。 不要使用斜线作为
当您的正则表达式有斜杠或反斜杠时的分隔符。

· 使用新的“and”和“or”运算符来避免将列表运算符括起来
很多，并减少标点运算符如“&&”和“||”的发生率。 称呼
您的子程序就好像它们是函数或列表运算符一样，以避免过度
和号和括号。

· 使用此处的文档而不是重复的“print()”语句。

· 垂直排列相应的东西，特别是如果它太长而无法放在一个
反正行。

$IDX = $ST_MTIME;
$IDX = $ST_ATIME 如果 $opt_u;
$IDX = $ST_CTIME 如果 $opt_c;
$IDX = $ST_SIZE 如果 $opt_s;

mkdir $tmpdir, 0700 or die "can't mkdir $tmpdir: $!";
chdir($tmpdir) 或者死“can't chdir $tmpdir: $!”;
mkdir 'tmp', 0777 or die "can't mkdir $tmpdir/tmp: $!";

· 经常检查系统调用的返回码。 好的错误信息应该去
“STDERR”，包括导致问题的程序、失败的系统调用和
参数是，并且（非常重要）应该包含标准系统错误消息
出了什么问题。 这是一个简单但足够的例子：

opendir(D, $dir) 或者死“can't opendir $dir: $!”;

· 在有意义的时候排列你的音译：

tr [abc]
[xyz]；

· 考虑可重用性。 当你可能想做的时候，为什么要一次性浪费脑力
又是一样的东西？ 考虑概括您的代码。 考虑编写一个模块
或对象类。 考虑使用“use strict”和“use
警告”（或 -w) 生效。 考虑放弃你的代码。 考虑改变你的
整个世界观。 考虑......哦，没关系。

· 尝试记录您的代码并以一致的方式使用 Pod 格式。 这里有
普遍预期的约定：

· 使用“C<>”作为函数名、变量名和模块名（更普遍的是任何
可以被视为代码的一部分，例如文件句柄或特定值）。 笔记
函数名被认为更易读，在它们之后加上括号
名称，即“函数（）”。

· 使用“B<>”作为命令名称，例如 猫 or grep的.

· 使用“F<>”或“C<>”作为文件名。 "F<>" 应该是文件的唯一 Pod 代码
名称，但由于大多数 Pod 格式化程序将其呈现为斜体，Unix 和 Windows 路径带有
他们的斜线和反斜线可能不太可读，并且更好地呈现
“C<>”。

· 始终如一。

· 对人好点。

使用 onworks.net 服务在线使用 perlstyle