Re: To sub or not to sub, that is the question?

Most of the Perl I have worked on has not been written to any coding standard¹ and has possibly taken longer to understand, but has been rewarding and enhanced my understanding.

I think consistency is over-played. If you apply a policy of where it is good to have a sub, you'll either break that rule when it is apt to do so or worse: you won't break that rule at all.

Perl and coding standards sounds like an oxymoron to me, yet I maintain that Perl is not a hackers language.

--

Brother Frankus.

Comment on Re: To sub or not to sub, that is the question?

Replies are listed 'Best First'.
Re2: To sub or not to sub, that is the question? by pmas (Hermit) on Jul 24, 2001 at 19:09 UTC
Importance of coding standards depends also on the size of the project. For 5 lines - even `use strict;` is overkill. But the bigger the project, the more programmers involved - the stricter standards you should have. I worked recently on a project with 40MB of source code (not in perl) - as a result of 10 years of development. Without rather strong coding standards (using custom toolkit) and agreed-on procedure names performing standard - trying to understand system will be much harder. 40MB! After 2 years, I was expert in one small part, conversant in couple others, and know who is expert for what part. In projects like that, game is not about ... possibly taken longer to understand, but has been rewarding and enhanced my understanding... . It's about plain survival... :) So if you insist on using perl without coding standards in such a project, I'll propose to use other language - or I'll prefer to work on different project. pmas To make errors is human. But to make million errors per second, you need a computer.	[reply] [d/l]
Re: Re2: To sub or not to sub, that is the question? by frankus (Priest) on Jul 24, 2001 at 19:23 UTC
Firstly I only apply this philosophy to Perl, my bad for not stating that explicitly. IMNTHO anything that has taken 10 years to develop is ripe for rewriting or part of NASA's space project. I think it's daft, having a document dictating how to code, it implies the authors know something (quite often wrong); I prefer a more natural method of buddying developers, that way the learning process is two-way I've only seen Coding standards work when they were constantly reviewed and altered by the people using them. IME this rarely happens as it involves doing something, it's easier to think write "the coding standard document" and leave it to stifle your developers. -- Brother Frankus. ¤	[reply]


No such thing as a small change
	PerlMonks