[jifty-devel] Questions on style, janitorial practice

Edgar Whipple jifty at misterwhipple.com
Sat Mar 3 12:54:04 EST 2007


After my recent attempt at sweeping Jifty/Request.pm, I re-read the
developers' style doco, and I'd like to beef it up a bit. Since the next
couple of items on my to-do list are also style-related, this seems like
a good time start collecting notes for revising Style.pod. I'd
appreciate feedback on the following questions.

These are only what I've thought of so far. Please throw in anything
else you think would be useful.

Most of these reflect Perl Best Practices recommendations. Although PBP
is included by reference in Style.pod, some items don't appear to
predominate in the code. So, I'd like feedback on those with an eye
towards mentioning them more specifically in the docs, whether up or
down.


1. Should every package be placed in its own, separate file?

Perlcritic says yes; PBP implies no. I figure the answer is no, but I'd
like to be sure.

2. What PBP recommendations, if any, have turned out either to be a Bad
Thing for Jifty, or contrary to the desires of most of Jifty's
contributors?

3. What PBP recommendations or other commonly-accepted principles are
lacking in Jifty actual practice, and should be added.

4. Would it be useful to designate some level of perlcritic compliance
as a goal?

I like perlcritic, but clearly not everyone agrees. If we were to do
this, I think -stern (second-most lenient) would be the right level in
general. Naturally, nothing prevents anyone from using a stricter level.

If the consensus is any degree of yes, we would probably want to define
a profile for inclusion in the documentation.

5. /xms flags for regexes: Since these aren't semantically neutral, I
wouldn't change them in someone else's code without prior consultation.
However, is there a consensus on including them in Style.pod?

6. Subroutine names that are homonyms for builtins.

7. The following changes are semantically neutral, and make code more
readable for some coders, especially the less experienced ones. Are
there any objections if I undertake these in janitorial?

-- changing all other regex delimiters to /.../ or m{...}
-- changing /.../  to m{...}, s/../../ to s{..}{..}, etc. for hairy
   expressions (or even stubbly ones)
-- Strict choice between q(') and q(") based on whether interpolation is
   indicated.
-- $$foo to ${$foo}

I believe these are also semantically neutral, but they're easier to
make a mistake with when refactoring:

-- changing postfix 'if', etc. to block-style except in flow-control
   statements
-- refactoring 'unless' to equivalent 'if'
   Let there be no holy war over this one. If it's unpopular I'll just
   leave it alone, except for reworking 'unless !' to 'if' (cancel
   out double-or-worse negatives, for clarity).



Edgar
-- 
ln -s /dev/null ~/.sig



More information about the jifty-devel mailing list