解决方法
要与Perl :: Critic一起去,我建议您获得一份Perl Best Practices(PBP)的副本.它包含了Perl :: Critic所基于的很多详细信息.即使您不同意本书中的特定指南,也可以让您考虑如何编写代码,这非常有价值.你不必为一本书掏钱,但是两者相互恭维,而且您在PBP中会发现您将不会从Perl :: Critic获得冗长的讨论.
如果您已经使用其他OO语言和OO设计,那么您可能会发现Moose是一个舒适的过渡.麋鹿非常稳定,得到很好的支持,并拥有一个庞大而活跃的社区(尤其是通过IRC). Moose几乎取代了所有现有的OO Perl建议,包括我自己的.面向对象设计是常见的原因;很多项目都是有意义的,没有理由不在Perl中使用它.
就个人而言,当我转到测试驱动的开发模式时,我发现自己的程序结构有了很大的改进.在这样的模式下,将问题分解成小型,易于测试的部件至关重要.如果您刚刚在Perl中进行测试,那么从Test::Tutorial开始,如果您想了解更多,请查看其他testing resources或books.使用像Devel::Cover或Devel::NYTProf这样的工具来看看你的测试用例是什么,它们不是什么.具有难以测试的代码通常是结构不良的一个迹象.
说完这一切,最好的老师是参与一个现有的Perl项目与经验丰富的贡献者.看看他们如何做事情,当你做出贡献时,想想他们的建议.如果您想要一个真正的应用程序与真棒很酷的价值,似乎吸引了最好和最聪明的Perl社区,那么我建议参与Padre,the Perl editor.
如果(无论什么原因)您无法参与另一个项目,那么请考虑向Stack Overflow或PerlMonks等社区发布代码示例.更好的是,如果您可以使您的代码开放源代码,然后请求反馈.所有的编程语言都与其他熟悉他人的人更好地学习,Perl也不例外.
你可以用Perl做好魔法,
保罗
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。