Re: My coding guidelines

[DamnDirtyApe]

in reply to My coding guidelines

I know it's been kicked around the monastery before, but I'd like to know Abigail-II's take on receiving arguments in subs. Do you tend to more towards $x = shift; $y = shift; ..., or ($x, $y) = @_;, or some combination of the two, depending on circumstances?

_______________
DamnDirtyApe

Those who know that they are profound strive for clarity. Those who
would like to seem profound to the crowd strive for obscurity.
            --Friedrich Nietzsche

[vek]

DamnDirtyApe - take a peek at this node of mine for some interesting insight on receiving arguments in subs.

-- vek --

[hakkr]

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.

[hakkr]

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.

[sauoq]

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.";

[Abigail-II]

It depends. Sometimes I use shift, sometimes list assignment. And often I prefer named parameters - sometimes in combination with shifts.

Abigail