As for shifting, yes, most of the time it doesn't make a big difference. If you have fairly meaningless rules (eg indent 4, not 2, using hanging braces, uncuddle your elses) to provide a common look and feel, that is perfectly fine. Look and feel issues affect ease of moving around your code base and consistency reduces bug rates. If cat2014 didn't use shift because of a style rule that she understood to just be a style rule, I would not be bothered. But she had trouble accepting a shift to be OK because she had it drilled in that it was a bad thing to do.

Now that is fine if the argument against - that you are losing track of what is at what index - really is important. But it is bogus. If you are thinking of Perl arrays as something to access by index, most of the time you are doing something wrong. They are things you access in order. Besides which if you write OO methods then the order of your argument list is already off by one. Repeating bogus arguments for meaningless details is bad.

Secondly while style is fairly arbitrary, it is good to not have rules which are not widely shared. The best references that any programmer at that company is likely to encounter all shift. That style is used in the top Perl books. It is used by good CPAN modules. It is used in core Perl modules. It is used by competent posters, in articles, etc. It will be used by most competent consultants, trainers, and hires. Do you really want to make reading all of that good advice a jarring experience? If not then your style should conform to the community.

Thirdly I ran across the argument for not shifting and believed it for a while. I changed my mind. Why you ask? Well I found that very frequently I have a few special arguments that I want to process one way and an arbitrary list I want to do something else with. For instance a wrapper method will grab the object and then for each parameter it will do something. Now yes, you can copy @_ into a few variables and a new temporary array, but why? First of all that copy goes by value not reference so it is more work for Perl. Secondly there are now more mechanics for the programmer to keep track of. Is, or isn't this new array important by virtue of its existence? This happened to me regularly enough that I found it cleaner to always be consistent and grab fixed arguments with shift.

So if I came to a new job and they wanted me to change how I indent, how I use braces, the capitalization style of variables and functions, naming convention, etc I would not object. I can adjust fairly quickly and I know that for those things, within reason, consistency matters far more than exact details. But I would argue if I was told to not use shift to process arguments in Perl. I have tried it both ways and I my experience says that it does make a difference.

You must remember my audience. I was not writting a set of coding standards but explaining my thinking when writting coding standards. I agree completely that the statements I gave were not useful except to expert users but hay that is who I am talking too. We were discussing the merits of a particular standard that requires understanding of the origins of those standards. I feel very strongly that all too often people forget why software is written, it is written to perform a specific task. If the code performs that task then it is a success, if that task requires that the code be extensiable then cool as. The code must be written to be extensiable. If the code is for a one shot task then it does not. That is where the 'and no more so' come from.

I feel that perl exemplifies this idea. It has the capiabilities to allow for write once code that can be quickly written. It also allows for long term maintanable code to be written. As a programmer it is my job to strike a balance between the two.
--

Zigster