http://qs321.pair.com?node_id=215808


in reply to Re: Re: My coding guidelines
in thread My coding guidelines

Personally I never pass arrays to subs just array references or hashes. This save you from adding extra shifts or assigning extra variables when you add a value to be be passed in. So you don't have to  my $x=$_[0]; my $y=shift;.

The same goes for returning values from subs, returning a list just causes hassle of typing out assignments for each value in the list.

Replies are listed 'Best First'.
Re: Re: Re: Re: My coding guidelines
by hakkr (Chaplain) on Nov 26, 2002 at 10:09 UTC
    In my defence, my guidelines were aimed at novice CGI programmers with many rules dictated by unofficial conventions that are used in our shop. This list is obviously more broadly aimed and as a style guide seems ok. Abigail pointed out my list omitted API/object interface guidelines and object initializators but so does this one:)

    Abigail asked WHY? on two of my points so here are my justifications for them

    '15. Always retrieve database rows into hash reference not arrays'

    because if you have a table with fifty columns then you get an array with fifty elemnets and it can be hard to remember what field element 27 refers to after the array has been shunted about a bit. Also you have to manually map all the elements to the field names whereas with a hash you already have the data labelled with the field names.

    '17. Assign CGI parameters to hashes'

    So you can pass them around easily in one variable and you don't have loads of variables and $q->params flying about.

    I also refute the fact I used any buzzwords. Anyway the more guidelines the better I say, as long as people don't treat them religiously.
[reply]
Re: Re: Re: Re: My coding guidelines
by sauoq (Abbot) on Dec 01, 2002 at 05:36 UTC
    This save you from adding extra shifts or assigning extra variables when you add a value to be be passed in. So you don't have to my $x=$_[0]; my $y=shift;.

    I don't really understand the point you are trying to make with that statement.

    Generally, I prefer my ($x) = @_; and, if a new parameter is later needed, I add it. So that would become my ($x, $y) = @_; when I add the second parameter.¹

    By the way, the code example you gave is in error. It would result in $y containing the same value as $x.

    ¹ Those who saw my other response to Abigail-II in this thread might wonder about my use of whitespace with my ($x) as I indicated that I prefer alternatives to foo ($bar). I treat my, our, and local differently because they are different. They are keywords for declaring scope, they aren't functions.

    -sauoq
"My two cents aren't worth a dime.";
[reply]
[d/l]
[select]

In Section Meditations