10

几年前，我参与了为我们（相当大且经常使用 Perl 的）公司编写最佳实践/编码风格。它是由“高级” Perl 开发人员组成的委员会完成的。

正如任何以协商一致方式完成的事情一样，它有一些每个人都不同意的部分。呃。

最错误的部分是强烈建议不要使用许多 Perlisms（松散地定义为在 C++ 或 Java 中不存在的代码习语），例如“避免使用 '... 除非 X;' 结构体”。

为此类规则提出的主要理由是，非 Perl 开发人员在使用 Perl 代码库时会更加困难。我猜这里的假设是 Perl 代码骑师总体上比非 Perl 的人更稀有——而且在公司的新员工中也是如此。

我想知道 SO 是否有任何好的论据来支持或拒绝这种逻辑......此时主要是学术上的好奇心，因为该公司的 Perl 编码标准已经僵化，据我所知，永远不会再修改。

PS 为了清楚起见，问题是在我提到的上下文中——对于一个全 Perl 的小型开发商店的答案显然是一个响亮的“将 Perl 发挥到最大的能力”。

4

6 回答 6

30

我编写代码时假设有能力的 Perl 程序员会阅读它。我不会特意变得聪明，但我也不会愚蠢。

如果您正在为不懂该语言的人编写代码，那么您将错过使用该语言的大部分要点。我经常发现人们想要取缔 Perlisms，因为他们拒绝学习比他们已经知道的更多的东西。

既然您说您在一家小型 Perl 商店，那么如果您不理解代码，应该很容易问编写代码的人是什么意思。这类东西应该出现在代码审查等中。由于您有定期和定期的机会查看代码，因此每个人都将继续了解有关该语言的更多信息。你不应该让太多的时间流逝而没有其他眼球查看某人的代码。你当然不应该等到他们离开公司一周后。

至于新员工，我总是很困惑，为什么有人会认为你应该让他们坐在键盘前，让他们放松，期待在他们从未见过的代码库中进行富有成效的工作。

这也不限于 Perl。这是一个通用的编程问题。您应该始终了解更多有关您的工具的信息。我认识的大多数大商店都有小型训练营，可以让开发人员快速了解代码库，包括他们可能遇到的任何棘手代码。

于 2010-01-22T18:20:42.920 回答
7

我问自己两个简单的问题：

  • 我这样做是因为它非常聪明和/或展示了我对 Perl arcana 的广泛了解吗？

那么这是一个坏主意。但，

  • 我这样做是因为它是惯用的 Perl 并且受益于 Perl 的独特优势吗？

那么这是个好主意。

我认为没有正当理由拒绝，比如，仅仅因为 Java 和 C 没有字符串插值。unless很有趣，但我认为有一个子程序从偶尔开始

return undef unless <something>;

还不错。

于 2010-01-22T20:22:07.403 回答
6

你是什​​么意思？

好的：

  • 惯用的 for 循环：for(1..5) {}或for( @foo ) {}
  • 数组的标量上下文评估：my $count = @items;
  • map,grep和sort:my %foo = map { $_->id => $_ } @objects;

如果有限，可以：

  • 语句修饰符控制 - 尾随 if、unless 等。
    • 仅限于错误捕获和提前返回。 die "Bad juju\n" unless $foo eq 'good juju';
    • 正如 Schwern 指出的那样，另一个很好的用途是有条件地分配默认值：my $foo = shift; $foo = 'blarg' unless defined $foo;. 在 IMO 中，这种用法比my $foo = defined $_[0] ? shift : 'blarg';.
    • 避免的原因：如果您需要在检查或其他内容中添加其他行为，则需要进行大量的重新格式化工作。IMO，重做语句的麻烦（即使在一个好的编辑器中）比输入几个“不必要的”块更具破坏性。
  • 原型 - 仅用于创建过滤函数，如map. 原型是编译器提示，而不是任何其他语言意义上的“原型”。
  • 逻辑运算符 - 标准化何时使用andandor与&&和||。你所有的代码都应该是一致的。最好使用 Perl::Critic 策略来强制执行。

避免：

  • 局部变量。动态范围非常奇怪，与其他任何地方都不local一样local。
  • 包变量。启用不良做法。如果您认为需要全局共享状态，请重构。如果您仍然需要全局共享状态，请使用单例。
  • 符号表黑客
于 2010-01-22T18:09:55.387 回答
2

正如您所说，这一定是几年前的事了，因为在过去的几年里，Damian Conway 通过Perl 最佳实践在 Perl 标准中“垄断了市场” 。

我曾在一个同样僵化的环境中工作——我们不允许采用最新的最佳实践，因为那将是一种变化，而且公司结构中没有足够高级别的人理解（或者可能会费心去理解） Perl 并同意进入 21 世纪。

一家部署并保留一项技术但既不购买专业知识也不进行内部培训的公司正在自找麻烦。

（我猜你是在一个高度变化控制的环境中工作——也许是财务？）

顺便说一句，我同意布赖恩的观点。

于 2010-01-23T03:21:19.820 回答
1

按照惯例，我想说Moose杀死了 99.9% 的不应该使用的 Perl 主义：符号表黑客、reblessing 对象、常见的黑盒违规：将对象视为数组或哈希。最棒的是，它在没有受到“不使用它”的功能影响的情况下完成了所有这些工作。

如果您真正指的“perl-isms”是突变形式（警告“坏主意”，除非 $good_idea），unless那么until我认为您真的没有太多争论，因为这些“perl-isms”没有似乎抑制了 perl 用户或非 perl 用户的可读性。

于 2010-01-22T17:40:35.197 回答
0

拿起一本Effective Perl Programming: Ways to Write Better, More Idiomatic Perl (2nd Edition)，并将其作为指南。它包含许多更好的习惯用法，并且包含一些信息，这些信息将使您编写好的 Perl 风格的 Perl 代码，而不是 C 或 Java（或其他）风格的 Perl 代码。

于 2010-08-18T20:03:46.750 回答