At 09:54 PM 11/2/2001 +0200, Robin Berjon wrote:
>On Friday 02 November 2001 20:14, Stephen Adkins wrote:
>> I have grabbed the Slash style guide, removed/modified
>> the offending sections (exit/die, DESTROY, shift), and
>> created a proposed P5EE style guide.
>
>It seems that you forgot shift. Please remove it, or even better, incite
>people to use it except when there is a really good reason not to (eg silly
>accessors sub getFoo { return $_[0]->[FOO]; } ).
Can you explain what you would change in this section?
=head2 shift
Where possible, use @_ rather than shift. shift is slower.
my $var = shift; # wrong
my ($var) = @_; # right
my ($var1, $var2, $var3) = @_; # right
sub foo { uc $_[0] } # OK
my ($var1, $var2) = (shift, shift); # Um, no.
However, where you will be passing the parameters to another method,
a shift is sometimes appropriate.
sub method1 {
my $self = shift;
$self->method2(@_);
}
>Something that needs to be discussed imho is whether we have constants
>defined with my $CONSTANT = 50 or with use constant CONSTANT => 50. Both
have
>pros and cons, and I never really could make up my mind here.
.... or even
sub CONSTANT { 50; }
particularly for "public" rather than "private" constants.
* Any comments from others on this?
Is there a dependency on the Perl version?
>I'd go against omitting the final semicolon on blocks. That's the surest way
>of coming up with a syntax error the first time you append something.
>Similarly, I'd recommend always finishing array and hash content
declarations
>with a trailing comma.
>
>Also, given the fact that we're using exceptions all over, I'd recommend
that
>methods return an object whenever it is possible so that method calls can be
>chained. Also, all subs should have an explicit return, set to "return;" if
>they really don't return anything.
Please write up proposed (or modified) POD sections if you want these
considered.
>> Method Naming: $obj->methodNameLikeThis();
>
>I was expecting since day 01 that this would be the first debate on this
>list, and it appears that it's shaping up to be that indeed :) I personally
>prefer methodNamesLikeThis because it makes separating methods from
variables
>visually much easier (given variables that use a $var_foo scheme). Something
>tells me that this argument, despite its infinite wisdom, will not suffice
to
>convince everyone ;-) A decision has to be made here however because we
>definitely want to be consistent on this, so if there is strong opposition
to
>the above I think we should vote.
The only reason it was in there is that it was in the Slashcode style guide
like that. I think that weighing reasons is much more important than
voting...
1. the perlstyle man page states "method_names_like_this()"
2. most of modules on CPAN have "method_names_like_this()"
Those reasons +50% of the vocal population on the list is enough to convince
me. We have no voting procedures here yet, but if there are others who
wish to
differ, speak up now!
I have updated the doc to be
Methods and Functions (except for special cases, like AUTOLOAD) begin
with a verb, with words following to complete the action.
Multi-word names should be all lower-case, separated by underscores,
in keeping with the "perlstyle" guide and most of the modules
already on CPAN. They
should as clearly as possible describe the activity to be peformed, and
the data to be returned.
$obj->getStory(); # wrong.
$obj->setStoryByName(); # wrong again.
$obj->getStoryByID(); # wrong again. This isn't Java!
$obj->get_story(); # right.
$obj->set_story_by_name(); # right.
$obj->get_story_by_id(); # right.
Methods and Functions beginning with C<_> are special:
they are not to be used
outside the current file (i.e. "private").
This is not enforced by the code itself,
but by programmer convention only.
Stephen
http://www.officevision.com/pub/p5ee/software/htdocs/P5EE/styleguide.html
