http://qs1969.pair.com?node_id=814376


in reply to Re: Help with Coding Style
in thread Help with Coding Style

First of all, i strongly join the people who recommended using Perl::Critic. It is an excellent to improve your style
Actually, using Perl::Critic doesn't help you to improves one style. It will however help you mimic the style of the people in charge of Perl::Critic.
my ($self) = @_; # You should probably write: my ($self) = shift; # Option 1. my ($self) = $_[0]; # Option 2. The two options do a very similar thin +g, choose the one that suits you and make sure you understand what th +ey mean.
I loathe this kind of advice. You give two alternatives to a line, without any explanation of why any of the alternatives are better. I certainly don't see any problem with the first line than any of the alternatives solves.
for (my $i = 1; $i <= $size; $i++) # This is OK, but it is C style, no +t Perl.
It's Perl. Hence, it's Perl style. Just because it looks like C doesn't mean it's bad.
for my $i (1 .. $size) # This is more Perlish and more readable. It's +a matter of taste.
If it's a matter of taste, why recommend one over the other?

Personally, I also look at the body when deciding what kind of loop to use. In this case, I wouldn't use a for statement at all.

$self->{allowed} = [undef, (1) x $size];
I suspect $self->{allowed}[0] is never used, but I didn't look at the code a lot. If it's not used, I wouldn't use the undef in the code above.

Replies are listed 'Best First'.
Re^3: Help with Coding Style
by CountZero (Bishop) on Dec 25, 2009 at 22:06 UTC
    Actually, using Perl::Critic doesn't help you to improves one style. It will however help you mimic the style of the people in charge of Perl::Critic.
    That may be but when the guidelines of Perl::Critic are quite sensible and when there is also the possibility to edit its rules to suit your own style, I find Perl::Critic really quite helpful.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re^3: Help with Coding Style
by amir_e_a (Hermit) on Dec 25, 2009 at 22:18 UTC
    Actually, using Perl::Critic doesn't help you to improves one style. It will however help you mimic the style of the people in charge of Perl::Critic.

    ... Who more or less mimic the style suggested by Damian Conway. Since i started using Perl::Critic, i get from an idea to working bugless code faster. Everyone is free not to use it.

    I loathe this kind of advice. You give two alternatives to a line, without any explanation of why any of the alternatives are better. I certainly don't see any problem with the first line than any of the alternatives solves.

    Writing my ($self) = @_ is not wrong, but it may mean that the coder - who admits to being a novice - is not sure that he knows what it means. I am showing other ways to pass args, TMTOWTDI.

    You may loathe it, but i hope that it encourages people to read documentation. Maybe i'm wrong.

      working bugless code

      You're living in cloud cuckoo land. There's no such thing..


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
      Writing my ($self) = @_ is not wrong, but it may mean that the coder - who admits to being a novice - is not sure that he knows what it means.
      I find that extremely insulting - it's a long time I've seen such an insult in the Perl community. "Oh, you might write a line of code of which nothing is wrong - but I'll presume you're an idiot and you don't understand your own code." And what makes you think he'll understand your two alternatives? Which you give without explanation? I mean, you're assuming the OP doesn't understand the code he wrote himself, how is he to understand your code?

      The Perl community used to be known for insulting newbies making mistakes, but you're way past that. You're insulting a newbie for writing good code.

      Shame on you.