在Perl中使用perl-isms(惯用语)是什么最佳实践？

Question

几年前,我参与了为我们(相当大的,经常使用Perl)公司编写最佳实践/编码风格.它由"高级"Perl开发人员委员会完成.

正如通过共识所做的任何事情一样,它有各自不同意的部分.咄.

最错误的部分强烈建议不要使用许多Perlisms(松散定义为C++或Java中没有的代码习语),例如"避免使用"......除非X;' 结构体".

这个规则的主要原理是,非Perl开发人员在使用Perl代码库时会花费更多的时间.我猜这里的假设是,Perl代码骑手总体上比普通人更为罕见 - 并且是新员工.

我想知道SO是否有任何好的论据来支持或拒绝这种逻辑......在这一点上,这主要是学术上的好奇心,因为该公司的Perl编码标准是僵化的,并且就我所知,永远不会再被修改.

PS为了清楚起见,问题是在我注意到的背景下 - 全Perl小型开发商店的答案显然是一个响亮的"使用Perl达到其最大能力".

Answer 1

我编写代码假设一个称职的Perl程序员会读它.我不会勉强聪明,但我也不会愚蠢.

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

既然你说你在一个小型的Perl商店,那么如果你不理解,那么编写代码的人应该很容易.这类东西应该出现在代码审查等等.每个人都会继续了解有关该语言的更多信息,因为您有定期和定期查看代码的机会.如果没有其他眼球看着别人的代码,你不应该花太多时间.你当然不应该等到他们离开公司一周后.

至于新员工,我总是感到困惑,为什么有人会认为你应该把它们放在键盘前面并将它们放松,以期在他们从未见过的代码库中进行富有成效的工作.

这也不仅限于Perl.这是一般编程问题.您应该始终了解有关工具的更多信息.我所知道的大多数大商店都有迷你版本,可以让开发人员加快代码库的速度,包括他们可能遇到的任何棘手的代码.

Answer 2

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

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

那是一个坏主意.但,

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

那么这是个好主意.

我认为没有合理的理由拒绝字符串插值,因为Java和C没有它.unless是一个有趣的,但我认为有一个子程序从偶尔开始

return undef unless <something>;

并不是那么糟糕.

Answer 3

你的意思是什么样的perlisms？

好:

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

好的,如果有限:

• 语句修饰符控制 - 尾随if,除等等
  • 限制错误捕获和提前返回. die "Bad juju\n" unless $foo eq 'good juju';
  • 正如Schwern所指出的,另一个好用途是默认值的条件分配:my $foo = shift; $foo = 'blarg' unless defined $foo;.这种用法是,IMO,比a更清洁my $foo = defined $_[0] ? shift : 'blarg';.
  • 要避免的原因:如果您需要在支票或其他方面添加其他行为,则需要进行大量的重新格式化工作.IMO,重做声明的麻烦(即使是在一个好的编辑器中)比打字几个"不必要的"块更具破坏性.
• 原型 - 仅用于创建像这样的过滤功能map.原型是编译器提示,而不是任何其他语言意义上的"原型".
• 逻辑运算符 - 标准化何时使用and和orvs. &&和||.您的所有代码都应该是一致的.最好使用Perl :: Critic策略来强制执行.

避免:

• 局部变量.动态范围非常奇怪,并且local与local其他任何地方都不一样.
• 包变量.实现不良做法.如果您认为您需要全局共享状态,则重构.如果仍需要全局共享状态,请使用单例.
• 符号表hackery