Re: Perl best practices fanatism

I'm aware of but not very familiar with PBP. I'm also aware of some rather bizarre corporate programming rules, including forbidding indentation, requiring subroutines to fit on a single page of printout (about 60 lines), and even one requiring code to fit on one VDT screen (80 columns by 25 lines).

One thing I would worry about is whether the "do whatever PBP says" are substituting the dicta of PBP for the intellectual judgment needed for code clarity and maintainability, which is, after all, the goal of coding standards. I doubt Dr Conway expects his book to be carved in stone, and its rules enforced by inquisitors (those not currently working at Guantanamo).

emc

Information about American English usage here and here.

Any Northeastern US area jobs? I'm currently unemployed.

Comment on Re: Perl best practices fanatism

Replies are listed 'Best First'.
Re^2: Perl best practices fanatism by theorbtwo (Prior) on Dec 09, 2007 at 20:34 UTC
The linux kernel coding standards says (amongst other good advice, some of which applies as well to Perl as C: Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well. I think it's generally right, if you go on to read the next two paragraphs: The maximum length of a function is inversely proportional to the complexity and indentation level of that function. So, if you have a conceptually simple function that is just one long (but simple) case-statement, where you have to do lots of small things for a lot of different cases, it's OK to have a longer function. However, if you have a complex function, and you suspect that a less-than-gifted first-year high-school student might not even understand what the function is all about, you should adhere to the maximum limits all the more closely. Use helper functions with descriptive names (you can ask the compiler to in-line them if you think it's performance-critical, and it will probably do a better job of it than you would have done).	[reply]
Re^3: Perl best practices fanatism by Joost (Canon) on Dec 14, 2007 at 01:17 UTC
This is very good advice, and I should probably take a closer look at the linux kernel coding standards even though I'm not particularly interested in C or kernel internals at the moment. Thanks for posting that. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]


laziness, impatience, and hubris
	PerlMonks